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 > 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 > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev