Open Stack

Thanks Mathieu, that is a great summary! It is much easier than trying to figure that out from the etherpad [1] notes.

--ruby

[1] https://etherpad.openstack.org/p/ironic-newton-midcycle



On 2016-06-23, 3:08 PM, "Mathieu Mitchell" <mmitchell at internap.com<mailto:mmitchell at internap.com>> wrote:

Dear group,

Please enjoy this midcycle sprint summary. You might have to put your
Markdown glasses on for proper formatting :)


The midcycle sprint lasted three days. It was virtually held over
Infra's conference system and IRC. The event was split in two different
time slots. The first slot, from 15:00 to 20:00 UTC, was by far the most
popular. A lot of topics were covered by the participants. The second
slot, from 00:00 to 04:00 UTC, was much less popular, having a whooping
peak participant count of four.


June 20 2016 15:00 to 20:00 UTC
-------------------------------

Most of the group was present for this session. Missing were Devananda
van der Veen (devananda) and Jay Faulkner (JayF). We decided to create
an agenda for the upcoming sessions and reserve topics of interest to
our missing members for the days where they would be present. Also,
Ukraine was observing a national holiday, so some of our Ukrainian
members were absent, too.

The session started with an overview of our Newton priorities. This was
done using the new Ironic Newton Priorities Trello board [1].

[1] https://trello.com/b/ROTxmGIc/ironic-newton-priorities


### Ironic-Neutron integration

The first topic to be covered was the Ironic-Neutron integration. At the
time of discussing that topic, most patches needed rebasing. However,
the group still agreed on the following game plan:

   * Merge the devstack parts ASAP
   * Split portgroups support to the end of the patch chain so they can
merge later. (done: Vladyslav Drok (vdrok) quickly posted a new revision
for [1] and created [2]).
   * Merge everything but portgroups in server-side Ironic
   * Merge client patches in
   * Merge "Ironic: change flat network provider to 'flat'" in nova [3]
   * Finish portgroups
   * Merge "Replace vif_portgroup_id with vif_port_id" [4] (merged
already, thanks Dmitry)

[1] https://review.openstack.org/#/c/206244/
[2] https://review.openstack.org/#/c/332177/
[3] https://review.openstack.org/#/c/297895/
[4] https://review.openstack.org/#/c/325197/


### Security groups for Bare metal deployments

Sukhdev Singh (Sukhdev) reports that full security group support will be
available for bare metal deployments by leveraging the Neutron integration.

> There is minor work that is needed in the Ironic driver. Most of the
ML2 drivers already know how to deal with Security Groups. Hence, this
becomes a slam dunk - huge reward with little work.


### Future networking work

Up for review is the spec for VLAN-aware baremetal instances [1] by Sam
Betts (sambetts). It has received comments and a few reviews, but more
eyes would help get this through :)

Attach and detach are becoming first class citizens [2] and will be
defined in network drivers, allowing for different vendors to implement
their own logic. This will also support post-boot network attach/detach.
Also, keep an eye open for network-aware scheduling in Nova.

[1] https://review.openstack.org/#/c/277853/
[2] https://review.openstack.org/#/c/317636/


### Driver composition

Big topic that has been in progress for officially more than a year
(first patch set is dated June 4th, 2015!). We are finally reaching
consensus. Most people are okay with the spec, the only pain point was
using the `driver` vs `hardware_type` field. Since hardware_type was
introduced before dynamic driver had default interfaces, most of the
group agreed to dropping it and simply keeping the `driver` field.

Dmitry Tantsur (dtantsur) quickly posted a few new patch sets and the
spec [1] is currently awaiting workflow.

[1] https://review.openstack.org/#/c/188370/


### Serial console spec

Up for review is the Nova-compatible serial console support [1]. The
group had a few questions but none of the authors were present in the room.

One interesting question was whether this should depend on the driver
composition spec. The answer was that, given the limited scope of the
serial console in current deployments, simply one or two new drivers
could be added to the matrix, instead of duplicating all current
drivers, preventing this from requiring the driver composition.

Everyone interested posted questions directly in the review for the
authors to answer. Another point of interest was the full path to the
socat binary, and the code behaving differently based finding "socat" in
said string.

[1] https://review.openstack.org/#/c/319505/


June 21 2016 00:00 to 04:00 UTC
-------------------------------

A small number of participants assisted the session.

An informal discussion took place and the following topics were discussed:

* Merge conflicts and their cause
* Feature enabling
* v2 API
* Multi-node devstack deployments

The session ended early at 01:20 UTC.


June 21 2016 15:00 to 20:00 UTC
-------------------------------

### Versioning the ironic-python-agent API

Our first topic of the day was IPA API versioning. It was agreed that
Ironic should work with N-1 and N+1 versions of IPA. The introduction of
a specific API version between ironic and ironic-python-agent would
allow us to assert that rolling upgrades are possible between
ironic-conductor and ironic-python-agent.

The action items are as follow:

* Sam Betts (sambetts) will submit a spec to version the IPA API.
   * Current version will probably be called 1.0
   * IPA will send it's API version during the lookup
   * Ironic will use the stored API version to gracefully degrade features
* A new src job for IPA will be added to test IPA master against N-1 ironic


### RAID during deployment

Dimtry led the discussion on our second topic of the day, building RAID
during deployment. Ironic currently supports configuring RAID during
manual clean steps, but operators are asking for just-in-time (JIT) RAID
configuration during image deployment. The main argument is to prevent
having to maintain different pools of the same hardware configured
differently.

The following action items were held:

* Mathieu Mitchell (mat128) and Dmitry Tantsur (dtantsur) to submit an
Ironic spec
   * Implement "deploy_steps" for JIT hardware configuration
   * Implement RAID steps in different drivers
   * Will only have one entry point for RAID configuration
   * RAID level declared in target_raid_config should be applied during
deploy_steps
        * This will handle already configured RAID correctly
* Nova <> Ironic interaction to be defined
* Michael Davies (mrda) to check with Nova developers that extra_specs
path is ok by them


### Software RAID (mdraid) in IPA

Following the just-in-time RAID configuration is an RFE for software
RAID support [1].

Action items:

* David Lenwell (davidlenwell) and Mathieu Mitchell (mat128) to update
the current spec
* Write an mdraid hardware manager

[1] https://bugs.launchpad.net/ironic/+bug/1590749


### Volume connection information spec / Boot from volume

Julia Kreger presented the volume connection information spec [1] and
the group agreed to merge it. That review had been up for almost a year
(July 10, 2015). Good job to everyone involved :) One more brick in that
boot from volume wall.

Next in that topic was the boot from volume spec itself [2]. It received
attention and a few comments. Those who have not read it yet should give
it a look.

[1] https://review.openstack.org/#/c/200496/
[2] https://review.openstack.org/#/c/294995/


June 22 2016 00:00 to 04:00 UTC
-------------------------------

Again, much less popular time slot for the group. This time, bug triage
was the hot topic. We pretty much sorted through all `new` ironic bugs.


June 22 2016 15:00 to 20:00 UTC
-------------------------------

### Soft power / NMI

Up for review is the soft power off and NMI injection spec [1]. The
group wanted to reach consensus on which (power or management) NMI
injection should belong to.

Devananda explained very well the reasoning as comments in the review.

What we agreed on:

* Spec author will
   * address comments in the spec
   * move NMI to management interface

[1] https://review.openstack.org/186700


### v2 API

The group wanted to discuss what would be required to move to a v2 api.
Much of this topic is copied in bulk from etherpad as I did not want to
leave any comment out of the summary.

We agreed on the following:

* A subteam will be created (led by Jim Rollenhagen)
* This subteam will have a weekly sync up. It will begin week of July 11
(Jim Rollenhagen)
* We will ask the API working group if they want to help (Jim Rollenhagen)
* We will following the API working group guidelines as much as possible
* Submit a spec before the Barcelona summit that covers:
        * Architectural goals of the new API
        * Current API pain points, and how the new API will address these
        * Implementation roadmap and release plan (how we'll develop it, how
we'll support running both in parallel, when/whether we'll consider
deprecating v1, etc)
        * This spec will NOT attempt to cover specific implementation of the
new API
        * Begin POC after that (stretch goal: before if someone really has time)


### client version negotiation

> Our client currently defaults to version 1.9 and does not negociate
in a normal use case. Because a user must currently explicitly ask for a
newer API version to get any newer features, even when using both a
newer client and a newer server! And even when the newer client
advertises those things on the command line --help output!! This is a
very poor user experience.

It was suggested to allow automatic version negotiation up to the
highest commonly supported version.

* Deva to update the existing version negotiation spec [1]
* Michael to review and assist

[1] https://review.openstack.org/#/c/305540/


### keystone policy

Keystone now supports policy-in-code which allows services to declare
policy defaults in code. Devananda paired up with a member of the
Keystone community and Jay Faulkner sent a work in progress spec,
available at [1]. Preliminary code implementation is available in two
reviews [2][3].

We also discussed the future related work and the following subjects
were discussed:

* Enhance access control by associating all resources to a user's request
        * Nova instance
        * Neutron network and ports
        * Ironic node and ports
* Passing user token to each service, rather than using admin or service
tokens for normal operation.
* Keystone Trusts could help us with this. Heat has solved this problem
as well.
* Swift interactions
* Providing the agent a user/token limited to specific actions, like
lookup and heartbeat.

Action items:

* Deva to research Policy in Code
* JayF to write spec on policy

[1] https://review.openstack.org/#/c/327437/
[2] https://review.openstack.org/#/c/325672/
[3] https://review.openstack.org/#/c/325599/


June 23 2016 00:00 to 04:00 UTC
-------------------------------

Audio quality issues inhibited communication.

Session ended at 00:18 UTC.


Conclusion
----------

A big thanks to everyone who assisted this midcycle. It really served
it's purpose and we are very happy with the results.


Mathieu Mitchell

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160627/b6ddda8f/attachment.html>