<div dir="ltr">Hi Devananda, <div><br></div><div>This is a good summary. I think the proposal makes a lot of sense. </div><div><br></div><div>We need to agree to this as soon as possible so that we can get the Ironic patches merged by this Friday - to meet the timelines. </div><div><br></div><div>Can you set up the number for the voice call so that we can all dial in, discuss, if further discussion is needed, and get this closed off. </div><div>Ideally, we can work to approve/modify the patches while we are all on the call. </div><div><br></div><div>thoughts? </div><div><br></div><div>-Sukhdev</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 11, 2016 at 3:03 PM, Sam Betts (sambetts) <span dir="ltr"><<a href="mailto:sambetts@cisco.com" target="_blank">sambetts@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for following up with this Devananda, I¹ve left a couple of<br>
corrections to my proposal inline, unfortunately IRC isn¹t the best for<br>
putting ideas this complex across :)<br>
<br>
Sam<br>
<br>
On 11/07/2016 21:57, "Devananda van der Veen" <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>><br>
wrote:<br>
<div><div class="h5"><br>
>We spent the majority of today's weekly IRC meeting [1] discussing the<br>
>finer<br>
>points of this question. I agreed to post a summary of those to the list<br>
>(it's<br>
>below the break).<br>
><br>
>tldr;<br>
><br>
>* we don't know if network_interface should behave like other hardware<br>
>interfaces, but...<br>
>* we need to come to an agreement on it this week, so we can proceed with<br>
>the<br>
>network integration work.<br>
><br>
><br>
>Background:<br>
><br>
>- As proposed in the driver composition reform spec [2], each<br>
>hardware_type<br>
>class (eg, ilo_gen8) shall specify a set of allowable interface<br>
>implementations<br>
>(eg, noop, flat, neutron are all network_interfaces) for each interface<br>
>type<br>
>(eg, deploy_interface, power_interface, network_interface).<br>
>- A hardware_type shall also indicate a default for each interface_type.<br>
>(**<br>
>this is what we debated ** )<br>
>- There is no CONF option to specify a global default for each<br>
>interface_type<br>
>(eg, there is no CONF.default_power_interface setting, because it varies<br>
>by<br>
>hardware_type)<br>
>- There will be a CONF option to enable ("allow") hardware classes and<br>
>CONF<br>
>options to enable ("allow") interface classes.<br>
><br>
><br>
>Points raised in the meeting today:<br>
><br>
>- in "most" cases, network_interface will depend more on the environment<br>
>than a<br>
>specific Node's hardware or out-of-band management device<br>
><br>
>- in "exceptional" cases, a Node may only support specific<br>
>network_interfaces<br>
>(eg, certain Cisco hardware, a Blade enclosure)<br>
><br>
>- maybe hardware_type should specify a default for some interfaces but not<br>
>others? Example:<br>
>  - the ilo_gen8 hardware class should specify power, deploy, and<br>
>management<br>
>interface defaults to ilo-specific interface classes<br>
>  - but the operator should set the network interface as appropriate to<br>
>their<br>
>environment<br>
><br>
>- if we were to force the operator to specify Node.network_interface (but<br>
>not<br>
>any other interface) when enrolling every node, this will be apoor<br>
>experience.<br>
><br>
>- we should add a global CONF setting to allow operators to set a default<br>
>network interface for their environment.<br>
><br>
>- words are hard. we shouldn't call network_interface an "interface" if it<br>
>behaves differently than other interfaces.<br>
><br>
>- we have two "types" of interfaces on drivers: hardware-types and<br>
>environment-types. maybe we should treat them differently?<br>
><br>
>- other things also depend on the environment (rather than the Node's<br>
>hardware<br>
>or BMC) such as deploy_interface and volume_interface.<br>
><br>
><br>
>There was a proposal from sambetts towards the end of the meeting, which<br>
>I've<br>
>edited for clarity (please correct if I misunderstood any of your<br>
>points). This<br>
>seems to capture/address most of the points above and proposes a way<br>
>forward,<br>
>while keeping within the intent of our driver composition reform spec. It<br>
>was<br>
>the only clear suggestion during the meeting.<br>
><br>
>- in-tree hardware_types declare supported_network_interfaces to be empty<br>
>[4]<br>
>and declare no default_network_interface<br>
<br>
</div></div>Your suggestion in [4] is what I meant, but I couldn¹t type fast enough in<br>
the meeting. In-tree hardware_types will list support for<br>
network_interfaces according to their vendor¹s preference (I expect for<br>
most/all drivers that will at least be [noop, flat, neutron]). And if in<br>
the future as a vendor I want to, for example, push my hardware specific<br>
network interface in tree, then my Cisco drivers will gain an additional<br>
network_interface in their supported_network_interfaces list, [noop, flat,<br>
neutron, cisco].<br>
<span class=""><br>
>- we add a CONF option for default_network_interface, with a sane default<br>
>value<br>
>- this CONF option is validated on conductor load to be supported by all<br>
>loaded<br>
>hardware_types, and the conductor refuses to start if this CONF option is<br>
>set to<br>
>a value not supported by one or more enabled_hardware_types<br>
>- if a(n out of tree) hardware_type declares a default_network_interface,<br>
>this<br>
>will take precedence over the CONF option<br>
<br>
</span>I believe that all hardware_types should specify their supported network<br>
interfaces, but none should specify a default network interface, because<br>
there is no way to define a sane default in the hardware_type without<br>
knowing what environment its being deployed into.<br>
<span class=""><br>
>- a node created without specifying a network interface will check the<br>
>hardware_type's supported_network_interfaces, and when that is empty,<br>
>fall back<br>
>to the CONF.default_network_interface, just as other interfaces fall back<br>
>to the<br>
>hardware_type's relevant default<br>
<br>
</span>A node created without specifying a specific network interface will get<br>
the default specified by the CONF option, which we know is supported by<br>
that hardware_type because of the validation on conductor start. Nodes<br>
created with a network_interface specified work with the usual rules as<br>
you've specified below.<br>
<div class="HOEnZb"><div class="h5"><br>
>- operators can override a specific node's network_interface, which<br>
>follows the<br>
>usual rules for setting an interface on a Node (ie, the interface must be<br>
>in<br>
>hardware_type.supported_network_interfaces AND in<br>
>CONF.enabled_network_interfaces)<br>
><br>
><br>
>If anyone else has other clear suggestions that address all the issues<br>
>here,<br>
>please reply with them.<br>
><br>
>I'm going to make myself available tomorrow at 1700 UTC, in both IRC and<br>
>by<br>
>voice [3] (conference line # TBD) to discuss this with anyone. If we need<br>
>to<br>
>discuss it again on Wednesday, we can.<br>
><br>
><br>
>Thanks much,<br>
>--devananda<br>
><br>
><br>
><br>
>[1] starting at 17:20<br>
><br>
><a href="http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-07-11-17.0" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/ironic/2016/ironic.2016-07-11-17.0</a><br>
>0.log.html<br>
><br>
>[2]<br>
><a href="http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-co" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/ironic-specs/specs/approved/driver-co</a><br>
>mposition-reform.html<br>
><br>
>[3] <a href="https://wiki.openstack.org/wiki/Infrastructure/Conferencing" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Infrastructure/Conferencing</a><br>
><br>
>[4] I think we may need to have in-tree drivers declare<br>
>supported_network_interfaces to be [noop, flat, neutron], but that is not<br>
>what<br>
>Sam suggested during the meeting<br>
><br>
><br>
><br>
>On 06/28/2016 08:32 AM, Dmitry Tantsur wrote:<br>
>> Hi folks!<br>
>><br>
>> I was reviewing <a href="https://review.openstack.org/317391" rel="noreferrer" target="_blank">https://review.openstack.org/317391</a> and realized I<br>
>>don't quite<br>
>> understand why we want to have node.network_interface. What's the real<br>
>>life use<br>
>> case for it?<br>
>><br>
>> Do we expect some nodes to use Neutron, some - not?<br>
>><br>
>> Do we expect some nodes to benefit from network separation, some - not?<br>
>>There<br>
>> may be a use case here, but then we have to expose this field to Nova<br>
>>for<br>
>> scheduling, so that users can request a "secure" node or a "less<br>
>>secure" one. If<br>
>> we don't do that, Nova will pick at random, which makes the use case<br>
>>unclear again.<br>
>> If we do that, the whole work goes substantially beyond what we were<br>
>>trying to<br>
>> do initially: isolate tenants from the provisioning network and from<br>
>>each other.<br>
>><br>
>> Flexibility it good, but the patches raise upgrade concerns, because<br>
>>it's<br>
>> unclear how to provide a good default for the new field. And anyway it<br>
>>makes the<br>
>> whole thing much more complex than it could be.<br>
>><br>
>> Any hints are welcome.<br>
>><br>
>><br>
>>_________________________________________________________________________<br>
>>_<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>