Here are my notes from the first two days of the Trove design summit sessions. I will send another tomorrow after we finish the contributor meetup.
Action items will follow tomorrow. Thanks, -amrith Python3 support - make python34 a voting test in the gate (was already done, so no action required) - peterstac to ensure that trove-dashboard is python3 enabled and enable python34 gate changes in trove-dashboard Multiple datastores with a single manager etherpad: trove-newton-summit-multiple-datastores - needs more discussion Management client and openstack client - add quota support through the management client (for now). this is trove-manage; add the ability to do quota management through trove-manage Trove upgrades etherpad: trove-newton-summit-trove-upgrades spec: https://review.openstack.org/#/c/302416/ - the team was in agreement with the proposal that has been up for review. - pete mackinnon had a specific request that some thought and research be put into the area of how nova rebuild may fail, and how a user would have to recover from this. Extend backend persistent storage etherpad: trove-newton-summit-extensible-backend-storage spec: https://review.openstack.org/#/c/302952/ - the team was in agreement with the proposal that has been up for review. - need to investigate supporting replicated volumes for DR and restoring a new database instance from a volume replica. This workflow is not currently possible. Trove container support etherpad: trove-newton-summit-container spec: https://review.openstack.org/307883 - rather than having trove integrate with magnum, we agreed that in the short term we would provide containers through the nova lxc or lxd drivers - the spec will need to be rewritten to reflect this, and to identify the work involved in doing that - in the future, trove will have to realize how it will deal with clouds where this solution would not work. for example, clouds that run kubernetes on native bare metal and don't have nova. Snapshot as a backup strategy etherpad: trove-newton-summit-snapshot-as-a-backup-strategy spec: https://review.openstack.org/#/c/306620/ - the team was in agreement with the proposal that was up for review, in principle. some changes are required such as to deal with quiescing the database. - there was discussion of whether the operation of taking the snapshot would be taken by the guest agent or the task manager and the consensus was that the task manager should be the one generating the snapshot. - it was recommended that the task manager should make a synchronous call to the task manager to quiesce the database, and to release it after the snapshot was taken. this would avoid the asynchronous mechanism based on cast(). - there are two operations here that could cause an interruption in service of the database and these relate to the period of time when the database is quiesced. it is possible that the operation to quiesce the database may take a while to happen (for example if there is a long running transaction going on). this could cause the call() from the task manager to timeout. Similarly once the database is quiesced, the snapshot may take a while. It was suggested that there should be mechanisms to place limits on how long either of these can take. - it should be configurable to determine where the snapshot will get stored; if we have to actually stream it somewhere. this is not necessarily the case for all storage solutions. - point in time rollback is not a deliverable of this project. Make it easier to build guest images etherpad: trove-newton-summit-easier-to-build-images spec: https://review.openstack.org/#/c/295274/ - the consensus was that we should create a new repository (named something like trove-image-builder) and pick up all the elements from trove-integration and move them here - we need to write a new element to install the guestagent code into the image - we need to write a image-builder script that would do the moral equivalent of redstack build-image - that script/tool should allow for creation of both development/testing images and images that a customer could use. - [amrith] to send a note to the ML with the [dib] in the subject line and keep the dib folks informed if there are real problems that we face with the tool - pete mackinnon will be working to update and provide elements with dib that will generate database images for some databases and operating system (CentOS 7) - there was no consensus on whether the future should be dib based or libvirt-customize based - there was a concern that if we ended up with a different tool in the future, there would end up being duplication and redundancy in the image-builder tool - once we get the elements out of trove-integration, if there's not much left there we can move it to the trove project and get rid of trove-integration altogether. Trove V2 API etherpad: trove-newton-summit-v2-api - need to review and think about this some more - would like more details and feel that this spec needs to be fleshed out some more; for example what will the REST api look like Modularity guest image and agent etherpad: trove-newton-summit-modularity-guest-image - needs more investigation and come up with a more concrete proposal. Self signed certificates for Trove etherpad: trove-newton-summit-ssl-self-signed-certificates Baking self signed certificates onto the image is a non-starter. Using cloud-init and sending down files at nova boot time is one thing, but there is no such API on rebuild. Therefore an upgrade of an instance could lose the CA Certificate. If there is a multi-region deployment of Trove, access to RabbitMQ is a challenge anyway and therefore we have to keep that in mind in handling the certificates. Superconductor etherpad: trove-newton-summit-superconductor - the objective is to get rid of the guest agent on the guest instance - the sense is that we want to lose the backup and restore capability as we have it today. We don't necessarily need the swift client to be on the guest, we could directly hit the REST endpoint. - we need to understand better how we will deal with the tracking of instance/database state. with the guest agent, there is a heartbeat from the guest which the conductor logs into the database. how do we want to do this with the superconductor. - this has implications, for example, with the performance of trove list. It would have to go and physically poll every instance if we don't cache state in a database. - the consensus was that we'd write a spec for this and move this forward. currently this will be done by Nikhil, Flavio, Pete and Amrith.
signature.asc
Description: This is a digitally signed message part
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
