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 __________________________________________________________________________ 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