> On 09 Mar 2016, at 08:43, Sukhdev Kapur <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?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
