[openstack-dev] [ironic] Midcycle summary part 3/6
jim at jimrollenhagen.com
Thu Feb 18 03:18:44 UTC 2016
On Wed, Feb 17, 2016 at 12:14:29PM -0800, Jim Rollenhagen wrote:
> 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.
Slight correction: this was session 3/6.
> * 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
> * 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
> * 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
> * 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
> * 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
> * 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev