<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.apple-tab-span
        {mso-style-name:apple-tab-span;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:Calibri;
        color:windowtext;}
span.msoIns
        {mso-style-type:export-only;
        mso-style-name:"";
        text-decoration:underline;
        color:teal;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">Thanks Mathieu, that is a great summary! It is much easier than trying to figure that out from the etherpad [1] notes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">--ruby<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri">[1] https://etherpad.openstack.org/p/ironic-newton-midcycle<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:Calibri"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal">On 2016-06-23, 3:08 PM, "Mathieu Mitchell" <<a href="mailto:mmitchell@internap.com">mmitchell@internap.com</a>> wrote:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0cm 0cm 0cm 4.0pt;margin-left:3.75pt;margin-right:0cm" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<div>
<p class="MsoNormal">Dear group,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Please enjoy this midcycle sprint summary. You might have to put your
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Markdown glasses on for proper formatting :)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The midcycle sprint lasted three days. It was virtually held over
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Infra's conference system and IRC. The event was split in two different
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">time slots. The first slot, from 15:00 to 20:00 UTC, was by far the most
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">popular. A lot of topics were covered by the participants. The second
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">slot, from 00:00 to 04:00 UTC, was much less popular, having a whooping
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">peak participant count of four.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">June 20 2016 15:00 to 20:00 UTC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Most of the group was present for this session. Missing were Devananda
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">van der Veen (devananda) and Jay Faulkner (JayF). We decided to create
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">an agenda for the upcoming sessions and reserve topics of interest to
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">our missing members for the days where they would be present. Also,
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ukraine was observing a national holiday, so some of our Ukrainian
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">members were absent, too.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The session started with an overview of our Newton priorities. This was
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">done using the new Ironic Newton Priorities Trello board [1].<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://trello.com/b/ROTxmGIc/ironic-newton-priorities">
https://trello.com/b/ROTxmGIc/ironic-newton-priorities</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Ironic-Neutron integration<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The first topic to be covered was the Ironic-Neutron integration. At the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">time of discussing that topic, most patches needed rebasing. However,
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the group still agreed on the following game plan:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">   * Merge the devstack parts ASAP<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Split portgroups support to the end of the patch chain so they can
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">merge later. (done: Vladyslav Drok (vdrok) quickly posted a new revision
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">for [1] and created [2]).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Merge everything but portgroups in server-side Ironic<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Merge client patches in<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Merge "Ironic: change flat network provider to 'flat'" in nova [3]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Finish portgroups<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Merge "Replace vif_portgroup_id with vif_port_id" [4] (merged
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">already, thanks Dmitry)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/206244/">https://review.openstack.org/#/c/206244/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://review.openstack.org/#/c/332177/">https://review.openstack.org/#/c/332177/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[3] <a href="https://review.openstack.org/#/c/297895/">https://review.openstack.org/#/c/297895/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[4] <a href="https://review.openstack.org/#/c/325197/">https://review.openstack.org/#/c/325197/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Security groups for Bare metal deployments<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Sukhdev Singh (Sukhdev) reports that full security group support will be
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">available for bare metal deployments by leveraging the Neutron integration.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> There is minor work that is needed in the Ironic driver. Most of the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ML2 drivers already know how to deal with Security Groups. Hence, this
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">becomes a slam dunk - huge reward with little work.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Future networking work<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Up for review is the spec for VLAN-aware baremetal instances [1] by Sam
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Betts (sambetts). It has received comments and a few reviews, but more
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">eyes would help get this through :)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Attach and detach are becoming first class citizens [2] and will be
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">defined in network drivers, allowing for different vendors to implement
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">their own logic. This will also support post-boot network attach/detach.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Also, keep an eye open for network-aware scheduling in Nova.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/277853/">https://review.openstack.org/#/c/277853/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://review.openstack.org/#/c/317636/">https://review.openstack.org/#/c/317636/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Driver composition<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Big topic that has been in progress for officially more than a year
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(first patch set is dated June 4th, 2015!). We are finally reaching
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">consensus. Most people are okay with the spec, the only pain point was
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">using the `driver` vs `hardware_type` field. Since hardware_type was
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">introduced before dynamic driver had default interfaces, most of the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">group agreed to dropping it and simply keeping the `driver` field.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Dmitry Tantsur (dtantsur) quickly posted a few new patch sets and the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">spec [1] is currently awaiting workflow.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/188370/">https://review.openstack.org/#/c/188370/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Serial console spec<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Up for review is the Nova-compatible serial console support [1]. The
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">group had a few questions but none of the authors were present in the room.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">One interesting question was whether this should depend on the driver
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">composition spec. The answer was that, given the limited scope of the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">serial console in current deployments, simply one or two new drivers
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">could be added to the matrix, instead of duplicating all current
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">drivers, preventing this from requiring the driver composition.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Everyone interested posted questions directly in the review for the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">authors to answer. Another point of interest was the full path to the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">socat binary, and the code behaving differently based finding "socat" in
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">said string.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/319505/">https://review.openstack.org/#/c/319505/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">June 21 2016 00:00 to 04:00 UTC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A small number of participants assisted the session.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">An informal discussion took place and the following topics were discussed:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* Merge conflicts and their cause<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Feature enabling<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* v2 API<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Multi-node devstack deployments<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The session ended early at 01:20 UTC.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">June 21 2016 15:00 to 20:00 UTC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Versioning the ironic-python-agent API<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Our first topic of the day was IPA API versioning. It was agreed that
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ironic should work with N-1 and N+1 versions of IPA. The introduction of
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">a specific API version between ironic and ironic-python-agent would
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">allow us to assert that rolling upgrades are possible between
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ironic-conductor and ironic-python-agent.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The action items are as follow:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* Sam Betts (sambetts) will submit a spec to version the IPA API.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Current version will probably be called 1.0<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * IPA will send it's API version during the lookup<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Ironic will use the stored API version to gracefully degrade features<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* A new src job for IPA will be added to test IPA master against N-1 ironic<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### RAID during deployment<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Dimtry led the discussion on our second topic of the day, building RAID
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">during deployment. Ironic currently supports configuring RAID during
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">manual clean steps, but operators are asking for just-in-time (JIT) RAID
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">configuration during image deployment. The main argument is to prevent
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">having to maintain different pools of the same hardware configured
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">differently.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The following action items were held:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* Mathieu Mitchell (mat128) and Dmitry Tantsur (dtantsur) to submit an
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Ironic spec<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Implement "deploy_steps" for JIT hardware configuration<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Implement RAID steps in different drivers<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * Will only have one entry point for RAID configuration<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * RAID level declared in target_raid_config should be applied during
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">deploy_steps<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   <span class="apple-tab-span">     </span>* This will handle already configured RAID correctly<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Nova <> Ironic interaction to be defined<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Michael Davies (mrda) to check with Nova developers that extra_specs
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">path is ok by them<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Software RAID (mdraid) in IPA<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Following the just-in-time RAID configuration is an RFE for software
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">RAID support [1].<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Action items:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* David Lenwell (davidlenwell) and Mathieu Mitchell (mat128) to update
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the current spec<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Write an mdraid hardware manager<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://bugs.launchpad.net/ironic/+bug/1590749">
https://bugs.launchpad.net/ironic/+bug/1590749</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Volume connection information spec / Boot from volume<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Julia Kreger presented the volume connection information spec [1] and
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">the group agreed to merge it. That review had been up for almost a year
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(July 10, 2015). Good job to everyone involved :) One more brick in that
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">boot from volume wall.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Next in that topic was the boot from volume spec itself [2]. It received
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">attention and a few comments. Those who have not read it yet should give
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">it a look.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/200496/">https://review.openstack.org/#/c/200496/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://review.openstack.org/#/c/294995/">https://review.openstack.org/#/c/294995/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">June 22 2016 00:00 to 04:00 UTC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Again, much less popular time slot for the group. This time, bug triage
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">was the hot topic. We pretty much sorted through all `new` ironic bugs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">June 22 2016 15:00 to 20:00 UTC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### Soft power / NMI<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Up for review is the soft power off and NMI injection spec [1]. The
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">group wanted to reach consensus on which (power or management) NMI
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">injection should belong to.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Devananda explained very well the reasoning as comments in the review.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What we agreed on:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* Spec author will<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * address comments in the spec<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">   * move NMI to management interface<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/186700">https://review.openstack.org/186700</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### v2 API<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The group wanted to discuss what would be required to move to a v2 api.
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Much of this topic is copied in bulk from etherpad as I did not want to
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">leave any comment out of the summary.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We agreed on the following:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* A subteam will be created (led by Jim Rollenhagen)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* This subteam will have a weekly sync up. It will begin week of July 11
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">(Jim Rollenhagen)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* We will ask the API working group if they want to help (Jim Rollenhagen)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* We will following the API working group guidelines as much as possible<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Submit a spec before the Barcelona summit that covers:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* Architectural goals of the new API<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* Current API pain points, and how the new API will address these<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* Implementation roadmap and release plan (how we'll develop it, how
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">we'll support running both in parallel, when/whether we'll consider
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">deprecating v1, etc)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* This spec will NOT attempt to cover specific implementation of the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">new API<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* Begin POC after that (stretch goal: before if someone really has time)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### client version negotiation<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">> Our client currently defaults to version 1.9 and does not negociate
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">in a normal use case. Because a user must currently explicitly ask for a
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">newer API version to get any newer features, even when using both a
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">newer client and a newer server! And even when the newer client
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">advertises those things on the command line --help output!! This is a
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">very poor user experience.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It was suggested to allow automatic version negotiation up to the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">highest commonly supported version.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* Deva to update the existing version negotiation spec [1]<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Michael to review and assist<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/305540/">https://review.openstack.org/#/c/305540/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">### keystone policy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Keystone now supports policy-in-code which allows services to declare
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">policy defaults in code. Devananda paired up with a member of the
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Keystone community and Jay Faulkner sent a work in progress spec,
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">available at [1]. Preliminary code implementation is available in two
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">reviews [2][3].<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We also discussed the future related work and the following subjects
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">were discussed:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* Enhance access control by associating all resources to a user's request<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* Nova instance<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* Neutron network and ports<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span class="apple-tab-span">        </span>* Ironic node and ports<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Passing user token to each service, rather than using admin or service
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">tokens for normal operation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Keystone Trusts could help us with this. Heat has solved this problem
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">as well.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Swift interactions<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* Providing the agent a user/token limited to specific actions, like
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">lookup and heartbeat.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Action items:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">* Deva to research Policy in Code<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">* JayF to write spec on policy<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">[1] <a href="https://review.openstack.org/#/c/327437/">https://review.openstack.org/#/c/327437/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[2] <a href="https://review.openstack.org/#/c/325672/">https://review.openstack.org/#/c/325672/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">[3] <a href="https://review.openstack.org/#/c/325599/">https://review.openstack.org/#/c/325599/</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">June 23 2016 00:00 to 04:00 UTC<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-------------------------------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Audio quality issues inhibited communication.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Session ended at 00:18 UTC.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Conclusion<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">----------<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A big thanks to everyone who assisted this midcycle. It really served
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">it's purpose and we are very happy with the results.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Mathieu Mitchell<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">__________________________________________________________________________<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">OpenStack Development Mailing List (not for usage questions)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</body>
</html>