-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DM-46556 Add consdb documentation #51
base: main
Are you sure you want to change the base?
Conversation
e9117f0
to
4feb271
Compare
|
||
pip install lsst-felis | ||
|
||
felis validate [options] [edited cdb_*.yml files] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically, this does not check that SQL tables can be created. Rather, the validate
command checks that the schema conforms to Felis's data model. Currently, schemas could pass validation but database creation may still fail. (Additional validation functions are planned to be added in order to rectify this.)
If you want to check that a database can be created, the felis create
command should be used.
Note that the sdm_schemas
checks on PRs will create test databases for all of the schemas in MySQL, PostgreSQL, and SQLite, so it may not be necessary to check this locally. Database creation failures will be caught in CI. (Running the validate
command locally is still a good idea though the CI does this as well.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, shell globs work fine with Felis commands, so this would work to validate all cdb schemas:
cd sdm_schemas && felis validate yml/cdb_*.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes sense to leave those details to the CI and Felis documentation then. I'm updating accordingly.
alembic-autogenerate.py
Outdated
@@ -3,27 +3,28 @@ | |||
# | |||
# How to use this script: | |||
# 1. Load the LSST environment and setup sdm_schemas and felis. | |||
# source loadLSST.bash | |||
# source loadLSST.bash or activate your eups setup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternately, the following should work to install all necessary dependencies for generating the migrations:
pip install lsst-felis testing.postgresql alembic sqlalchemy pyyaml
And sdm_schemas
could then be setup with:
git clone https://github.com/lsst/sdm-schemas
cd sdm_schemas
export SDM_SCHEMAS_DIR=`pwd`
I just verified that the migration script runs okay with the above.
It shouldn't really be necessary to have a full LSST stack available just to run the migrations. (Neitheralembic-automigratte.py
nor the env.py
script depend on any stack software besides felis
and sdm_schemas
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be able to pip install
sdm_schemas itself and use the python package resources to find the schemas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be able to
pip install
sdm_schemas itself and use the python package resources to find the schemas.
That is on the todo list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for verifying your directions above, very helpful!
doc/user-guide/schemas.rst
Outdated
|
||
Think about the utility of these versions in terms of interaction with the ConsDB APIs, migrations, etc. | ||
|
||
Do sdm_schemas versions appear in the db? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The versions are not currently stored in the database, but I plan to add this capability.
See DM-47367
doc/user-guide/schemas.rst
Outdated
Currently the schemas are tagged and versioned as a set, at least w.r.t. the Science Platform. | ||
So once ConsDB is available in TAP, it should be part of that set. | ||
|
||
What do users see, how does TAP play into this, do the schema need this type of micro versioning? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do not currently have any capability to provide individual schema versions via TAP, as TAP_SCHEMA does not include a column providing this information. Users on the Science Platform do not really see any schema versions at all, currently, because the tag on sdm_schemas
is only specified in Phalanx and not propagated to the web UI either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This section was added just to capture the conversation that was happening in reference to schema versioning the other week. Is there still clarification I need to add here, or maybe we need to speak about this at a weekly meeting? Did this happen on 11.11, when I missed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless the procedures change, ConsDB schemas will be deployed to the Science Platform as part of an sdm_schemas release. This version will not be visible to users. This will determine what tables and columns are visible in TAP. We can cut new releases of sdm_schemas to incorporate changes to ConsDB as needed. (The sdm_schemas semver releases used on the Science Platform are made ad hoc/as needed and not on a fixed schedule.)
We will have the capability to deploy different releases of sdm_schemas to different environments if this is required (usdf-rsp
, usdf-rsp-dev
, etc.). But we cannot currently deploy different versions of specific schemas individually. They are versioned as a set.
doc/user-guide/schemas.rst
Outdated
|
||
- or there can be ones that are not neutral. | ||
|
||
Think about the utility of these versions in terms of interaction with the ConsDB APIs, migrations, etc. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would think that a release of the ConsDB API should be connected to a set of compatible schema versions. Would a tag of sdm_schemas
be good enough? We don't currently have a good way of retrieving schemas by their internal versions, so I don't know how useful it would be to have them listed individually. This sdm_schemas
tag could be included as part of the release notes.
I am not sure how this information could be tracked automatically though. Maybe it is just something that needs to be tracked and included manually.
doc/operator-guide/deployment.rst
Outdated
Deployments of the Consolidated Database are currently located at | ||
|
||
- Summit | ||
- USDF (+ dev) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth noting here that (1) USDF and USDF-dev use the same underlying database and (2) that database is a replica of the summit database.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will add a clarification for this.
doc/.DS_Store
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file should be removed and probably added to .gitignore
.
As a general comment, the RST formatting needs work. See cheat sheet here. |
da8576b
to
f4b66f1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left some specific suggestions for changes.
Overall, I'm wondering why all the additional content is being added that doesn't have to do with the deployment process. I would think going forward that it would be better to stick more closely to the issue a ticket is intended to solve in updating the documentation, rather than including a bunch of different updates that are not closely related. (I'm not requesting that these changes be removed this time, though.)
alembic-autogenerate.py
Outdated
# setup felis | ||
# setup -r /path/to/sdm_schemas | ||
# 1. Install Felis and sdm_schemas, set environment variables: | ||
# pip install lsst-felis testing.postgresql alembic sqlalchemy pyyaml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to be missing a few dependencies. What I found worked from scratch was:
pip install lsst-felis testing.postgresql alembic sqlalchemy pyyaml black psycopg2-binary
alembic-autogenerate.py
Outdated
# python alembic-autogenerate.py this is my revision message "\n" \ | ||
# the message can span multiple lines "\n" \ | ||
# if desired | ||
# python alembic-autogenerate.py DM-12345 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know that we have "officially" determined that ticket names will be used in migrations. Maybe it needs to be discussed in the meeting first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did we officially decide something? it wasn't super clear to me from the recording
|
||
Process: | ||
-------- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this section have content if the PR is for adding deployment process documentation?
@@ -2,8 +2,118 @@ | |||
Schema Migration Process |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bullets also overused in this section. I would remove most of them and just write it as prose.
* Near-real-time "prompt" ConsDB replicates a subset of the USDF version | ||
* Data Release ConsDB is a snapshot of a subset of the USDF version with data pertaining to the exposures/visits in the DR | ||
* Schema browser | ||
Types of schemas |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rewrite the bullets below as complete sentences.
@Vebop Additional note: If you want to make various changes/updates across the whole documentation site, I do not feel that this needs to be connected to a ticket. I think it would be reasonable to do this on user branches. Tickets can be used for more focused/specific work. Unless you want to create and use a generic ticket like "Write consdb documentation site." :) |
|
||
#consolidated-database | ||
|
||
Overall complaints: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems somewhat terse and could use more explanation. Is the idea that someone would open a ticket and assign it to a certain individual based on the specific sub-component?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I copied this from the linked runbook, so I'm actually not sure.
https://rubinobs.atlassian.net/wiki/spaces/LSSTOps/pages/45665320/Consolidated+Database+ConsDB+Runbook+draft+incomplete
Create an Alembic Migration (manually) | ||
====================================== | ||
|
||
- Alembic (https://alembic.sqlalchemy.org/en/latest/front.html) keeps track of versioning by autogenerated migrations to sync the test stands and summit databases. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make "Alembic" a proper link to the website.
- Access to argo-cd deployments is available via the Summit OpenVPN. | ||
- To coordinate your deployment update on the summit, you must attend Coordination Activities Planning (CAP) meeting on Tuesday mornings and announce your request. | ||
|
||
- Add it to the agenda here: https://rubinobs.atlassian.net/wiki/spaces/LSSTCOM/pages/53765933/Agenda+Items+for+Future+CAP+Meetings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Link
- The CAP members may tell you a time frame that is acceptable for you to perform these changes. | ||
|
||
- They may also tell you specific people to coordinate with to help you take images to test LATISS and LSSTCOMCAMSIM tables. There will be more tables to test eventually. | ||
- Channels to note: #rubinobs-test-planning; #summit-announce; #summit-auxtel, https://obs-ops.lsst.io/Communications/slack-channel-usage.html. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Link
@Vebop Another general comment... There is a mix of URLs and linking styles in this PR, some of which do not work. Links should be consistently formatted like this in RST:
We should avoid raw URLs and use the above format instead. |
828d909
to
d6c9f8f
Compare
Added Deployment process documentation to Schema Migration Process in the operator guide.
Added other small documentation, like schema versioning conversation, and monitoring notes.
Most recent build of docs: https://consdb.lsst.io/builds/105