[Openstack-operators] neutron-server high cpu usage

[David Riedl]

Hello Everyone,

I just upgraded my Openstack Installation from Liberty to Mitaka. It is 
a pretty small cluster with only 3 nodes.


Since the upgrade, the neutron-server on my control node produces a very 
high cpu load. Unfortunately the log files throw no errors and google 
does not give me any answers either, so I am a bit lost.


This is my neutron.conf
http://pastebin.com/cQbgeP4H
Please tell me if you need any log files or config files.


Regards and thanks for any help

David


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

Re: [Openstack-operators] neutron-server high cpu usage

[Kevin Benton]

Does it calm down if you stop the agents? If so, check the agent logs for
exceptions because one may be stuck in a sync loop because it's
encountering an error.

If you still don't see anything, try reducing the report interval for the
agents (and increase agent_down_time on the server accordingly) and see if
that helps.


On Feb 10, 2017 03:15, "David Riedl"  wrote:

Hello Everyone,

I just upgraded my Openstack Installation from Liberty to Mitaka. It is a
pretty small cluster with only 3 nodes.

Since the upgrade, the neutron-server on my control node produces a very
high cpu load. Unfortunately the log files throw no errors and google does
not give me any answers either, so I am a bit lost.

This is my neutron.conf
http://pastebin.com/cQbgeP4H
Please tell me if you need any log files or config files.


Regards and thanks for any help

David


___
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] [openstack-dev] [nova] Next minimum libvirt version

[Kashyap Chamarthy]

On Thu, Feb 09, 2017 at 05:29:22PM -0600, Matt Riedemann wrote:
> Since danpb hasn't been around I've sort of forgotten about this, but we
> should talk about bumping the minimum required libvirt version in nova.
> 
> Currently it's 1.2.1 and the next was set to 1.2.9.
> 
> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04 had
> 1.2.2).
> 
> If we move to require 1.2.9 that effectively kills 14.04 support for
> devstack + libvirt on master, which is probably OK.
> 
> There is also the distro support wiki [1] which hasn't been updated in
> awhile.
> 
> I'm wondering if 1.2.9 is a safe move for the next required minimum version
> and if so, does anyone have ideas on the next required version after that?

1.2.9 was release on OCT 2014.

And there have been 26 releases from 1.2.9 until now:

1.2.{10,11,12,13,14,15,16,17,18,19,20,21}
1.3.{0,1,2,3,4,5}
2.0.0 [01 JUL 2016]
2.1.0 [02 AUG 2016]
2.2.0 [02 SEP 2016]
2.3.0 [04 OCT 2016]
2.4.0 [01 NOV 2016]
2.5.0 [04 DEC 2016]
3.0.0 [17 JAN 2017]
3.1.0 [Unreleased, as of 10-FEB-2017]

IIUC, going by how[X] Dan settled on 1.1.1, as minimum version for
Newton, it seems like have to mine through the current releases,
that'll: 

  - provide unconditional support for specific features we need; 
  - removes need for maintaining backward compatibility code

[X] 
http://lists.openstack.org/pipermail/openstack-operators/2015-October/008400.html

---

Good news for future: Upstream libvirt recently started an effort to
make release notes more consumable, by writing more 'structured' release
notes, and categorizing the work into: new Features; improvements; and
bug fixes.

You can see the result by comparing this page:

http://libvirt.org/news.html

With the older releases (where it's mostly information from Git
commits):

http://libvirt.org/news-2016.html

[...]

-- 
/kashyap

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

Re: [Openstack-operators] OpenStack-operators Digest, Vol 76, Issue 11

[Y.Rahulan]

g
> > to overcome, bit by bit.
> >
>
> I would also have a request - if these tools are going to be used
> can we make them world readable, with no requirement to log in to
> view content?
>
>
>
>
> --
>
> Message: 5
> Date: Thu, 9 Feb 2017 14:21:52 -0700
> From: David Medberry 
> To: Matt Riedemann 
> Cc: "openstack-operators@lists.openstack.org"
> 
> Subject: Re: [Openstack-operators] [nova] FYI:
> live_migration_progress_timeout will default to 0 and be
> deprecated in
> Ocata
> Message-ID:
>  mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Feb 9, 2017 at 9:29 AM, Matt Riedemann 
> wrote:
>
> >
> Thanks for the heads up Matt, ops appreciate.
> -- next part --
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-operators/
> attachments/20170209/626608ad/attachment-0001.html>
>
> --
>
> Message: 6
> Date: Thu, 9 Feb 2017 17:29:22 -0600
> From: Matt Riedemann 
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> "openstack-operators@lists.openstack.org"
> 
> Subject: [Openstack-operators] [nova] Next minimum libvirt version
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Since danpb hasn't been around I've sort of forgotten about this, but we
> should talk about bumping the minimum required libvirt version in nova.
>
> Currently it's 1.2.1 and the next was set to 1.2.9.
>
> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04
> had 1.2.2).
>
> If we move to require 1.2.9 that effectively kills 14.04 support for
> devstack + libvirt on master, which is probably OK.
>
> There is also the distro support wiki [1] which hasn't been updated in
> awhile.
>
> I'm wondering if 1.2.9 is a safe move for the next required minimum
> version and if so, does anyone have ideas on the next required version
> after that?
>
> I'm hoping some of the Red Hat people can chime in here.
>
> [1] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> --
>
> Message: 7
> Date: Thu, 9 Feb 2017 18:51:42 -0500 (EST)
> From: Steve Gordon 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Cc: Vladik Romanovsky , Sahid Orentino Ferdjaoui
> , openstack-operators@lists.
> openstack.org
> Subject: Re: [Openstack-operators] [openstack-dev] [nova] Next minimum
> libvirt version
> Message-ID:
> <786189857.103656865.1486684302672.javamail.zim...@redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> - Original Message -
> > From: "Matt Riedemann" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-...@lists.openstack.org>,
> > openstack-operators@lists.openstack.org
> > Sent: Thursday, February 9, 2017 6:29:22 PM
> > Subject: [openstack-dev] [nova] Next minimum libvirt version
> >
> > Since danpb hasn't been around I've sort of forgotten about this, but we
> > should talk about bumping the minimum required libvirt version in nova.
> >
> > Currently it's 1.2.1 and the next was set to 1.2.9.
> >
> > On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04
> > had 1.2.2).
> >
> > If we move to require 1.2.9 that effectively kills 14.04 support for
> > devstack + libvirt on master, which is probably OK.
>
> This would also kill off RHEL/CentOS 7.1 support but that would also seem
> to be OK at this point.
>
> > There is also the distro support wiki [1] which hasn't been updated in
> > awhile.
>
> I've added the details I have for Fedora 25 and RHEL/CentOS 7.3, TL;DR:
>
> Fedora 25:
> Libvirt 2.2.0
> Qemu 2.7.1
> Libguestfs 1.34.3
>
> RHEL 7.3:
> Libvirt 2.0.0
> Qemu 2.6.0
> Libguestfs 1.32.7
>
>
> > I'm wondering if 1.2.9 is a safe move for the next required minimum
> > version and if so, does anyone have ideas on the next required version
> > after that?
> >
> > I'm hoping some of the Red Hat people can chime in here.
>
> I just play someone intelligent on TV so adding Sahid and Vladik who might
> be better placed to comment in Dan's absence.
>
> Thanks,
>
> Steve
>
> --
> Steve Gordon,
> Principal Product Manager,
> Red

Re: [Openstack-operators] OpenStack-operators Digest, Vol 76, Issue 11

[Curtis]

pment there).
>> >
>> >> Automating the status updating is something I've begun to discuss
>> >> within the PWG's "Story Tracker" team. We have the same challenge
>> >> there.
>> > [...]
>> >
>> > Our hope is that once we get further along with the current
>> > migration blockers for StoryBoard, we'll implement an "epics"
>> > concept in it which ties individual stories and their tasksets to
>> > over-arching efforts where their progress can be tracked more
>> > holistically.
>> >
>> >> BTW, Atlassian has always made their tools free for use by open
>> >> source projects. Also, although they're commercial products they
>> >> do provide the source code and allow users to modify it freely
>> >> which makes them much more open-source-ish than most.
>> > [...]
>> >
>> > 
>> > Yes, I saw you mention it in the other ML thread. "Free as in beer"
>> > is a somewhat dirty concept in free software development circles,
>> > and our community infrastructure similarly eschews gratis services
>> > like GitHub in favor of libre alternatives (we provide read-only
>> > mirrors there on request, but don't rely on it in any of our
>> > automation and officially recommend git.openstack.org which runs
>> > entirely on free software).
>> >
>> > As an author of free software myself I prefer when people use and
>> > help improve OpenStack rather than supporting commercial/proprietary
>> > solutions to accomplish the same tasks, and so think it hypocritical
>> > to not extend the same courtesy to other free software communities
>> > who are attempting to overcome similar hurdles in their respective
>> > problem spaces. To quote Harry Tuttle, "We're all in it together."
>> > 
>> >
>> > I understand you'll probably end up using whatever tools you're
>> > familiar/comfortable with and which help you accomplish your goals,
>> > I just ask that you keep in mind that publicly recommending non-free
>> > tools in the service of free software development sets an example.
>> > OpenStack already has a slightly negative reputation as "not really
>> > free" in the wider community... one which we're desperately trying
>> > to overcome, bit by bit.
>> >
>>
>> I would also have a request - if these tools are going to be used
>> can we make them world readable, with no requirement to log in to
>> view content?
>>
>>
>>
>>
>> --
>>
>> Message: 5
>> Date: Thu, 9 Feb 2017 14:21:52 -0700
>> From: David Medberry 
>> To: Matt Riedemann 
>> Cc: "openstack-operators@lists.openstack.org"
>> 
>> Subject: Re: [Openstack-operators] [nova] FYI:
>> live_migration_progress_timeout will default to 0 and be
>> deprecated in
>> Ocata
>> Message-ID:
>>
>> 
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Thu, Feb 9, 2017 at 9:29 AM, Matt Riedemann 
>> wrote:
>>
>> >
>> Thanks for the heads up Matt, ops appreciate.
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170209/626608ad/attachment-0001.html>
>>
>> --
>>
>> Message: 6
>> Date: Thu, 9 Feb 2017 17:29:22 -0600
>> From: Matt Riedemann 
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> ,
>> "openstack-operators@lists.openstack.org"
>> 
>> Subject: [Openstack-operators] [nova] Next minimum libvirt version
>> Message-ID: 
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Since danpb hasn't been around I've sort of forgotten about this, but we
>> should talk about bumping the minimum required libvirt version in nova.
>>
>> Currently it's 1.2.1 and the next was set to 1.2.9.
>>
>> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04
>> had 1.2.2).
>>
>> If we move to require 1.2.9 that effectively kills 14.04 support for
>> devstack + libvirt on master, which is probably OK.
>>
>> There is also the distro support wiki [1] which hasn't been updated in
>> awhile.
>>
>> I'm wondering if 1.2.9 is a safe 

Re: [Openstack-operators] neutron-server high cpu usage

[David Riedl]

Thanks for pointing me in the right direction.

Turns out Mitaka doesn't really like it when there is an ip address on 
the linuxbridge interface and the neutron-linuxbridge-agent goes 
absolutely bonkers as a result. (It worked like this for 3 releases though)


Regards

David


Am 10.02.2017 um 11:21 schrieb Kevin Benton:
Does it calm down if you stop the agents? If so, check the agent logs 
for exceptions because one may be stuck in a sync loop because it's 
encountering an error.


If you still don't see anything, try reducing the report interval for 
the agents (and increase agent_down_time on the server accordingly) 
and see if that helps.



On Feb 10, 2017 03:15, "David Riedl" > wrote:


Hello Everyone,

I just upgraded my Openstack Installation from Liberty to Mitaka.
It is a pretty small cluster with only 3 nodes.

Since the upgrade, the neutron-server on my control node produces
a very high cpu load. Unfortunately the log files throw no errors
and google does not give me any answers either, so I am a bit lost.

This is my neutron.conf
http://pastebin.com/cQbgeP4H
Please tell me if you need any log files or config files.


Regards and thanks for any help

David


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





--
David Riedl

IT Systemadministrator
Staatl. gepr. Techniker (IT)
Tel. +49 7543 966-126

Sitz der Gesellschaft: Langenargen
Registergericht: ULM, HRB 734260
USt-Id.: DE232931635, WEEE-Id.: DE74015979
Vorstand: Thomas Ehrle (Vorsitz), Fritz R. Paul, Tobias Treß
Aufsichtsratvorsitzender: Jürgen Maucher

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

[Openstack-operators] help: Multiple external networks with a single L3 agent

[Gaurav Goyal]

Hi,

I need your help to configure multiple external networks in openstack
environment.

I am using Liberty openstack.  openvswitch with gre tunneling.
I want to create multiple external networks so that all interfaces of my VM
can be accessible to outside world.
I need your help to config neutron for multiple external networks.

should i do following changes   in my existing configuration?

flat_networks = *
bridge_mappings = external:br-ex,external1:br-ex1
ovs-vsctl add-br br-ex1
ovs-vsctl add-port br-ex *p5p3*

is it going to impact all existing VMs running in openstack environment?

   -
  -

  Edit the /etc/neutron/plugins/ml2/ml2_conf.ini file and complete the
  following actions:
  1.



 1
 2
 3
 4
 5
 [ml2]
 ...
 type_drivers = flat,vlan,gre,vxlan
 tenant_network_types = gre
 mechanism_drivers = openvswitch
 2.

 In the [ml2_type_flat]


 1
 2
 3
 [ml2_type_flat]
 ...
 flat_networks = external
 3.

 In the [ml2_type_gre] section,


 1
 2
 3
 [ml2_type_gre]
 ...
 tunnel_id_ranges = 1:1000

 -  /etc/neutron/plugins/ml2/openvswitch_agent.ini

  [root@OSKVM1 ml2]# grep -v ^# openvswitch_agent.ini|grep -v ^$

  [ovs]
  local_ip = 10.24.0.4
  bridge_mappings = external:br-ex
  [agent]
  tunnel_types = gre


   -

   *To configure the Layer-3 (L3) agent*

   The Layer-3 (L3) agent
   

provides
   routing services for virtual networks.
   -

   /etc/neutron/l3_agent.ini file
  1.

 In the [DEFAULT] section,


 1
 2
 3
 4
 5
 [DEFAULT]
 ...
 interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
 external_network_bridge =
 router_delete_namespaces = True



 Note

 The external_network_bridge option intentionally lacks a value to
 enable multiple external networks on a single agent.

*To configure the DHCP agent*

The DHCP agent

provides
DHCP services for virtual networks.

   1.

/etc/neutron/dhcp_agent.ini file
   1.

  In the [DEFAULT] section,


  1
  2
  3
  4
  5
  [DEFAULT]
  ...
  interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
  dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
  dhcp_delete_namespaces = True


   1.

/etc/neutron/dhcp_agent.ini file
   1.

  In the [DEFAULT] section,


  1
  2
  3
  [DEFAULT]
  ...
  dnsmasq_config_file = /etc/neutron/dnsmasq-neutron.conf
  2.

   Created  /etc/neutron/dnsmasq-neutron.conf file and complete the
   following action:
   1.

  Enable the DHCP MTU option (26) and configure it to 1454 bytes:


  1
  dhcp-option-force=26,1454

*To configure the metadata agent*

The metadata agent

provides
configuration information such as credentials to instances.

   1.

/etc/neutron/metadata_agent.ini file
   1.

  In the [DEFAULT] section,


  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  [DEFAULT]
  ...
  auth_uri = http://controller:5000
  auth_url = http://controller:35357
  auth_region = RegionOne
  auth_plugin = password
  project_domain_id = default
  user_domain_id = default
  project_name = service
  username = neutron
  password = NEUTRON_PASS


  In the [DEFAULT] section, configure the metadata host:
  2.


  1
  2
  3
  [DEFAULT]
  ...
  nova_metadata_ip = controller
  3.


  4.

  In the [DEFAULT] section, configure the metadata proxy shared secret:


  1
  2
  3
  [DEFAULT]
  ...
  metadata_proxy_shared_secret = METADATA_SECRET





   1.

   Add the external bridge:
   2.

   # ovs-vsctl add-br br-ex
   3.

   Add a port to the external bridge that connects to the physical external
   network interface:

   Replace *INTERFACE_NAME* with the actual interface name. For example,
   *eth2* or *ens256*.

   # ovs-vsctl add-port br-ex *p5p2*



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

Re: [Openstack-operators] [nova] Next minimum libvirt version

[Daniel P. Berrange]

On Thu, Feb 09, 2017 at 05:29:22PM -0600, Matt Riedemann wrote:
> Since danpb hasn't been around I've sort of forgotten about this, but we
> should talk about bumping the minimum required libvirt version in nova.
> 
> Currently it's 1.2.1 and the next was set to 1.2.9.
> 
> On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04 had
> 1.2.2).
> 
> If we move to require 1.2.9 that effectively kills 14.04 support for
> devstack + libvirt on master, which is probably OK.
> 
> There is also the distro support wiki [1] which hasn't been updated in
> awhile.
> 
> I'm wondering if 1.2.9 is a safe move for the next required minimum version
> and if so, does anyone have ideas on the next required version after that?

I think libvirt 1.2.9 is absolutely fine as a next version. It is still
ancient history comparatively speaking.

The more difficult question is what happens after that. To go further than
that effectively requires dropping Debian as a supportable platform since
AFAIK, they never rebase libvirt & next Debian major release is still
unannounced.  So the question is whether "stock" Debian is something the
project cares about targetting or will the answer be that Debian users
are required to pull in newer libvirt from elsewhere.

Also, it is just as important to consider minimum QEMU versions at the
same time, though it could just be set to the lowest common denominator
across distros that remain, after choosing the libvirt version.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|

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

Re: [Openstack-operators] [Fault Genes] WG Weekly Meeting Summary

[Nematollah Bidokhti]

Hi All,

Following is our meeting summary:

*   Zainab presented her work on creating the dictionary.
*   Suli talked about his plan and development of Fault Genes web based 
database
*   Isaac discussed the logging research that he is doing.
*   The goal is for him to take more leadership in running the Logging WG.
*   There is a meeting with OSIC team regarding further collaboration on 
machine learning and Web based database.
*   Mike Turvey has been providing information and guidance on his 
development of the FI orchestration.
*   Since Nemat will be on China business trip, Isaac will run the meeting 
for the next two weeks.

Thanks,
Nemat


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

[Openstack-operators] Ceilometer and cpu_util meter

[Jonathan Abdiel Gonzalez Valdebenito]

Hi All!!

We run a public cloud and doing the proper tests to release heat but we hit
that the meter cpu_util which it's the one that appears in almost all heat
templates sample, it's taking about 10 minutes between samples which as my
friend Sergio says unacceptable[1].

Question, does anyone knows if this it's the expected behavior or there's a
way to speed up this meter?

Best Regards,
[1]
http://lists.openstack.org/pipermail/openstack-operators/2017-February/012610.html
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [LCOO] Intro to Large Contributing

[UKASICK, ANDREW]

>
>Date: Thu, 9 Feb 2017 16:29:52 +
>From: Jeremy Stanley 
>To: openstack-operators@lists.openstack.org,
>   user-commit...@lists.openstack.org
>Subject: Re: [Openstack-operators] [LCOO] Intro to Large Contributing
>Message-ID: <20170209162952.gq12...@yuggoth.org>
>Content-Type: text/plain; charset="us-ascii"
>
>On 2017-02-09 00:59:52 + (+), UKASICK, ANDREW wrote:
>[...]
>> I'm the mysterious "AndyU" who was chatting with you about a year ago 
>> in IRC with questions about how to go about donating hosted cloud 
>> resources for use by the Infra team. It's nice to bump into you again! 
>> ;-) That idea is still stirring btw, but has been much slower moving 
>> than I'd hoped.
>[...]
>
>Always appreciated, and happy to pick that back up if and when you're ready.

I've moved into a different role and I'm no longer driving that effort, but 
it's still alive and we'll be sure and reach out if/when it gets more traction!

>> I've been having a pretty lengthy conversation with jay Pipes 
>> regarding similar questions. You can catch up on that in the thread 
>> below this one.
>
>I've been following it closely, and tried not to duplicate questions/comments 
>as much as possible.
>
>> LCOO is unlike any other working groups that I'm familiar with in some 
>> significant ways. You zero'd in on one of those in your statements 
>> above about companies joining as opposed to individuals. In that 
>> regard, LCOO is similar to an entity like OSIC.org as opposed to a 
>> traditional working group.
>[...]
>
>This is probably where some of the confusion comes in for me; I expect it's 
>just one of terminology/semantics. The OpenStack User Committee has 
>specifically tied "Active members and contributors to functional teams and/or 
>working groups" to its electorate in their charter, and also defines working 
>groups as "teams" (which to me implies they're made up of individuals, not 
>organizations):

Agreed. You put your finger on another one of those things we're still figuring 
out.  I can tell you this much, the active members are individuals who have 
been consistently participating. Maybe a better way to think of it is as people 
who have a kind of dual role. They are members as individuals, but at the same 
time they're also representing the company they work for.  We've never 
discussed some of the nuances that you raise. They're good points. For example, 
if someone is elected as a chair and then changes companies would they be 
expected to step down as chair?  My opinion would be that no they would not be. 
 The individual earned that role just like in any other community team.  But 
that's just my opinion... I think that others would agree. If it ever comes up 
we'll have to decide!  But by my saying that, it would also imply that there 
may be people who are LCOO members who do not work for a "member company".  
That sounds reasonable to me, but again... it's something that just h
 asn't come up yet.  We haven't discussed anything like that in any depth 
because we haven't had to yet. I know that there are concerns about the group 
remaining User focused, being representative of large Users and also 
representing actual contributors.  People wanted to avoid a situation where 
there might be lots of requests or even complaints being raised without any 
commitment to share in the work of actually fixing and delivering on them. 

>
>https://governance.openstack.org/uc/reference/charter.html
>
>Maybe LCOO is something other than a "working group" in the formal UC sense? 
>Or maybe the organizations who participate in the LCOO designate 
>representatives (those LCOO "organization coordinators"
>and "governance board" mentioned in your wiki article) who are the actual 
>working group as far as the UC is concerned? 

Yes, I'd say that is how we've been functioning.  The "Coordinators" are the 
core regular attendees who also have a role as representing their company 
within LCOO.  When we finally get rocking and rolling on trying to help drive 
some significant enhancements of some kind, the "Coordinator" part would mean 
serving as a coordination point with respect to other architects, developers, 
etc., that their own company may be contributing to the effort.  And then 
collectively, all of the "Coordinators" would be collaborating to help in 
jointly  coordinating any activity we (LCOO) may have across the life cycle.  
As far as a "Governance Board" goes, that was an idea we had and put in the 
Charter, but that was before we actually tried out this experiment. We've never 
been anything but the "Coordinators" that I mentioned so far. There has been no 
need for a "Board". But maybe if LCOO became big enough and active enough, then 
there would be a need. I guess we'll find out if that ever happens.

> I'm just concerned if, for example, all employees within AT&T suddenly become 
> part of the UC electorate by way of AT&T as an organization being an active 
> "member" of an official UC work

Re: [Openstack-operators] help: Multiple external networks with a single L3 agent

[Dan Sneddon]

On 02/10/2017 08:39 AM, Gaurav Goyal wrote:
> Hi,
> 
> I need your help to configure multiple external networks in openstack
> environment.
> 
> I am using Liberty openstack.  openvswitch with gre tunneling. 
> I want to create multiple external networks so that all interfaces of my
> VM can be accessible to outside world.
> I need your help to config neutron for multiple external networks.
> 
> should i do following changes   in my existing configuration?
> 
> flat_networks = *
> bridge_mappings = external:br-ex,external1:br-ex1
> ovs-vsctl add-br br-ex1
> ovs-vsctl add-port br-ex /p5p3/
> 
> is it going to impact all existing VMs running in openstack environment?
> 
>   *
>   o
> 
> Edit the |/etc/neutron/plugins/ml2/ml2_conf.ini| file and
> complete the following actions:
> 
>  1.
> 
> 
> 
> 1
> 2
> 3
> 4
> 5
>   
> |[ml2]|
> |...|
> |type_drivers = flat,vlan,gre,vxlan|
> |tenant_network_types = gre|
> |mechanism_drivers = openvswitch|
> 
>  2.
> 
> In the |[ml2_type_flat]| 
> 
> 
> 1
> 2
> 3
>   
> |[ml2_type_flat]|
> |...|
> |flat_networks = external|
> 
>  3.
> 
> In the |[ml2_type_gre]| section, 
> 
> 
> 1
> 2
> 3
>   
> |[ml2_type_gre]|
> |...|
> |tunnel_id_ranges = 1:1000|
> 
> 
>   o  |/etc/neutron/plugins/ml2/openvswitch_agent.ini|
> 
> [root@OSKVM1 ml2]# grep -v ^# openvswitch_agent.ini|grep -v ^$
> 
> [ovs]
> local_ip = 10.24.0.4
> bridge_mappings = external:br-ex
> [agent]
> tunnel_types = gre
> 
>   *
> 
> *To configure the Layer-3 (L3) agent*
> 
> The Layer-3 (L3) agent
> 
> 
>  provides
> routing services for virtual networks.
> 
>   o
> 
>  |/etc/neutron/l3_agent.ini| file 
> 
>  1.
> 
> In the |[DEFAULT]| section, 
> 
> 
> 1
> 2
> 3
> 4
> 5
>   
> |[DEFAULT]|
> |...|
> |interface_driver =
> neutron.agent.linux.interface.OVSInterfaceDriver|
> |external_network_bridge =|
> |router_delete_namespaces = True|
> 
> 
> 
>   Note
> 
> The |external_network_bridge| option intentionally lacks a
> value to enable multiple external networks on a single agent.
> 
> *To configure the DHCP agent*
> 
> The DHCP agent
> 
>  provides
> DHCP services for virtual networks.
> 
>  1.
> 
>  |/etc/neutron/dhcp_agent.ini| file
> 
>  1.
> 
> In the |[DEFAULT]| section, 
> 
> 
> 1
> 2
> 3
> 4
> 5
>   
> |[DEFAULT]|
> |...|
> |interface_driver =
> neutron.agent.linux.interface.OVSInterfaceDriver|
> |dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq|
> |dhcp_delete_namespaces = True|
> 
>  1.
> 
>  |/etc/neutron/dhcp_agent.ini| file 
> 
>  1.
> 
> In the |[DEFAULT]| section,
> 
> 
> 1
> 2
> 3
>   
> |[DEFAULT]|
> |...|
> |dnsmasq_config_file = ||/etc/neutron/dnsmasq-neutron||.conf|
> 
>  2.
> 
> Created  |/etc/neutron/dnsmasq-neutron.conf| file and complete the
> following action:
> 
>  1.
> 
> Enable the DHCP MTU option (26) and configure it to 1454 bytes:
> 
> 
> 1
>   
> |dhcp-option-force=26,1454|
> 
> *To configure the metadata agent*
> 
> The metadata agent
> 
>  provides
> configuration information such as credentials to instances.
> 
>  1.
> 
>  |/etc/neutron/metadata_agent.ini| file 
> 
>  1.
> 
> In the |[DEFAULT]| section, 
> 
> 
> 1
> 2
> 3
> 4
> 5
> 6
> 7
> 8
> 9
> 10
> 11
>   
> |[DEFAULT]|
> |...|
> |auth_uri = http:||//||controller:5000|
> |auth_url = http:||//||controller:35357|
> |auth_region = RegionOne|
> |auth_plugin = password|
> |project_domain_id = default|
> |user_domain_id = default|
> |project_name = service|
> |username = neutron|
> |password = NEUTRON_PASS|
> 
> 
> In the |[DEFAULT]| section, configure the metadata host:
> 
>  2.
> 
> 
> 1
> 2
> 3
>   
> |[DEFAULT]|
> |...|
> |n

Re: [Openstack-operators] [nova] Next minimum libvirt version

[gustavo panizzo]

On Fri, Feb 10, 2017 at 05:42:26PM +, Daniel P. Berrange wrote:
> On Thu, Feb 09, 2017 at 05:29:22PM -0600, Matt Riedemann wrote:
> > Since danpb hasn't been around I've sort of forgotten about this, but we
> > should talk about bumping the minimum required libvirt version in nova.
> > 
> > Currently it's 1.2.1 and the next was set to 1.2.9.
> > 
> > On master we're gating on ubuntu 14.04 which has libvirt 1.3.1 (14.04 had
> > 1.2.2).
> > 
> > If we move to require 1.2.9 that effectively kills 14.04 support for
> > devstack + libvirt on master, which is probably OK.
> > 
> > There is also the distro support wiki [1] which hasn't been updated in
> > awhile.
> > 
> > I'm wondering if 1.2.9 is a safe move for the next required minimum version
> > and if so, does anyone have ideas on the next required version after that?
> 
> I think libvirt 1.2.9 is absolutely fine as a next version. It is still
> ancient history comparatively speaking.
> 
> The more difficult question is what happens after that. To go further than
> that effectively requires dropping Debian as a supportable platform since
> AFAIK, they never rebase libvirt & next Debian major release is still
> unannounced.  So the question is whether "stock" Debian is something the
> project cares about targetting or will the answer be that Debian users
> are required to pull in newer libvirt from elsewhere.
Debian 9.0 has been frozen, soon it will be released with libvirt 3.0.0
Previous release has 1.2.9 

https://packages.debian.org/search?keywords=libvirt0&searchon=names&suite=all§ion=all

> Also, it is just as important to consider minimum QEMU versions at the
> same time, though it could just be set to the lowest common denominator
> across distros that remain, after choosing the libvirt version.

Qemu version for the next release is 2.8, previous release is 2.1

https://packages.debian.org/search?keywords=qemu&searchon=names&suite=all§ion=all

> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org  -o- http://virt-manager.org :|
> |: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

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

[Openstack-operators] User Committee Election

[Matt Van Winkle]

Greetings!

The time for our very first User Committee election is almost upon us.  In case 
you are unaware, there were recent changes – approved by the Board of Directors 
– that allowed for the expansion of the UC from 3 to 5 members and a move to 
elected positions.  Monday morning UTC, February 13th, notifications will go 
out to all community members with the AUC designation.  The poll will stay open 
till 23:59 UTC on Friday, February 17th.

This election, members will be voting on two additional seats for the UC.  We 
have a pool of five vetted candidates:

Yih Leong Sun
Maish Saidel-Keesing
Christopher Adeo
Shamail Tahir
Melvin Hillsman

We encourage all AUC members to participate in order to maintain a strong and 
active UC.  Many thanks to the current Committee and many other community 
members who have worked very hard over the last couple of years to implement 
the AUC process, develop the new structure and obtain all the necessary 
approval and by-laws changes to make it a reality.  For information on the new 
UC approach, the details of the AUC designation or any other questions around 
this area of OpenStack governance, you may refer to the charter online [1]

If you have any other election related questions, you may reach out directly to 
the election inspectors – Matt Van Winkle 
(v...@rackspace.com) or Matt Jarvis 
(m...@mattjarvis.org.uk) with any questions.

Thank you all, and happy voting!
Matt and Matt

[1] https://governance.openstack.org/uc/reference/charter.html



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

Re: [Openstack-operators] [User-committee] User Committee Election

[Matt Van Winkle]

Correction of one small typo

From: Matt Van Winkle 
Date: Friday, February 10, 2017 at 10:11 PM

Greetings!

The time for our very first User Committee election is almost upon us.  In case 
you are unaware, there were recent changes – approved by the Board of Directors 
– that allowed for the expansion of the UC from 3 to 5 members and a move to 
elected positions.  Monday morning UTC, February 13th, notifications will go 
out to all community members with the AUC designation.  The poll will stay open 
till 23:59 UTC on Friday, February 17th.

This election, members will be voting on two additional seats for the UC.  We 
have a pool of five vetted candidates:

Yih Leong Sun
Maish Saidel-Keesing
Christopher Aedo
Shamail Tahir
Melvin Hillsman

We encourage all AUC members to participate in order to maintain a strong and 
active UC.  Many thanks to the current Committee and many other community 
members who have worked very hard over the last couple of years to implement 
the AUC process, develop the new structure and obtain all the necessary 
approval and by-laws changes to make it a reality.  For information on the new 
UC approach, the details of the AUC designation or any other questions around 
this area of OpenStack governance, you may refer to the charter online [1]

If you have any other election related questions, you may reach out directly to 
the election inspectors – Matt Van Winkle 
(v...@rackspace.com) or Matt Jarvis 
(m...@mattjarvis.org.uk) with any questions.

Thank you all, and happy voting!
Matt and Matt

[1] https://governance.openstack.org/uc/reference/charter.html



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