Open Stack

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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev