Open Stack

Hi all,

As our midcycle is virtual and split into 6 "sessions" for the sake of
timezones, we'll be sending a brief summary of each session so that
folks can catch up before the next one. All of this info should be on
the etherpad as well.

Session 2/6 was February 17, 1500-2000 UTC.

* Discussed boot-from-volume things
  * This is something we'd like to start working on in Newton, though
    depending on priority it may be an Otaca thing.
  * Would like to ship a reference implementation first as the "base
    case"; this would support a deployment where all of the below are
    true:
    * Deployment has metadata service (configdrive not supported)
    * Deployment does not require local boot (in other words, this will
      only support booting the instance via iPXE)
    * Hardware supports iPXE
    * Hardware supports the UEFI 2.4 spec
  * Once that ships, vendors are free to use vendor-specific features to
    provide a better experience
  * TheJulia will be writing a spec for this reference implementation
  * Talked about how we might get a configdrive to the instance
    * Some hardware may support it via virtualmedia
    * Some hardware may support it via a second volume
    * ironic-conductor could mount the volume and carve out a
      configdrive partition. This has implications on network and
      customer data security, cannot be used with encrypted volumes, and
      could break an image that doesn't have sufficient space at the
      end.

* Discussed the node filter/claims API work
  * Claims API should accept a list of node uuids and a count <= len(uuids)
  * Talked about whether claims need to happen in the conductor
    * Depends on outcome of live upgrades discussion, which has been
      thought to require that only the conductor interact with the DB.
      * This discussion may happen tomorrow, or we may wait for the
        summit.
  * Talked about making filter API performant, which depends on being
    able to index properties and capabilites (currently JSON fields).
  * Break those out into a key/value table.
  * These currently have no length restriction, meaning MySQL cannot
    index the full value.
  * Postgres does not support prefix indices, which would solve that for
    MySQL.
  * We can't/shouldn't break users by suddenly restricting the length of
    the values for these fields.
  * Current plan:
    * Break cpus, ram, local_gb properties into dedicated columns in the
      node table, such that operations like < or > can be used.
    * All other fields are in a key/value table and only support exact
      matching.
    * This key/value table will have a third column which is a hash of
      the data; this will be indexed and used for filtering.

* Discussed ongoing grenade work
  * jlvillal has made progress on that, though it still isn't working
  * There's a thought that running REGEX=ironic tests, rather than all
    smoke tests may help; yet to be verified.
  * Work to allow more ironic nodes in the gate may help; some of the
    smoke failures seem to be due to booting too many things at once.
  * jlvillal warmly welcomes help with this :)

* Dogpiled on reviewing the manual cleaning patches
  * Landed 2/4 patches, and updated the remaining two. These need
  * further reviews and updates. Remaining patches are:
    * https://review.openstack.org/#/c/264266/
    * https://review.openstack.org/#/c/258694/

Thanks to all participants for another great session! :)

// jim