Open Stack

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