Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-03-10 Thread Koderer, Marc
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 =

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-03-09 Thread Koderer, Marc
> On 09 Mar 2016, at 08:43, Sukhdev Kapur 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

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-03-08 Thread Sukhdev Kapur
Hi Marc, I am driving the ironic-ml2 integration and introduced baremetal type for vmic_type. 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

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-03-01 Thread Koderer, Marc
> On 01 Mar 2016, at 06:22, Kevin Benton 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

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-02-29 Thread Valeriy Ponomaryov
For the moment Manila does following: - creates Neutron port, consider "reserves" network info. - then calls its own share driver that supports network handling and that driver does binding on its backend. - Neutron does not have info about real usage of a port and its info. So, it is correct to

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-02-29 Thread Kevin Benton
>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

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-02-29 Thread Ben Swartzlander
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

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-02-29 Thread Robert Kukura
Is Manila actually connecting (i.e. binding) something it controls to a Neutron port, similar to how a Neutron L3 or DHCP agent connects a network namespace to a port? Or does it just need to know the details about a port bound for a VM (or a service)? If the former, it should probably be

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-02-29 Thread Kevin Benton
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. Have you considered writing an ML2 driver that just notifies Manilla

Re: [openstack-dev] [Neutron][ml2][Manila] API to query segments used during port binding

2016-02-29 Thread Ihar Hrachyshka
Fixed neutron tag in the subject. Marc 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