[Openstack-operators] OpenStack Community Weekly Newsletter (May 29 - June 5)

[Stefano Maffulli]

  Containers and OpenStack: here's what you need to know
  


Interview with Adrian Otto, a principal architect at Rackspace, is the
project technical lead (PTL) for Magnum, an API service developed by the
OpenStack containers team for OpenStack to make container management
tools such as Docker and Kubernetes available as first-class resources
in OpenStack. Magnum officially joined the OpenStack project list upon
approval by a unanimous vote by the Technical Committee in March 2015.


  What building Legos can teach you about open source
  


If you want to build a gas station next to a children’s playground,
fireworks are pretty much guaranteed. That not-in-my-neighborhood
face-off was one of the issues hashed out in a recent OpenStack Upstream
Training 
session where about 50 participants split into teams building Lego sets.


  Travel grants bring global community members to OpenStack Summit
  


Turns out there's nothing like working together in person to push a
cloud project forward. To help make that valuable face time happen, the
OpenStack Foundation funded the travel and hotel accommodations for 21
men and 7 women who are key contributors to attend the OpenStack Summit
Vancouver.


  Neutron RFE Process
  

Starting with the development of the Juno release, the Neutron project
moved to using a specs repository
 similar to how
other projects were using them. Kyle Mestery, Neutron's PTL, reflects on
the fact that the process at best, lengthened the pipeline we had in
place to gate the incoming feature fire-hose. At worst, it turned off
potential committers. Neutron's team is implementing a new process meant
to allow users to express their desires for new features using Launchpad.


More Post-Vancouver Summaries

  * Geocaching at OpenStack Summit

  * The OpenStack Summit Kilo Summit – Recap


  * [oslo] Updates from the Summit

  * Liberty summit: Updates in Glance

  * summit session summary: Release Versioning for Server Applications



Relevant Conversations

  * Dynamic Policy and Microversions

  * The Nova API in Kilo and Beyond

  * 10 ways to make OpenStack more Start-up Friendly [even more critical
in wake of recent consolidation]

  * OpenStack is as start-up friendly as anything


  * OpenStack and Diversity 
  * [ceilometer][all] Scalable metering

  * Scaling out Nova (and the code review process)

  * [Nova] Follow up actions from the Summit: please help

  * Architecture Diagrams in ascii art?



Deadlines and Contributors Notifications

  * What's Up, Doc? 29 May 2015

  * What's Up, Doc? 5 June 2015

  * No longer doing stable point release

  * [Swift] dropping Py26 support

  * The new Lieutenant system in Neutron

  * [cinder] Cutting Inactive Blueprints for L-1

  * Architecture Diagrams in ascii art?



Security Advisories and Notices

  * None


Tips ‘n Tricks

  * By Thomas Oulevey

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Fox, Kevin M]

With my op hat on, I'd very much prefer packaged-in-ubuntu/packaged-in-centos 
or packaged=ubuntu,centos. If its just packaged=True, I'd still have to go look 
up if its in my distro of choice.

Thanks,
Kevin

From: Jeremy Stanley [fu...@yuggoth.org]
Sent: Friday, June 05, 2015 11:42 AM
To: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

On 2015-06-05 18:34:02 + (+), Tim Bell wrote:
> But if there is one package out of all of the OS options, does
> that make true or false ? Or do we have a rule that says a 1 means
> that at least CentOS and Ubuntu are packaged ?
>
> I remain to be convinced that a 0 or 1 can be achieved within the
> constraints that we need something which is useful for the
> operators rather than mathematically correct.
>
> Let’s not forget the target audience for the Ops tags.

This doesn't seem orthogonal to the idea of tags as boolean flags.
Is there any reason not to have separate tags like
packaged-in-ubuntu and packaged-in-centos? Of course there's still
some ambiguity over details like "how new is the packaged version?"
and "in what release(s) of the distro?" but those are probably
things you could build tag-qualifying rules around.
--
Jeremy Stanley

___
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

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Clint Byrum]

Excerpts from Tim Bell's message of 2015-06-05 11:34:02 -0700:
> 
> But if there is one package out of all of the OS options, does that make true 
> or false ? Or do we have a rule that says a 1 means that at least CentOS and 
> Ubuntu are packaged ?
> 
> I remain to be convinced that a 0 or 1 can be achieved within the constraints 
> that we need something which is useful for the operators rather than 
> mathematically correct.
> 
> Let’s not forget the target audience for the Ops tags.
> 

Wouldn't it make sense that having coarse grained tags would help the
rather busy operator more than a pile of information that has to be
processed and inserted into an already very complex model? Nobody
is saying tags can't find a position on a sliding scale, like
'packaged-in-ubuntu' or 'tested-on-rhel' seems like two tags that would
be relevant to ubuntu or rhel users, and are entirely binary.

Data from a real analysis is interesting, but what I really want when
evaluating options to spend my time on is "Is the community with me?"
If I can't find any tags that define what I'm trying to do, then the
answer is "probably not". If I grab the ubuntu packages of project X and
they aren't very high quality, I think the tag helps me to know that
it's worth it to report bugs and plow through the problems, because
the community is expressing very clearly "We want this to be packaged
in Ubuntu."

Meanwhie saying something is a 74 on the packaged scale in Ubuntu is a)
inaccurate the moment something changes, and b) very confusing to anybody
who doesn't know what that scale actually means.

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

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Anne Gentle]

On Fri, Jun 5, 2015 at 1:34 PM, Tim Bell  wrote:

>
>
> But if there is one package out of all of the OS options, does that make
> true or false ? Or do we have a rule that says a 1 means that at least
> CentOS and Ubuntu are packaged ?
>
>
>

I think it means you have to answer yes/no questions to fill in the
metadata. If that's not possible, or not desirable, let's keep talking.

There does need to be some descriptive information, especially for areas
like documentation completeness, but I do think I can help come up with
checklists that answer yes/no even for docs. (wow did I really just sign up
for that?) :)

Would that get closer and serve the audience? I'm highly aware we need to
serve ops making decisions.

Anne


>  I remain to be convinced that a 0 or 1 can be achieved within the
> constraints that we need something which is useful for the operators rather
> than mathematically correct.
>
>
>
> Let’s not forget the target audience for the Ops tags.
>
>
>
> Tim
>
>
>
> *From:* Anne Gentle [mailto:annegen...@justwriteclick.com]
> *Sent:* 05 June 2015 20:21
> *To:* Jesus M. Gonzalez-Barahona
> *Cc:* openstack-operators@lists.openstack.org
> *Subject:* Re: [Openstack-operators] [Tags] Tags Team Repo & our first
> tags!
>
>
>
>
>
>
>
> On Thu, Jun 4, 2015 at 1:34 PM, Jesus M. Gonzalez-Barahona <
> j...@bitergia.com> wrote:
>
> [Disclamer: I'm not an OpenStack operator, neither an OpenStack
> developer. I only have some experience in metrics, quality models, and
> tags]
>
> Given that tags have a clear binary value, and that some people have
> expressed the convenience of having some more information available,
> maybe the tags could be just the result of applying certain conditions
> to a more complex description of a metric or set of metrics.
>
>
>
> I definitely think we need both tags and descriptions. And what you
> describe below would be great!
>
>
>
>
>
>
> For example, we could have the metric "Ops:Packaged", which could be a
> detailed description of how the module is packaged, for example as a
> JSON document:
>
> {"complete-pkgs": 2,
>  "complete-pkgs-list": [{"system": "Debian", "url": ...}, {... }]
>  "wip-pkgs": 1,
>  "wip-pkgs": [...],
>  ...
> }
>
> And then one or more tags, based on conditions stated in that JSON. For
> example, the tag "Ops:Well-Packaged" could be defined for those
> "Ops:Packaged" with more than 5 in the "complete-pkgs" field, or with at
> least certain systems in "complete-pkgs-list", or whatever.
>
> But you could also define the tag "Ops:Basic-Packaged", if that is
> useful, for those covering say at least Ubuntu and CentOS.
>
> That way, an operator could just go for the tag, if that's enough for
> them. But they could also look at the complete definition of the metric,
> if they need more detail. My guess is that as the use of OpenStack
> becomes more and more complex, people will need more and more
> information to take decisions. And having metrics and tags this way
> provide the best of both worlds: tags are simple, binary, while metrics
> are detailed and can capture complexity (for example, the above JSON
> format could be extended to have into account specific releases for
> which packages are available).
>
> Another advantage is that tags could be derived automatically from
> metrics, and at least some metrics could be derived as well
> automatically from factual information (such as the existence of those
> packages in the corresponding repository). All of that would simplify a
> lot the maintenance of tags over time.
>
>
>
> Agreed. I'd love it if the ops team is willing to encode as much as they
> can and keep iterating over time.
>
>
>
> This tagging definition work won't be done for a while but we should keep
> poking at the problem with real data. I'm happy to have the ops team keep
> working on it and then come back to the TC with their list, similar to how
> the API Working Group is working separately from the TC.
>
>
>
> Anne
>
>
>
>
> Saludos,
>
> Jesus.
>
>
> On Thu, 2015-06-04 at 10:49 -0400, Jonathan Proulx wrote:
> > Been sort of chewing on the various opinions expressed ...
> > clearly this decision needs to be one of the first things to come
> > out of  the ops-tags team
> >
> > I think we could do most of what we need with binary tags if those
> > were hierarchical ie this tag means those other five are also applied,
> > but multiplies the number of tags by a lot and I think multiplies
> > complexity especially since many (perhaps most) of our tags will
> > require human judgement.
> >
> > Having a common schema for ops tags may allow us to retain the
> > richness of the content while not unnecessarily complicating their use
> > for example
> >
> > :
> >   value: 
> >   bug_list: []
> >   description: 
> >   exceptions: 
> >
> > Of these I'm not sure description and exceptions are needed but I'm
> > pretty sure value and bug list are, and once we have a data structure
> > beyond binary or key-value adding those two doesn't raise 

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Jeremy Stanley]

On 2015-06-05 18:34:02 + (+), Tim Bell wrote:
> But if there is one package out of all of the OS options, does
> that make true or false ? Or do we have a rule that says a 1 means
> that at least CentOS and Ubuntu are packaged ?
> 
> I remain to be convinced that a 0 or 1 can be achieved within the
> constraints that we need something which is useful for the
> operators rather than mathematically correct.
> 
> Let’s not forget the target audience for the Ops tags.

This doesn't seem orthogonal to the idea of tags as boolean flags.
Is there any reason not to have separate tags like
packaged-in-ubuntu and packaged-in-centos? Of course there's still
some ambiguity over details like "how new is the packaged version?"
and "in what release(s) of the distro?" but those are probably
things you could build tag-qualifying rules around.
-- 
Jeremy Stanley

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

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Tim Bell]

But if there is one package out of all of the OS options, does that make true 
or false ? Or do we have a rule that says a 1 means that at least CentOS and 
Ubuntu are packaged ?

I remain to be convinced that a 0 or 1 can be achieved within the constraints 
that we need something which is useful for the operators rather than 
mathematically correct.

Let’s not forget the target audience for the Ops tags.

Tim

From: Anne Gentle [mailto:annegen...@justwriteclick.com]
Sent: 05 June 2015 20:21
To: Jesus M. Gonzalez-Barahona
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!



On Thu, Jun 4, 2015 at 1:34 PM, Jesus M. Gonzalez-Barahona 
mailto:j...@bitergia.com>> wrote:
[Disclamer: I'm not an OpenStack operator, neither an OpenStack
developer. I only have some experience in metrics, quality models, and
tags]

Given that tags have a clear binary value, and that some people have
expressed the convenience of having some more information available,
maybe the tags could be just the result of applying certain conditions
to a more complex description of a metric or set of metrics.

I definitely think we need both tags and descriptions. And what you describe 
below would be great!



For example, we could have the metric "Ops:Packaged", which could be a
detailed description of how the module is packaged, for example as a
JSON document:

{"complete-pkgs": 2,
 "complete-pkgs-list": [{"system": "Debian", "url": ...}, {... }]
 "wip-pkgs": 1,
 "wip-pkgs": [...],
 ...
}

And then one or more tags, based on conditions stated in that JSON. For
example, the tag "Ops:Well-Packaged" could be defined for those
"Ops:Packaged" with more than 5 in the "complete-pkgs" field, or with at
least certain systems in "complete-pkgs-list", or whatever.

But you could also define the tag "Ops:Basic-Packaged", if that is
useful, for those covering say at least Ubuntu and CentOS.

That way, an operator could just go for the tag, if that's enough for
them. But they could also look at the complete definition of the metric,
if they need more detail. My guess is that as the use of OpenStack
becomes more and more complex, people will need more and more
information to take decisions. And having metrics and tags this way
provide the best of both worlds: tags are simple, binary, while metrics
are detailed and can capture complexity (for example, the above JSON
format could be extended to have into account specific releases for
which packages are available).

Another advantage is that tags could be derived automatically from
metrics, and at least some metrics could be derived as well
automatically from factual information (such as the existence of those
packages in the corresponding repository). All of that would simplify a
lot the maintenance of tags over time.

Agreed. I'd love it if the ops team is willing to encode as much as they can 
and keep iterating over time.

This tagging definition work won't be done for a while but we should keep 
poking at the problem with real data. I'm happy to have the ops team keep 
working on it and then come back to the TC with their list, similar to how the 
API Working Group is working separately from the TC.

Anne


Saludos,

Jesus.

On Thu, 2015-06-04 at 10:49 -0400, Jonathan Proulx wrote:
> Been sort of chewing on the various opinions expressed ...
> clearly this decision needs to be one of the first things to come
> out of  the ops-tags team
>
> I think we could do most of what we need with binary tags if those
> were hierarchical ie this tag means those other five are also applied,
> but multiplies the number of tags by a lot and I think multiplies
> complexity especially since many (perhaps most) of our tags will
> require human judgement.
>
> Having a common schema for ops tags may allow us to retain the
> richness of the content while not unnecessarily complicating their use
> for example
>
> :
>   value: 
>   bug_list: []
>   description: 
>   exceptions: 
>
> Of these I'm not sure description and exceptions are needed but I'm
> pretty sure value and bug list are, and once we have a data structure
> beyond binary or key-value adding those two doesn't raise complexity
> significantly and does add some value.
>
> Once we do set a precedent for either binary tags or rich tags I have a
> feeling it will stick hard, especially if we choose binary.
>
> If we really find we can define all the tags we want with just a true or false
> value then there's no point in complicating things and the additional info 
> could
> likely be provided in a wiki page or something as a concordance to the tags
> rather than in the tag itself.
>
> So I'd like to challenge those of us currently advocating structured rather
> than binary tags to come up with tag examples we feel are necessary and
> nonbinary.
>
> The install-guide tag likely could be binary, though enriching 'false'
> with links to less official or work in progress documentation could be
> v

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Anne Gentle]

On Thu, Jun 4, 2015 at 1:34 PM, Jesus M. Gonzalez-Barahona  wrote:

> [Disclamer: I'm not an OpenStack operator, neither an OpenStack
> developer. I only have some experience in metrics, quality models, and
> tags]
>
> Given that tags have a clear binary value, and that some people have
> expressed the convenience of having some more information available,
> maybe the tags could be just the result of applying certain conditions
> to a more complex description of a metric or set of metrics.
>

I definitely think we need both tags and descriptions. And what you
describe below would be great!



>
> For example, we could have the metric "Ops:Packaged", which could be a
> detailed description of how the module is packaged, for example as a
> JSON document:
>
> {"complete-pkgs": 2,
>  "complete-pkgs-list": [{"system": "Debian", "url": ...}, {... }]
>  "wip-pkgs": 1,
>  "wip-pkgs": [...],
>  ...
> }
>
> And then one or more tags, based on conditions stated in that JSON. For
> example, the tag "Ops:Well-Packaged" could be defined for those
> "Ops:Packaged" with more than 5 in the "complete-pkgs" field, or with at
> least certain systems in "complete-pkgs-list", or whatever.
>
> But you could also define the tag "Ops:Basic-Packaged", if that is
> useful, for those covering say at least Ubuntu and CentOS.
>
> That way, an operator could just go for the tag, if that's enough for
> them. But they could also look at the complete definition of the metric,
> if they need more detail. My guess is that as the use of OpenStack
> becomes more and more complex, people will need more and more
> information to take decisions. And having metrics and tags this way
> provide the best of both worlds: tags are simple, binary, while metrics
> are detailed and can capture complexity (for example, the above JSON
> format could be extended to have into account specific releases for
> which packages are available).
>
> Another advantage is that tags could be derived automatically from
> metrics, and at least some metrics could be derived as well
> automatically from factual information (such as the existence of those
> packages in the corresponding repository). All of that would simplify a
> lot the maintenance of tags over time.
>

Agreed. I'd love it if the ops team is willing to encode as much as they
can and keep iterating over time.

This tagging definition work won't be done for a while but we should keep
poking at the problem with real data. I'm happy to have the ops team keep
working on it and then come back to the TC with their list, similar to how
the API Working Group is working separately from the TC.

Anne


>
> Saludos,
>
> Jesus.
>
> On Thu, 2015-06-04 at 10:49 -0400, Jonathan Proulx wrote:
> > Been sort of chewing on the various opinions expressed ...
> > clearly this decision needs to be one of the first things to come
> > out of  the ops-tags team
> >
> > I think we could do most of what we need with binary tags if those
> > were hierarchical ie this tag means those other five are also applied,
> > but multiplies the number of tags by a lot and I think multiplies
> > complexity especially since many (perhaps most) of our tags will
> > require human judgement.
> >
> > Having a common schema for ops tags may allow us to retain the
> > richness of the content while not unnecessarily complicating their use
> > for example
> >
> > :
> >   value: 
> >   bug_list: []
> >   description: 
> >   exceptions: 
> >
> > Of these I'm not sure description and exceptions are needed but I'm
> > pretty sure value and bug list are, and once we have a data structure
> > beyond binary or key-value adding those two doesn't raise complexity
> > significantly and does add some value.
> >
> > Once we do set a precedent for either binary tags or rich tags I have a
> > feeling it will stick hard, especially if we choose binary.
> >
> > If we really find we can define all the tags we want with just a true or
> false
> > value then there's no point in complicating things and the additional
> info could
> > likely be provided in a wiki page or something as a concordance to the
> tags
> > rather than in the tag itself.
> >
> > So I'd like to challenge those of us currently advocating structured
> rather
> > than binary tags to come up with tag examples we feel are necessary and
> > nonbinary.
> >
> > The install-guide tag likely could be binary, though enriching 'false'
> > with links to less official or work in progress documentation could be
> > valuable a web search could hopefully get you that, exceptions might
> > be useful if a distro does something that breaks an install guide for
> > that one case and if there is an exception a bug pointer would be
> > ideal, IMO.
> >
> > The packaged tag I think is a stronger case for structured content.
> > Imagine we break it down to the obvious packaged-deb and packaged-rpm
> > there's still much complexity back there and I think we'd need
> > exceptions.
> >
> > -Jon
> >
> > On Wed, Jun 3, 2015 a

[Openstack-operators] [neutron] DVR & other drivers

[Fox, Kevin M]

Does DVR work with other drivers such as the Mellenox or Cisco drivers? What 
about with anything SRIOV?

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

Re: [Openstack-operators] Help with multiple external network in openstack

[Geo Varghese]

Kevin,

You are right. Just found the issue. Created external network as Flat
network.

Now its is working :)

Thanks a lot guys for your valuable help

Kevin
Miguel
Noah

I will keep in touch wth you guys.





On Fri, Jun 5, 2015 at 8:31 PM, Fox, Kevin M  wrote:

>  Since you are passing the tagged physical network device eth1.803 into
> the bridge, I think you need to use a flat network in the config/ external
> network create command. Otherwise it may do nested vlan tags.
>
> Thanks,
> Kevin
>
> --
> *From:* Geo Varghese
> *Sent:* Friday, June 05, 2015 5:38:33 AM
> *To:* Miguel A Diaz Corchero
> *Cc:* openstack-operators@lists.openstack.org
> *Subject:* Re: [Openstack-operators] Help with multiple external network
> in openstack
>
>   Hi Miguel,
>
>  *I am adding my content of /etc/neutron/plugins/ml2/ml2_conf.ini of
> controller*
>
> [ml2]
> type_drivers = gre,vlan
> tenant_network_types = gre,vlan
> mechanism_drivers = openvswitch
>
> [ml2_type_flat]
> flat_networks =
>
> [ml2_type_vlan]
> network_vlan_ranges = physnet1:803:803,physnet2:805:805
>
> [ml2_type_gre]
> tunnel_id_ranges = 1:1000
>
> [ml2_type_vxlan]
> vni_ranges =
> vxlan_group =
>
> [securitygroup]
> enable_security_group = True
> enable_ipset = True
> firewall_driver =
> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>
> [ovs]
> local_ip = 192.168.100.74
> tunnel_type = gre
> enable_tunneling = True
> bridge_mappings = physnet1:br-ex803,physnet2:br-ex805
>
>  *The content of /etc/neutron/l3_agent.ini of controller*
>
> [DEFAULT]
> debug = True
> interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
> use_namespaces = True
> gateway_external_network_id =
> handle_internal_only_routers = True
> external_network_bridge =
> metadata_port = 9697
> send_arp_for_ha = 3
> periodic_interval = 40
> periodic_fuzzy_delay = 5
> router_delete_namespaces = False
>
>
>  *Content of ovs-vsctl show  after creating the bridges
>   *
>
> root@Node25:/home/geo# ovs-vsctl show
> cd31399c-bdb7-4b79-9d51-acbec1a41619
> Bridge br-int
> fail_mode: secure
> Port int-br-ex
> Interface int-br-ex
> Port "qr-221f276d-81"
> tag: 1
> Interface "qr-221f276d-81"
> type: internal
> Port patch-tun
> Interface patch-tun
> type: patch
> options: {peer=patch-int}
> Port "int-br-ex805"
> Interface "int-br-ex805"
> Port "int-br-ex803"
> Interface "int-br-ex803"
> Port "qg-d3568030-c3"
> tag: 2
> Interface "qg-d3568030-c3"
> type: internal
> Port "tapd7bacca2-15"
> tag: 1
> Interface "tapd7bacca2-15"
> type: internal
> Port br-int
> Interface br-int
> type: internal
> Bridge "br-ex803"
> Port "eth1.803"
> Interface "eth1.803"
> Port "phy-br-ex803"
> Interface "phy-br-ex803"
> Port "br-ex803"
> Interface "br-ex803"
> type: internal
> Bridge br-tun
> Port "gre-c0a864fe"
> Interface "gre-c0a864fe"
> type: gre
> options: {in_key=flow, local_ip="192.168.100.74",
> out_key=flow, remote_ip="192.168.100.254"}
> Port patch-int
> Interface patch-int
> type: patch
> options: {peer=patch-tun}
> Port br-tun
> Interface br-tun
> type: internal
> Bridge "br-ex805"
> Port "phy-br-ex805"
> Interface "phy-br-ex805"
> Port "br-ex805"
> Interface "br-ex805"
> type: internal
> Port "eth1.805"
> Interface "eth1.805"
> ovs_version: "2.0.2"
>
>
>  *External network added by following commands*
>
> External network 1 =>
>
>  neutron net-create ext-net1 --shared --router:external=True
> --provider:physical_network physnet1 --provider:network_type vlan
> --provider:segmentation_id 803
>
> neutron subnet-create ext-net1 --name ext-subnet1 --allocation-pool
> start=192.168.200.150,end=192.168.200.160 --disable-dhcp 192.168.200.0/24
>
> External network 2 =>
> neutron net-create ext-net2 --shared --router:external=True
> --provider:physical_network physnet2 --provider:network_type vlan
> --provider:segmentation_id 805
>
> neutron subnet-create ext-net2 --name ext-subnet1 --allocation-pool
> start=192.168.123.150,end=192.168.123.160 --disable-dhcp 192.168.123.0/24
>
>  Please update if you need any other details.
>
>  Thanks again for your time.
>
>
> On Fri, Jun 5, 2015 at 5:05 PM, Geo Varghese  wrote:
>
>>   Hi Miguel,
>>
>>  Thanks for getting back to me.
>>
>>  I have already restarted both machines - controller and compute
>>
>>  Do i need to paste any commands or conf to debug it?
>>
>>
>> On Fri, Jun 5, 201

Re: [Openstack-operators] Help with multiple external network in openstack

[Fox, Kevin M]

Since you are passing the tagged physical network device eth1.803 into the 
bridge, I think you need to use a flat network in the config/ external network 
create command. Otherwise it may do nested vlan tags.

Thanks,
Kevin


From: Geo Varghese
Sent: Friday, June 05, 2015 5:38:33 AM
To: Miguel A Diaz Corchero
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Help with multiple external network in 
openstack

Hi Miguel,

I am adding my content of /etc/neutron/plugins/ml2/ml2_conf.ini of controller

[ml2]
type_drivers = gre,vlan
tenant_network_types = gre,vlan
mechanism_drivers = openvswitch

[ml2_type_flat]
flat_networks =

[ml2_type_vlan]
network_vlan_ranges = physnet1:803:803,physnet2:805:805

[ml2_type_gre]
tunnel_id_ranges = 1:1000

[ml2_type_vxlan]
vni_ranges =
vxlan_group =

[securitygroup]
enable_security_group = True
enable_ipset = True
firewall_driver = 
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[ovs]
local_ip = 192.168.100.74
tunnel_type = gre
enable_tunneling = True
bridge_mappings = physnet1:br-ex803,physnet2:br-ex805

The content of /etc/neutron/l3_agent.ini of controller

[DEFAULT]
debug = True
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
use_namespaces = True
gateway_external_network_id =
handle_internal_only_routers = True
external_network_bridge =
metadata_port = 9697
send_arp_for_ha = 3
periodic_interval = 40
periodic_fuzzy_delay = 5
router_delete_namespaces = False


Content of ovs-vsctl show  after creating the bridges

root@Node25:/home/geo# ovs-vsctl show
cd31399c-bdb7-4b79-9d51-acbec1a41619
Bridge br-int
fail_mode: secure
Port int-br-ex
Interface int-br-ex
Port "qr-221f276d-81"
tag: 1
Interface "qr-221f276d-81"
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "int-br-ex805"
Interface "int-br-ex805"
Port "int-br-ex803"
Interface "int-br-ex803"
Port "qg-d3568030-c3"
tag: 2
Interface "qg-d3568030-c3"
type: internal
Port "tapd7bacca2-15"
tag: 1
Interface "tapd7bacca2-15"
type: internal
Port br-int
Interface br-int
type: internal
Bridge "br-ex803"
Port "eth1.803"
Interface "eth1.803"
Port "phy-br-ex803"
Interface "phy-br-ex803"
Port "br-ex803"
Interface "br-ex803"
type: internal
Bridge br-tun
Port "gre-c0a864fe"
Interface "gre-c0a864fe"
type: gre
options: {in_key=flow, local_ip="192.168.100.74", out_key=flow, 
remote_ip="192.168.100.254"}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Bridge "br-ex805"
Port "phy-br-ex805"
Interface "phy-br-ex805"
Port "br-ex805"
Interface "br-ex805"
type: internal
Port "eth1.805"
Interface "eth1.805"
ovs_version: "2.0.2"


External network added by following commands

External network 1 =>

 neutron net-create ext-net1 --shared --router:external=True 
--provider:physical_network physnet1 --provider:network_type vlan 
--provider:segmentation_id 803

neutron subnet-create ext-net1 --name ext-subnet1 --allocation-pool 
start=192.168.200.150,end=192.168.200.160 --disable-dhcp 
192.168.200.0/24

External network 2 =>
neutron net-create ext-net2 --shared --router:external=True 
--provider:physical_network physnet2 --provider:network_type vlan 
--provider:segmentation_id 805

neutron subnet-create ext-net2 --name ext-subnet1 --allocation-pool 
start=192.168.123.150,end=192.168.123.160 --disable-dhcp 
192.168.123.0/24

Please update if you need any other details.

Thanks again for your time.


On Fri, Jun 5, 2015 at 5:05 PM, Geo Varghese 
mailto:gvargh...@aqorn.com>> wrote:
Hi Miguel,

Thanks for getting back to me.

I have already restarted both machines - controller and compute

Do i need to paste any commands or conf to debug it?


On Fri, Jun 5, 2015 at 4:55 PM, Miguel A Diaz Corchero 
mailto:miguelangel.d...@externos.ciemat.es>>
 wrote:
El 05/06/15 13:07, Geo Varghese escribió:
I tried it but somethig missing still, ping to floating IP seems not working
please, try to restart the L3 agent linked with that floating IP and let us know

do we have to add any changes to compute node  for it?
it shouldn't be necessary

Miguel.



On Fri, Jun 5, 2015 at 12:16 PM, Geo Varghese 
mailto:gvargh...@aqorn.com>> wrote:
Miguel,

Thanks thats a great link. Let me try it.

On Fri, Jun 5, 2015 at 12:04 

[Openstack-operators] Random NUMA cell selection can leave NUMA cells unused

[Belmiro Moreira]

Hi,
I would like to raise your attention for the bug
https://bugs.launchpad.net/nova/+bug/1461777
since it can impact the efficiency of your cloud.
It affects Juno and Kilo deployments.

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

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Jonathan Proulx]

On Fri, Jun 5, 2015 at 4:34 AM, Thierry Carrez  wrote:

> One option is to abandon the idea and converge to using the same
> concept. Another option is to rename that rich data ("project
> operational metadata" ?) to avoid the confusion of calling with same
> name what is essentially two different things. That will open the door
> to defining "tags" on top of it.

I guess I'm still not seeing why binary is a hard requirement, but...

This is an interesting alternative which may give both sides
everything they want.  If this is the way we go I think the same WG
should handle the rich metadata and binary tags.  Generating binary
tags out of structured data sources should be pretty trivial, if we
really need to have an other layer of abstraction here.

-Jon

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

Re: [Openstack-operators] Help with multiple external network in openstack

[Geo Varghese]

Hi Miguel,

*I am adding my content of /etc/neutron/plugins/ml2/ml2_conf.ini of
controller*

[ml2]
type_drivers = gre,vlan
tenant_network_types = gre,vlan
mechanism_drivers = openvswitch

[ml2_type_flat]
flat_networks =

[ml2_type_vlan]
network_vlan_ranges = physnet1:803:803,physnet2:805:805

[ml2_type_gre]
tunnel_id_ranges = 1:1000

[ml2_type_vxlan]
vni_ranges =
vxlan_group =

[securitygroup]
enable_security_group = True
enable_ipset = True
firewall_driver =
neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[ovs]
local_ip = 192.168.100.74
tunnel_type = gre
enable_tunneling = True
bridge_mappings = physnet1:br-ex803,physnet2:br-ex805

*The content of /etc/neutron/l3_agent.ini of controller*

[DEFAULT]
debug = True
interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
use_namespaces = True
gateway_external_network_id =
handle_internal_only_routers = True
external_network_bridge =
metadata_port = 9697
send_arp_for_ha = 3
periodic_interval = 40
periodic_fuzzy_delay = 5
router_delete_namespaces = False


*Content of ovs-vsctl show  after creating the bridges
  *

root@Node25:/home/geo# ovs-vsctl show
cd31399c-bdb7-4b79-9d51-acbec1a41619
Bridge br-int
fail_mode: secure
Port int-br-ex
Interface int-br-ex
Port "qr-221f276d-81"
tag: 1
Interface "qr-221f276d-81"
type: internal
Port patch-tun
Interface patch-tun
type: patch
options: {peer=patch-int}
Port "int-br-ex805"
Interface "int-br-ex805"
Port "int-br-ex803"
Interface "int-br-ex803"
Port "qg-d3568030-c3"
tag: 2
Interface "qg-d3568030-c3"
type: internal
Port "tapd7bacca2-15"
tag: 1
Interface "tapd7bacca2-15"
type: internal
Port br-int
Interface br-int
type: internal
Bridge "br-ex803"
Port "eth1.803"
Interface "eth1.803"
Port "phy-br-ex803"
Interface "phy-br-ex803"
Port "br-ex803"
Interface "br-ex803"
type: internal
Bridge br-tun
Port "gre-c0a864fe"
Interface "gre-c0a864fe"
type: gre
options: {in_key=flow, local_ip="192.168.100.74",
out_key=flow, remote_ip="192.168.100.254"}
Port patch-int
Interface patch-int
type: patch
options: {peer=patch-tun}
Port br-tun
Interface br-tun
type: internal
Bridge "br-ex805"
Port "phy-br-ex805"
Interface "phy-br-ex805"
Port "br-ex805"
Interface "br-ex805"
type: internal
Port "eth1.805"
Interface "eth1.805"
ovs_version: "2.0.2"


*External network added by following commands*

External network 1 =>

 neutron net-create ext-net1 --shared --router:external=True
--provider:physical_network physnet1 --provider:network_type vlan
--provider:segmentation_id 803

neutron subnet-create ext-net1 --name ext-subnet1 --allocation-pool
start=192.168.200.150,end=192.168.200.160 --disable-dhcp 192.168.200.0/24

External network 2 =>
neutron net-create ext-net2 --shared --router:external=True
--provider:physical_network physnet2 --provider:network_type vlan
--provider:segmentation_id 805

neutron subnet-create ext-net2 --name ext-subnet1 --allocation-pool
start=192.168.123.150,end=192.168.123.160 --disable-dhcp 192.168.123.0/24

Please update if you need any other details.

Thanks again for your time.


On Fri, Jun 5, 2015 at 5:05 PM, Geo Varghese  wrote:

> Hi Miguel,
>
> Thanks for getting back to me.
>
> I have already restarted both machines - controller and compute
>
> Do i need to paste any commands or conf to debug it?
>
>
> On Fri, Jun 5, 2015 at 4:55 PM, Miguel A Diaz Corchero <
> miguelangel.d...@externos.ciemat.es> wrote:
>
>>  El 05/06/15 13:07, Geo Varghese escribió:
>>
>> I tried it but somethig missing still, ping to floating IP seems not
>> working
>>
>> please, try to restart the L3 agent linked with that floating IP and let
>> us know
>>
>>
>> do we have to add any changes to compute node  for it?
>>
>> it shouldn't be necessary
>>
>> Miguel.
>>
>>
>>
>> On Fri, Jun 5, 2015 at 12:16 PM, Geo Varghese 
>> wrote:
>>
>>>  Miguel,
>>>
>>>  Thanks thats a great link. Let me try it.
>>>
>>> On Fri, Jun 5, 2015 at 12:04 PM, Miguel A Diaz Corchero <
>>> miguelangel.d...@externos.ciemat.es> wrote:
>>>
  Following this link I configured it in my infrastructure. Maybe this
 can also help you.


 https://www.softwareab.net/wordpress/openstack-adding-external-networks-neutron-gre/

 Miguel.

 El 04/06/15 23:15, Geo Varghese escribió:

   Thanks a lot friend for explaining it. I am also using ubuntu.

  let me try it. I will upd

Re: [Openstack-operators] Help with multiple external network in openstack

[Geo Varghese]

Hi Miguel,

Thanks for getting back to me.

I have already restarted both machines - controller and compute

Do i need to paste any commands or conf to debug it?


On Fri, Jun 5, 2015 at 4:55 PM, Miguel A Diaz Corchero <
miguelangel.d...@externos.ciemat.es> wrote:

>  El 05/06/15 13:07, Geo Varghese escribió:
>
> I tried it but somethig missing still, ping to floating IP seems not
> working
>
> please, try to restart the L3 agent linked with that floating IP and let
> us know
>
>
> do we have to add any changes to compute node  for it?
>
> it shouldn't be necessary
>
> Miguel.
>
>
>
> On Fri, Jun 5, 2015 at 12:16 PM, Geo Varghese  wrote:
>
>>  Miguel,
>>
>>  Thanks thats a great link. Let me try it.
>>
>> On Fri, Jun 5, 2015 at 12:04 PM, Miguel A Diaz Corchero <
>> miguelangel.d...@externos.ciemat.es> wrote:
>>
>>>  Following this link I configured it in my infrastructure. Maybe this
>>> can also help you.
>>>
>>>
>>> https://www.softwareab.net/wordpress/openstack-adding-external-networks-neutron-gre/
>>>
>>> Miguel.
>>>
>>> El 04/06/15 23:15, Geo Varghese escribió:
>>>
>>>   Thanks a lot friend for explaining it. I am also using ubuntu.
>>>
>>>  let me try it. I will update you with the results.
>>>
>>> On Fri, Jun 5, 2015 at 2:20 AM, Abrahams.Noah 
>>> wrote:
>>>
  Hi Geo,



 First a disclaimer: I’m working on Ubuntu and Icehouse, so you might
 have different behavior, based on your distributions.  Also, I don’t have
 all the specifics and flags you might need, but hopefully this can point
 you in the right direction.  Also, also, the design below accounts for some
 VLAN segregation, and may be more complicated than what you need.



 Since you already have the eth devices created, and assuming your
 routing is correct: I would create a new bridge for each vlan with
 ovs-vsctl (say, br-ex803 and br-ex805).  If you look at
 http://openvswitch.org/support/dist-docs/ovs-vsctl.8.txt you can find
 the syntax for add-br to create the bridge, then add-port to bind it to the
 eth device.  You can also use ovs-vsctl to set the trunks property on the
 port, after it’s created, which you’ll need for the vlan tagging.  Then,
 create a new physnet to match each one of those (physnet3, physnet4, etc)
 and include them in the bridge-mapping as “physnet3:br-ex803”, or something
 similar, and specify the VLANs as belonging to that particular physnet in
 the network_vlan_ranges parameter, like “…physnet3:803,physnet4:805”.



 After all that, you’ll need to update the neutron sql database so the
 entry in the network segments table will point to the correct physnet.
 Search it by the UUID of the network you’re creating, and update the
 physical_network property to match “physnet3” or whatever you create.  Then
 you can create a subnet from that network, allocate from it, and it should
 work.  You’ll also need to restart the openvswitch-agent and the L3-agent,
 probably before you create the subnet.



 *Noah Abrahams*

 Staff Engineer @ IGT  |  Central Platforms and Apps



 *From:* Geo Varghese [mailto:gvargh...@aqorn.com]
 *Sent:* Thursday, June 04, 2015 12:43 PM
 *To:* Abrahams.Noah
 *Cc:* openstack-operators@lists.openstack.org
 *Subject:* Re: [Openstack-operators] Help with multiple external
 network in openstack



 Hi Noah,



 Thanks a lot for valuable inputs.



 I am using vlan tags for 2 external network and it configured on eth1.



 The two interfaces for multiple external networks are eth1.803 and
 eth1.805



 Currently i didn't created br-ex bridge as it is multiple network.





 I have added vlan rages as =>



 network_vlan_ranges = physnet1:100:2999



 bridge_mappings as



 bridge_mappings =





 Can you please explain what are the configurations I have to do to
 implement it.



 Thanks for your time.





 On Fri, Jun 5, 2015 at 12:18 AM, Abrahams.Noah 
 wrote:

 Geo,



 You also need to set the gateway_external_network_id variable to
 empty.  If you don’t, the L3 agent is either using the gateway from the
 network with the specified UUID, or can’t figure out which one to use.



 Also, if the networks have VLAN tags that would be handled by the
 switch, you might need to create that network on an entirely separate
 bridge (for example: br-ex2) and bind it to your physical interface.  After
 you do that, go through all the associations, such as adding the new
 physnet# in your bridge mappings and vlan ranges in your ml2_conf.ini.



 *Noah Abrahams*

 Staff Engineer @ IGT  |  Central Platforms and

Re: [Openstack-operators] Help with multiple external network in openstack

[Miguel A Diaz Corchero]

El 05/06/15 13:07, Geo Varghese escribió:
I tried it but somethig missing still, ping to floating IP seems not 
working
please, try to restart the L3 agent linked with that floating IP and let 
us know


do we have to add any changes to compute node  for it?

it shouldn't be necessary

Miguel.



On Fri, Jun 5, 2015 at 12:16 PM, Geo Varghese > wrote:


Miguel,

Thanks thats a great link. Let me try it.

On Fri, Jun 5, 2015 at 12:04 PM, Miguel A Diaz Corchero
mailto:miguelangel.d...@externos.ciemat.es>> wrote:

Following this link I configured it in my infrastructure.
Maybe this can also help you.


https://www.softwareab.net/wordpress/openstack-adding-external-networks-neutron-gre/

Miguel.

El 04/06/15 23:15, Geo Varghese escribió:

Thanks a lot friend for explaining it. I am also using ubuntu.

let me try it. I will update you with the results.

On Fri, Jun 5, 2015 at 2:20 AM, Abrahams.Noah
mailto:noah.abrah...@igt.com>> wrote:

Hi Geo,

First a disclaimer: I’m working on Ubuntu and Icehouse,
so you might have different behavior, based on your
distributions.  Also, I don’t have all the specifics and
flags you might need, but hopefully this can point you in
the right direction. Also, also, the design below
accounts for some VLAN segregation, and may be more
complicated than what you need.

Since you already have the eth devices created, and
assuming your routing is correct: I would create a new
bridge for each vlan with ovs-vsctl (say, br-ex803 and
br-ex805).  If you look at
http://openvswitch.org/support/dist-docs/ovs-vsctl.8.txt
you can find the syntax for add-br to create the bridge,
then add-port to bind it to the eth device.  You can also
use ovs-vsctl to set the trunks property on the port,
after it’s created, which you’ll need for the vlan
tagging.  Then, create a new physnet to match each one of
those (physnet3, physnet4, etc) and include them in the
bridge-mapping as “physnet3:br-ex803”, or something
similar, and specify the VLANs as belonging to that
particular physnet in the network_vlan_ranges parameter,
like “…physnet3:803,physnet4:805”.

After all that, you’ll need to update the neutron sql
database so the entry in the network segments table will
point to the correct physnet.  Search it by the UUID of
the network you’re creating, and update the
physical_network property to match “physnet3” or whatever
you create.  Then you can create a subnet from that
network, allocate from it, and it should work.  You’ll
also need to restart the openvswitch-agent and the
L3-agent, probably before you create the subnet.

*Noah Abrahams*

Staff Engineer @ IGT  |  Central Platforms and Apps

*From:*Geo Varghese [mailto:gvargh...@aqorn.com
]
*Sent:* Thursday, June 04, 2015 12:43 PM
*To:* Abrahams.Noah
*Cc:* openstack-operators@lists.openstack.org

*Subject:* Re: [Openstack-operators] Help with multiple
external network in openstack

Hi Noah,

Thanks a lot for valuable inputs.

I am using vlan tags for 2 external network and it
configured on eth1.

The two interfaces for multiple external networks are
eth1.803 and eth1.805

Currently i didn't created br-ex bridge as it is multiple
network.

I have added vlan rages as =>

network_vlan_ranges = physnet1:100:2999

bridge_mappings as

bridge_mappings =

Can you please explain what are the configurations I have
to do to implement it.

Thanks for your time.

On Fri, Jun 5, 2015 at 12:18 AM, Abrahams.Noah
mailto:noah.abrah...@igt.com>> wrote:

Geo,

You also need to set the gateway_external_network_id
variable to empty.  If you don’t, the L3 agent is either
using the gateway from the network with the specified
UUID, or can’t figure out which one to use.

Also, if the networks have VLAN tags that would be
handled by the switch, you might need to create that
network on an entirely separate bridge (for example:
br-ex2) and bind it to your physical interface. After you
do that, go through all the associations, such as adding
the new physnet# in your bridge ma

Re: [Openstack-operators] Help with multiple external network in openstack

[Geo Varghese]

I tried it but somethig missing still, ping to floating IP seems not working

do we have to add any changes to compute node  for it?

On Fri, Jun 5, 2015 at 12:16 PM, Geo Varghese  wrote:

> Miguel,
>
> Thanks thats a great link. Let me try it.
>
> On Fri, Jun 5, 2015 at 12:04 PM, Miguel A Diaz Corchero <
> miguelangel.d...@externos.ciemat.es> wrote:
>
>>  Following this link I configured it in my infrastructure. Maybe this
>> can also help you.
>>
>>
>> https://www.softwareab.net/wordpress/openstack-adding-external-networks-neutron-gre/
>>
>> Miguel.
>>
>> El 04/06/15 23:15, Geo Varghese escribió:
>>
>>  Thanks a lot friend for explaining it. I am also using ubuntu.
>>
>>  let me try it. I will update you with the results.
>>
>> On Fri, Jun 5, 2015 at 2:20 AM, Abrahams.Noah 
>> wrote:
>>
>>>  Hi Geo,
>>>
>>>
>>>
>>> First a disclaimer: I’m working on Ubuntu and Icehouse, so you might
>>> have different behavior, based on your distributions.  Also, I don’t have
>>> all the specifics and flags you might need, but hopefully this can point
>>> you in the right direction.  Also, also, the design below accounts for some
>>> VLAN segregation, and may be more complicated than what you need.
>>>
>>>
>>>
>>> Since you already have the eth devices created, and assuming your
>>> routing is correct: I would create a new bridge for each vlan with
>>> ovs-vsctl (say, br-ex803 and br-ex805).  If you look at
>>> http://openvswitch.org/support/dist-docs/ovs-vsctl.8.txt you can find
>>> the syntax for add-br to create the bridge, then add-port to bind it to the
>>> eth device.  You can also use ovs-vsctl to set the trunks property on the
>>> port, after it’s created, which you’ll need for the vlan tagging.  Then,
>>> create a new physnet to match each one of those (physnet3, physnet4, etc)
>>> and include them in the bridge-mapping as “physnet3:br-ex803”, or something
>>> similar, and specify the VLANs as belonging to that particular physnet in
>>> the network_vlan_ranges parameter, like “…physnet3:803,physnet4:805”.
>>>
>>>
>>>
>>> After all that, you’ll need to update the neutron sql database so the
>>> entry in the network segments table will point to the correct physnet.
>>> Search it by the UUID of the network you’re creating, and update the
>>> physical_network property to match “physnet3” or whatever you create.  Then
>>> you can create a subnet from that network, allocate from it, and it should
>>> work.  You’ll also need to restart the openvswitch-agent and the L3-agent,
>>> probably before you create the subnet.
>>>
>>>
>>>
>>> *Noah Abrahams*
>>>
>>> Staff Engineer @ IGT  |  Central Platforms and Apps
>>>
>>>
>>>
>>> *From:* Geo Varghese [mailto:gvargh...@aqorn.com]
>>> *Sent:* Thursday, June 04, 2015 12:43 PM
>>> *To:* Abrahams.Noah
>>> *Cc:* openstack-operators@lists.openstack.org
>>> *Subject:* Re: [Openstack-operators] Help with multiple external
>>> network in openstack
>>>
>>>
>>>
>>> Hi Noah,
>>>
>>>
>>>
>>> Thanks a lot for valuable inputs.
>>>
>>>
>>>
>>> I am using vlan tags for 2 external network and it configured on eth1.
>>>
>>>
>>>
>>> The two interfaces for multiple external networks are eth1.803 and
>>> eth1.805
>>>
>>>
>>>
>>> Currently i didn't created br-ex bridge as it is multiple network.
>>>
>>>
>>>
>>>
>>>
>>> I have added vlan rages as =>
>>>
>>>
>>>
>>> network_vlan_ranges = physnet1:100:2999
>>>
>>>
>>>
>>> bridge_mappings as
>>>
>>>
>>>
>>> bridge_mappings =
>>>
>>>
>>>
>>>
>>>
>>> Can you please explain what are the configurations I have to do to
>>> implement it.
>>>
>>>
>>>
>>> Thanks for your time.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jun 5, 2015 at 12:18 AM, Abrahams.Noah 
>>> wrote:
>>>
>>> Geo,
>>>
>>>
>>>
>>> You also need to set the gateway_external_network_id variable to empty.
>>> If you don’t, the L3 agent is either using the gateway from the network
>>> with the specified UUID, or can’t figure out which one to use.
>>>
>>>
>>>
>>> Also, if the networks have VLAN tags that would be handled by the
>>> switch, you might need to create that network on an entirely separate
>>> bridge (for example: br-ex2) and bind it to your physical interface.  After
>>> you do that, go through all the associations, such as adding the new
>>> physnet# in your bridge mappings and vlan ranges in your ml2_conf.ini.
>>>
>>>
>>>
>>> *Noah Abrahams*
>>>
>>> Staff Engineer @ IGT  |  Central Platforms and Apps
>>>
>>>
>>>
>>> *From:* Geo Varghese [mailto:gvargh...@aqorn.com]
>>> *Sent:* Thursday, June 04, 2015 6:26 AM
>>> *To:* openstack-operators@lists.openstack.org;
>>> openst...@lists.openstack.org
>>> *Subject:* [Openstack-operators] Help with multiple external network in
>>> openstack
>>>
>>>
>>>
>>> Hi Team,
>>>
>>> I need some help to setup multiple external network
>>>
>>>
>>>  In normal single external network we create *br-ex* bridge and add it
>>> in
>>>
>>> /etc/neutron/l3_agent.ini
>>>
>>> As
>>>
>>> external_network_bridge = br-ex
>>>
>>> It is working for me.
>>>
>>> But in the case of multip

Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!

[Thierry Carrez]

Jesus M. Gonzalez-Barahona wrote:
> Given that tags have a clear binary value, and that some people have
> expressed the convenience of having some more information available,
> maybe the tags could be just the result of applying certain conditions
> to a more complex description of a metric or set of metrics.

Right, and that's was I was hinting at in another thread where I said we
could totally define tags on top of Ops-provided more complex data.

I think the key thing to recognize here is that "tags" mean a precise
thing (i.e. just a label), and that the Ops Tag WG is actually
interested in providing a richer data set around specific
operator-impacting areas.

One option is to abandon the idea and converge to using the same
concept. Another option is to rename that rich data ("project
operational metadata" ?) to avoid the confusion of calling with same
name what is essentially two different things. That will open the door
to defining "tags" on top of it.

And if the ops WG is only interested in publishing the complex metadata,
I guess a workgroup around the TC could take up the work of turning that
data into a set of tags.

-- 
Thierry Carrez (ttx)

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