Re: [openstack-dev] [Magnum] Containers and networking

2015-05-11 Thread Bob Melander (bmelande)
I agree, that is my take too.

Russell, since you lead the OVN session in Vancouver, would it be possible to 
include the VLAN-aware-vms BP in that session?

Thanks,
Bob

From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: fredag 3 april 2015 13:17
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum] Containers and networking

This puts me in mind of a previous proposal, from the Neutron side of things. 
Specifically, I would look at Erik Moe's proposal for VM ports attached to 
multiple networks: 
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms .

I believe that you want logical ports hiding behind a conventional port (which 
that has); the logical ports attached to a variety of Neutron networks despite 
coming through the same VM interface (ditto); and an encap on the logical port 
with a segmentation ID (that uses exclusively VLANs, which probably suits here, 
though there's no particular reason why it has to be VLANs or why it couldn't 
be selectable).  The original concept didn't require multiple ports attached to 
the same incoming subnetwork, but that's a comparatively minor adaptation.
--
Ian.


On 2 April 2015 at 11:35, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:
On 04/02/2015 01:45 PM, Kevin Benton wrote:
 +1. I added a suggestion for a container networking suggestion to the
 etherpad for neutron. It would be sad if the container solution built
 yet another overlay on top of the Neutron networks with yet another
 network management workflow. By the time the packets are traveling
 across the wires, it would be nice not to have double encapsulation from
 completely different systems.

Yeah, that's what I like about this proposal.  Most of the existing work
in this space seems to result in double encapsulation.  Now we just need
to finish building it ...

--
Russell Bryant

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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


Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs in Liberty?

2015-05-11 Thread Bob Melander (bmelande)
Hi Eric,

Cisco is also interested in the kind of VLAN trunking feature that your 
VLAN-aware VM’s BP describe. If this could be achieved in Liberty it’d be great.
Perhaps your BP could be brought up during one of the Neutron sessions in 
Vancouver, e.g., the one on OVN since there seems to be some similarities?

Thanks
Bob


From: Erik Moe erik@ericsson.commailto:erik@ericsson.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: fredag 8 maj 2015 06:29
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware 
VMs in Liberty?


Hi,

I have not been able to work with upstreaming of this for some time now. But 
now it looks like I may make another attempt. Who else is interested in this, 
as a user or to help contributing? If we get some traction we can have an IRC 
meeting sometime next week.

Thanks,
Erik


From: Scott Drennan [mailto:sco...@nuagenetworks.net]
Sent: den 4 maj 2015 18:42
To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron]Anyone looking at support for VLAN-aware VMs 
in Liberty?

VLAN-transparent or VLAN-trunking networks have landed in Kilo, but I don't see 
any work on VLAN-aware VMs for Liberty.  There is a blueprint[1] and specs[2] 
which was deferred from Kilo - is this something anyone is looking at as a 
Liberty candidate?  I looked but didn't find any recent work - is there 
somewhere else work on this is happening?  No-one has listed it on the liberty 
summit topics[3] etherpad, which could mean it's uncontroversial, but given 
history on this, I think that's unlikely.

cheers,
Scott

[1]: https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
[2]: https://review.openstack.org/#/c/94612
[3]: https://etherpad.openstack.org/p/liberty-neutron-summit-topics
__
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


Re: [openstack-dev] [neutron][api] Extensions out, Micro-versions in

2015-05-06 Thread Bob Melander (bmelande)
Hi Salvatore,

Two questions/remarks below.

From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: onsdag 6 maj 2015 00:13
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in

#5 Plugin/Vendor specific APIs

Neutron is without doubt the project with the highest number of 3rd party (OSS 
and commercial) integration. After all it was mostly vendors who started this 
project.
Vendors [4] use the extension mechanism to expose features in their products 
not covered by the Neutron API or to provide some sort of value-added service.
The current proposal still allows 3rd parties to attach extensions to the 
neutron API, provided that:
- they're not considered part of the Neutron API, in terms of versioning, 
documentation, and client support

BOB There are today vendor specific commands in the Neutron CLI client. Such 
commands are prepended with the name of the vendor, like cisco_command and 
nec_command.
I think that makes it quite visible to the user that the command is specific to 
a vendor feature and not part of neutron core. Would it be possible to allow 
for that also going forward? I would think that from a user perspective it can 
be convenient to be able to access vendor add-on features using a single CLI 
client.

- they do not redefine resources defined by the Neutron API.

BOB Does “redefine here include extending a resource with additional 
attributes?

- they do not live in the neutron source tree
The aim of the provisions above is to minimize the impact of such extensions on 
API portability.

Thanks for reading and thanks in advance for your feedback,
Salvatore

The title of this post has been inspired by [2]  (the message in the banner may 
be unintelligible to readers not fluent in european football)

[1] https://review.openstack.org/#/c/136760/
[2] 
http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpgw=738site=espnfc
[3] 
http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[4] By vendor here we refer either to a cloud provider or a company providing 
Neutron integration for their products.
__
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


Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-10-24 Thread Bob Melander (bmelande)
What scares me a bit about the “let’s find a common solution for both external 
devices and VMs” approach is the challenge to reach an agreement. I remember a 
rather long discussion in the dev lounge in HongKong about trunking support 
that ended up going in all kinds of directions.

I work on implementing services in VMs so my opinion is definitely colored by 
that. Personally, proposal C is the most appealing to me for the following 
reasons: It is “good enough”, a trunk port notion is semantically easy to take 
in (at least to me), by doing it all within the port resource Nova implications 
are minimal, it seemingly can handle multiple network types (VLAN, GRE, VXLAN, 
… they are all mapped to different trunk port local VLAN tags), DHCP should 
work to the trunk ports and its sub ports (unless I overlook something), the 
spec already elaborates a lot on details, there is also already code available 
that can be inspected.

Thanks,
Bob

From: Ian Wells ijw.ubu...@cack.org.ukmailto:ijw.ubu...@cack.org.uk
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: torsdag 23 oktober 2014 23:58
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

There are two categories of problems:

1. some networks don't pass VLAN tagged traffic, and it's impossible to detect 
this from the API
2. it's not possible to pass traffic from multiple networks to one port on one 
machine as (e.g.) VLAN tagged traffic

(1) is addressed by the VLAN trunking network blueprint, XXX. Nothing else 
addresses this, particularly in the case that one VM is emitting tagged packets 
that another one should receive and Openstack knows nothing about what's going 
on.

We should get this in, and ideally in quickly and in a simple form where it 
simply tells you if a network is capable of passing tagged traffic.  In 
general, this is possible to calculate but a bit tricky in ML2 - anything using 
the OVS mechanism driver won't pass VLAN traffic, anything using VLANs should 
probably also claim it doesn't pass VLAN traffic (though actually it depends a 
little on the switch), and combinations of L3 tunnels plus Linuxbridge seem to 
pass VLAN traffic just fine.  Beyond that, it's got a backward compatibility 
mode, so it's possible to ensure that any plugin that doesn't implement VLAN 
reporting is still behaving correctly per the specification.

(2) is addressed by several blueprints, and these have overlapping ideas that 
all solve the problem.  I would summarise the possibilities as follows:

A. Racha's L2 gateway blueprint, 
https://blueprints.launchpad.net/neutron/+spec/gateway-api-extension, which (at 
its simplest, though it's had features added on and is somewhat OVS-specific in 
its detail) acts as a concentrator to multiplex multiple networks onto one as a 
trunk.  This is a very simple approach and doesn't attempt to resolve any of 
the hairier questions like making DHCP work as you might want it to on the 
ports attached to the trunk network.
B. Isaku's L2 gateway blueprint, https://review.openstack.org/#/c/100278/, 
which is more limited in that it refers only to external connections.
C. Erik's VLAN port blueprint, 
https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms, which tries to 
solve the addressing problem mentioned above by having ports within ports (much 
as, on the VM side, interfaces passing trunk traffic tend to have subinterfaces 
that deal with the traffic streams).
D. Not a blueprint, but an idea I've come across: create a network that is a 
collection of other networks, each 'subnetwork' being a VLAN in the network 
trunk.
E. Kyle's very old blueprint, 
https://blueprints.launchpad.net/neutron/+spec/quantum-network-bundle-api - 
where we attach a port, not a network, to multiple networks.  Probably doesn't 
work with appliances.

I would recommend we try and find a solution that works with both external 
hardware and internal networks.  (B) is only a partial solution.

Considering the others, note that (C) and (D) add significant complexity to the 
data model, independently of the benefits they bring.  (A) adds one new 
functional block to networking (similar to today's routers, or even today's 
Nova instances).

Finally, I suggest we consider the most prominent use case for multiplexing 
networks.  This seems to be condensing traffic from many networks to either a 
service VM or a service appliance.  It's useful, but not essential, to have 
Neutron control the addresses on the trunk port subinterfaces.

So, that said, I personally favour (A) is the simplest way to solve our current 
needs, and I recommend paring (A) right down to its basics: a block that has 
access ports that we tag with a VLAN ID, and one trunk port that has all of the 
access 

Re: [openstack-dev] [neutron] [nfv] VM-based VLAN trunking blueprints

2014-10-22 Thread Bob Melander (bmelande)
I suppose this BP also has some relevance to such a discussion.

https://review.openstack.org/#/c/100278/

/ Bob


On 2014-10-22 15:42, Kyle Mestery mest...@mestery.com wrote:

There are currently at least two BPs registered for VLAN trunk support
to VMs in neutron-specs [1] [2]. This is clearly something that I'd
like to see us land in Kilo, as it enables a bunch of things for the
NFV use cases. I'm going to propose that we talk about this at an
upcoming Neutron meeting [3]. Given the rotating schedule of this
meeting, and the fact the Summit is fast approaching, I'm going to
propose we allocate a bit of time in next Monday's meeting to discuss
this. It's likely we can continue this discussion F2F in Paris as
well, but getting a head start would be good.

Thanks,
Kyle

[1] https://review.openstack.org/#/c/94612/
[2] https://review.openstack.org/#/c/97714
[3] https://wiki.openstack.org/wiki/Network/Meetings

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][L3] Agent manager customization

2014-04-29 Thread Bob Melander (bmelande)
Hi Zzelle, Carl and others,

We’ve been doing work on a more modular agent whose responsibilities are 
basically to:
1: apply configurations in devices when Neutron service resources (like Neutron 
Routers) are created or updated.
2: monitor the health of devices hosting such service resources

Our starting point was the l3 agent which we’ve then evolved to become a 
configuration agent.
It can perform configurations in remote devices so it does not have to run 
locally on the device it configures
(this helps to reduce agent reporting traffic and thus the load on the Neutron 
service)
It makes use of device drivers that knows how to instantiate/manipulate service 
resources in devices of the type that the driver handles.
It also introduces what we call service helpers. Such a helper (a python class) 
essentially describes the workflow that should be used to create/update Neutron 
resources of a certain type.
At the moment we have a single service helper for Neutron routing service but 
our thinking is to take this one step further and allow for different service 
helpers for each service.
That would allow for pretty much completely different workflows to be used if a 
Neutron router is implemented in say a device of type A, vs if it is 
implemented in device of type B.

Perhaps something like the config agent could help handling some of the 
complexities you bring up. In case your interested you can have a look at the 
BP for the config agent. The link for blueprint spec is:
https://review.openstack.org/#/c/90729/

We hope to at least briefly be able to bring up the configuration agent in the 
design summit session on the service vm framework (on Friday, shared session 
with Isaku Yamahata) as that is the context in which we started this work.

Thanks,
Bob

From: ZZelle zze...@gmail.commailto:zze...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: torsdag 24 april 2014 00:34
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron][L3] Agent manager customization

Hi Carl,


 A clear l3 agent manager interface with hookable methods would clearly 
simplify the understanding, the dev/support.


Difficulties:
1. (un)deployment method names are associated to the triggering event not to 
performed action:
 - router deployment is done by _router_added
 - router gateway deployment/config is  done by  external_gateway_added
 - more generally (un)deployments are done by the associated *_added and 
*_removed methods
It implies to fully understand the behaviour of the L3 agent manager in order 
to check that (un)deployment actions are done and only done by the associated 
triggering event methods.
2. Because docstrings are missing, i needed to double check previous check.

3. Customization testing is not really easy, because inherited manager 
implementation could change.
So i preferred to perform only black box tests to reduce coupling between 
implementation and tests.

4. Support: extending a class without a contract/interface implies to perform 
some adaptations/checks (not so much in practice) simplified by previous tests
But that's the topic !

5. It's not possible currently to change l3 agent manager through configuration
 - so i must develop my own neutron-l3-agent binary implementation in order 
to allow providing a custom manager to main()
 - i must verify my binary was not erased during updates


Awkward:
6. (un)deployment methods get the router RouterInfo using different strategies:
 - _router_added builds it and stores it in self.router_info cache
 - _router_removed get it from self.router_info cache
 - external_gateway/internal_network_added/removed get it through arguments

7._router_added and _process_routers have strange behaviours:
 - _process_routers calls _router_added will verifying to build router 
RouterInfo object
 - _router_added computes the router RouterInfo object and store it in 
self.router_info
 - _process_routers get it back from self.router_info
IMHO, it seems more logical to let
 - _process_routers builds and stores router RouterInfo object and
 - _process_routers pass the object as an argument to _router_added
The same might apply to _router_removed and _process_routers ?


I must share with pcm about L3 Vendor plugins BPs to verify my understanding 
and possible synergies.
But a priori [1] BP seems to be the only synergy candidate.


Cedric


[1] https://blueprints.launchpad.net/neutron/+spec/l3-svcs-vendor-validation

On Tue, Apr 22, 2014 at 6:18 PM, Carl Baldwin 
c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote:
Cedric,

I'm just getting back from a short vacation.  Please excuse the delayed reply.

I have a feeling that this subject may have been discussed in the past
before I was very active in Neutron.  So, others may chime in if I'm
missing 

Re: [openstack-dev] Neutron Distributed Virtual Router

2013-12-23 Thread Bob Melander (bmelande)
I agree. With your patch it ought to be possible to make the distributed router 
a provider type so to me it seems like a good match.

Thanks,
Bob

From: Gary Duan gd...@varmour.commailto:gd...@varmour.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: måndag 23 december 2013 19:17
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] Neutron Distributed Virtual Router

Regarding using 'provider' in L3 router, for the BP 'L3 service integration 
with service framework', I've submitted some code for review, which is using 
'provider' in a same notion as other advanced services. I am not sure if it can 
be reused to describe 'centralized' and 'distributed' behavior.

https://review.openstack.org/#/c/59242/

Thanks,
Gary


On Wed, Dec 11, 2013 at 2:17 AM, Salvatore Orlando 
sorla...@nicira.commailto:sorla...@nicira.com wrote:
I generally tend to agree that once the distributed router is available, nobody 
would probably want to use a centralized one.
Nevertheless, I think it is correct that, at least for the moment, some 
advanced services would only work with a centralized router.
There might also be unforeseen scalability/security issues which might arise 
from the implementation, so it is worth giving users a chance to choose what 
router's they'd like.

In the case of the NSX plugin, this was provided as an extended API attribute 
in the Havana release with the aim of making it the default solution for 
routing in the future.
One thing that is worth adding is that at the time it was explored the ability 
of leveraging service providers for having a centralized router provider and 
a distributed one; we had working code, but then we reverted to the extended 
attribute. Perhaps it would be worth exploring whether this is a feasible 
solution, and whether it might be even possible to define flavors which 
characterise how routers and advanced services are provided.

Salvatore


On 10 December 2013 18:09, Nachi Ueno na...@ntti3.commailto:na...@ntti3.com 
wrote:
I'm +1 for 'provider'.

2013/12/9 Akihiro Motoki mot...@da.jp.nec.commailto:mot...@da.jp.nec.com:
 Neutron defines provider attribute and it is/will be used in advanced 
 services (LB, FW, VPN).
 Doesn't it fit for a distributed router case? If we can cover all services 
 with one concept, it would be nice.

 According to this thread, we assumes at least two types edge and 
 distributed.
 Though edge and distributed is a type of implementations, I think they 
 are some kind of provider.

 I just would like to add an option. I am open to provider vs distirbute 
 attributes.

 Thanks,
 Akihiro

 (2013/12/10 7:01), Vasudevan, Swaminathan (PNB Roseville) wrote:
 Hi Folks,

 We are in the process of defining the API for the Neutron Distributed 
 Virtual Router, and we have a question.

 Just wanted to get the feedback from the community before we implement and 
 post for review.

 We are planning to use the “distributed” flag for the routers that are 
 supposed to be routing traffic locally (both East West and North South).
 This “distributed” flag is already there in the “neutronclient” API, but 
 currently only utilized by the “Nicira Plugin”.
 We would like to go ahead and use the same “distributed” flag and add an 
 extension to the router table to accommodate the “distributed flag”.

 Please let us know your feedback.

 Thanks.

 Swaminathan Vasudevan
 Systems Software Engineer (TC)
 HP Networking
 Hewlett-Packard
 8000 Foothills Blvd
 M/S 5541
 Roseville, CA - 95747
 tel: 916.785.0937tel:916.785.0937
 fax: 916.785.1815tel:916.785.1815
 email: swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com 
 mailto:swaminathan.vasude...@hp.commailto:swaminathan.vasude...@hp.com

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Shared network between specific tenants, but not all tenants?

2013-11-13 Thread Bob Melander (bmelande)
Somewhat related: Sharing of networks between tenants has also come up in the 
discussions on trunk support; One use case there is , a VM VIF is plugged to 
multiple networks at the same time and packets are VLAN tagged (visible to the 
VM) to separate those networks. For usage with service VMs it is desirable that 
those networks can belong to different tenants.

BP is here:https://blueprints.launchpad.net/neutron/+spec/vlan-aware-vms
There is also a thread 'VLAN aware VMs' on this email list about this.

Thanks,
Bob

From: Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: söndag 3 november 2013 21:20
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Shared network between specific tenants, 
but not all tenants?

This blueprint is related (the concept stands for any network, not just 
externals): 
https://blueprints.launchpad.net/neutron/+spec/sharing-model-for-external-networks

You can read the blueprint and spec pages for some context.
Bottom line is that it would be great to have some feedback on whether you 
reckon this:
i) a RBAC problem, which should be enhanced in order to delegate access to 
network resources thus enabling a tenant to select with which tenants a network 
should be shared
ii) a network topology problem, meaning that we don't really care about whether 
there's a single shared network segment or not, as long as there is a 
possibility to provide a CIDR which is routable by different tenants.

Regards,
Salvatore


On 29 October 2013 22:20, Mike Wilson 
geekinu...@gmail.commailto:geekinu...@gmail.com wrote:
+1

I also have tenants asking for this :-). I'm interested to see a blueprint.

-Mike


On Tue, Oct 29, 2013 at 1:24 PM, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:
On 10/29/2013 02:25 PM, Justin Hammond wrote:
We have been considering this and have some notes on our concept, but we
haven't made a blueprint for it. I will speak amongst my group and find
out what they think of making it more public.

OK, cool, glad to know I'm not the only one with tenants asking for this :)

Looking forward to a possible blueprint on this.

Best,
-jay


On 10/29/13 12:26 PM, Jay Pipes 
jaypi...@gmail.commailto:jaypi...@gmail.com wrote:

Hi Neutron devs,

Are there any plans to support networks that are shared/routed only
between certain tenants (not all tenants)?

Thanks,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Bob Melander (bmelande)
While specification of which networks a service VM has interfaces on indicates 
which tenant(s) it serves, that by itself does not allow setting constraints on 
which tenants that VM will accept to serve.
Setting such constraints could be taken a long way, almost like ACL. However, 
I'm not proposing something that extensive. Ability to flag that a certain VM 
should only allow to serve a single tenant (but still multiple service 
instances for that tenant) would cover a requirement we've been given in work 
we've done.

Thanks,
Bob


From: Sumit Naiksatam 
sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: onsdag 9 oktober 2013 23:09
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

Thanks Bob, I agree this is an important aspect of the implementation. However, 
apart from being able to specify which network(s) the VM has interfaces on, 
what more needs to be done specifically in the proposed library to achieve the 
tenant level isolation?

Thanks,
~Sumit.


On Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande) 
bmela...@cisco.commailto:bmela...@cisco.com wrote:
For use case 2, ability to pin an admin/operator owned VM to a particular 
tenant can be useful.
I.e., the service VMs are owned by the operator but a particular service VM 
will only allow service instances from a single tenant.

Thanks,
Bob

From: Regnier, Greg J 
greg.j.regn...@intel.commailto:greg.j.regn...@intel.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: tisdag 8 oktober 2013 23:48
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Service VM discussion - Use Cases

Hi,

Re: blueprint:  
https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

Before going into more detail on the mechanics, would like to nail down use 
cases.

Based on input and feedback, here is what I see so far.



Assumptions:



- a 'Service VM' hosts one or more 'Service Instances'

- each Service Instance has one or more Data Ports that plug into Neutron 
networks

- each Service Instance has a Service Management i/f for Service management 
(e.g. FW rules)

- each Service Instance has a VM Management i/f for VM management (e.g. health 
monitor)



Use case 1: Private Service VM

Owned by tenant

VM hosts one or more service instances

Ports of each service instance only plug into network(s) owned by tenant



Use case 2: Shared Service VM

Owned by admin/operator

VM hosts multiple service instances

The ports of each service instance plug into one tenants network(s)

Service instance provides isolation from other service instances within VM



Use case 3: Multi-Service VM

Either Private or Shared Service VM

Support multiple service types (e.g. FW, LB, …)


-  Greg

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Bob Melander (bmelande)
Harshad,

By service instance I referred to the logical entities that Neutron creates 
(e.g. Neutron's router). I see a service VM as a (virtual) host where one or 
several service instances can be placed.
The service VM (at least if managed through Nova) will belong to a tenant and 
the service instances are owned by tenants.

If the service VM tenant is different from service instance tenants (which is a 
simple way to hide the service VM from the tenants owning the service 
instances) then it is not clear to me how the existing access control in 
openstack will support pinning the service VM to a particular tenant owning a 
service instance.

Thanks,
Bob

From: Harshad Nakil 
hna...@contrailsystems.commailto:hna...@contrailsystems.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: onsdag 9 oktober 2013 18:56
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

Admin creating service instance for a tenant could common use case. But 
ownership of service can be controlled via already existing access control 
mechanism in openstack. If the service instance belonged to a particular 
project then other tenants should by definition should not be able to use this 
instance.

On Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande) 
bmela...@cisco.commailto:bmela...@cisco.com wrote:
For use case 2, ability to pin an admin/operator owned VM to a particular 
tenant can be useful.
I.e., the service VMs are owned by the operator but a particular service VM 
will only allow service instances from a single tenant.

Thanks,
Bob

From: Regnier, Greg J 
greg.j.regn...@intel.commailto:greg.j.regn...@intel.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: tisdag 8 oktober 2013 23:48
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Service VM discussion - Use Cases

Hi,

Re: blueprint:  
https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

Before going into more detail on the mechanics, would like to nail down use 
cases.

Based on input and feedback, here is what I see so far.



Assumptions:



- a 'Service VM' hosts one or more 'Service Instances'

- each Service Instance has one or more Data Ports that plug into Neutron 
networks

- each Service Instance has a Service Management i/f for Service management 
(e.g. FW rules)

- each Service Instance has a VM Management i/f for VM management (e.g. health 
monitor)



Use case 1: Private Service VM

Owned by tenant

VM hosts one or more service instances

Ports of each service instance only plug into network(s) owned by tenant



Use case 2: Shared Service VM

Owned by admin/operator

VM hosts multiple service instances

The ports of each service instance plug into one tenants network(s)

Service instance provides isolation from other service instances within VM



Use case 3: Multi-Service VM

Either Private or Shared Service VM

Support multiple service types (e.g. FW, LB, …)


-  Greg

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Common requirements for services' discussion

2013-10-10 Thread Bob Melander (bmelande)
Hi Edgar,

I'm also interested in a broadening of NAT capability in Neutron using the 
evolving service framework.

Thanks,
Bob

From: Edgar Magana emag...@plumgrid.commailto:emag...@plumgrid.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: onsdag 9 oktober 2013 21:38
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Common requirements for services' 
discussion

Hello all,

Is anyone working on NATaaS?
I know we have some developer working on Router as a Service and they probably 
want to include NAT functionality but I have some interest in having NAT as a 
Service.

Please, response is somebody is interested in having some discussions about it.

Thanks,

Edgar

From: Sumit Naiksatam 
sumitnaiksa...@gmail.commailto:sumitnaiksa...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, October 8, 2013 8:30 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Common requirements for services' discussion

Hi All,

We had a VPNaaS meeting yesterday and it was felt that we should have a 
separate meeting to discuss the topics common to all services. So, in 
preparation for the Icehouse summit, I am proposing an IRC meeting on Oct 14th 
22:00 UTC (immediately after the Neutron meeting) to discuss common aspects 
related to the FWaaS, LBaaS, and VPNaaS.

We will begin with service insertion and chaining discussion, and I hope we can 
collect requirements for other common aspects such as service agents, services 
instances, etc. as well.

Etherpad for service insertion  chaining can be found here:
https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining

Hope you all can join.

Thanks,
~Sumit.


___ OpenStack-dev mailing list 
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-10 Thread Bob Melander (bmelande)
Possibly but not necessarily. Some VMs have a large footprint, have 
multi-service capability and physical devices with capabilities sufficient for 
tenant isolation are not that rare (especially if tenants can only indirectly 
control them through a cloud service API).

My point is that if we take into account, in the design, the case where 
multiple service instances are hosted by a single service VM we'll be well 
positioned to support other use cases. But that is not to say the 
implementation effort should target that aspect initially.

Thanks,
 Bob

10 okt 2013 kl. 15:12 skrev Harshad Nakil 
hna...@contrailsystems.commailto:hna...@contrailsystems.com:

Won't it be simpler to keep service instance  as one or more VMs, rather than 
1VM being many service instances?
Usually a appliance is collectively (all it's functions) providing a service. 
Like firewall or load balancer. A appliance is packaged as VM.
It will be easier to manage
it will be easier for the provider to charge.
It will be easier to control resource allocation.
Once a appliance is physical device than you have all of the above issues and 
usually multi-tenancy implementation is weak in most of physical appliances.

Regards
-Harshad


On Oct 10, 2013, at 12:44 AM, Bob Melander (bmelande) 
bmela...@cisco.commailto:bmela...@cisco.com wrote:

Harshad,

By service instance I referred to the logical entities that Neutron creates 
(e.g. Neutron's router). I see a service VM as a (virtual) host where one or 
several service instances can be placed.
The service VM (at least if managed through Nova) will belong to a tenant and 
the service instances are owned by tenants.

If the service VM tenant is different from service instance tenants (which is a 
simple way to hide the service VM from the tenants owning the service 
instances) then it is not clear to me how the existing access control in 
openstack will support pinning the service VM to a particular tenant owning a 
service instance.

Thanks,
Bob

From: Harshad Nakil 
hna...@contrailsystems.commailto:hna...@contrailsystems.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: onsdag 9 oktober 2013 18:56
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

Admin creating service instance for a tenant could common use case. But 
ownership of service can be controlled via already existing access control 
mechanism in openstack. If the service instance belonged to a particular 
project then other tenants should by definition should not be able to use this 
instance.

On Tue, Oct 8, 2013 at 11:34 PM, Bob Melander (bmelande) 
bmela...@cisco.commailto:bmela...@cisco.com wrote:
For use case 2, ability to pin an admin/operator owned VM to a particular 
tenant can be useful.
I.e., the service VMs are owned by the operator but a particular service VM 
will only allow service instances from a single tenant.

Thanks,
Bob

From: Regnier, Greg J 
greg.j.regn...@intel.commailto:greg.j.regn...@intel.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: tisdag 8 oktober 2013 23:48
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Service VM discussion - Use Cases

Hi,

Re: blueprint:  
https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

Before going into more detail on the mechanics, would like to nail down use 
cases.

Based on input and feedback, here is what I see so far.



Assumptions:



- a 'Service VM' hosts one or more 'Service Instances'

- each Service Instance has one or more Data Ports that plug into Neutron 
networks

- each Service Instance has a Service Management i/f for Service management 
(e.g. FW rules)

- each Service Instance has a VM Management i/f for VM management (e.g. health 
monitor)



Use case 1: Private Service VM

Owned by tenant

VM hosts one or more service instances

Ports of each service instance only plug into network(s) owned by tenant



Use case 2: Shared Service VM

Owned by admin/operator

VM hosts multiple service instances

The ports of each service instance plug into one tenants network(s)

Service instance provides isolation from other service instances within VM



Use case 3: Multi-Service VM

Either Private or Shared Service VM

Support multiple service types (e.g. FW, LB, …)


-  Greg

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev

Re: [openstack-dev] [Neutron] Service VM discussion - Use Cases

2013-10-09 Thread Bob Melander (bmelande)
For use case 2, ability to pin an admin/operator owned VM to a particular 
tenant can be useful.
I.e., the service VMs are owned by the operator but a particular service VM 
will only allow service instances from a single tenant.

Thanks,
Bob

From: Regnier, Greg J 
greg.j.regn...@intel.commailto:greg.j.regn...@intel.com
Reply-To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: tisdag 8 oktober 2013 23:48
To: 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Service VM discussion - Use Cases

Hi,

Re: blueprint:  
https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

Before going into more detail on the mechanics, would like to nail down use 
cases.

Based on input and feedback, here is what I see so far.



Assumptions:



- a 'Service VM' hosts one or more 'Service Instances'

- each Service Instance has one or more Data Ports that plug into Neutron 
networks

- each Service Instance has a Service Management i/f for Service management 
(e.g. FW rules)

- each Service Instance has a VM Management i/f for VM management (e.g. health 
monitor)



Use case 1: Private Service VM

Owned by tenant

VM hosts one or more service instances

Ports of each service instance only plug into network(s) owned by tenant



Use case 2: Shared Service VM

Owned by admin/operator

VM hosts multiple service instances

The ports of each service instance plug into one tenants network(s)

Service instance provides isolation from other service instances within VM



Use case 3: Multi-Service VM

Either Private or Shared Service VM

Support multiple service types (e.g. FW, LB, …)


-  Greg
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev