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" <mmitch...@internap.com<mailto:mmitch...@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-requ...@lists.openstack.org<mailto: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