[openstack-dev] [Designate] In what sense is it multi-tenant?

[Mike Spreitzer]

In what sense is Designate multi-tenant?  Can it be programmed to give 
different views to different DNS clients?  (If so, how?)

Thanks,
Mike

__
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] [designate] Status of the project

[Mike Spreitzer]

Joshua Harlow  wrote on 02/10/2017 12:21:08 PM:

> Knowing where this is at and the issues. It makes me wonder if it is 
> worthwhile to start thinking about how we can start to look at 'outside 
> the openstack' projects for DNS. I believe there is a few that are 
> similar enough to designate (though I don't know well enough) for 
> example things like SkyDNS (or others which I believe there are a few).
> 
> Perhaps we need to start thinking outside the openstack 'box' in regards 

> to NIH syndrome and accept the fact that we as a community may not be 
> able to recreate the world successfully in all cases (the same could be 
> said about things like k8s and others).
> 
> If we got out of the mindset of openstack as a thing must have tightly 
> integrated components (over all else) and started thinking about how we 
> can be much more loosely coupled (and even say integrating non-python, 
> non-openstack projects) would that be beneficial (I think it would)?

I think you might be on to something.  The Kubernetes community seems to 
be thinking about an external DNS service too.  I see 
https://github.com/kubernetes-incubator/external-dns was just created, but 
do not know anything more about it.

Regards,
Mike



__
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] [Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

[Mike Spreitzer]

I do not recall trying that case.  I am surprised it is failing; and even 
more surprised that it is failing due to an explicit RST from the server 
VM.  Fortunately this is something you can debug.  Have a look at packet 
traces taken at various points along the way, and see what is going on. 
BTW, when using packet tracing I find it troublesome to do the filtering 
and/or the pretty-printing online; I simply capture all the packets at a 
given interface and them examine them later with Wireshark.

Regards,
Mike



From:   Gustavo Randich <gustavo.rand...@gmail.com>
To:     Mike Spreitzer/Watson/IBM@IBMUS
Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org>, 
"openstack-operat...@lists.openstack.org" 
<openstack-operat...@lists.openstack.org>
Date:   07/15/2016 01:44 PM
Subject:Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)



Hi, this approach worked fine, except in the case when VM has a floating 
IP, perhaps because of some SNAT rules in the Neutron Node router 
preventing TCP traffic (connection reset by peer) using internal IP 
address, although ICMP works. Using floating IP works ok, but for the use 
case we are deploying, we need to always access VMs via internal IP, 
regardless of the VM having a float or not.

I remember this problem was corrected in DVR for the case of VMs with 
floating IPs assigned communicating via internal IPs (it works ok now).




On Thu, Jun 30, 2016 at 2:32 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
No, those routers are routers.  If one of them gets a packet, the router 
will forward the packet as usual for a router.

You might think they don't handle connections into tenant networks, but 
that might be because nothing is trying to use them as routers for the 
tenant networks.  That's a question about the routing tables in the rest 
of your environment.

If the client has a route to a Neutron tenant network that goes through a 
Neutron router, the client is able to connect to a server on the Neutron 
tenant network.

The normal configuration for routers on the internet is to not forward 
traffic to the RFC 1918 addresses.  I do not recall how the Neutron 
routers handle packets addressed to those addresses from sources on the 
"outside".

Regards,
Mike



From:Gustavo Randich <gustavo.rand...@gmail.com>
To:Mike Spreitzer/Watson/IBM@IBMUS
Cc:"openstack@lists.openstack.org" <openstack@lists.openstack.org
>, "openstack-operat...@lists.openstack.org" <
openstack-operat...@lists.openstack.org>
Date:06/30/2016 11:25 AM
Subject:Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)




Mike, as far as I know those routers allow only outgoing traffic, i.e. VM 
can see external networks, but those external networks cannot connect to 
VM if it doesn't have a FIP, am I right?

Thanks!
Gustavo

On Wed, Jun 29, 2016 at 7:24 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
Gustavo Randich <gustavo.rand...@gmail.com> wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike









___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

[Mike Spreitzer]

I do not recall trying that case.  I am surprised it is failing; and even 
more surprised that it is failing due to an explicit RST from the server 
VM.  Fortunately this is something you can debug.  Have a look at packet 
traces taken at various points along the way, and see what is going on. 
BTW, when using packet tracing I find it troublesome to do the filtering 
and/or the pretty-printing online; I simply capture all the packets at a 
given interface and them examine them later with Wireshark.

Regards,
Mike



From:   Gustavo Randich <gustavo.rand...@gmail.com>
To:     Mike Spreitzer/Watson/IBM@IBMUS
Cc: "openst...@lists.openstack.org" <openst...@lists.openstack.org>, 
"openstack-operators@lists.openstack.org" 
<openstack-operators@lists.openstack.org>
Date:   07/15/2016 01:44 PM
Subject:Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)



Hi, this approach worked fine, except in the case when VM has a floating 
IP, perhaps because of some SNAT rules in the Neutron Node router 
preventing TCP traffic (connection reset by peer) using internal IP 
address, although ICMP works. Using floating IP works ok, but for the use 
case we are deploying, we need to always access VMs via internal IP, 
regardless of the VM having a float or not.

I remember this problem was corrected in DVR for the case of VMs with 
floating IPs assigned communicating via internal IPs (it works ok now).




On Thu, Jun 30, 2016 at 2:32 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
No, those routers are routers.  If one of them gets a packet, the router 
will forward the packet as usual for a router.

You might think they don't handle connections into tenant networks, but 
that might be because nothing is trying to use them as routers for the 
tenant networks.  That's a question about the routing tables in the rest 
of your environment.

If the client has a route to a Neutron tenant network that goes through a 
Neutron router, the client is able to connect to a server on the Neutron 
tenant network.

The normal configuration for routers on the internet is to not forward 
traffic to the RFC 1918 addresses.  I do not recall how the Neutron 
routers handle packets addressed to those addresses from sources on the 
"outside".

Regards,
Mike



From:Gustavo Randich <gustavo.rand...@gmail.com>
To:Mike Spreitzer/Watson/IBM@IBMUS
Cc:"openst...@lists.openstack.org" <openst...@lists.openstack.org
>, "openstack-operators@lists.openstack.org" <
openstack-operators@lists.openstack.org>
Date:06/30/2016 11:25 AM
Subject:Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)




Mike, as far as I know those routers allow only outgoing traffic, i.e. VM 
can see external networks, but those external networks cannot connect to 
VM if it doesn't have a FIP, am I right?

Thanks!
Gustavo

On Wed, Jun 29, 2016 at 7:24 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
Gustavo Randich <gustavo.rand...@gmail.com> wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike









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

Re: [Openstack] Stop external network to reach instances (Was: Reaching VXLAN tenant networks from outside (without floating IPs))

[Mike Spreitzer]

Turbo Fredriksson  wrote on 07/06/2016 07:29:48 AM:

> Ok, I managed to get this working as well. Was quite
> simple actually.
> 
> But how do I _STOP_ this from happening?? If there's a root
> user on the [local] network, they can simply add that route.
> But in some cases I'd like to make sure that this DOESN'T work!
> 
> 
> Is there some configuration I can do in either the router or
> in Openstack to make sure that traffic from the outside can't
> be routed in to the instance(s)?
> 
> I'd like that to happen ONLY if there's a floating IP for the
> host..

Floating IP for the host?  Those are usually for the guest.

Have you looked at Neutron's FWaaS?

Regards,
Mike



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

[Mike Spreitzer]

No, those routers are routers.  If one of them gets a packet, the router 
will forward the packet as usual for a router.

You might think they don't handle connections into tenant networks, but 
that might be because nothing is trying to use them as routers for the 
tenant networks.  That's a question about the routing tables in the rest 
of your environment.

If the client has a route to a Neutron tenant network that goes through a 
Neutron router, the client is able to connect to a server on the Neutron 
tenant network.

The normal configuration for routers on the internet is to not forward 
traffic to the RFC 1918 addresses.  I do not recall how the Neutron 
routers handle packets addressed to those addresses from sources on the 
"outside".

Regards,
Mike



From:   Gustavo Randich <gustavo.rand...@gmail.com>
To:     Mike Spreitzer/Watson/IBM@IBMUS
Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org>, 
"openstack-operat...@lists.openstack.org" 
<openstack-operat...@lists.openstack.org>
Date:   06/30/2016 11:25 AM
Subject:Re: [Openstack-operators] Reaching VXLAN tenant networks 
from outside (without floating IPs)



Mike, as far as I know those routers allow only outgoing traffic, i.e. VM 
can see external networks, but those external networks cannot connect to 
VM if it doesn't have a FIP, am I right?

Thanks!
Gustavo

On Wed, Jun 29, 2016 at 7:24 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
Gustavo Randich <gustavo.rand...@gmail.com> wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike






___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

[Mike Spreitzer]

Gustavo Randich  wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack-operators] Reaching VXLAN tenant networks from outside (without floating IPs)

[Mike Spreitzer]

Gustavo Randich  wrote on 06/29/2016 03:17:54 
PM:

> Hi operators...
> 
> Transitioning from nova-network to Neutron (Mitaka), one of the key 
> issues we are facing is how to reach VMs in VXLAN tenant networks 
> without using precious floating IPs.
> 
> Things that are outside Neutron in our case are:
> 
> - in-house made application orchestrator: needs SSH access to 
> instances to perform various tasks (start / shutdown apps, configure
> filesystems, etc.)
> 
> - various centralized and external monitoring/metrics pollers: need 
> SNMP / SSH access to gather status and trends
> 
> - internal customers: need SSH access to instance from non-openstack
> VPN service
> 
> - ideally, non-VXLAN aware traffic balancer appliances
> 
> We have considered these approaches:
> 
> - putting some of the external components inside a Network Node: 
> inviable because components need access to multiple Neutron deployments
> 
> - Neutron's VPNaaS: cannot figure how to configure a client-to-site 
> VPN topology
> 
> - integrate hardware switches capable of VXLAN VTEP: for us in this 
> stage, it is complex and expensive
> 
> - other?

You know Neutron includes routers that can route between tenant networks 
and external networks, right?  You could use those, if your tenant 
networks use disjoint IP subnets.

Regards,
Mike



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

Re: [openstack-dev] [Kuryr] [Neutron] Controlling security groups through Kuryr's libnetwork plugin [was: Waiting until Neutron PortisActive]

[Mike Spreitzer]

Antoni Segura Puimedon  wrote on 06/11/2016 
07:39:41 PM:

> Well, with a label you can make the Neutron Port have an SG that 
> forbids pinging.

Wait, what?  Labels on what can do what?

Thanks,
Mike


__
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] [Kuryr] [Neutron] Waiting until Neutron PortisActive

[Mike Spreitzer]

What about pinging?  BTW, from where would the pings come?

In the Docker/Swarm API today there is no way to disable ping.  However, 
once Kuryr's libnetwork plugin is updated so that `docker network connect 
--ip=W.X.Y.Z ...` will latch onto a matching pre-existing Neutron Port, if 
it exists, there will be a way for a user to disable pings (right?).

In the Kubernetes API there is now a way to do something like security 
groups, it is called NetworkPolicy; it is not yet well defined enough to 
say whether it gives the user a way to disable pings.

Thanks,
Mike



From:   Mohammad Banikazemi/Watson/IBM@IBMUS
To: "OpenStack Development Mailing List \(not for usage questions\)" 

Date:   06/10/2016 10:50 AM
Subject:Re: [openstack-dev] [Kuryr] [Neutron] Waiting until 
Neutron PortisActive



Hi Neil,

Currently, when a docker libnetwork "join" operation in Kuryr is returned, 
it is not guaranteed that the network connectivity has been established. 
There are containers that check for network connectivity as the first 
thing they do when they come up and under heavy load some notice there is 
no connectivity and simply bail out. I am trying to deal with such a use 
case,

Thanks for pointing out that option 2 won't work for you. I think 
Salvatore also alluded to that in his response. What you are suggesting 
with pinging the container from the appropriate namespace may be worth a 
try but then there may be containers that do not allow ingress traffic 
while they are up and happy. So short of what Salvatore suggested in his 
earlier email (and I am not sure if that can be done without additions to 
Neutron), we are left with option 1.

Keep in mind that users can choose not to enable the blocking option and 
things will be as they are right now. Would that be reasonable?

Best,

Mohammad

Neil Jerram ---06/10/2016 09:25:59 AM---Hi Mohammad, Why is the blocking 
needed? Is it to report some kind of status back to

From: Neil Jerram 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date: 06/10/2016 09:25 AM
Subject: Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron Port 
is Active



Hi Mohammad,

Why is the blocking needed?  Is it to report some kind of status back to 
Docker/Kubernetes, or to allow some follow-on action to happen?

When using networking-calico as the driver, I think that only option (1) 
would work, out of the options you've suggested below.  (3) doesn't work, 
as you say, because Calico doesn't involve an L2 agent.  Also Calico 
doesn't use the RPC message queue for reporting port status, because we've 
found that that message queue is in itself a scalability bottleneck.

I guess another option would be for the using system to determine for 
itself when the port appears to be working, e.g. by the host pinging the 
container/pod's IP address.

Regards,
Neil


On Wed, Jun 8, 2016 at 4:23 PM Mohammad Banikazemi  wrote:
For the Kuryr project, in order to support blocking until vifs are plugged 
in (that is adding config options similar to the following options define 
in Nova: vif_plugging_is_fatal and vif_plugging_timeout), we need to 
detect that the Neutron plugin being used is done with plugging a given 
vif.

Here are a few options:

1- The simplest approach seems to be polling for the status of the Neutron 
port to become Active. (This may lead to scalability issues but short of 
having a specific goal for scalability, it is not clear that will be the 
case.)
2- Alternatively, We could subscribe to the message queue and wait for 
such a port update event. 
3- It was also suggested that we could use l2 agent extension to detect 
such an event but that seems to limit us to certain Neutron plugins and 
therefore not acceptable.

I was wondering if there are other and better options. 

Best,

Mohammad
__
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

__
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

Re: [Openstack] Control network access between tenant networks in same neutron L3 router?

[Mike Spreitzer]

"Hong Hui Xiao"  wrote on 05/09/2016 10:55:17 PM:

> ...
> I think the neutron fwaas can meet your requirement. Try "neutron help | 

> grep firewall" and [1] to see more.
> 
> 
> [1] https://wiki.openstack.org/wiki/Neutron/FWaaS
> 
> 
> HongHui Xiao(肖宏辉)
> 
> 
> 
> From:   "Rui Mao" 
> To: 
> Date:   05/10/2016 09:22
> Subject:[Openstack] Control network access between tenant 
networks 
> in same neutron L3 router?
> 
> 
> 
> For example, tenant network A/B/C/D connect to same neutron L3 router. 
> A/B/C can communicate with D, but A/B/C cannot access each others.
> 
> Is this possible? Any performance issue should be considered?
> 
> Best regards,
> Rui Mao

But remember the discussion in 
http://lists.openstack.org/pipermail/openstack-operators/2016-May/010295.html

Regards,
Mike



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] [designate] multi-tenancy in Neutron's DNS integration

[Mike Spreitzer]

"Hayes, Graham" <graham.ha...@hpe.com> wrote on 05/09/2016 04:08:07 PM:

> ...
> On 09/05/2016 20:55, Mike Spreitzer wrote:
> ...
> > Oh, right, the network gets to specify the rest of the FQDN.  In my 
case
> > I am interested in Neutron Ports on tenant networks.  So with a 
per-port
> > "hostname" (first label) and per-network "domain" (rest of the 
labels),
> > I would get separation between tenants --- at least in the sense that
> > there is no overlap in FQDNs.  Will this work for private tenant 
networks?
> 
> Yes, you could publish the records to Designate for this, or using the
> internal dns resolution side of the integration.
> 
> Pushing the records to designate would make them viewable globally
> (anywhere the DNS servers are accessible)
> 
> 
> > The other part of separation is that I do not want one tenant to even 
be
> > able to look up FQDNs that belong to another tenant.  Is this
> > prohibition possible today?  If not, is anyone else interested in it?
> 
> Do you want to limit this to inside the tenant private network? if so, 
> just allowing users to set the dns_domain on a network, and not enabling 

> the external DNS plugin will work fine.

Ah, that may be what I want.  BTW, I am not planning to use Nova.  I am 
planning to use Swarm and Kubernetes to create containers attached to 
Neutron private tenant networks.  What DNS server would I configure those 
containers to use?

Thanks,
Mike




__
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] [designate] multi-tenancy in Neutron's DNS integration

[Mike Spreitzer]

"Hayes, Graham" <graham.ha...@hpe.com> wrote on 05/09/2016 03:00:34 PM:

> From: "Hayes, Graham" <graham.ha...@hpe.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: 05/09/2016 03:05 PM
> Subject: Re: [openstack-dev] [neutron] [designate] multi-tenancy in 
> Neutron's DNS integration
> 
> On 09/05/2016 19:21, Mike Spreitzer wrote:
> > I just read
> > 
http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.htmland
> , unless
> > I missed something, it seems to be describing something that is not
> > multi-tenant.  I am focused on FQDNs for Neutron Ports.  For those, 
only
> > the "hostname" part (the first label, in official DNS jargon) is
> > controllable by the Neutron user, the rest of the FQDN is fixed in
> > Neutron configuration.  Have I got that right?  If so then I am
> > surprised.  I would have expected something that isolates tenants
> > (projects) from one another.  Is there any interest in such a thing?
> >
> > Thanks,
> > Mike
> 
> ...
> 
> If you have per-project networks the integration can be done on a
> project by project basis, with floating IPs assigned the name from
> the port and the zone from the private network.

Oh, right, the network gets to specify the rest of the FQDN.  In my case I 
am interested in Neutron Ports on tenant networks.  So with a per-port 
"hostname" (first label) and per-network "domain" (rest of the labels), I 
would get separation between tenants --- at least in the sense that there 
is no overlap in FQDNs.  Will this work for private tenant networks?

The other part of separation is that I do not want one tenant to even be 
able to look up FQDNs that belong to another tenant.  Is this prohibition 
possible today?  If not, is anyone else interested in it?

Thanks,
Mike



__
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-dev] [neutron] [designate] multi-tenancy in Neutron's DNS integration

[Mike Spreitzer]

I just read 
http://docs.openstack.org/mitaka/networking-guide/adv-config-dns.html and, 
unless I missed something, it seems to be describing something that is not 
multi-tenant.  I am focused on FQDNs for Neutron Ports.  For those, only 
the "hostname" part (the first label, in official DNS jargon) is 
controllable by the Neutron user, the rest of the FQDN is fixed in Neutron 
configuration.  Have I got that right?  If so then I am surprised.  I 
would have expected something that isolates tenants (projects) from one 
another.  Is there any interest in such a thing?

Thanks,
Mike

__
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-dev] [kuryr] Question for Antoni Puimedon about load balancers and overlay networks

[Mike Spreitzer]

I am looking at 
https://www.openstack.org/videos/video/project-kuryr-docker-delivered-kubernetes-next
 
, around 28:00.  You have said that overlay networks are involved, and are 
now talking about load balancers.  Is this Neutron LBaaS?  As far as I 
know, a Neutron LBaaS instance is "one-armed" --- both the VIP and the 
back endpoints have to be on the same Neutron network.  But you seem to 
have all the k8s services on a single subnet.  So I am having some trouble 
following exactly what is going on.  Can you please elaborate?

BTW, there is also some discussion of k8s multi-tenancy in the Kubernetes 
Networking SIG and the Kubernetes OpenStack SIG.

Thanks,
Mike

__
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] Openstack powered Public cloud

[Mike Spreitzer]

There's no shortage of public IPv6 addresses.

Regards,
Mike

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [devstack][neutron] Eliminating the DevStack layer

[Mike Spreitzer]

I like this, for a reason not mentioned.  I am not a Neutron dev or 
operator and have never learned how to deploy Neutron; I have always 
driven it through DevStack.  The documentation for that has never been 
adequate, and I have concluded it will never be adequate.  With inadequate 
documentation, that layer isn't really doing its job anyway.  If there is 
no devstack layer getting in my way, I am willing to learn how to deploy 
Neutron from what I suppose is better documentation than I have been 
reading.  I understand that direct Neutron configuration is more 
troublesome than it should be.  Eliminating the devstack Neutron layer 
will only increase the pressure to both improve the documentation of 
Neutron configuration and simplify the subject, both of which are Good 
Things (TM).

Regards,
Mike



__
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-operators] [neutron] Attach routing rules to networks?

[Mike Spreitzer]

I assume `--host-route` works with a destination that is a single host. Is 
there something I can do to establish a routing rule for a destination 
that is a CIDR block?

Thanks,
Mike



From:   Joseph Bajin <josephba...@gmail.com>
To: James Denton <james.den...@rackspace.com>
Cc: Mike Spreitzer/Watson/IBM@IBMUS, openstack-operators 
<openstack-operators@lists.openstack.org>
Date:   04/04/2016 04:46 PM
Subject:Re: [Openstack-operators] [neutron] Attach routing rules 
to networks?



We use the host-route flag as mentioned above.  It makes it easy to sent 
internet like traffic to a gateway type of box and internal traffic to the 
inside for tenants that do have public access. 

On Sat, Apr 2, 2016 at 10:33 PM, James Denton <james.den...@rackspace.com> 
wrote:
Hi Mike,

You should be able to update the subnet(s) and use the --host-route flag 
with destination,nexthop pairs. The routes get pushed via DHCP.

James

Sent from my iPhone

On Apr 2, 2016, at 9:28 PM, Mike Spreitzer <mspre...@us.ibm.com> wrote:

Is there a way to attach a routing rule to a network or subnet, with the 
consequence that each device attached to that net or subnet gets that 
routing rule?

Thanks,
Mike


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

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





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

[openstack-dev] [kuryr] Did kuryr need to know about Docker's cluster store?

[Mike Spreitzer]

On Feb 5 I was given a tarchive of kuryr with an install script that 
configures the docker daemon to use consul as its cluster store.  If I 
modify the config of docker to use etcd instead then do I need to change 
anything in Kuryr?

Thanks,
Mike



__
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] - Changing the Neutron default security group rules

[Mike Spreitzer]

Kevin Benton  wrote on 03/02/2016 01:27:27 PM:

> Does it at least also include the UUID, or is there no way to tell 
> from 'nova show'?

No direct way to tell, as far as I can see.


__
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] - Changing the Neutron default security group rules

[Mike Spreitzer]

"Sean M. Collins"  wrote on 03/02/2016 01:16:52 PM:

> Meaning your users are creating new security groups and naming them
> "default" - so you have the "default" default (heh) and then the one
> that they created named default?
> 
> Are security group names in Nova-Net unqiue? I seem to recall that being
> a difference between Nova-Net and Neutron, where security group names
> are not unique in Neutron - hence the problem above.

I have seen this happen in a variety of use cases.  It does not bother me 
that security group names are scoped to tenants; other kinds of names also 
lack various kinds of uniqueness.  I am really just raising a tiny, 
peripheral rant here.  When I go in as admin to look at a problem, `nova 
show` identifies a Compute Instance's security group in a useless way.  If 
only I could make `nova show` tell me the UUID instead of, or in addition 
to, the security group's name then I would be happy.

Thanks,
Mike


__
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] - Changing the Neutron default security group rules

[Mike Spreitzer]

"Sean M. Collins"  wrote on 03/02/2016 12:38:29 PM:

> I think that the default security group should be left as is - and users
> should be trained that they should bring/create security groups with the
> appropriate rules for their need.

Could we at least make it less difficult to figure out which security 
group is attached to a Nova instance?  Right now `nova show` says only 
that the security group is named "default" and guess what --- they are 
*all* named default!  An admin looking at this is lost.


__
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-dev] [devstack] [neutron] How to ask for linuxbridge instead of openvswitch

[Mike Spreitzer]

How would I modify the recipe at 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
to get linuxbridge instead of openvswitch?

Thanks,
Mike



__
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] MTU configuration pain

[Mike Spreitzer]

BTW, regarding devstack: See 
https://bugs.launchpad.net/devstack/+bug/1532924.  I have been trying to 
get the current code to work, following the ideas in 
https://specs.openstack.org/openstack/fuel-specs/specs/7.0/jumbo-frames-between-instances.html#proposed-change
.  It fails only at the last step: the MTU on the network interface inside 
the VM is still 1500.

Regards,
Mike

__
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] MTU configuration pain

[Mike Spreitzer]

Adam Lawson  wrote on 01/23/2016 02:27:46 PM:

> For the sake of over-simplification, is there ever a reason to NOT 
> enable jumbo frames in a cloud/SDN context where most of the traffic
> is between virtual elements that all support it? I understand that 
> some switches do not support it and traffic form the web doesn't 
> support it either but besides that, seems like a default 
> "jumboframes = 1" concept would work just fine to me.
> 
> Then again I'm all about making OpenStack easier to consume so my 
> ideas tend to gloss over special use cases with special requirements.

Regardless of the default, there needs to be clear documentation on what 
to do for those of us who can not use jumbo frames, and it needs to work. 
That goes for production deployers and also for developers using DevStack.

Thanks,
Mike



__
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-operators] [openstack-operators]disable snat for router gateway

[Mike Spreitzer]

Aaron Segura  wrote on 01/16/2016 12:19:53 PM:

> You shouldn't have to do anything other than disable SNAT and set a 
> route for your tenant network upstream.

Indeed, I have exercised exactly this.

Regards,
Mike



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

Re: [Openstack-operators] [neutron] Routing to tenant networks

[Mike Spreitzer]

> From: Carl Baldwin <c...@ecbaldwin.net>
> To: Dan Sneddon <dsned...@redhat.com>
> Cc: Matt Kassawara <mkassaw...@gmail.com>, Mike Spreitzer/Watson/
> IBM@IBMUS, "openstack-operators@lists.openstack.org"  operat...@lists.openstack.org>
> Date: 01/14/2016 10:59 AM
> Subject: Re: [Openstack-operators] [neutron] Routing to tenant networks
> 
...
> 
> I'd discourage the use of 100.64.0.0/10 for any tenant networks.
> Quoted the RFC [1]:  "This address block will be called the "Shared
> Address Space" and will be used to number the interfaces that connect
> CGN devices to Customer Premises Equipment (CPE)." and "In particular,
> Shared Address Space can only be used in Service Provider networks or
> on routing equipment that is able to do address translation across
> router interfaces when the addresses are identical on two different
> interfaces."  It isn't spelled out clearly, but this hints at only
> using these addresses on infrastructure devices used in service
> providers' networks.  The closest this would get to a customer is
> assigning the router at the customer's edge an address from this range
> (like your home router's external address).  These devices pass
> packets and use the shared address space to communicate with other
> devices in the service provider's network but these addresses are
> never seen by the end user in the packets that reach their devices.
...

I think OpenStack's position should be that it is the operator's choice 
how to assign/use addresses.  And OpenStack's advice to the operators 
should be to follow the RFC (duh!).

Thanks,
Mike


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

Re: [Openstack] [neutron] User documentation for Neutron's Firewall-as-a-Service (FWaaS)?

[Mike Spreitzer]

> From: Matt Kassawara <mkassaw...@gmail.com>
> To: Mike Spreitzer/Watson/IBM@IBMUS
> Cc: "openstack@lists.openstack.org" <openstack@lists.openstack.org>
> Date: 01/12/2016 12:16 PM
> Subject: Re: [Openstack] [neutron] User documentation for Neutron's 
> Firewall-as-a-Service (FWaaS)?
> 
> Not really... :/
> 
> On Tue, Jan 12, 2016 at 9:43 AM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
> Is there any user documentation for FWaaS besides http://
> docs.openstack.org/admin-guide-cloud/
> networking_introduction.html#firewall-as-a-service-fwaas-overview
> ?  That one is a bit skimpy and, I suspect, a little outdated. For 
> example, `neutron help firewall-create` mentions an option, `--
> router`, that is not mentioned in that doc section and not well 
> explained in the on-line help.

So can someone please explain the `--router` option to `neutron 
firewall-create` in more detail?  Here is what I get from `neutron help 
firewall-create`:

usage: neutron firewall-create [-h] [-f {json,shell,table,value,yaml}]
   [-c COLUMN] [--max-width ]
   [--noindent] [--prefix PREFIX]
   [--request-format {json,xml}]
   [--tenant-id TENANT_ID] [--name NAME]
   [--description DESCRIPTION]
   [--admin-state-down] [--router ROUTER]
   POLICY

...
optional arguments:
...
  --router ROUTER   Firewall associated router names or IDs (requires
FWaaS router insertion extension, this option can 
be
repeated)
...

Is there someplace I can learn more about this "FWaaS router insertion 
extension"?  When I use DevStack, does it install this extension?  How do 
I controls its installation when using DevStack?  How do I install it when 
not using DevStack?  How, in general, can I tell whether it is 
installed/enabled?  What happens if I do not supply a `--router` argument 
to this command?  Does the answer to that depend on whether the FWaaS 
router insertion extension is installed/enabled?

Thanks,
Mike



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [neutron] User documentation for Neutron's Firewall-as-a-Service (FWaaS)?

[Mike Spreitzer]

Is there any user documentation for FWaaS besides 
http://docs.openstack.org/admin-guide-cloud/networking_introduction.html#firewall-as-a-service-fwaas-overview
 
?  That one is a bit skimpy and, I suspect, a little outdated.  For 
example, `neutron help firewall-create` mentions an option, `--router`, 
that is not mentioned in that doc section and not well explained in the 
on-line help.
 
Thanks,
Mike



___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] [neutron] Routing to tenant networks

[Mike Spreitzer]

Is there any condition under which a Neutron router will route packets 
from a provider network to a tenant network with destination address 
unmolested? E.g., non-RFC1918 addresses on the tenant network?  Does 
Neutron know anything about RFC6598?

Thanks,
Mike



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

[openstack-dev] [devstack] [neutron] Progress, and current problems

[Mike Spreitzer]

I have been trying to get 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
working on Ubuntu 14.04 (updated to the latest, which includes kernel 
3.19).  With the latest sources and a sufficiently recent OVS, the 
one-node install pretty much works!  I added to local.conf only: (a) 
IP_VERSION=4, to avoid issues with v6, and (b) some settings to get logs 
saved to files without coloring.

In particular, what I have done regarding OVS is to download 2.4 and build 
the .deb packages according to the instructions.  I used the kernel 
datapath from the linux kernel 3.19.  I installed the openvswitch-common 
and openvswitch-switch .debs that I built.

I think the doc should be enhanced to discuss IPv6.  I tried once without 
the `IP_VERSION=4`, and the resulting IPv6 config was not good.

IMHO the default should be to keeps logs in files without coloring, 
because that is the most user-friendly.  I think that for DevStack the 
defaults should be friendly to newbies, since this is where they start.

I then went on to 
http://docs.openstack.org/developer/devstack/guides/neutron.html#adding-additional-compute-nodes
 
, and ran into MTU problems.  All MTUs come out to be 1500, which just 
does not work (due to the tunneling overhead).

I then tried a fresh DevStack install with a revised local.conf derived 
from 
https://specs.openstack.org/openstack/fuel-specs/specs/7.0/jumbo-frames-between-instances.html#proposed-change
 
.  Specifically, this is what I added to my local.conf for MTU issues:

[[post-config|$NEUTRON_CONF]]
[DEFAULT]
advertise_mtu=True
network_device_mtu=1450

[[post-config|/$Q_PLUGIN_CONF_FILE]]
[ml2]
physical_network_mtus = public:1450

That got me MTUs of 1450 on the router and DHCP ports but not the VM 
plumbing.  Perhaps I read too much into the word "keep".

Then I added

network_device_mtu = 65000

to the DEFAULT section of nova.conf, then restarted all the nova 
processes.  I created a new VM after that.  The result was that the 
qbr..., qvo..., qvb..., and tap... network interfaces in the main netns 
have MTU of 65000 --- and eth0 inside the VM has an MTU of 1500.

So then I changed the network_device_mtu setting in nova.conf to 1450, 
restarted all the nova processes again, and made another new VM.  Now the 
qbr..., qvo..., qvb..., and tap... network interfaces in the main netns 
have MTU of 1450 but the VM still got an MTU of 1500 on its eth0.

In my logs directory, `grep 'Running command' *.log | grep set | grep -i 
mtu` finds only the setting of the MTUs of the router and DHCP stuff --- 
nothing for any of the VMs.

Regards,
Mike



__
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] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

[Mike Spreitzer]

> From: Kyle Mestery <mest...@mestery.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: 01/03/2016 02:15 PM
> Subject: Re: [openstack-dev] [devstack] [neutron] Procedure for 
> back-porting a bug fix to stable/liberty branch of a Neutron script 
> in DevStack?
> 
> On Sun, Jan 3, 2016 at 4:01 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
> I would like to back-port https://review.openstack.org/#/c/242721/
> --- which fixed https://bugs.launchpad.net/devstack/+bug/1469596--- 
> to stable/liberty.  I have contributed to main line development 
> before, but not stable branches.  I see that http://
> docs.openstack.org/infra/manual/developers.htmldoes not specifically
> address this case.  What is the procedure to follow?

> The best place to look is in the project team guide [1], 
> specifically the section on proposing fixes.
> 
> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> [2] 
http://docs.openstack.org/project-team-guide/stable-branches.html#proposing-fixes


Reference [2] says I should

$ git checkout stable/tango

but that doesn't work.  Here is a typescript of how it goes wrong:

mjs10:devstack mspreitz$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

mjs10:devstack mspreitz$ git pull
Already up-to-date.

mjs10:devstack mspreitz$ git remote -v
gerrit 
ssh://mspre...@review.openstack.org:29418/openstack-dev/devstack.git 
(fetch)
gerrit 
ssh://mspre...@review.openstack.org:29418/openstack-dev/devstack.git 
(push)
origin  https://github.com/openstack-dev/devstack.git (fetch)
origin  https://github.com/openstack-dev/devstack.git (push)

mjs10:devstack mspreitz$ git checkout stable/liberty
error: pathspec 'stable/liberty' did not match any file(s) known to git.



__
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] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

[Mike Spreitzer]

> From: Kyle Mestery <mest...@mestery.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: 01/03/2016 02:15 PM
> Subject: Re: [openstack-dev] [devstack] [neutron] Procedure for 
> back-porting a bug fix to stable/liberty branch of a Neutron script 
> in DevStack?
> 
> On Sun, Jan 3, 2016 at 4:01 PM, Mike Spreitzer <mspre...@us.ibm.com> 
wrote:
> I would like to back-port https://review.openstack.org/#/c/242721/
> --- which fixed https://bugs.launchpad.net/devstack/+bug/1469596--- 
> to stable/liberty.  I have contributed to main line development 
> before, but not stable branches.  I see that http://
> docs.openstack.org/infra/manual/developers.htmldoes not specifically
> address this case.  What is the procedure to follow?

> The best place to look is in the project team guide [1], 
> specifically the section on proposing fixes.
> 
> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> [2] http://docs.openstack.org/project-team-guide/stable-
> branches.html#proposing-fixes

Regarding the mechanics, I was given the following alternate recipe in a 
discussion on #openstack-neutron; I assume it is pretty much equivalent.

"do something like 'git checkout -b libery/backport/### 
remotes/origin/stable/liberty' then 'git pull' then 'git review -X ###' 
then push it for review"

Thanks,
Mike


__
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-dev] [devstack] [neutron] Procedure for back-porting a bug fix to stable/liberty branch of a Neutron script in DevStack?

[Mike Spreitzer]

I would like to back-port https://review.openstack.org/#/c/242721/ --- 
which fixed https://bugs.launchpad.net/devstack/+bug/1469596 --- to 
stable/liberty.  I have contributed to main line development before, but 
not stable branches.  I see that 
http://docs.openstack.org/infra/manual/developers.html does not 
specifically address this case.  What is the procedure to follow?

Thanks,
Mike

__
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] Multiple locations for documentation of features

[Mike Spreitzer]

> From: Henry Gessau 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 12/04/2015 02:23 PM
> Subject: Re: [openstack-dev] [neutron] Multiple locations for 
> documentation of features
> 
> Sean M. Collins  wrote:
> > I've noticed that a lot of features are now being documented as RSTs
> > inside of devref. Like the following:
> > 
> > https://review.openstack.org/#/c/251859/
> > 
> > But there are lots already present. Can someone point out to me what 
the
> > criteria is for these documents? I am a little confused about the
> > relationship between neutron-specs, RFE bugs, and some features being
> > documented in devref. Especially when a review includes the actual 
code,
> > then a new RST file in devref - wasn't that what specs were for?
> 
> Here is how I would like to see things ending up:
> 
> 1. RFE: "I want X"
> 2. Spec: "I plan to implement X like this"
> 3. devref: "How X is implemented and how to extend it"
> 4. OS docs: "API and guide for using X"
> 
> Once X is implemented I don't want to have to go to 1 or 2 to find 
information
> on it. The devref may have a lot of content from the spec, but the spec 
is not
> maintained and the implementation may differ in some ways. The devref 
should
> be kept current with refactorings, etc. of the implementation.

Lots cheers from me too.  Let me add one thing: "the spec is not 
maintained" is a remaining process bug.  A spec by itself is a very useful 
thing.  It is the first thing to read when trying to understand the 
implementation.  How about we resolve that devref includes a maintained 
version of the spec?

Regards,
Mike

__
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-dev] The OVS and Provider Networks section of the guide to Neutron in DevStack

[Mike Spreitzer]

First let me make sure I understand what this section (
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
) is trying to say.  The second paragraph is saying that some 
infrastructure provider has allocated a VLAN tag (and the later display of 
localrc contents uses 2010 as that tag) and an address range (later seen 
to be 203.0.113.0/24) to use on that VLAN on provider_net.  The exhibited 
localrc contents also say that tenant networks can be created, using VLAN 
tags drawn from the range 3001:4000.  Those localrc contents do not 
explicitly say which ethernet --- provider_net or control_plane --- will 
carry those tenant VLANs.  Which ethernet do you think those localrc 
contents imply will carry the tenant VLANs?

Second, I tested this using stable/liberty on Ubuntu 14.04.03, and got a 
few surprises.  I did exactly as described by that section, starting from 
a "physical network setup" as described there (but it was actually 
virtual, using VirtualBox), and using the localrc contents exhibited there 
except patched to fix bugs 
https://bugs.launchpad.net/devstack/+bug/1508195 and 
https://bugs.launchpad.net/devstack/+bug/1508202 (the latter by sadly 
stipulating IP_VERSION=4).  After creating the controller, compute1, and 
compute2 I looked at `ovs-vsctl show` on the controller, and found that 
br-tun had two VxLan ports (see display below).  This surprised me because 
I thought that VxLan can itself handle multiple hosts, it is not just 
point-to-point.

Bridge br-tun
fail_mode: secure
Port "vxlan-0a03"
Interface "vxlan-0a03"
type: vxlan
options: {df_default="true", in_key=flow, 
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.3"}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port "vxlan-0a04"
Interface "vxlan-0a04"
type: vxlan
options: {df_default="true", in_key=flow, 
local_ip="10.0.0.2", out_key=flow, remote_ip="10.0.0.4"}
Port br-tun
Interface br-tun
type: internal

My second surprise is that the path from controller to the VM's host goes 
over the control_plane network --- somewhat contrary to its name!

My third surprise came after I made a VM on the provider network and tried 
to ping it from the router.  I got no response.  A little investigation 
shows that the router's ARP request for the VM gets lost somewhere between 
br-int and br-tun.  `tcpdump -nne -i br-int` on the controller shows the 
ARP requests appearing with VLAN tag 1 (which is right, the external VLAN 
tags are translated to internal host-local tags on br-int), and no ARP 
replies.  OTOH, `tcpdump -nne -i br-tun` does not even find the ARP 
requests.

Digging a little deeper, I looked at the OpenFlow tables on the 
controller.  It looks like the flow table for br-tun does indeed prescribe 
that all traffic coming from outside be dropped!  Here is the output from 
`ovs-appctl bridge/dump-flows br-tun`:

duration=23916s, priority=1, n_packets=0, n_bytes=0, 
priority=1,in_port=3,actions=resubmit(,4)
duration=39904s, priority=1, n_packets=82, n_bytes=7025, 
priority=1,in_port=1,actions=resubmit(,2)
duration=36711s, priority=1, n_packets=0, n_bytes=0, 
priority=1,in_port=2,actions=resubmit(,4)
duration=39904s, priority=0, n_packets=7, n_bytes=558, 
priority=0,actions=drop
table_id=2, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00,actions=resubmit(,20)
table_id=2, duration=39904s, priority=0, n_packets=82, n_bytes=7025, 
priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=resubmit(,22)
table_id=3, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=4, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=6, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=drop
table_id=10, duration=39904s, priority=1, n_packets=0, n_bytes=0, 
priority=1,actions=learn(table=20,hard_timeout=300,priority=1,cookie=0xb64bc7164f7e1137,NXM_OF_VLAN_TCI[0..11],NXM_OF_ETH_DST[]=NXM_OF_ETH_SRC[],load:0->NXM_OF_VLAN_TCI[],load:NXM_NX_TUN_ID[]->NXM_NX_TUN_ID[],output:NXM_OF_IN_PORT[]),output:1
table_id=20, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,actions=resubmit(,22)
table_id=22, duration=39904s, priority=0, n_packets=82, n_bytes=7025, 
priority=0,actions=drop
table_id=254, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,reg0=0x3,actions=drop
table_id=254, duration=39904s, priority=0, n_packets=1, n_bytes=90, 
priority=0,reg0=0x1,actions=controller(reason=no_match)
table_id=254, duration=39904s, priority=0, n_packets=0, n_bytes=0, 
priority=0,reg0=0x2,actions=drop

By examining `ovs-vsctl list Interface` I can see that patch-int is 
OpenFlow 

Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Mike Spreitzer]

"Sean M. Collins" <s...@coreitpro.com> wrote on 10/16/2015 01:03:53 PM:

> From: "Sean M. Collins" <s...@coreitpro.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: 10/16/2015 01:12 PM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> On Fri, Oct 16, 2015 at 02:02:57AM EDT, Mike Spreitzer wrote:
> > Now I have tested the first section (taking the latest of both 
changes) 
> > using stable/liberty, and it failed because br-ex was not created 
> > automatically.  I opened 
https://bugs.launchpad.net/devstack/+bug/1506733
> > 
> > I think Kilo did not have this problem.
> > 
> 
> Ok. I have assigned myself the bug. I will be sightseeing with my 
partner
> Caroline in Tokyo next week before the summit, so it may take me a
> little bit of time to get around to it, but I will try and follow up on
> the bug after the summit.

Thanks.  I am going to do some more tests in the interim, to see what I 
can add.

Thanks,
Mike



__
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] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Mike Spreitzer]

> From: Mike Spreitzer/Watson/IBM@IBMUS
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev@lists.openstack.org>
> Date: 10/13/2015 03:39 AM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> > From: "Sean M. Collins" <s...@coreitpro.com>
> > To: "OpenStack Development Mailing List (not for usage questions)" 
> > <openstack-dev@lists.openstack.org>
> > Date: 10/12/2015 11:34 AM
> > Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> > questions about configuring DevStack to use Neutron
> > 
> > On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:
> > > ..
> > > > > In the section 
> > > > > http://docs.openstack.org/developer/devstack/guides/
> > > > neutron.html#using-neutron-with-a-single-interface
> > > > > there is a helpful display of localrc contents.  It says, among 
other 
> > > > > things,
> > > > > 
> > > > >OVS_PHYSICAL_BRIDGE=br-ex
> > > > >PUBLIC_BRIDGE=br-ex
> > > > > 
> > > > > In the next top-level section, 
> > > > > http://docs.openstack.org/developer/devstack/guides/
> > > > neutron.html#using-neutron-with-multiple-interfaces
> > > > > , there is no display of revised localrc contents and no mention 
of 
> > > > > changing either bridge setting.  That is an oversight, right?
> > > > 
> > > > No, this is deliberate. Each section is meant to be independent, 
since
> > > > each networking configuration and corresponding DevStack 
configuration
> > > > is different. Of course, this may need to be explicitly stated in 
the
> > > > guide, so there is always room for improvement.
> > > 
> > > I am not quite sure I understand your answer.  Is the intent that I 
can 
> > > read only one section, ignore all the others, and that will tellme 
how to 
> > > use DevStack to produce that section's configuration?  If so 
> then it would 
> > > be good if each section had a display of all the necessary localrc 
> > > contents.
> > 
> > Agreed. This is a failure on my part, because I was pasting in only
> > parts of my localrc (since it came out of a live lab environment). 
I've
> > started pushing patches to correct this.
> > 
> > 
> > > I have started over, from exactly the picture drawn at the start of 
the 
> > > doc.  That has produced a configuration that mostly works.  However, 
I 
> > > tried creating a VM connected to the public network, and that failed 
for 
> > > lack of a Neutron DHCP server there.
> > 
> > The public network is used for floating IPs. The L3 agent creates NAT
> > rules to intercept traffic on the public network and NAT it back to a
> > guest instance that has the floating IP allocated to it.
> > 
> > The behavior for when a guest is directly attached to the public
> > network, I sort of forget what happens exactly but I do know that it
> > doesn't work from experience - most likely because the network is not
> > configured as a flat network. It will not receive a DHCP lease from 
the
> > external router.
> > 
> > > I am going to work out how to change 
> > > that, and am willing to contribute an update to this doc.  Wouldyou 
want 
> > > that in this section --- in which case this section needs to specify 
that 
> > > the provider DOES NOT already have DHCP service on the hardware 
network 
> > > --- or as a new section?
> > 
> > No, I think we should maybe have a warning or something that the
> > external network will be used for Floating IPs, and that guest 
instances
> > should not be directly attached to that network.
> > 
> > > > > 
> > > > > Looking at 
> > > > > 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or
> > > , in 
> > > > > former days, the doc now preserved at 
> > > > > http://docs.ocselected.org/openstack-manuals/kilo/networking-
> > > > guide/content/under_the_hood_openvswitch.html
> > > > > ) I see the name br-ex used for $PUBLIC_BRIDGE--- not 
> > > $OVS_PHYSICAL_BRIDGE
> > > > > , right?  Wouldn't it be less confusing if 
> > > > > 
http://docs.openstack.org/developer/devstack/guides/neutron.htmluseda 
> > > 
> > > > > name other than "br-ex" 

Re: [openstack-dev] [devstack] A few questions on configuring DevStack for Neutron

[Mike Spreitzer]

Matt Riedemann  wrote on 10/08/2015 09:48:33 
PM:

> On 10/8/2015 11:38 AM, Sean M. Collins wrote:
> > Please see my response here:
> >
> > 
http://lists.openstack.org/pipermail/openstack-dev/2015-October/076251.html

> >
> > In the future, do not create multiple threads since responses will get
> > lost
> >
> 
> Maybe a dumb question, but couldn't people copy the localrc from the 
> gate-tempest-dsvm-neutron-full job, i.e.:
> 
> http://logs.openstack.org/20/231720/1/check/gate-tempest-dsvm-
> neutron-full/f418dc8/logs/localrc.txt.gz

Matt, thanks for the reminder.  I was pointed at one of those once before, 
but do not remember how to find them in general.  To be useful in 
http://docs.openstack.org/developer/devstack/guides/neutron.html we need 
to identify which section they illuminate, or add another section with 
appropriate explanation.  Which would it be?

Sean, you said that those URLs are tribal knowledge.  Would you recommend 
documenting them and, if so, where?  I see that the one Matt cited is part 
of a comprehensive archive from a tempest run, and there is even some 
explanatory material included within that run's archive.  Would it be 
possible and appropriate for the DevStack Neutron guide to point to some 
documentation that describes these archives?

Thanks,
Mike



__
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] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Mike Spreitzer]

> From: "Sean M. Collins" <s...@coreitpro.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: 10/12/2015 11:34 AM
> Subject: Re: [openstack-dev] [devstack] [neutron] A larger batch of 
> questions about configuring DevStack to use Neutron
> 
> On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote:
> > ..
> > > > In the section 
> > > > http://docs.openstack.org/developer/devstack/guides/
> > > neutron.html#using-neutron-with-a-single-interface
> > > > there is a helpful display of localrc contents.  It says, among 
other 
> > > > things,
> > > > 
> > > >OVS_PHYSICAL_BRIDGE=br-ex
> > > >PUBLIC_BRIDGE=br-ex
> > > > 
> > > > In the next top-level section, 
> > > > http://docs.openstack.org/developer/devstack/guides/
> > > neutron.html#using-neutron-with-multiple-interfaces
> > > > , there is no display of revised localrc contents and no mention 
of 
> > > > changing either bridge setting.  That is an oversight, right?
> > > 
> > > No, this is deliberate. Each section is meant to be independent, 
since
> > > each networking configuration and corresponding DevStack 
configuration
> > > is different. Of course, this may need to be explicitly stated in 
the
> > > guide, so there is always room for improvement.
> > 
> > I am not quite sure I understand your answer.  Is the intent that I 
can 
> > read only one section, ignore all the others, and that will tell me 
how to 
> > use DevStack to produce that section's configuration?  If so then it 
would 
> > be good if each section had a display of all the necessary localrc 
> > contents.
> 
> Agreed. This is a failure on my part, because I was pasting in only
> parts of my localrc (since it came out of a live lab environment). I've
> started pushing patches to correct this.
> 
> 
> > I have started over, from exactly the picture drawn at the start of 
the 
> > doc.  That has produced a configuration that mostly works.  However, I 

> > tried creating a VM connected to the public network, and that failed 
for 
> > lack of a Neutron DHCP server there.
> 
> The public network is used for floating IPs. The L3 agent creates NAT
> rules to intercept traffic on the public network and NAT it back to a
> guest instance that has the floating IP allocated to it.
> 
> The behavior for when a guest is directly attached to the public
> network, I sort of forget what happens exactly but I do know that it
> doesn't work from experience - most likely because the network is not
> configured as a flat network. It will not receive a DHCP lease from the
> external router.
> 
> > I am going to work out how to change 
> > that, and am willing to contribute an update to this doc.  Would you 
want 
> > that in this section --- in which case this section needs to specify 
that 
> > the provider DOES NOT already have DHCP service on the hardware 
network 
> > --- or as a new section?
> 
> No, I think we should maybe have a warning or something that the
> external network will be used for Floating IPs, and that guest instances
> should not be directly attached to that network.
> 
> > > > 
> > > > Looking at 
> > > > 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or
> > , in 
> > > > former days, the doc now preserved at 
> > > > http://docs.ocselected.org/openstack-manuals/kilo/networking-
> > > guide/content/under_the_hood_openvswitch.html
> > > > ) I see the name br-ex used for $PUBLIC_BRIDGE--- not 
> > $OVS_PHYSICAL_BRIDGE
> > > > , right?  Wouldn't it be less confusing if 
> > > > 
http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a 
> > 
> > > > name other than "br-ex" for the exhibited commands that apply to 
> > > > $OVS_PHYSICAL_BRIDGE?
> > > 
> > > No, this is deliberate - br-ex is the bridge that is used for 
external
> > > network traffic - such as floating IPs and public IP address ranges. 
On
> > > the network node, a physical interface is attached to br-ex so that
> > > traffic will flow.
> > > 
> > > PUBLIC_BRIDGE is a carryover from DevStack's Nova-Network support 
and is
> > > used in some places, with OVS_PHYSICAL_BRIDGE being used by 
DevStack's
> > > Neutron support, for the Open vSwitch driver specifically. They are 
two
> > > variables that for the most part serve the same pu

Re: [openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Mike Spreitzer]

Thanks, i will review soon.  BTW, i am interested in creating a config in which 
a Compute Instance can be created on an external network.

Thanks,
Mike




   Sean M. Collins --- Re: [openstack-dev] [devstack] [neutron] A larger batch 
of questions about configuring DevStack to use Neutron --- 
From:"Sean M. Collins" <s...@coreitpro.com>To:"OpenStack Development 
Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>Date:Mon, Oct 12, 2015 11:34Subject:Re: 
[openstack-dev] [devstack] [neutron] A larger batch of questions about 
configuring DevStack to use Neutron
  On Thu, Oct 08, 2015 at 01:47:31PM EDT, Mike Spreitzer wrote: > .. > > > In 
the section > > > http://docs.openstack.org/developer/devstack/guides/ > > 
neutron.html#using-neutron-with-a-single-interface > > > there is a helpful 
display of localrc contents. It says, among other > > > things, > > > > > > 
OVS_PHYSICAL_BRIDGE=br-ex > > > PUBLIC_BRIDGE=br-ex > > > > > > In the next 
top-level section, > > > http://docs.openstack.org/developer/devstack/guides/ > 
> neutron.html#using-neutron-with-multiple-interfaces > > > , there is no 
display of revised localrc contents and no mention of > > > changing either 
bridge setting. That is an oversight, right? > > > > No, this is deliberate. 
Each section is meant to be independent, since > > each networking 
configuration and corresponding DevStack configuration > > is different. Of 
course, this may need to be explicitly stated in the > > guide, so there is 
always room for improvement. > > I am not quite sure I understand your answer. 
Is the intent that I can > read only one section, ignore all the others, and 
that will tell me how to > use DevStack to produce that section's 
configuration? If so then it would > be good if each section had a display of 
all the necessary localrc > contents. Agreed. This is a failure on my part, 
because I was pasting in only parts of my localrc (since it came out of a live 
lab environment). I've started pushing patches to correct this. > I have 
started over, from exactly the picture drawn at the start of the > doc. That 
has produced a configuration that mostly works. However, I > tried creating a 
VM connected to the public network, and that failed for > lack of a Neutron 
DHCP server there. The public network is used for floating IPs. The L3 agent 
creates NAT rules to intercept traffic on the public network and NAT it back to 
a guest instance that has the floating IP allocated to it. The behavior for 
when a guest is directly attached to the public network, I sort of forget what 
happens exactly but I do know that it doesn't work from experience - most 
likely because the network is not configured as a flat network. It will not 
receive a DHCP lease from the external router. > I am going to work out how to 
change > that, and am willing to contribute an update to this doc. Would you 
want > that in this section --- in which case this section needs to specify 
that > the provider DOES NOT already have DHCP service on the hardware network 
> --- or as a new section? No, I think we should maybe have a warning or 
something that the external network will be used for Floating IPs, and that 
guest instances should not be directly attached to that network. > > > > > > 
Looking at > > > 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or > , in > 
> > former days, the doc now preserved at > > > 
http://docs.ocselected.org/openstack-manuals/kilo/networking- > > 
guide/content/under_the_hood_openvswitch.html > > > ) I see the name br-ex used 
for $PUBLIC_BRIDGE--- not > $OVS_PHYSICAL_BRIDGE > > > , right? Wouldn't it be 
less confusing if > > > 
http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a > > > > 
name other than "br-ex" for the exhibited commands that apply to > > > 
$OVS_PHYSICAL_BRIDGE? > > > > No, this is deliberate - br-ex is the bridge that 
is used for external > > network traffic - such as floating IPs and public IP 
address ranges. On > > the network node, a physical interface is attached to 
br-ex so that > > traffic will flow. > > > > PUBLIC_BRIDGE is a carryover from 
DevStack's Nova-Network support and is > > used in some places, with 
OVS_PHYSICAL_BRIDGE being used by DevStack's > > Neutron support, for the Open 
vSwitch driver specifically. They are two > > variables that for the most part 
serve the same purpose. Frankly, > > DevStack has a lot of problems with 
configuration knobs, and > > PUBLIC_BRIDGE and OVS_PHYSICAL_BRIDGE is just a 
symptom. > > 

Re: [openstack-dev] [all] Recording little everyday OpenStack successes

[Mike Spreitzer]

Thierry Carrez  wrote on 10/09/2015 05:42:49 AM:

...
> So whenever you feel like you made progress, or had a little success in
> your OpenStack adventures, or have some joyful moment to share, just
> throw the following message on your local IRC channel:
> 
> #success [Your message here]
> 
> The openstackstatus bot will take that and record it on this wiki page:
> 
> https://wiki.openstack.org/wiki/Successes
> 
> We'll add a few of those every week to the weekly newsletter (as part of
> the developer digest that we reecently added there).
> 
> Caveats: Obviously that only works on channels where openstackstatus is
> present (the official OpenStack IRC channels), and we may remove entries
> that are off-topic or spam.
> 
> So... please use #success liberally and record lttle everyday OpenStack
> successes. Share the joy and make the OpenStack community a happy place.

Great.  I am about to contribute one myself.  Lucky I noticed this email. 
How will the word get out to those who did not?  How about a pointer to 
instructions on the Successes page?

Thanks,
Mike


__
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] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Mike Spreitzer]

> From: "Sean M. Collins" <s...@coreitpro.com>
...
> 
> On Tue, Oct 06, 2015 at 11:25:03AM EDT, Mike Spreitzer wrote:
> > [Sorry, but I do not know if the thundering silence is because these 
> > questions are too hard, too easy, grossly off-topic, or simply because 

> > nobody cares.]
> 
> You sent your first e-mail on a Saturday. I saw it and flagged it for
> reply, but have not had a chance yet. It's only Tuesday. I do care and
> your questions are important. I will say though that it's a little
> difficult to answer your e-mail because of formatting and your thoughts
> seem to jump around. This is not intended as a personal criticism, it's
> just a little difficult to follow your e-mail in order to reply.

Thanks, I am glad somebody cares.  I used different subject lines because 
I was suspecting that I did not flag them correctly.  I see now that I was 
just too impatient.

..
> > In the section 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#using-neutron-with-a-single-interface
> > there is a helpful display of localrc contents.  It says, among other 
> > things,
> > 
> >OVS_PHYSICAL_BRIDGE=br-ex
> >PUBLIC_BRIDGE=br-ex
> > 
> > In the next top-level section, 
> > http://docs.openstack.org/developer/devstack/guides/
> neutron.html#using-neutron-with-multiple-interfaces
> > , there is no display of revised localrc contents and no mention of 
> > changing either bridge setting.  That is an oversight, right?
> 
> No, this is deliberate. Each section is meant to be independent, since
> each networking configuration and corresponding DevStack configuration
> is different. Of course, this may need to be explicitly stated in the
> guide, so there is always room for improvement.

I am not quite sure I understand your answer.  Is the intent that I can 
read only one section, ignore all the others, and that will tell me how to 
use DevStack to produce that section's configuration?  If so then it would 
be good if each section had a display of all the necessary localrc 
contents.  OTOH, if some sections build on other sections, it would be 
good if the dependent sections display the localrc contents that differ. 
Right now, the section at 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
 
does not display any localrc contents at all.

> For example, There needs
> to be some editing done for that doc - the part about disabling the
> firewall is just dropped in the middle of the doc and breaks the flow -
> among other things. This is obviously not helpful to a new reader and we
> need to fix.
> 
> 
> > I am 
> > guessing I need to set OVS_PHYSICAL_BRIDGEand PUBLIC_BRIDGEto 
different 
> > values, and the exhibited `ovs-vsctl` commands in this section apply 
to 
> > $OVS_PHYSICAL_BRIDGE.  Is that right?  Are there other revisions I 
need to 
> > make to localrc?
> 
> No, this is not correct.
> 
> What does your networking layout look like on the DevStack node that you
> are trying to configure?

I have started over, from exactly the picture drawn at the start of the 
doc.  That has produced a configuration that mostly works.  However, I 
tried creating a VM connected to the public network, and that failed for 
lack of a Neutron DHCP server there.  I am going to work out how to change 
that, and am willing to contribute an update to this doc.  Would you want 
that in this section --- in which case this section needs to specify that 
the provider DOES NOT already have DHCP service on the hardware network 
--- or as a new section?

> 
> 
> > 
> > Looking at 
> > http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or
, in 
> > former days, the doc now preserved at 
> > http://docs.ocselected.org/openstack-manuals/kilo/networking-
> guide/content/under_the_hood_openvswitch.html
> > ) I see the name br-ex used for $PUBLIC_BRIDGE--- not 
$OVS_PHYSICAL_BRIDGE
> > , right?  Wouldn't it be less confusing if 
> > http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a 

> > name other than "br-ex" for the exhibited commands that apply to 
> > $OVS_PHYSICAL_BRIDGE?
> 
> No, this is deliberate - br-ex is the bridge that is used for external
> network traffic - such as floating IPs and public IP address ranges. On
> the network node, a physical interface is attached to br-ex so that
> traffic will flow.
> 
> PUBLIC_BRIDGE is a carryover from DevStack's Nova-Network support and is
> used in some places, with OVS_PHYSICAL_BRIDGE being used by DevStack's
> Neutron support, for the Open vSwitch driver specifically. They are two
> variables that for the most part serve the same p

[openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

[Mike Spreitzer]

[Sorry, but I do not know if the thundering silence is because these 
questions are too hard, too easy, grossly off-topic, or simply because 
nobody cares.]

I have been looking at 
http://docs.openstack.org/developer/devstack/guides/neutron.htmland wonder 
about a few things.

In the section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
there is a helpful display of localrc contents.  It says, among other 
things,

   OVS_PHYSICAL_BRIDGE=br-ex
   PUBLIC_BRIDGE=br-ex

In the next top-level section, 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
, there is no display of revised localrc contents and no mention of 
changing either bridge setting.  That is an oversight, right?  I am 
guessing I need to set OVS_PHYSICAL_BRIDGEand PUBLIC_BRIDGEto different 
values, and the exhibited `ovs-vsctl` commands in this section apply to 
$OVS_PHYSICAL_BRIDGE.  Is that right?  Are there other revisions I need to 
make to localrc?

Looking at 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or, in 
former days, the doc now preserved at 
http://docs.ocselected.org/openstack-manuals/kilo/networking-guide/content/under_the_hood_openvswitch.html
) I see the name br-ex used for $PUBLIC_BRIDGE--- not $OVS_PHYSICAL_BRIDGE
, right?  Wouldn't it be less confusing if 
http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a 
name other than "br-ex" for the exhibited commands that apply to 
$OVS_PHYSICAL_BRIDGE?

The section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch
builds on 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
NOT 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
--- right?  Could I stop after reading that section, or must I go on to 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
?

The exhibited localrc contents in section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
include both of these:

   Q_L3_ENABLED=True
   Q_USE_PROVIDERNET_FOR_PUBLIC=True

and nothing gainsays either of them until section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
--- where we first see

   Q_L3_ENABLED=False

Is it true that all the other sections want both Q_L3_ENABLEDand 
Q_USE_PROVIDERNET_FOR_PUBLICto be True?

I tried adding IPv6 support to the recipe of the first section (
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
).  I added this to my localrc:

IP_VERSION=4+6
IPV6_PUBLIC_RANGE=fddf:2::/64
IPV6_PUBLIC_NETWORK_GATEWAY=fddf:2::1
IPV6_ROUTER_GW_IP=fddf:2::231

At first I had tried setting a different set of IPv6 variables (having 
only IP_VERSION in common with what I exhibit here), but found those: (a) 
duplicated the defaults and (b) caused problems due to lack of the ones I 
mention here.  Even the ones mentioned here led to a problem.  There is a 
bit of scripging that replaces my setting for IPV6_ROUTER_GW_IP with 
something dug out of Neutron.  That went wrong.  It replaced my setting 
with fddf:2::2, but that address was already in use by something else.

Thanks,
Mike


Thanks,
Mike

__
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-dev] [devstack] A few questions on configuring DevStack for Neutron

[Mike Spreitzer]

[Apologies for re-posting, but I botched the subject line the first time 
and know that people use filters.]

I have been looking at 
http://docs.openstack.org/developer/devstack/guides/neutron.html and 
wonder about a few things.

In the section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
there is a helpful display of localrc contents.  It says, among other 
things,

OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex

In the next top-level section, 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
, there is no display of revised localrc contents and no mention of 
changing either bridge setting.  That is an oversight, right?  I am 
guessing I need to set OVS_PHYSICAL_BRIDGEand PUBLIC_BRIDGEto different 
values, and the exhibited `ovs-vsctl` commands in this section apply to 
$OVS_PHYSICAL_BRIDGE.  Is that right?  Are there other revisions I need to 
make to localrc?

Looking at 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html (or, 
in former days, the doc now preserved at 
http://docs.ocselected.org/openstack-manuals/kilo/networking-guide/content/under_the_hood_openvswitch.html
) I see the name br-ex used for $PUBLIC_BRIDGE--- not $OVS_PHYSICAL_BRIDGE
, right?  Wouldn't it be less confusing if 
http://docs.openstack.org/developer/devstack/guides/neutron.html used a 
name other than "br-ex" for the exhibited commands that apply to 
$OVS_PHYSICAL_BRIDGE?

The section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch
 
builds on 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
 
NOT 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
--- right?  Could I stop after reading that section, or must I go on to 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
 
?

The exhibited localrc contents in section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
include both of these:

Q_L3_ENABLED=True
Q_USE_PROVIDERNET_FOR_PUBLIC=True

and nothing gainsays either of them until section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
 
--- where we first see

Q_L3_ENABLED=False

Is it true that all the other sections want both Q_L3_ENABLEDand 
Q_USE_PROVIDERNET_FOR_PUBLICto be True?

Thanks,
Mike


__
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-dev] A few questions on configuring DevStack for Neutron

[Mike Spreitzer]

I have been looking at 
http://docs.openstack.org/developer/devstack/guides/neutron.html and 
wonder about a few things.

In the section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
there is a helpful display of localrc contents.  It says, among other 
things,

OVS_PHYSICAL_BRIDGE=br-ex
PUBLIC_BRIDGE=br-ex

In the next top-level section, 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
 
, there is no display of revised localrc contents and no mention of 
changing either bridge setting.  That is an oversight, right?  I am 
guessing I need to set OVS_PHYSICAL_BRIDGE and PUBLIC_BRIDGE to different 
values, and the exhibited `ovs-vsctl` commands in this section apply to 
$OVS_PHYSICAL_BRIDGE.  Is that right?  Are there other revisions I need to 
make to localrc?

Looking at 
http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html (or, 
in former days, the doc now preserved at 
http://docs.ocselected.org/openstack-manuals/kilo/networking-guide/content/under_the_hood_openvswitch.html
) I see the name br-ex used for $PUBLIC_BRIDGE --- not $
OVS_PHYSICAL_BRIDGE, right?  Wouldn't it be less confusing if 
http://docs.openstack.org/developer/devstack/guides/neutron.html used a 
name other than "br-ex" for the exhibited commands that apply to 
$OVS_PHYSICAL_BRIDGE?

The section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch
 
builds on 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
 
NOT 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
--- right?  Could I stop after reading that section, or must I go on to 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
 
?

The exhibited localrc contents in section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
 
include both of these:

Q_L3_ENABLED=True
Q_USE_PROVIDERNET_FOR_PUBLIC=True

and nothing gainsays either of them until section 
http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
 
--- where we first see

Q_L3_ENABLED=False

Is it true that all the other sections want both Q_L3_ENABLED and 
Q_USE_PROVIDERNET_FOR_PUBLIC to be True ?

Thanks,
Mike

__
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] [all] -1 due to line length violation in commit messages

[Mike Spreitzer]

> From: Gorka Eguileor 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 09/29/2015 07:34 AM
> Subject: Re: [openstack-dev] [all] -1 due to line length violation 
> in commit messages
...
> Since we are not all native speakers expecting everyone to realize that
> difference - which is completely right - may be a little optimistic,
> moreover considering that parts of those guidelines may even be written
> by non natives.
> 
> Let's say I interpret all "should" instances in that guideline as rules
> that don't need to be strictly enforced, I see that the Change-Id
> "should not be changed when rebasing" - this one would certainly be fun
> to watch if we didn't follow it - the blueprint "should give the name of
> a Launchpad blueprint" - I don't know any core that would not -1 a patch
> if he notices the BP reference missing - and machine targeted metadata
> "should all be grouped together at the end of the commit message" - this
> one everyone follows instinctively, so no problem.
> 
> And if we look at the i18n guidelines, almost everything is using
> should, but on reviews these are treated as strict *must* because of the
> implications.
> 
> Anyway, it's a matter of opinion and afaik in Cinder we don't even have
> a real problem with downvoting for the commit message length, I don't
> see more than 1 every couple of months or so.

Other communities have solved this by explicit reference to a standard 
defining terms like "must" and "should".

Regards,
Mike


__
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] [magnum]swarm + compose = k8s?

[Mike Spreitzer]

> From: 王华 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 09/28/2015 11:34 PM
> Subject: [openstack-dev] [magnum]swarm + compose = k8s?
> 
> Hi folks,
> 
> Magnum now exposes service, pod, etc to users in kubernetes coe, but
> exposes container in swarm coe. As I know, swarm is only a scheduler
> of container, which is like nova in openstack. Docker compose is a 
> orchestration program which is like heat in openstack. k8s is the 
> combination of scheduler and orchestration. So I think it is better 
> to expose the apis in compose to users which are at the same level as 
k8s.
> 

Why should the users be deprived of direct access to the Swarm API when it 
is there?

Note also that Compose addresses more general, and differently focused, 
orchestration than Kubernetes; the latter only offers homogenous scaling 
groups --- which a docker-compose.yaml file can not even describe.

Regards,
Mike



__
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] Compute API (Was Re: [nova][cinder] how to handle AZ bug 1496235?)

[Mike Spreitzer]

> From: Monty Taylor 
> To: Sylvain Bauza , "OpenStack Development 
> Mailing List (not for usage questions)" 

> Date: 09/28/2015 09:54 AM
> Subject: Re: [openstack-dev] Compute API (Was Re: [nova][cinder] how
> to handle AZ bug 1496235?)
>
> ...
> Specifically, I want "nova boot" to get me a VM with an IP address. I 
> don't want it to do fancy orchestration - I want it to not need fancy 
> orchestration, because needing fancy orchestration to get a VM  on a 
> network is not a feature.
> 
> I also VERY MUCH do not want to need Heat to get a VM. I want to use 
> Heat to do something complex. Getting a VM is not complex. It should not 

> be complex. What it's complex and to the level of needing Heat, we've 
> failed somewhere else.
> 
> Also, people should stop deploying clouds that require people to use 
> floating IPs to get basic internet access. It's a misuse of the 
construct.
> 
> Public Network "ext-net" -> shared / directly attachable
> Per-tenant Network "private" -> private network, not shared, not 
routable
> 
> If the user chooses, a router can be added with gateway set to ext-net.
> 
> This way:
> 
> nova boot --network=ext-net  -> vm dhcp'd on the public network
> nova boot --network=private  -> vm dhcp'd on the private network
> nova floating-ip-attach  -> vm gets a floating ip attached to their 
> vm from the ext-net network
> 
> All of the use cases are handled, basic things are easy (boot a vm on 
> the network works in one step) and for the 5% of cases where a floating 
> IP is actually needed (a long-lived service on a single vm that wants to 

> keep the IP and not just a DNS name across VM migrations and isn't using 

> a load-balancer) can use that.
> 
> This is, btw, the most common public cloud deployment model.
> 
> Let's stop making things harder than they need to be and serve our 
users.

As an operator, +1

Mike



__
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-dev] [devstack] Is there a way to configure devstack for one flat external network using Kilo, Neutron?

[Mike Spreitzer]

Is there a way to configure devstack to install Neutron such that there is 
just one network and that is an external network and Nova can create 
Compute Instances on it, using projects of Kilo vintage?

Thanks,
Mike



__
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] Data transmission failure between VM and outsidemachines

[Mike Spreitzer]

> From: "applyhhj" 
> To: "openstack" 
> Date: 09/27/2015 11:16 AM
> Subject: [Openstack] Data transmission failure between VM and outside 
machines
> 
> Hi, I have setup the openstack cloud and launched VMs in the cloud. 
> At first everything went very well. But yesterday evening, due to 
> some reasons our lab lost power and all servers were shutdown. This 
> morning I turned on all nodes and try to connect to the VM by ssh 
> but failed. I used netstat to check the status of port 22. It shows 
> that connection between VM and machine in the external network can 
> be established. However the ssh process just stuck at 
> SSH2_MSG_KEXINIT sent. Also I setup a rabbitmq server in the VM and 
> the same situation happened. When connecting rabbitmq server through
> web ui, netstat shows that connections have been established however
> the web browser can not get any data from the server, it shows a 
> blank page. Also I tried to ssh from one VM to another VM through 
> internal network, the 192.168.1.0/24 network, similar things 
> happened. Does anyone know how to fix this problem? Thank you! By 
> the way the br-ex bridge can only be brought up manually, so after 
> boot the network node I brought up the br-ex bridge and restart all 
> relevant network services in network node. Please help me with this 
> problem. Thank you very much!!

When faced with networking mysteries like that my next step is usually to 
start taking packet traces at various points.

Regards,
Mike

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mike Spreitzer]

Monty Taylor  wrote on 09/15/2015 11:04:07 AM:

> a) an update to python-novaclient to allow a named network to be passed 
> to satisfy the "you have more than one network" - the nics argument is 
> still useful for more complex things

I am not using the latest, but rather Juno.  I find that in many places 
the Neutron CLI insists on a UUID when a name could be used.  Three cheers 
for any campaign to fix that.

And, yeah, creating VMs on a shared public network is good too.

Thanks,
mike

__
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] [nova][neutron][devstack] New proposed 'default' network model

[Mike Spreitzer]

"Armando M."  wrote on 09/15/2015 03:50:24 PM:

> On 15 September 2015 at 10:02, Doug Hellmann  
wrote:
> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
...
> As with the Glance image upload API discussion, this is an example
> of an extremely common use case that is either complex for the end
> user or for which they have to know something about the deployment
> in order to do it at all. The usability of an OpenStack cloud running
> neutron would be enhanced greatly if there was a simple, clear, way
> for the user to get a new VM with a public IP on any cloud without
> multiple steps on their part. 

<>

...
> 
> So this boils down to: in light of the possible ways of providing VM
> connectivity, how can we make a choice on the user's behalf? Can we 
> assume that he/she always want a publicly facing VM connected to 
> Internet? The answer is 'no'.

While it may be true that in some deployments there is no good way for the 
code to choose, I think that is not the end of the story here.  The 
motivation to do this is that in *some* deployments there *is* a good way 
for the code to figure out what to do.

Regards,
Mike

__
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] [nova][neutron][devstack] New proposed 'default' network model

[Mike Spreitzer]

Clark Boylan  wrote on 09/15/2015 04:06:26 PM:

> > I also strongly recommend to users to put vms on a private network and
> > use floating ip's/load balancers. For many reasons. Such as, if you
> > don't, the ip that gets assigned to the vm helps it become a pet. you
> > can't replace the vm and get the same IP. Floating IP's and load
> > balancers can help prevent pets. It also prevents security issues with
> > DNS and IP's. Also, for every floating ip/lb I have, I usually have 3x 
or
> > more the number of instances that are on the private network. Sure its
> > easy to put everything on the public network, but it provides much 
better
> > security if you only put what you must on the public network. Consider
> > the internet. would you want to expose every device in your house
> > directly on the internet? No. you put them in a private network and 
poke
> > holes just for the stuff that does. we should be encouraging good
> > security practices. If we encourage bad ones, then it will bite us 
later
> > when OpenStack gets a reputation for being associated with 
compromises.
> There are a few issues with this. Neutron IPv6 does not support floating
> IPs. So now you have to use two completely different concepts for
> networking on a single dual stacked VM. IPv4 goes on a private network
> and you attach a floating IP. IPv6 is publicly routable. If security and
> DNS and not making pets were really the driving force behind floating
> IPs we would see IPv6 support them too. These aren't the reasons
> floating IPs exist, they exist because we are running out of IPv4
> addresses and NAT is everyones preferred solution to that problem. But
> that doesn't make it a good default for a cloud; use them if you are
> affected by an IP shortage.
> 
> Nothing prevents you from load balancing against public IPs to address
> the DNS and firewall rule concerns (basically don't make pets). This
> works great and is how OpenStack's git mirrors work.
> 
> It is also easy to firewall public IPs using Neutron via security groups
> (and possibly the firewall service? I have never used it and don't
> know). All this to say I think it is reasonable to use public shared
> networks by default particularly since IPv6 does not have any concept of
> a floating IP in Neutron so using them is just odd unless you really
> really need them and you aren't actually any less secure.

I'm really glad to see the IPv6 front opened.

But I have to say that the analysis of options for securing public 
addresses omits one case that I think is important: using an external (to 
Neutron) "appliance".  In my environment this is more or less required. 
This reinforces the bifurcation of addresses that was mentioned: some VMs 
are private and do not need any service from the external appliance, while 
others have addresses that need the external appliance on the 
public/private path.

In fact, for this reason, I have taken to using two "external" networks 
(from Neutron's point of view) --- one whose addresses are handled by the 
external appliance and one whose addresses are not.  In fact, both ranges 
of address are on the same VLAN.  This is FYI, some people have wondered 
why these thins might be done.

> Not to get too off topic, but I would love it if all the devices in my
> home were publicly routable. I can use my firewall to punch holes for
> them, NAT is not required. Unfortunately I still have issues with IPv6
> at home. Maybe one day this will be a reality :)

Frankly, given the propensity for bugs to be discovered, I am glad that 
nothing in my home is accessible from the outside (aside from the device 
that does firewall, and I worry about that too).  Not that this is really 
germane to what we want to do for internet-accessible 
applications/services.

Regards,
Mike

__
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] veth pair disappear after hardware reboot

[Mike Spreitzer]

You know that veths do not survive reboot, right?  It is up to Neutron or 
whatever needs them to create them after each boot.  Have you checked that 
all the right Neutron services came up and are healthy after your reboot?


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack-operators] Neutron IPv6 manual for single-stacking in Juno

[Mike Spreitzer]

I see https://wiki.openstack.org/wiki/NEUTRON-IPV6-MANUAL explicitly 
disclaims interest in single-stacking and in Juno.  Where would I go to 
learn how to use IPv6 in the single-stack Juno case?

Thanks,
Mike

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

Re: [openstack-dev] [neutron] [fwaas] -IPv6 support in Kilo

[Mike Spreitzer]

 From: Rukhsana Ansari rukhsana.ans...@oneconvergence.com
 To: openstack-dev@lists.openstack.org
 Date: 06/02/2015 01:59 PM
 Subject: [openstack-dev]  [neutron] [fwaas] -IPv6 support in Kilo
 
 Hi,
 
 I was browsing the code to understand IPv6  support For FWaaS in Kilo.
 
 I don't see a restriction in the db code or in reference fwaas_plugin.py
 
 However, from  this:
 https://github.com/openstack/neutron-fwaas/blob/stable/kilo/
 neutron_fwaas/services/firewall/drivers/vyatta/vyatta_fwaas.py#L126
 
 I gather that at least Vyatta does not have IPv6 firewall support.
 
 Would greatly appreciate it if someone could explain  the reasons 
 for this restriction.
 
 Thanks
 -Rukhsana

Indeed, this is a surprise to me.  
http://www.brocade.com/downloads/documents/html_product_manuals/vyatta/vyatta_5400_manual/wwhelp/wwhimpl/js/html/wwhelp.htm#href=Firewall/Firewall_Overview.02.11.html#1749726
 
indicates that the Vyatta 5400, at least, definitely has firewall 
functionality.
__
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] IPv4 transition/interoperation with IPv6

[Mike Spreitzer]

Robert Li (baoli) ba...@cisco.com wrote on 05/05/2015 09:02:08 AM:

 Currently dual stack is supported. Can you be specific on what 
 interoperation/transition techniques you are interested in? We’ve 
 been thinking about NAT64 (stateless or stateful).
 
 thanks,
 Robert
 
 On 5/4/15, 9:56 PM, Mike Spreitzer mspre...@us.ibm.com wrote:
 
 Does Neutron support any of the 4/6 interoperation/transition 
 techniques?  I wear an operator's hat nowadays, and want to make 
 IPv6 as useful and easy to use as possible for my tenants.  I think 
 the interoperation/transition techniques will play a big role in this. 


Is dual stacking working in routers now?  At the moment I am still using 
Juno, but plan to move to Kilo.

I want to encourage my tenants to use as much IPv6 as possible.  But I 
expect some will have to keep some of their workload on v4 (I know there 
is on-going work to get many application frameworks up to v6 speed, and it 
is not complete yet).  I expect some tenants could be mixed: some workload 
on v4 and some on v6.  Such a tenant would appreciate a NAT between his v6 
space and his v4 space.  This is the easiest cases --- sections 2.5 and 
2.6 --- of RFC 6144.

I would prefer to do it in a stateless way if possible.  That would be 
pretty easy if Neutron and Nova were willing to accept an IPv6 subnet that 
is much smaller than 2^64 addresses.  I see that my macs differ only in 
their last 24 bits.

Some tenants could put their entire workload on v6, but that workload 
would be unreachable from customers of all those ISPs (such as mine, 
CableVision) that deny IPv6 service to their customers.  There are 
techniques for coping, and Teredo looks like a pretty good one.  It has 
been shipped in Windows for years.  Yet I can not find a Windows machine 
where the Teredo actually works.  What's up with that?  If Windows somehow 
got its Teredo, or other, act together, that would be only half the job; 
Teredo requires something from the server side as well, right?

Supposing a focus on mobile, where IPv6 is much more available, and/or 
progress by Microsoft and/or other ISPs, my tenant might face a situation 
where his clients could come in over v6 but some of his servers still have 
to run on v4.  That's section 2.3 of RFC 6144.

While I am a Neutron operator, I am also a customer of a lower layer 
network provider.  That network provider will happily give me a few /64. 
How do I serve IPv6 subnets to lots of my tenants?  In the bad old v4 days 
this would be easy: a tenant puts all his stuff on his private networks 
and NATs (e.g., floating IP) his edge servers onto a public network --- no 
need to align tenant private subnets with public subnets.  But with no NAT 
for v6, there is no public/private distinction --- I can only give out the 
public v6 subnets that I am given.  Yes, NAT is bad.  But not being able 
to get your job done is worse.


Sean M. Collins s...@coreitpro.com wrote on 05/05/2015 06:26:28 AM:

 I think that Neutron exposes enough primitives through the API that
 advanced services for handling your transition technique of choice could
 be built.

I think that is right, if I am willing to assume Neutron is using OVS --- 
or build a bunch of alternatives that correspond to all the Neutron 
plugins and mechanisms that I might encounter.  And it would feel a lot 
like Neutron implementation work.  Really, it is one instance of doing 
some NFV.


Thanks,
Mike

__
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] Clean shutdown

[Mike Spreitzer]

Binan AL Halabi binanalhal...@yahoo.com wrote on 05/05/2015 01:15:51 AM:

 I have this question:
 When the autoscaling policy (scale down policy) is triggered and one
 of the server is going to be killed.
 Nova select the oldest to kill.
 The question is there a way to make the termination clean (give the 
 instance a chance to finish its processing and its communications 
 with a database).

One way would be to use OS::Heat::SoftwareDeployment to deploy a DELETE 
action.

Regards,
Mike

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

[Mike Spreitzer]

Does Neutron support any of the 4/6 interoperation/transition techniques? 
I wear an operator's hat nowadays, and want to make IPv6 as useful and 
easy to use as possible for my tenants.  I think the 
interoperation/transition techniques will play a big role in this.

Thanks,
Mike__
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-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:17:35 PM:

 Or instead of using Linux bridges you could use a manually created 
 OpenVSwitch bridge. This allows you to add internal
 ports that could be used by Neutron like any other interface.
 
 - Create OVS bridge
 - Add your external interface to OVS bridge
   * If your external connection supports/needs VLANs, configure 
 external interface as trunk
 - Add any number of internal interfaces to OVS bridge
   * Tag each interface with its VLAN ID, if needed
 - Configure Neutron to use one internal interface for each subnet 
 you'd like to use (no VLAN configuration required as
 this happenes outside of Neutron)
 
 Regards,
 
Uwe
 
 Am 25.04.2015 um 21:41 schrieb George Shuklin:
  Can you put them to different vlans? After that it would be very easy 
task.
  
  If not, AFAIK, neutron does not allow this.
  
  Or you can trick it thinking it is (are) separate networks.
  
  Create brige (br-join), plug eth to it.
  Create to fake external bridges (br-ex1, br-ex2). Join them 
 together to br-join by patch links
  (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
 patch-ports/)
  
  Instruct neutron like there is two external networks: one on br-
 ex1, second on br-ex2.
  
  But be alert that this not very stable configuration, you need to 
 maintain it by yourself.
  
  On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
  Is there a way to create multiple external networks from 
 Neutron's point of view, where both of those networks are
  accessed through the same host NIC?  Obviously those networks 
 would be using different subnets.  I need this sort of
  thing because the two subnets are treated differently by the 
 stuff outside of OpenStack, so I need a way that a tenant
  can get a floating IP of the sort he wants.  Since Neutron 
 equates floating IP allocation pools with external
  networks, I need two external networks.
 
  I found, for example, http://www.marcoberube.com/archives/248--- 
 which describes how to have multiple external
  networks but uses a distinct host network interface for each one.

Now that I have found my bridge_mappings configuration statement, I can 
return to thinking about what you said.  It sounds very similar to what 
George said --- it is just that you suggest an OVS switch in place of 
George's br-join (which I had assumed was also an OVS switch, since it is 
named like the others).  Do I have this right?

Thanks,
Mike

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

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 AM:

 Am 27.04.2015 um 16:36 schrieb Mike Spreitzer:
  Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:17:35 PM:
  
  Or instead of using Linux bridges you could use a manually created
  OpenVSwitch bridge. This allows you to add internal
  ports that could be used by Neutron like any other interface.
 
  - Create OVS bridge
  - Add your external interface to OVS bridge
* If your external connection supports/needs VLANs, configure
  external interface as trunk
  - Add any number of internal interfaces to OVS bridge
* Tag each interface with its VLAN ID, if needed
  - Configure Neutron to use one internal interface for each subnet
  you'd like to use (no VLAN configuration required as
  this happenes outside of Neutron)
 
  Regards,
 
 Uwe
 
  Am 25.04.2015 um 21:41 schrieb George Shuklin:
   Can you put them to different vlans? After that it would be 
 very easy task.
  
   If not, AFAIK, neutron does not allow this.
  
   Or you can trick it thinking it is (are) separate networks.
  
   Create brige (br-join), plug eth to it.
   Create to fake external bridges (br-ex1, br-ex2). Join them
  together to br-join by patch links
   (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
  patch-ports/)
  
   Instruct neutron like there is two external networks: one on br-
  ex1, second on br-ex2.
  
   But be alert that this not very stable configuration, you need to
  maintain it by yourself.
  
   On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
   Is there a way to create multiple external networks from
  Neutron's point of view, where both of those networks are
   accessed through the same host NIC?  Obviously those networks
  would be using different subnets.  I need this sort of
   thing because the two subnets are treated differently by the
  stuff outside of OpenStack, so I need a way that a tenant
   can get a floating IP of the sort he wants.  Since Neutron
  equates floating IP allocation pools with external
   networks, I need two external networks.
  
   I found, for example, http://www.marcoberube.com/archives/248---
  which describes how to have multiple external
   networks but uses a distinct host network interface for each one.
  
  Now that I have found my bridge_mappings configuration statement, 
 I can return to thinking about what you said.  It sounds very
  similar to what George said --- it is just that you suggest an OVS
 switch in place of George's br-join (which I had assumed was
  also an OVS switch, since it is named like the others).  Do I have
 this right?
  
  Thanks,
  Mike
  
 
 Mike,
 
 
 if I understood Georges answer correctly he suggested one bridge 
 (br-join, either OVS or linux bridge) to connect other bridges
 via patch links, one for each external network you'd like to create.
 These second level bridges are then used for the Neutron
 configuration:
 
 br-ext1 - Neutron
/
 patch-link
  /
 ethX –br-join
  \
 patch-link
\
 br-ext2 - Neutron
 
 
 
 I suggested to use an OVS bridge because there it'd be possible to 
 stay away from the performance-wise worse patch-links and Linux
 bridges and use internal interfaces to connect to Neutron directly
 – which on second thought won't work if Neutron expects a
 bridge in that place.
 
 What I suggested later on is that you probably don't need any second
 level bridge at all. Just create a second/third external
 network with appropriate CIDR. As long as those networks are 
 externally connected to your interface (and thus the bridge) you
 should be good to go.

To be precise, are you suggesting that I have just one br-ex, connected to 
the host NIC as usual, and in my bridge_mappings configuration statement, 
map all the external network names to br-ex?

Thanks,
Mike



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

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 01:22:35 PM:

  if I understood Georges answer correctly he suggested one bridge
  (br-join, either OVS or linux bridge) to connect other bridges
  via patch links, one for each external network you'd like to create.
  These second level bridges are then used for the Neutron
  configuration:
 
  br-ext1 - Neutron
 /
  patch-link
   /
  ethX –br-join
   \
  patch-link
 \
  br-ext2 - Neutron
 
 
 
  I suggested to use an OVS bridge because there it'd be possible to
  stay away from the performance-wise worse patch-links and Linux
  bridges and use internal interfaces to connect to Neutron directly
  – which on second thought won't work if Neutron expects a
  bridge in that place.
 
  What I suggested later on is that you probably don't need any second
  level bridge at all. Just create a second/third external
  network with appropriate CIDR. As long as those networks are
  externally connected to your interface (and thus the bridge) you
  should be good to go.
  
  In parallel emails we have established that I have to do what you 
 have drawn.  I need to do that the node(s) that run L3
  agents.  Do I need to modify the bridge_mappings, flat_networks, 
 or network_vlan_ranges configuration statement on the
  other nodes (compute hosts)?
  
  Thanks,
  Mike
  
 
 I think you just need to create the cascading bridges with their 
 inter-connects, then tell Neutron the association
 between secondary bridge (e.g. br-ext1, br-ext2) and external 
 network. Then create (!) the external networks and restart
 Neutron.
 
 Concerning you intra-cloud networking I don't think you need to 
 reconfigure anything as long as this is already working.
 Compute hosts shouldn't be affected as its not their business to 
 know about external networks.

So I did what George said and you drew, using OVS bridges, and it seems to 
be working.

Thanks,
Mike


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

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

gustavo panizzo (gfa) g...@zumbi.com.ar wrote on 04/27/2015 11:23:13 
AM:

 On 2015-04-27 22:59, Mike Spreitzer wrote:
  Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 AM:
 
  What I suggested later on is that you probably don't need any second
  level bridge at all. Just create a second/third external
  network with appropriate CIDR. As long as those networks are
  externally connected to your interface (and thus the bridge) you
  should be good to go.
  
  To be precise, are you suggesting that I have just one br-ex, 
connected
  to the host NIC as usual, and in my bridge_mappings configuration
  statement, map all the external network names to br-ex?
 
 you can only have one flat network per bridge.
 
 i don't know what's your usercase but one i had the need to map 2
 different public ip address to each vm vnic, i was going to do the
 double bridge thing but i resolved it using allowed pairs extension. it
 may work for you

My use case is that I have two behaviorally different external subnets --- 
they are treated differently by stuff outside of OpenStack, with 
consequences that are meaningful to tenants.  Thus, I have two categories 
of floating IP addresses, depending on which external subnet holds the 
floating IP address.  The difference is meaningful to tenants.  So I need 
to enable a tenant to request a floating IP address of a specific 
category.  Since Neutron equates floating IP address allocation pool with 
network, I need two external networks.

Both of these external subnets are present on the same actual external 
LAN, thus both are reached through the same host NIC.

It looks to me like the allowed mac/IP address pair feature will not solve 
this problem.

Thanks,
Mike

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

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

 gustavo panizzo (gfa) g...@zumbi.com.ar wrote on 04/27/2015 11:23:13 
AM:
 
  On 2015-04-27 22:59, Mike Spreitzer wrote:
   Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 
AM:
  
   What I suggested later on is that you probably don't need any 
second
   level bridge at all. Just create a second/third external
   network with appropriate CIDR. As long as those networks are
   externally connected to your interface (and thus the bridge) you
   should be good to go.
   
   To be precise, are you suggesting that I have just one br-ex, 
connected
   to the host NIC as usual, and in my bridge_mappings configuration
   statement, map all the external network names to br-ex?
  
  you can only have one flat network per bridge.
  
  i don't know what's your usercase but one i had the need to map 2
  different public ip address to each vm vnic, i was going to do the
  double bridge thing but i resolved it using allowed pairs extension. 
it
  may work for you
 
 My use case is that I have two behaviorally different external 
 subnets --- they are treated differently by stuff outside of 
 OpenStack, with consequences that are meaningful to tenants.  Thus, 
 I have two categories of floating IP addresses, depending on which 
 external subnet holds the floating IP address.  The difference is 
 meaningful to tenants.  So I need to enable a tenant to request a 
 floating IP address of a specific category.  Since Neutron equates 
 floating IP address allocation pool with network, I need two 
 external networks. 
 
 Both of these external subnets are present on the same actual 
 external LAN, thus both are reached through the same host NIC. 
 
 It looks to me like the allowed mac/IP address pair feature will not
 solve this problem. 

Sorry, I simplified too much.  Here is one other critical detail.  I do 
not really have just two different external subnets.  What I really have 
is two behaviorally different collections of subnets.  I need to make a 
Neutron external network for each of the two collections of external 
subnets.

Thanks,
Mike

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

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/27/2015 10:54:15 AM:

 Am 27.04.2015 um 16:36 schrieb Mike Spreitzer:
  Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:17:35 PM:
  
  Or instead of using Linux bridges you could use a manually created
  OpenVSwitch bridge. This allows you to add internal
  ports that could be used by Neutron like any other interface.
 
  - Create OVS bridge
  - Add your external interface to OVS bridge
* If your external connection supports/needs VLANs, configure
  external interface as trunk
  - Add any number of internal interfaces to OVS bridge
* Tag each interface with its VLAN ID, if needed
  - Configure Neutron to use one internal interface for each subnet
  you'd like to use (no VLAN configuration required as
  this happenes outside of Neutron)
 
  Regards,
 
 Uwe
 
  Am 25.04.2015 um 21:41 schrieb George Shuklin:
   Can you put them to different vlans? After that it would be 
 very easy task.
  
   If not, AFAIK, neutron does not allow this.
  
   Or you can trick it thinking it is (are) separate networks.
  
   Create brige (br-join), plug eth to it.
   Create to fake external bridges (br-ex1, br-ex2). Join them
  together to br-join by patch links
   (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
  patch-ports/)
  
   Instruct neutron like there is two external networks: one on br-
  ex1, second on br-ex2.
  
   But be alert that this not very stable configuration, you need to
  maintain it by yourself.
  
   On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
   Is there a way to create multiple external networks from
  Neutron's point of view, where both of those networks are
   accessed through the same host NIC?  Obviously those networks
  would be using different subnets.  I need this sort of
   thing because the two subnets are treated differently by the
  stuff outside of OpenStack, so I need a way that a tenant
   can get a floating IP of the sort he wants.  Since Neutron
  equates floating IP allocation pools with external
   networks, I need two external networks.
  
   I found, for example, http://www.marcoberube.com/archives/248---
  which describes how to have multiple external
   networks but uses a distinct host network interface for each one.
  
  Now that I have found my bridge_mappings configuration statement, 
 I can return to thinking about what you said.  It sounds very
  similar to what George said --- it is just that you suggest an OVS
 switch in place of George's br-join (which I had assumed was
  also an OVS switch, since it is named like the others).  Do I have
 this right?
  
  Thanks,
  Mike
  
 
 Mike,
 
 
 if I understood Georges answer correctly he suggested one bridge 
 (br-join, either OVS or linux bridge) to connect other bridges
 via patch links, one for each external network you'd like to create.
 These second level bridges are then used for the Neutron
 configuration:
 
 br-ext1 - Neutron
/
 patch-link
  /
 ethX –br-join
  \
 patch-link
\
 br-ext2 - Neutron
 
 
 
 I suggested to use an OVS bridge because there it'd be possible to 
 stay away from the performance-wise worse patch-links and Linux
 bridges and use internal interfaces to connect to Neutron directly
 – which on second thought won't work if Neutron expects a
 bridge in that place.
 
 What I suggested later on is that you probably don't need any second
 level bridge at all. Just create a second/third external
 network with appropriate CIDR. As long as those networks are 
 externally connected to your interface (and thus the bridge) you
 should be good to go.

In parallel emails we have established that I have to do what you have 
drawn.  I need to do that the node(s) that run L3 agents.  Do I need to 
modify the bridge_mappings, flat_networks, or network_vlan_ranges 
configuration statement on the other nodes (compute hosts)?

Thanks,
Mike


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

[Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Is there a way to create multiple external networks from Neutron's point 
of view, where both of those networks are accessed through the same host 
NIC?  Obviously those networks would be using different subnets.  I need 
this sort of thing because the two subnets are treated differently by the 
stuff outside of OpenStack, so I need a way that a tenant can get a 
floating IP of the sort he wants.  Since Neutron equates floating IP 
allocation pools with external networks, I need two external networks.

I found, for example, http://www.marcoberube.com/archives/248 --- which 
describes how to have multiple external networks but uses a distinct host 
network interface for each one.

Thanks,
Mike___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[openstack-dev] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

As an operator, is there a way I can create two external networks from 
Neutron's point of view, where both of those networks are accessed through 
the same host NIC?  Obviously those networks would be using different 
subnets.  I need this sort of thing because the two subnets are treated 
differently by the stuff outside of OpenStack, so I need a way that a 
tenant can get a floating IP of the sort he wants.  Since Neutron equates 
floating IP allocation pools with external networks, I need two external 
networks.

I asked this on openstack-operators, and got one response saying my 
choices are either to use VLAN tagging on that NIC or manually make more 
OVS switches that ultimately get their external connectivity through the 
same NIC.  The VLAN tagging is problematic in my environment.  Is there 
any other choice?

BTW, I am currently using Juno but plan to move to Kilo.

BTW, is Neutron creating any ebtables rules that will get in my way?

Thanks,
Mike__
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-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Uwe Sauter uwe.sauter...@gmail.com wrote on 04/25/2015 04:42:06 PM:

 Am 25.04.2015 um 22:28 schrieb Mike Spreitzer:
  From: Uwe Sauter uwe.sauter...@gmail.com
 
  Or instead of using Linux bridges you could use a manually created
  OpenVSwitch bridge. This allows you to add internal
  ports that could be used by Neutron like any other interface.
 
  - Create OVS bridge
  - Add your external interface to OVS bridge
* If your external connection supports/needs VLANs, configure
  external interface as trunk
  - Add any number of internal interfaces to OVS bridge
* Tag each interface with its VLAN ID, if needed
  - Configure Neutron to use one internal interface for each subnet
  you'd like to use (no VLAN configuration required as
  this happenes outside of Neutron)
 
  Regards,
 
 Uwe
 
  Am 25.04.2015 um 21:41 schrieb George Shuklin:
   Can you put them to different vlans? After that it would be 
 very easy task.
  
   If not, AFAIK, neutron does not allow this.
  
   Or you can trick it thinking it is (are) separate networks.
  
   Create brige (br-join), plug eth to it.
   Create to fake external bridges (br-ex1, br-ex2). Join them
  together to br-join by patch links
   (http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-
  patch-ports/)
  
   Instruct neutron like there is two external networks: one on br-
  ex1, second on br-ex2.
  
   But be alert that this not very stable configuration, you need to
  maintain it by yourself.
  
   On 04/25/2015 10:13 PM, Mike Spreitzer wrote:
   Is there a way to create multiple external networks from
  Neutron's point of view, where both of those networks are
   accessed through the same host NIC?  Obviously those networks
  would be using different subnets.  I need this sort of
   thing because the two subnets are treated differently by the
  stuff outside of OpenStack, so I need a way that a tenant
   can get a floating IP of the sort he wants.  Since Neutron
  equates floating IP allocation pools with external
   networks, I need two external networks.
  
   I found, for example, http://www.marcoberube.com/archives/248---
  which describes how to have multiple external
   networks but uses a distinct host network interface for each one.
  
   Thanks,
   Mike
  
  Thanks Uwe, I might try that, it sounds like the simplest thing 
 that will work.  I think I can not use VLAN tagging in my
  environment.  I am using ML2 with OVS, and it is working now with 
 a single external network.  Should I expect to find a
  bridge_mappings entry in my plugin.ini?  I do not find one now. 
 This setup was mainly created by other people, so I am not sure
  what to expect.  When using ML2 with OVS, how do I tell Neutron 
 what my bridge mappings are?
  
  Thanks,
  Mike
  
 
 Mike,
 
 VLAN is optional in the setup I described. I just was pointing out 
 where such a configuration could take place.
 
 As far as my experience with OVS and Neutron goes, Neutron will just
 ignore already existing configurations. That's also the
 reason why install manuals tell you to create br-int and br-ex.
 
 Regarding the exact configuration of ML2 and plugin.ini I'm not 
 quite sure if I understand your question correctly. Are you asking
 how to tell Neutron which interface should be used for the different
 IP subnets?
 
 Perhaps you could post your plugin.ini with sensitive information 
 replaced with something generic.
 
 Regards,
 
Uwe
 

Yes, I realize the VLAN tagging is just an option in the approach you are 
outlining.  George pointed out that VLAN tagging could carry even more of 
the load here.  I mentioned that I can not use VLAN tagging as an 
explanation of why I have to pursue what you are describing.

Following in my plugin.ini.  As you can see, it is not what I would be 
editing. I have already added stuff to flat_networks, in anticipation of 
being able to use more than one.  My problem is that there is no 
bridge_mappings, so I can not update it to add more external networks!


# This file autogenerated by Chef
# Do not edit, changes will be overwritten

[ml2]
# (ListOpt) List of network type driver entrypoints to be loaded from
# the neutron.ml2.type_drivers namespace.
#
# type_drivers = local,flat,vlan,gre,vxlan
# Example: type_drivers = flat,vlan,gre,vxlan
type_drivers = gre,flat

# (ListOpt) Ordered list of network_types to allocate as tenant
# networks. The default value 'local' is useful for single-box testing
# but provides no connectivity between hosts.
#
# tenant_network_types = local
# Example: tenant_network_types = vlan,gre,vxlan
tenant_network_types = gre

# (ListOpt) Ordered list of networking mechanism driver entrypoints
# to be loaded from the neutron.ml2.mechanism_drivers namespace.
# mechanism_drivers =
# Example: mechanism_drivers = openvswitch,mlnx
# Example: mechanism_drivers = arista
# Example: mechanism_drivers = cisco,logger
# Example: mechanism_drivers = openvswitch,brocade
# Example: mechanism_drivers = linuxbridge,brocade

Re: [Openstack-operators] [neutron] multiple external networks on the same host NIC

[Mike Spreitzer]

Kevin Benton blak...@gmail.com wrote on 04/25/2015 08:38:25 PM:

 Bridge mappings is an agent configuration value, it's not in the 
 neutron server config. 
 Run ps -ef and look for the neutron openvswitch agent process to see
 which configuration files it's referencing. The bridge mappings will
 be in one of those. 

Thanks, that led me to it.

Mike

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

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

 From: Jacob Godin jacobgo...@gmail.com
 To: Mike Spreitzer/Watson/IBM@IBMUS
 Cc: Daniel Comnea comnea.d...@gmail.com, OpenStack Operators 
 openstack-operators@lists.openstack.org
 Date: 04/15/2015 08:37 AM
 Subject: Re: [Openstack-operators] [Neutron] Floating IPs / Router 
Gateways
 
 Ah, gotcha. So you're not using overlapping subnets then.
 
 Unfortunately that hack wouldn't work in our environment, but 
 definitely something that others might consider using.

Right, the solution I am using now imposes address constraints between 
tenants that share a router.  I need to eliminate constraints between 
tenants, so I have to abandon the solution I am using.  So I, too, am 
looking for different solution.

I want to support a lot of tenants doing fairly unrestricted stuff, so all 
the connections --- from their Compute Instances that do NOT have a 
floating IP --- to public servers is more than I want to SNAT onto a 
*single* public address.

Thanks,
Mike

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

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

 From: Mike Spreitzer/Watson/IBM@IBMUS
 
  From: Jacob Godin jacobgo...@gmail.com 
  
  Ah, gotcha. So you're not using overlapping subnets then. 
  
  Unfortunately that hack wouldn't work in our environment, but 
  definitely something that others might consider using. 
 
 Right, the solution I am using now imposes address constraints 
 between tenants that share a router.  I need to eliminate 
 constraints between tenants, so I have to abandon the solution I am 
 using.  So I, too, am looking for different solution. 
 
 I want to support a lot of tenants doing fairly unrestricted stuff, 
 so all the connections --- from their Compute Instances that do NOT 
 have a floating IP --- to public servers is more than I want to SNAT
 onto a *single* public address. 

I found a few tantalizing leads in 
http://specs.openstack.org/openstack/neutron-specs/index.html
I can not check them out fully right now because review.openstack.org is 
temporarily down.

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/specify-router-ext-ip.html
Allow the external IP address of a router to be specified

If you, like I, are intermediating the calls on Neutron and can transform 
a less specific call by the tenant into a precise formulation of your 
choosing (as either admin or the tenant, on a case by case basis), you can 
use the following solution.

Let the external network known to Neutron not be the actual public 
network but rather some other private network.  Using control over the 
router's IP on that other private network, scrunch all the router IP 
addresses into a dense range that is not in the allocation range.  Thus, 
the router IP addresses and the tenants' floating IP addresses are 
separated - you can put them in distinct large CIDR blocks.  Using some 
other router that connects that other private network to the actual public 
network, masquerade the router IP addresses onto however many public 
addresses you like, while doing 1:1 bidirectional NAT for the tenants' 
floating IP addresses.

Regards,
Mike___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

 From: Daniel Comnea comnea.d...@gmail.com
 To: Jacob Godin jacobgo...@gmail.com
 Cc: Mike Spreitzer/Watson/IBM@IBMUS, OpenStack Operators openstack-
 operat...@lists.openstack.org
 Date: 04/15/2015 02:34 AM
 Subject: Re: [Openstack-operators] [Neutron] Floating IPs / Router 
Gateways
 Sent by: daniel.com...@gmail.com
 
 Mike, pls share the solution, some are interested even if is a hack 
 as long as it gets the job done.
 

 
 On Tue, Apr 14, 2015 at 10:24 PM, Jacob Godin jacobgo...@gmail.com 
wrote:
 Hey Mike,
 
 Would you send along your solution off-list? I'm curious, and I won't 
judge :)
 
 On Tue, Apr 14, 2015 at 6:22 PM, Mike Spreitzer mspre...@us.ibm.com 
wrote:
 Jacob Godin jacobgo...@gmail.com wrote on 04/14/2015 05:12:48 PM:
 
  Absolutely. We're trying to reduce our public IPv4 usage, so having 
  one per tenant network (not even including floating IPs) is a drain. 
 
 I am having exactly the same issue.  I am currently solving it with 
 a different hack that nobody likes, I will not even describe it 
 here.  But total agreement that the problem is important. 
 
 IPv6 is the ultimate answer, provided there is a reasonably smooth 
 transition.  I think we will need to support a tenant that is using 
 both v4 and v6 during his transition.  This will require NAT between
 a tenant's v4 and v6. 
 
 Regards, 
 Mike

OK, you asked for it.  What we do is share Neutron routers, and add some 
iptables rules that prevent communication between the tenants sharing a 
router.  I told you it was a hack.

Regards,
Mike

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

Re: [Openstack-operators] [Neutron] Floating IPs / Router Gateways

[Mike Spreitzer]

Jacob Godin jacobgo...@gmail.com wrote on 04/14/2015 05:12:48 PM:

 Absolutely. We're trying to reduce our public IPv4 usage, so having 
 one per tenant network (not even including floating IPs) is a drain.

I am having exactly the same issue.  I am currently solving it with a 
different hack that nobody likes, I will not even describe it here.  But 
total agreement that the problem is important.

IPv6 is the ultimate answer, provided there is a reasonably smooth 
transition.  I think we will need to support a tenant that is using both 
v4 and v6 during his transition.  This will require NAT between a tenant's 
v4 and v6.

Regards,
Mike___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack] [neutron] how to use multiple external networks?

[Mike Spreitzer]

Supposing there are two external provider networks, and a tenant wants (a) 
some of his Compute Instances to have floating IP addresses on one of 
those external networks, (b) some other of his Compute Instances to have 
floating IP addresses on the other external network, and (c) all of his 
Compute Instances to be able to talk to each other using only tenant 
private networking, what arrangement of tenant networks and routers would 
accomplish this?  In Juno, if it matters.

Thanks,
Mike

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [neutron] Neutron scaling datapoints?

[Mike Spreitzer]

Are you looking at scaling the numbers of tenants, Neutron routers, and 
tenant networks as you scale hosts and guests?  I think this is a 
plausible way to grow.  The compartmentalizations that comes with growing 
those things may make a difference in results.

Thanks,
Mike



From:   Neil Jerram neil.jer...@metaswitch.com
To: openstack-dev@lists.openstack.org
Date:   04/08/2015 12:29 PM
Subject:[openstack-dev] [neutron] Neutron scaling datapoints?



My team is working on experiments looking at how far the Neutron server
will scale, with increasing numbers of compute hosts and VMs.  Does
anyone have any datapoints on this that they can share?  Or any clever
hints?

I'm already aware of the following ones:

https://javacruft.wordpress.com/2014/06/18/168k-instances/
 Icehouse
 118 compute hosts
 80 Neutron server processes (10 per core on each of 8 cores, on the
 controller node)
 27,000 VMs - but only after disabling all security/iptables

http://www.opencontrail.org/openstack-neutron-at-scale/
 1000 hosts
 5000 VMs
 3 Neutron servers (via a load balancer)
 But doesn't describe if any specific configuration is needed for this.
 (Other than using OpenContrail! :-))

Many thanks!
 Neil

__
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

Re: [Openstack] [neutron] how to use multiple external networks?

[Mike Spreitzer]

Oops, my original email did not contain all of the constraints.  Each 
compute instance gets only one network interface, only one IP address. 
Does Juno Neutron have a way to solve this problem?

Thanks,
Mike



From:   James Denton james.den...@rackspace.com
To: Mike Spreitzer/Watson/IBM@IBMUS, openstack 
openstack@lists.openstack.org
Date:   04/08/2015 07:04 PM
Subject:Re: [Openstack] [neutron] how to use multiple external 
networks?



Hi Mike,

With those requirements, I think dual-homing the instances may be the best 
approach. 

In my mind, you would have 5 networks:

A - External Network 1
B - External Network 2
C - Tenant Network 1 
D - Tenant Network 2
E - Shared Tenant Network (No gateway)

Because routers can only connect to one external network at a time, and a 
tenant network can only be connected to one router at a time, you would 
need two routers:

Router 1
Router 2

You would connect them as follows:

External Network 1 - Router 1 - Tenant Network 1
External Network 2 - Router 2 - Tenant Network 2

The VMs would then connect as follows:

Tenant Network 1 - VM1 - Shared Network
Tenant Network 2 - VM2 - Shared Network

With no gateway set on the shared network, you won't have to worry about 
multiple default routes, nor do you need to worry about terminating that 
network off a router. It's simply isolated. 

Hope that helps,
James

From: Mike Spreitzer mspre...@us.ibm.com
Sent: Wednesday, April 8, 2015 12:28 PM
To: openstack
Subject: [Openstack] [neutron] how to use multiple external networks? 
 
Supposing there are two external provider networks, and a tenant wants (a) 
some of his Compute Instances to have floating IP addresses on one of 
those external networks, (b) some other of his Compute Instances to have 
floating IP addresses on the other external network, and (c) all of his 
Compute Instances to be able to talk to each other using only tenant 
private networking, what arrangement of tenant networks and routers would 
accomplish this?  In Juno, if it matters. 

Thanks,
Mike 

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Latency of Neutron's floatingip-associate operation?

[Mike Spreitzer]

 I think I am seeing a latency on the order of 10 seconds between (a)
 the time Neutron returns success from that operation and (b) the 
 time when the association is actually functioning.  Is this sort of 
 latency to be expected?  I am using Juno, ML2, OVS, and GRE, if it 
matters. 

Sorry, I goofed when I calculated the time; I saw about 6 minutes between 
the return from the floatingip-associate operation and when it took 
effect.  Is the RPC from Neutron server to L3 agent synchronous with that 
API operation?

In this situation I had about 300 floating IPs spread over 4 routers, all 
served by one L3 agent.

Thanks,
Mike___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Latency of Neutron's floatingip-associate operation?

[Mike Spreitzer]

I think I am seeing a latency on the order of 10 seconds between (a) the 
time Neutron returns success from that operation and (b) the time when the 
association is actually functioning.  Is this sort of latency to be 
expected?  I am using Juno, ML2, OVS, and GRE, if it matters.

Thanks,
Mike

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [neutron] questions about IPv6 playing nice together with IPv4

[Mike Spreitzer]

Can Neutron do NAT between IPv4 and IPv6?  For example, if there is a 
Neutron router between an external network having only IPv6 subnets and a 
tenant network having only IPv4 subnets, can there be a floating IP 
address in v6 bound to a private IP address in v4?

If I have a tenant network with both IPv6 and IPv4 subnets and I attach 
that network to a router, does the router get both a v4 and a v6 address 
in the tenant network?

If I have an external network with both IPv6 and IPv4 subnets and I set 
that network to be the gateway network for a router, does that router get 
both a v4 and a v6 address in the external network?

A router can have only one gateway network, right?

If I have a dual stack Compute Instance, and a tenant network with both 
IPv4 and IPv6 subnets, I can give that Compute Instance just one network 
connection and the Compute Instance will be able to have both IPv4 and 
IPv6 addresses on that network, right?

Thanks,
Mike___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [openstack][ceilometer][icehouse]

[Mike Spreitzer]

Chinasubbareddy M chinasubbaredd...@persistent.com wrote on 03/13/2015 
12:56:33 AM:


 need to write a code in python to Implement a new custom meter data 
 in ceilometer, could you please help me out with your suggestion ?
 
 my intention is to collect the application sample data through that 
 new meter and implement auto scaling .

What sort of application sample data?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] Heat: autoscaling across availability zones

[Mike Spreitzer]

 From: Weidong Shao weidongs...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 Date: 02/28/2015 02:12 PM
 Subject: [openstack-dev] Heat: autoscaling across availability zones
 
 From the  heat template reference doc, it seems that auto-scaling 
 across AZs is not supported.   Is there any blueprint or plan in 
 adding this support?

Yes.  Here are some ways you can find that work:

https://blueprints.launchpad.net/openstack/?searchtext=availabilityzone

https://review.openstack.org/#/q/message:availability+message:zone,n,z 
includes some relevant answers; I have not yet figured out how to narrow 
the query to match only items in the heat and heat-specs projects.

Subscribe to notifications from Gerrit about activity in the Heat project, 
watch the email subject lines as they whizz by.

Regards,
Mike__
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] Fn::FindInMap gives error in Heat HOT Template

[Mike Spreitzer]

That doc also says that Ref is not supported in 
template heat_template_version: 2014-10-16.

Qiming Teng teng...@linux.vnet.ibm.com wrote on 02/12/2015 05:35:45 AM:

 From: Qiming Teng teng...@linux.vnet.ibm.com
 To: openstack@lists.openstack.org
 Date: 02/11/2015 09:47 PM
 Subject: Re: [Openstack] Fn::FindInMap gives error in Heat HOT Template
 
 I think Thomas was referring to this doc ...
 
 http://docs.openstack.org/developer/heat/template_guide/
 hot_spec.html#heat-template-verion
 
 
 On Wed, Feb 11, 2015 at 12:18:01AM -0800, Thomas Spatzier wrote:
  Hi Khayam,
  
  the Fn::FindInMap is not supported in HOT as far as I can see in the 
code.
  
  The list of functions supported in the HOT version you are using is 
defined
  in this part of the code:
  https://github.com/openstack/heat/blob/master/heat/engine/hot/
 template.py#L274
  
  The list for version 2013-05-23 can be found in the same file.
  I think this should also be covered in docs that get generated from 
the
  sources, but I do not have a link at hand right now.
  
  Regards,
  Thomas
  
   From: Khayam Gondal khayam.gon...@gmail.com
   To: openstack@lists.openstack.org openstack@lists.openstack.org
   Date: 11/02/2015 07:03
   Subject: [Openstack] Fn::FindInMap gives error in Heat HOT Template
  
   In my HOT template heat_template_version: 2014-10-16 I have a
   autoscaling group as
   auto_scale_server:
   type: OS::Heat::AutoScalingGroup
   properties:
 min_size: 0
 max_size: { Fn::FindInMap : [ mirror_map, { Ref :
  Mirror } ]}
 resource:
 type: OS::Nova::Server
 properties:
   name: Scaled_Blade
   image: UbuntuDemo
   flavor: g1.disk
   key_name: htor
   networks: [{network: internal}]
   where value of max_size depends upon Property Mirror
   In Parameters section
   parameters:
  
 Mirror:
   type: string
   label: Mirroring Port
   description: Select the Port on which you want to Mirror the
  traffic
   constraints:
- allowed_values:
  - port1
  - fm00
  
Mappings:
   mirror_map:
 fm00: 0
 port1: 1
   When I start this template, I got error
   ERROR: Invalid key 'mirror_map' for parameter (Mappings)
  
   P.S I had also changed  HOT template version to '2013-05-23' but no 
luck
   ___
   Mailing list:
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
   Post to : openstack@lists.openstack.org
   Unsubscribe :
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
  
  
  ___
  Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
  Post to : openstack@lists.openstack.org
  Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
  
 
 
 ___
 Mailing list: 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 Post to : openstack@lists.openstack.org
 Unsubscribe : 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
 
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] Control over gateway subnet?

[Mike Spreitzer]

For a certain Neutron installation I plan to have one external network 
with several subnets.  I was given a vague warning that there are problems 
with multiple subnets in an external network, but no details.  Do you know 
of any?  I have done a little testing and found no nasty surprise.

However, I find a critical lack of control.  When I create a router in 
Neutron and set it to be a gateway, I tell Neutron which external network 
the router is a gateway for.  But I need to control which external subnet 
the router attaches to.  I do this as an admin.  Is there a way to do 
this?

Let's start with a relatively easy version of the problem, which I will 
call initialization.  In this version of the problem, I am creating these 
routers as admin before there are any ordinary tenants in the system 
trying to use it in ordinary ways (e.g., allocating and releasing floating 
IP addresses), and there are no other admins doing anything interesting 
concurrently.  I can add the subnets to the external network one by one, 
and create the batch of routers that I want on that subnet before I 
proceed to the next subnet.

I could get the control I want by hacking the allocation ranges of the 
subnets, right?  That is, after I create and gateway-ize the routers I 
want for a given subnet, I can set that subnet's allocation range to be 
empty, and then proceed to the next subnet, so that the only choice that 
Neutron has is the one and only subnet with a non-empty allocation range 
at that moment.  When I am all done I can go back and restore the 
allocation ranges to what they should be.  That would be a viable 
approach, right?  Is there a better one?  It would be great if I could 
just directly indicate the desired subnet when I make a router become a 
gateway.

However, what I really want solved is a harder version of the problem --- 
which I will call update.  In this version of the problem I am not the 
sole user of the system.  While I am adding a given subnet and trying to 
attach some routers specifically to it, there are already ordinary tenants 
in the system doing ordinary things (including allocating and releasing 
floating IP addresses) involving subnets I created earlier.  I can still 
forbid interfering admins, and I know that none of the ordinary tenants 
will be using routers I create until I am ready --- those plebians can not 
attach their networks to the routers I create, I have to do it for them. 
But I can NOT close the allocation ranges of the previously created 
subnets, those need to be open so that the ordinary tenants can allocate 
and release floating IP addresses.  Is there a solution to the update 
version of my problem?

Thanks,
Mike___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] How to run the HEAT autoscaling YAML

[Mike Spreitzer]

Venu Murthy ve...@thoughtworks.com wrote on 11/06/2014 08:34:37 PM:

 In terms of the architecture for OpenStack setup, if we have a 
 controller node, Compute Node A and Compute Node B. 
 In the same availability zone. 
 
 I do understand that this autoscaling is more for the instances. But
 how can we load balance or start spawning our instances on Compute 
 Node B, if the Compute Node A's utilisation has reached a threshold

OpenStack gives a HOT author no access to the relationship between host 
and guest.  You can autoscale based only on metrics about the guest or 
things relatable to the guest in HOT.  Would it work for you to autoscale 
based on load or performance of your guests?

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [heat] AutoScalingGroup with LB Member

[Mike Spreitzer]

Cameron Seader csea...@suse.com wrote on 11/03/2014 06:22:32 PM:

 Please if you can help me out..
 
 Here is my heat stack
 http://paste.opensuse.org/80575159
 for some reason its failing on the member address.. not sure the syntax
 is right.

Compare with 
https://github.com/openstack/heat-templates/blob/master/hot/asg_of_stacks.yaml

Perhaps the text in the Template Guide (
http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::AutoScalingGroup
) is confusing on this point.  The value of the resource property should 
be the definition of one resource (i.e., the value to which the resource 
name is mapped in the YAML), not a set of resource definitions.

Regards,
Mike


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

Re: [Openstack] How to run the HEAT autoscaling YAML

[Mike Spreitzer]

Mridhul Pax mrid...@live.com wrote on 11/03/2014 02:17:23 AM:

 From: Mridhul Pax mrid...@live.com
 To: openstack@lists.openstack.org openstack@lists.openstack.org
 Date: 11/03/2014 02:26 AM
 Subject: [Openstack] How to run the HEAT autoscaling YAML
 
 Hello All,
 
 I'm trying to run the autoscaling heat template under : https://
 github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml 
 
 Can someone quickly help me how to run this and what all the 
 parameters to pass ? Im a newbie and getting confused with the 
 parameters to be passed.
 
 Thanks in advance
 Pax

Can you cite specific questions?
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [heat][ceilometer]: scale up/ down based on number of instances in a group

[Mike Spreitzer]

Daniel Comnea comnea.d...@gmail.com wrote on 10/27/2014 07:16:32 AM:

 Yes i did but if you look at this example
 
 
https://github.com/openstack/heat-templates/blob/master/hot/autoscaling.yaml

 

 the flow is simple:

 CPU alarm in Ceilometer triggers the type: OS::Heat::ScalingPolicy
 which then triggers the type: OS::Heat::AutoScalingGroup

Actually the ScalingPolicy does not trigger the ASG.  BTW, 
ScalingPolicy is mis-named; it is not a full policy, it is only an 
action (the condition part is missing --- as you noted, that is in the 
Ceilometer alarm).  The so-called ScalingPolicy does the action itself 
when triggered.  But it respects your configured min and max size.

What are you concerned about making your scaling group smaller than your 
configured minimum?  Just checking here that there is not a 
misunderstanding.

As Clint noted, there is a large-scale effort underway to make Heat 
maintain what it creates despite deletion of the underlying resources.

There is also a small-scale effort underway to make ASGs recover from 
members stopping proper functioning for whatever reason.  See 
https://review.openstack.org/#/c/127884/ for a proposed interface and 
initial implementation.

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

Re: [openstack-dev] [DevStack] Proposal - add support for Markdown for docs

[Mike Spreitzer]

Sean Dague s...@dague.net wrote on 10/27/2014 09:13:27 AM:

 From: Sean Dague s...@dague.net
 
 On 10/22/2014 11:10 AM, Collins, Sean wrote:
  With some xargs, sed, and pandoc - I now present to you the first
  attempt at converting the DevStack docs to RST, and making the doc 
build
  look similar to other projects.
  
  https://review.openstack.org/130241
  
  It is extremely rough, I basically ran everything through Pandoc and
  cleaned up any errors that Sphinx spat out. I'm sure there is a lot of
  work that needs to be done to format it to be more readable - but I'm
  pretty pleased with the result.
 
 +2, you are awesome for taking this on! Thanks much.
 
-Sean

Yes, thank you very much --- both for the doc infrastructure and the docs 
that you will write using it.

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

Re: [openstack-dev] [all] How can we get more feedback from users?

[Mike Spreitzer]

Angus Salkeld asalk...@mirantis.com wrote on 10/24/2014 12:32:04 AM:

 I have felt some grumblings about usability issues with Heat 
 templates/client/etc..
 and wanted a way that users could come and give us feedback easily 
 (low barrier). I started an etherpad (https://
 etherpad.openstack.org/p/heat-useablity-improvements) - the first 
 win is it is spelt wrong :-O

 We now have some great feedback there in a very short time, most of 
 this we should be able to solve.

 This lead me to think, should OpenStack have a more general 
 mechanism for users to provide feedback. The idea is this is not 
 for bugs or support, but for users to express pain points, requests 
 for features and docs/howtos.

 It's not easy to improve your software unless you are listening to your 
users.

 Ideas?

I very much agree with this.

I am actually surprised that OpenStack does not have something fairly 
formal and organized about this.  I suppose it is part of the TC's job, 
but I think we need more than they can do.  I would suggest some sort of 
user's council that gets involved in blueprint and change reviews. Perhaps 
after first working toward some degree of consensus and some degree of 
shaping what the developers work on in each release (this latter is part 
of the overall program of improving review queue speed, by better focusing 
developers and reviewers on some shared agenda).

Other products have discussion fora, some explicitly dedicated to 
feedback.  You could approximate this with etherpads, or use some real 
discussion forum platform.

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

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

[Mike Spreitzer]

I like the idea of measuring complexity.  I looked briefly at `python -m 
mccabe`.  It seems to measure each method independently.  Is this really 
fair?  If I have a class with some big methods, and I break it down into 
more numerous and smaller methods, then the largest method gets smaller, 
but the number of methods gets larger.  A large number of methods is 
itself a form of complexity.  It is not clear to me that said re-org has 
necessarily made the class easier to understand.  I can also break one 
class into two, but it is not clear to me that the project has necessarily 
become easier to understand.  While it is true that when you truly make a 
project easier to understand you sometimes break it into more classes, it 
is also true that you can do a bad job of re-organizing a set of classes 
while still reducing the size of the largest method.  Has the McCabe 
metric been evaluated on Python projects?  There is a danger in focusing 
on what is easy to measure if that is not really what you want to 
optimize.

BTW, I find that one of the complexity issues for me when I am learning 
about a Python class is doing the whole-program type inference so that I 
know what the arguments are.  It seems to me that if you want to measure 
complexity of Python code then something like the complexity of the 
argument typing should be taken into account.

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

[openstack-dev] [ceilometer] [heat] grace period for an alarm?

[Mike Spreitzer]

Can a Ceilometer client create an alarm with a grace period?  That is, an 
initial period of time during which alarms are suppressed.  For a related 
concept, see the grace period in an AWS autoscaling group.  Note that in 
an OpenStack heat template, the author can not write an arithmetic 
expression --- any time written must be a literal (and thus apply equally 
to all members of a scaling group, regardless of when they were created).

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

Re: [Openstack] How to make DevStack install OpenStack with Neutron?

[Mike Spreitzer]

Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote on 10/07/2014 02:50:01 
AM:

 On 07/10/14 19:44, Mike Spreitzer wrote:
  Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote on 10/07/2014
  02:23:36 AM:
 
I think why this is not documented is the usual use-case for 
devstack is
development setups where real external ips for the VMs is usually 
not a
point of interest.
   
For instance I never need this...I do sometimes want the VMs to be 
able
to access the internet, and that is pretty easy:
   
$ sudo sysctl -w net.ipv4.ip_forward=1
$ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
   
For access the other way, yes it's more complex. As others have 
posted,
you need real ip ranges available in your external network and
(probably) an additional nic in your test box that can be
designated/mapped as br-ex
so that the various routers/gateways in the neutron setup use it.
 
  Thanks, Mark.  As I mentioned in my original post, I have a block of 
IP
  addresses that I can use as I see fit --- I have a subnet that I
  control.  I do not see why an additional NIC on the host would be
  needed, it already has a NIC connected to a subnet that I control (I 
am
  trying to make it easy here).
 
 
 True, you can just assign another ip to your nic (in the appropriate 
 subnet range) and use that as br-ex - yes, I'm being old fashioned and 
 would prefer another nic to make it clear to me what was happening :-)


So I tried using DevStack with FLOATING_RANGE and PUBLIC_NETWORK_GATEWAY 
matching the initial network config of my lab machine, and with 
Q_FLOATING_ALLOCATION_POOL set to keep Neutron from allocating IPs already 
in use on my subnet.  I found that DevStack ruined my machine, by setting 
PUBLIC_NETWORK_GATEWAY as the address of br-ex.  There is an existing bug 
for this: https://bugs.launchpad.net/devstack/+bug/1339982 .  What 
mystifies me is that it is marked as affecting only three people.  Are 
there really only three people who use DevStack on service machines 
(rather than personal ones) and try to get inside/outside communication 
working as Neutron intended it?  Our CI checking uses DevStack on service 
machines, right?  Perhaps there is no problem there because checking does 
not attempt inside-outside communication?

Thanks,
Mike


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] How to make DevStack install OpenStack with Neutron?

[Mike Spreitzer]

Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote on 10/07/2014 02:23:36 
AM:

 I think why this is not documented is the usual use-case for devstack is 

 development setups where real external ips for the VMs is usually not a 
 point of interest.
 
 For instance I never need this...I do sometimes want the VMs to be able 
 to access the internet, and that is pretty easy:
 
 $ sudo sysctl -w net.ipv4.ip_forward=1
 $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
 
 For access the other way, yes it's more complex. As others have posted, 
 you need real ip ranges available in your external network and 
 (probably) an additional nic in your test box that can be 
 designated/mapped as br-ex
 so that the various routers/gateways in the neutron setup use it.

Thanks, Mark.  As I mentioned in my original post, I have a block of IP 
addresses that I can use as I see fit --- I have a subnet that I control. 
I do not see why an additional NIC on the host would be needed, it already 
has a NIC connected to a subnet that I control (I am trying to make it 
easy here).

Thanks,
Mike
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [Openstack-dev][nova] git fetch fails with permission denied (publickey)

[Mike Spreitzer]

Jennifer Mulsow/Austin/IBM@IBMUS wrote on 10/06/2014 06:45:21 PM:

 I have followed the instructions on https://wiki.openstack.org/wiki/
 Gerrit_Workflow and am trying to fetch the nova repository, but it 
 fails with Permission denied (publickey). I believe this has 
 something to do with my specific account on review.openstack.org, 
 but not sure what.
 
 git remote add origin ssh://jmul...@review.openstack.org:29418/
 openstack/nova.git
 git fetch origin
 Permission denied (publickey).
 fatal: Could not read from remote repository.
 
 Please make sure you have the correct access rights
 and the repository exists.

Maybe I am blind tonight, but I do not see where the Gerrit_Workflow wiki 
page is telling you to `git fetch origin`.  When starting from scratch 
(which I suppose you are), you want a command like this:

git clone git://git.openstack.org/openstack/nova.git

Your SSH test looks valid to me, I do not see why it should fail.

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

[Openstack] How to make DevStack install OpenStack with Neutron?

[Mike Spreitzer]

Is it possible to use DevStack to install OpenStack, including Neutron, so 
that OpenStack can make a VM that can communicate with the world beyond 
OpenStack?  I am looking for a simple localrc or local.conf that will do 
this.

Let us take a concrete example.  Suppose I have a machine with one NIC, at 
10.84.133.238/28.  It has a simple routing table: one entry for the local 
subnet, one default route through a gateway at 10.84.133.225.  I have 
nothing else on the 10.84.133.238/28 subnet, I can use the other addresses 
(aside from .224 and .239) for VMs. What do I put in my localrc?  Do I 
have to fix up anything after stack.sh completes?

Once I have a working OpenStack, the remaining questions are about how to 
use it to create a VM with the desired ability.  That would be as the demo 
user, in the demo tenant, right?  I would need a security group that 
allows the desired communication, of course.  Create the VM on the private 
net, give it a floating IP on the public network.  Any tricks missed here?

Does it matter whether my machine at 10.84.133.238 is a bare metal machine 
or a VM in some undercloud?

Does it matter whether my machine has multiple ethN interfaces that have 
been bonded to make the interface (named bond0) in use?

Thanks,
Mike___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] How to make DevStack install OpenStack with Neutron?

[Mike Spreitzer]

 From: Salvatore Orlando sorla...@nicira.com
 To: Mike Spreitzer/Watson/IBM@IBMUS
 Cc: OpenStack openstack@lists.openstack.org
 Date: 10/06/2014 05:40 PM
 Subject: Re: [Openstack] How to make DevStack install OpenStack with 
Neutron?
 
 Some (hopefully) helpful answer inline.
 
 Salvatore 
 
 On 6 October 2014 22:45, Mike Spreitzer mspre...@us.ibm.com wrote:
 Is it possible to use DevStack to install OpenStack, including 
 Neutron, so that OpenStack can make a VM that can communicate with 
 the world beyond OpenStack?  I am looking for a simple localrc or 
 local.conf that will do this. 
 
 This is a localrc I have been using for ages for launching neutron 
 (with a few changes over time, of course): http://
 paste.openstack.org/show/119143/ 

When I open http://paste.openstack.org/show/119143/ in my browser, I see 
this:

Internal Server Error
The server encountered an internal error and was unable to complete your 
request. Either the server is overloaded or there is an error in the 
application.

 Let us take a concrete example.  Suppose I have a machine with one NIC, 
at 
 10.84.133.238/28.  It has a simple routing table: one entry for the 
 local subnet, one default route through a gateway at 10.84.133.225. 
 I have nothing else on the 10.84.133.238/28 subnet, I can use the 
 other addresses (aside from .224 and .239) for VMs. What do I put in
 my localrc?  Do I have to fix up anything after stack.sh completes?
 
 If that's your only interface, there is no need to specify anything 
 in localrc.

You mean I do not have to set PUBLIC_NETWORK_GATEWAY=10.84.133.225 in my 
localrc?  I guess I am still confused about a basic fact about 
PUBLIC_NETWORK_GATEWAY: is this the IP address of a pre-existing gateway 
between my host's subnet and the wider world, or is it the IP address that 
DevStack will assign to a gateway that DevStack creates between 
OpenStack's external and private networks?

 I rarely do that, but if you wish to use flat or vlan networking 
 you'll probably need to specify the name of a bridge in localrc.

To start with, I'll settle for anything that works.


 Once I have a working OpenStack, the remaining questions are about 
 how to use it to create a VM with the desired ability.  That would 
 be as the demo user, in the demo tenant, right?  I would need a 
 security group that allows the desired communication, of course.  
 Create the VM on the private net, give it a floating IP on the 
 public network.  Any tricks missed here? 
 
 Devstack will give you a private network connected to a router which
 is uplinked to the external network. So you're right - you just need
 to boot a vm and assign a floating ip to its port.
  
 Does it matter whether my machine at 10.84.133.238 is a bare metal 
 machine or a VM in some undercloud? 
 
 I don't think it matters, at least with the ML2 plugin and OVS/LB 
 mech drivers - plus other plugins I know of. But restrictions might 
 exist with other plugins of which I'm not aware.
  
 
 Does it matter whether my machine has multiple ethN interfaces that 
 have been bonded to make the interface (named bond0) in use? 
 
 I don't think it matters at all, especially if you have a single node 
setup.

Thanks,
Mike___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] How to make DevStack install OpenStack with Neutron?

[Mike Spreitzer]

 From: Salvatore Orlando sorla...@nicira.com
 To: Mike Spreitzer/Watson/IBM@IBMUS
 Cc: OpenStack openstack@lists.openstack.org
 Date: 10/06/2014 05:40 PM
 Subject: Re: [Openstack] How to make DevStack install OpenStack with 
Neutron?
 
 ... 
 
 This is a localrc I have been using for ages for launching neutron 
 (with a few changes over time, of course): http://
 paste.openstack.org/show/119143/ 

Thank you.  When I try exactly that URL, the server errors.  But if I 
strip off the final slash, I see your paste.

I see nothing in that paste about setting the FLOATING_RANGE nor 
PUBLIC_NETWORK_GATEWAY.
These need to bear some relation to the host's subnet, right?
Before you run DevStack, what is your host's IP address, netmask, and 
gateway?

Does PUBLIC_NETWORK_GATEWAY describe a pre-existing gateway between the 
host's subnet and the wider world, or does it describe a gateway that 
DevStack creates between OpenStack's public and private networks?

Sorry, I should have given more details up front.  I am trying for my 
first successful install, so am not picky.  I do not really care which 
plugin is used, nor which driver.  A single-node install is fine.  I have 
done most of my testing with a fully updated Ubuntu 14.04 host.  I am 
trying to use DevStack to install the latest code.

Thanks,
Mike

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Fwd: Re: How to make DevStack install OpenStack with Neutron?

[Mike Spreitzer]

 From: Ian Y. Choi i...@naimnetworks.com
 To: openstack@lists.openstack.org
 Cc: Mike Spreitzer/Watson/IBM@IBMUS
 Date: 10/06/2014 10:50 PM
 Subject: Fwd: Re: [Openstack] How to make DevStack install OpenStack
 with Neutron?

 Hello,
 
 I'm not sure which Linux distribution you are using such as Redhat and 
Ubuntu.
 But, Hope that the two videos and localrc file would be helpful for you.
 
 - DevStack installation on VirtualBox: Icehouse with Neutron
 
 Video 1: http://youtu.be/zoi8WpGwrXM (Part 1: Installing Ubuntu 
 Linux on VirtualBox)
 Video 2: http://youtu.be/1GgODv34E08 (Part 2: Installing DevStack 
 with Neutron: Icehouse)
 Localrc file: http://goo.gl/OeOGq

Thank you, Ian.  I watched your videos. You pointed out that the floating 
IP addresses are not working well for you.  Other people, such as 
Salvatore Orlando in another reply to my question, have claimed that 
floating IP addresses will work.  I would like to have the floating IP 
addresses working well for me.

In one of my replies to Salvatore I said that I am not picky.  Perhaps I 
have one unusual requirement: I do not want to install OpenStack in a 
VirtualBox VM.  I want to install OpenStack on a bare metal machine, and I 
want to install OpenStack in a VM made by somebody else's OpenStack 
installation.

I noticed that you did not discuss the setting of FLOATING_RANGE and 
PUBLIC_NETWORK_GATEWAY.  I suspect that, in order for floating IP 
addresses to work correctly, the settings of these need to bear some 
particular relationship to the host's IP address, netmask, and gateway. 
And I wonder whether PUBLIC_NETWORK_GATEWAY describes a pre-existing 
gateway or one that DevStack will create.

I am attempting only a single-node install.  I prefer to use Ubuntu 14.04 
on the host.  I want DevStack to install the latest code from the master 
branch.

I think there was a copy-and-paste error on the short URL for your 
localrc; I presume you meant http://goo.gl/OeOGqL --- as in your video.

Thanks,
Mike
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state

[Mike Spreitzer]

Clint Byrum cl...@fewbar.com wrote on 10/01/2014 09:50:33 PM:

 Recently we've been testing image based updates using TripleO, and we've
 run into an interesting conundrum.
 
 Currently, our image build scripts create a user per service for the
 image. We don't, at this time, assert a UID, so it could get any UID in
 the /etc/passwd database of the image.
 
 However, if we add a service that happens to have its users created
 before a previously existing service, the UID's shift by one. When
 this new image is deployed, the username might be 'ceilometer', but
 /mnt/state/var/lib/ceilometer is now owned by 'cinder'.

I do not understand the problem statement. Unfortunately, I am not 
familiar with image based updates using TripleO.  What is updating what? 
If the UIDs are not asserted, what UIDs shift by one?  Is this because 
some files keep owner UID while the some UID=name binding in /etc/passwd 
changes? Or the other way around?  Why would there be a change in either?

If there is no short answer, don't worry about it.

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