Hi folks,
I had a deep dive session with Bob (thx Bob).
We have a plan to solve the issue without any change of APIs or
manila driver reworks.
The process will look like the following:
1.) In case of multi-segment/hpb Manila creates a port like Ironic ML2
would do it [1]:
vif_type = baremetal
binding_profile = list of sw ports
device_owner = manila:ID
2.) Manila waits until all ports are actively bound
2.a) Neutron binds the port through the segments
2.b) A manila-neutron mech driver (a really simple one) fulfils the binding
and sets:
vif_details = {“share_segmentation_id" = XX,
“share_network_type" = YY}
3.) When the port becomes active Manila has all it needs to proceed
In 2.b. the manila MD will only search for device_owner == “manila:”,
sets the needed details and fulfils the binding (~10 LOC).
We also discussed about using ML2 GW [2] or trunk port [3].
I consider the design above as simple enough to get merged smoothly
in Newton.
@Ben: Will be back for bug hunting now.
Regards
Marc
[1]:
https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
<https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html>
[2]: https://wiki.openstack.org/wiki/Neutron/L2-GW
[3]: https://wiki.openstack.org/wiki/Neutron/TrunkPort
> On 09 Mar 2016, at 09:25, Koderer, Marc <m...@koderer.com> wrote:
>
>>
>> On 09 Mar 2016, at 08:43, Sukhdev Kapur <sukhdevka...@gmail.com
>> <mailto:sukhdevka...@gmail.com>> wrote:
>>
>> Hi Marc,
>>
>> I am driving the ironic-ml2 integration and introduced baremetal type for
>> vmic_type.
>
> Basically that’s my plan. So in my current implementation
> I use the baremetal vnic_type [1] and add a binding profile [2].
>
>> You can very much use the same integration here - however, I am not
>> completely clear about your use case.
>> Do you want neutron/ML2 to plumb the network for Manila or do you want to
>> find out what VLAN (segmentation id) is used on the segment which connects
>> TOR to the storage device?
>
> Generally I want to find the best architecture for this feature :)
> Introducing a neutron-agent that does the plumbing will mean this agent needs
> to have a connection to the storage node itself. So we will end-up in a
> storage agent with a driver model (or an agent for each storage device). On
> the other side it follows the idea that neutron takes care about networking.
>
> From a Manila perspective the easiest solution would be to have an interface
> to
> get the segmentation id of the lowest bound segment.
>
>>
>> You had this on the agenda of ML2 meeting for tomorrow and I was going to
>> discuss this with you in the meeting. But, I noticed that you removed it
>> from the agenda. Do you have what you need? If not, you may want to join us
>> in the ML2 meeting tomorrow and we can discuss this use case there.
>
> Yeah I am sorry - I have to move the topic +1 week due to an internal meeting
> :(
> But we can have a chat on IRC (mkoderer on freenode).
>
> Regards
> Marc
>
> [1]: https://review.openstack.org/#/c/283494/
> <https://review.openstack.org/#/c/283494/>
> [2]: https://review.openstack.org/#/c/284034/
> <https://review.openstack.org/#/c/284034/>
>
>
>>
>> -Sukhdev
>>
>>
>> On Tue, Mar 1, 2016 at 1:08 AM, Koderer, Marc <m...@koderer.com
>> <mailto:m...@koderer.com>> wrote:
>>
>>> On 01 Mar 2016, at 06:22, Kevin Benton <ke...@benton.pub
>>> <mailto:ke...@benton.pub>> wrote:
>>>
>>> >This seems gross and backwards. It makes sense as a short term hack but
>>> >given that we have time to design this correctly I'd prefer to get this
>>> >information in a more straighforward way.
>>>
>>> Well it depends on what is happening here. If Manilla is wiring up a
>>> specific VLAN for a port, that makes it part of the port binding process,
>>> in which case it should be an ML2 driver. Can you provide some more details
>>> about what Manilla is doing with this info?
>>
>> The VLAN segment ID and IP address is used in the share driver to configure
>> the
>> corresponding interface resources within the storage. Just to give some
>> examples:
>>
>> - NetApp driver uses it to create a logical interface and assign it to a
>> “storage virtual machine” [1]
>> - EMC driver does it in similar manner [2]
>>
>> My idea was to use the same principle as ironic ml2 intregration is doing [3]
>> by setting the vnic_type to “baremetal”.
>>
>> In Manila's current implementation storage drivers are also responsible to
>> setup the right networking setup. Would you suggest to move this part into
>> the
>> port binding phase?
>>
>> Regards
>> Marc
>>
>>
>> [1]:
>> https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272
>>
>> <https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272>
>> [2]:
>> https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609
>>
>> <https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609>
>> [3]:
>> https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
>>
>> <https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html>
>>
>>
>>>
>>> On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander <b...@swartzlander.org
>>> <mailto:b...@swartzlander.org>> wrote:
>>> On 02/29/2016 04:38 PM, Kevin Benton wrote:
>>> You're correct. Right now there is no way via the HTTP API to find which
>>> segments a port is bound to.
>>> This is something we can certainly consider adding, but it will need an
>>> RFE so it wouldn't land until Newton at the earliest.
>>>
>>> I believe Newton is the target for this work. This is feature freeze week
>>> after all.
>>>
>>> Have you considered writing an ML2 driver that just notifies Manilla of
>>> the port's segment info? All of this information is available to ML2
>>> drivers in the PortContext object that is passed to them.
>>>
>>> This seems gross and backwards. It makes sense as a short term hack but
>>> given that we have time to design this correctly I'd prefer to get this
>>> information in a more straighforward way.
>>>
>>> -Ben Swartzlander
>>>
>>>
>>> On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka <ihrac...@redhat.com
>>> <mailto:ihrac...@redhat.com>
>>> <mailto:ihrac...@redhat.com <mailto:ihrac...@redhat.com>>> wrote:
>>>
>>> Fixed neutron tag in the subject.
>>>
>>> Marc <m...@koderer.com <mailto:m...@koderer.com>
>>> <mailto:m...@koderer.com <mailto:m...@koderer.com>>> wrote:
>>>
>>> Hi Neutron team,
>>>
>>> I am currently working on a feature for hierarchical port
>>> binding support in
>>> Manila [1] [2]. Just to give some context: In the current
>>> implementation Manila
>>> creates a neutron port but let it unbound (state DOWN).
>>> Therefore Manila uses
>>> the port create only retrieve an IP address and segmentation ID
>>> (some drivers
>>> only support VLAN here).
>>>
>>> My idea is to change this behavior and do an actual port binding
>>> action so that
>>> the configuration of VLAN isn’t a manual job any longer. And
>>> that multi-segment
>>> and HPB is supported on the long-run.
>>>
>>> My current issue is: How can Manila retrieve the segment
>>> information for a
>>> bound port? Manila only is interested in the last (bottom)
>>> segmentation ID
>>> since I assume the storage is connected to a ToR switch.
>>>
>>> Database-wise it’s possible to query it using
>>> ml2_port_binding_levels table.
>>> But AFAIK there is no API to query this. The only information
>>> that is exposed
>>> are all segments of a network. But this is not sufficient to
>>> identify which
>>> segments actually used for a port binding.
>>>
>>> Regards
>>> Marc
>>> SAP SE
>>>
>>> [1]:
>>>
>>> https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support
>>> <https://wiki.openstack.org/wiki/Manila/design/manila-newton-hpb-support>
>>> [2]: https://review.openstack.org/#/c/277731/
>>> <https://review.openstack.org/#/c/277731/>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>>>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>>> <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> <http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> <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
>>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> <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://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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
>> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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
> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> <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
