Open Stack

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160428/31393780/attachment.pgp>