date:20161213

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

2016-12-13 Thread George Zhao


yup, I have to use cpu_mode=host-passthrough to get vms booting up.



On 12/14/2016 12:13 PM, David Moreau Simard wrote:

Hi,

CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
was shipped as part of this release if you have the CentOS
Virtualization SIG repositories enabled.

If you're using RDO >= Newton, you will have this repository enabled.
It was not yet enforced in the Mitaka release so you might or might
not have it, depending on your deployment.
Older releases of OpenStack may also be affected but they are not
proactively tested anymore due to EOL.

There is currently a known issue when using the following
configuration in nova for compute:
==
virt_type=qemu
cpu_mode=host-model
==

This combination will yield in failed attempts at creating instances
and you will see errors like these in nova-compute.log [1] or the
libvirt logs [2].
The problem boils down to libvirt trying to pass a cpu extension that
is unknown to qemu:
==
qemu-kvm: CPU feature arat not found
==

There is a bugzilla [3] for this issue but in the meantime users are
encouraged to work around the issue by setting "cpu_mode=none" if they
are using the qemu (not KVM) hypervisor.
Please note that Nova defaults the 'cpu_mode' parameter to
'host-model' [4] if 'cpu_mode' is not explicitely configured and
'virt_type' is 'qemu' so if you're running into this issue, you will
need to explicitely configure it.

[1]: 
http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
[2]: 
http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
[4]: 
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

___
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] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

2016-12-13 Thread David Moreau Simard

Hi,

CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
was shipped as part of this release if you have the CentOS
Virtualization SIG repositories enabled.

If you're using RDO >= Newton, you will have this repository enabled.
It was not yet enforced in the Mitaka release so you might or might
not have it, depending on your deployment.
Older releases of OpenStack may also be affected but they are not
proactively tested anymore due to EOL.

There is currently a known issue when using the following
configuration in nova for compute:
==
virt_type=qemu
cpu_mode=host-model
==

This combination will yield in failed attempts at creating instances
and you will see errors like these in nova-compute.log [1] or the
libvirt logs [2].
The problem boils down to libvirt trying to pass a cpu extension that
is unknown to qemu:
==
qemu-kvm: CPU feature arat not found
==

There is a bugzilla [3] for this issue but in the meantime users are
encouraged to work around the issue by setting "cpu_mode=none" if they
are using the qemu (not KVM) hypervisor.
Please note that Nova defaults the 'cpu_mode' parameter to
'host-model' [4] if 'cpu_mode' is not explicitely configured and
'virt_type' is 'qemu' so if you're running into this issue, you will
need to explicitely configure it.

[1]: 
http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
[2]: 
http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
[4]: 
http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

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

[Openstack-operators] [telecom-nfv] Meeting #15

2016-12-13 Thread Curtis

Hi,

We'll be having our bi-weekly meeting Wed at 15:00 UTC in meeting room
#openstack-meeting-4.

Hope to see you there. :)

Thanks,
Curtis.

PS. We will cancel the Dec 27th meeting due to the holidays (not
tomorrow but the 27th) and reconvene in the second week of January.

-- 
Blog: serverascode.com

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

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

2016-12-13 Thread Steve Gordon

- Original Message -
> From: "George Zhao" 
> To: openstack-operators@lists.openstack.org
> Sent: Tuesday, December 13, 2016 7:44:02 PM
> Subject: Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and 
> qemu-kvm(-ev) 2.6.0
> 
> yup, I have to use cpu_mode=host-passthrough to get vms booting up.

Are you using virt_type="qemu" or virt_type="kvm"? If the later you should be 
OK to switch back to host-model once the qemu-kvm-ev-2.6.0 build is available.

Thanks,

Steve

> On 12/14/2016 12:13 PM, David Moreau Simard wrote:
> > Hi,
> >
> > CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> > was shipped as part of this release if you have the CentOS
> > Virtualization SIG repositories enabled.
> >
> > If you're using RDO >= Newton, you will have this repository enabled.
> > It was not yet enforced in the Mitaka release so you might or might
> > not have it, depending on your deployment.
> > Older releases of OpenStack may also be affected but they are not
> > proactively tested anymore due to EOL.
> >
> > There is currently a known issue when using the following
> > configuration in nova for compute:
> > ==
> > virt_type=qemu
> > cpu_mode=host-model
> > ==
> >
> > This combination will yield in failed attempts at creating instances
> > and you will see errors like these in nova-compute.log [1] or the
> > libvirt logs [2].
> > The problem boils down to libvirt trying to pass a cpu extension that
> > is unknown to qemu:
> > ==
> > qemu-kvm: CPU feature arat not found
> > ==
> >
> > There is a bugzilla [3] for this issue but in the meantime users are
> > encouraged to work around the issue by setting "cpu_mode=none" if they
> > are using the qemu (not KVM) hypervisor.
> > Please note that Nova defaults the 'cpu_mode' parameter to
> > 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> > 'virt_type' is 'qemu' so if you're running into this issue, you will
> > need to explicitely configure it.
> >
> > [1]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> > [2]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> > [4]:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> >
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> >
> > dmsimard = [irc, github, twitter]
> >
> > ___
> > 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
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

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

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

2016-12-13 Thread Steve Gordon

- Original Message -
> From: "Steve Gordon" 
> To: "David Moreau Simard" 
> Cc: "OpenStack Development Mailing List (not for usage questions)" 
> , "OpenStack
> Operators" 
> Sent: Tuesday, December 13, 2016 11:06:48 PM
> Subject: Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and  
> qemu-kvm(-ev) 2.6.0
> 
> - Original Message -
> > From: "David Moreau Simard" 
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > , "OpenStack
> > Operators" 
> > Sent: Tuesday, December 13, 2016 6:13:12 PM
> > Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and
> > qemu-kvm(-ev) 2.6.0
> > 
> > Hi,
> > 
> > CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> > was shipped as part of this release if you have the CentOS
> > Virtualization SIG repositories enabled.
> 
> Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't*
> shipped yet? E.g. it's not in:
> 
> http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/
> 
> Hence the mismatch is created because the CentOS repos contain Libvirt 2.0.0
> but not a matching qemu-kvm-ev build (yet).
> 
> Thanks,
> 
> Steve

Just to elaborate on the above, for there are two potential scenarios where you 
will potentially hit "qemu-kvm: CPU feature arat not found":

1) When using virt_type="qemu", CentOS 7 1611 (Libvirt 2.0.0). In this case the 
corrective action for now appears to be as David noted, this is the scenario 
that is most likely hitting the noted CI jobs.

2) When using virt_type="kvm", CentOS 7 1611 (Libvirt 2.0.0) with qemu-kvm-ev < 
2.6.0. In this case the corrective action based on 
https://bugzilla.redhat.com/show_bug.cgi?id=1371617 is actually to install 
qemu-kvm-ev 2.6.0, this is the scenario most likely to hit users.

I wanted to highlight this because David is (quite rightly) focusing on 
resolving (1) to get the CI jobs impacted moving, but it's quite possible many 
users will actually be hitting (2).

Thanks,

Steve

> > If you're using RDO >= Newton, you will have this repository enabled.
> > It was not yet enforced in the Mitaka release so you might or might
> > not have it, depending on your deployment.
> > Older releases of OpenStack may also be affected but they are not
> > proactively tested anymore due to EOL.
> > 
> > There is currently a known issue when using the following
> > configuration in nova for compute:
> > ==
> > virt_type=qemu
> > cpu_mode=host-model
> > ==
> > 
> > This combination will yield in failed attempts at creating instances
> > and you will see errors like these in nova-compute.log [1] or the
> > libvirt logs [2].
> > The problem boils down to libvirt trying to pass a cpu extension that
> > is unknown to qemu:
> > ==
> > qemu-kvm: CPU feature arat not found
> > ==
> > 
> > There is a bugzilla [3] for this issue but in the meantime users are
> > encouraged to work around the issue by setting "cpu_mode=none" if they
> > are using the qemu (not KVM) hypervisor.
> > Please note that Nova defaults the 'cpu_mode' parameter to
> > 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> > 'virt_type' is 'qemu' so if you're running into this issue, you will
> > need to explicitely configure it.
> > 
> > [1]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> > [2]:
> > http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> > [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> > [4]:
> > http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> > 
> > David Moreau Simard
> > Senior Software Engineer | Openstack RDO
> > 
> > dmsimard = [irc, github, twitter]
> > 
> > ___
> > OpenStack-operators mailing list
> > OpenStack-operators@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > 
> 
> 

-- 
Steve Gordon,
Principal Product Manager,
Red Hat OpenStack Platform

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

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

2016-12-13 Thread Steve Gordon

- Original Message -
> From: "David Moreau Simard" 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> , "OpenStack
> Operators" 
> Sent: Tuesday, December 13, 2016 6:13:12 PM
> Subject: [Openstack-operators] [all] Known issue with CentOS 7.3 and  
> qemu-kvm(-ev) 2.6.0
> 
> Hi,
> 
> CentOS 7.3 was released yesterday and a newer version of qemu-kvm-ev
> was shipped as part of this release if you have the CentOS
> Virtualization SIG repositories enabled.

Isn't the issue that the newer version of qemu-kvm-ev (2.6.0) *hasn't* shipped 
yet? E.g. it's not in:

http://mirror.centos.org/centos/7/virt/x86_64/kvm-common/

Hence the mismatch is created because the CentOS repos contain Libvirt 2.0.0 
but not a matching qemu-kvm-ev build (yet).

Thanks,

Steve

> If you're using RDO >= Newton, you will have this repository enabled.
> It was not yet enforced in the Mitaka release so you might or might
> not have it, depending on your deployment.
> Older releases of OpenStack may also be affected but they are not
> proactively tested anymore due to EOL.
> 
> There is currently a known issue when using the following
> configuration in nova for compute:
> ==
> virt_type=qemu
> cpu_mode=host-model
> ==
> 
> This combination will yield in failed attempts at creating instances
> and you will see errors like these in nova-compute.log [1] or the
> libvirt logs [2].
> The problem boils down to libvirt trying to pass a cpu extension that
> is unknown to qemu:
> ==
> qemu-kvm: CPU feature arat not found
> ==
> 
> There is a bugzilla [3] for this issue but in the meantime users are
> encouraged to work around the issue by setting "cpu_mode=none" if they
> are using the qemu (not KVM) hypervisor.
> Please note that Nova defaults the 'cpu_mode' parameter to
> 'host-model' [4] if 'cpu_mode' is not explicitely configured and
> 'virt_type' is 'qemu' so if you're running into this issue, you will
> need to explicitely configure it.
> 
> [1]:
> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/nova/nova-compute.txt.gz#_2016-12-13_16_39_50_832
> [2]:
> http://logs.openstack.org/76/409476/4/check/gate-puppet-openstack-integration-4-scenario003-tempest-centos-7/8881991/logs/libvirt/qemu/instance-0001.txt.gz
> [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1371617
> [4]:
> http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/libvirt/driver.py?id=146b27f22327f8d60c1017c22ccf18d0e16f1eb7#n3411
> 
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> ___
> 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] operators meetups team meetings

2016-12-13 Thread Chris Morgan

Yes almost all responses were in favor and shintaro can (just about) manage it. 
We can discuss whether that's the new standard time during today's meeting 

Chris 

Sent from my iPhone

> On Dec 13, 2016, at 5:11 AM, Matt Jarvis  wrote:
> 
> Are we definitely moving this meeting to 1500 today ? 
> 
> Matt
> 
>> On Fri, Dec 9, 2016 at 8:49 PM, Chris Morgan  wrote:
>> Please note: all responses regarding timing of weekly openstack operators 
>> meetups team IRC meetings are in favor (or at least not against) moving the 
>> meeting to 15:00 UTC. Unless more responses are received changing this, I 
>> propose we move next weeks meeting to Tuesday 15:00 UTC.
>> 
>> Chris
>> 
>>> On Wed, Dec 7, 2016 at 8:08 PM, Shintaro Mizuno 
>>>  wrote:
>>> 1500UTC (2400JST) would work, but no later please :)
>>> 
>>> Shintaro
>>> 
 On 2016/12/07 0:07, Chris Morgan wrote:
 Today's meeting was held at 14:00 UTC, minutes here
 http://eavesdrop.openstack.org/meetings/ops_meetups_team/
 2016/ops_meetups_team.2016-12-06-14.25.html
 
 Actually though the meeting started late and was thinly attended. I would
 like to ask attendees and prospective attendees whether moving this regular
 meeting might help attendance. There are several in favor of pushing it to
 15:00 UTC, although this places some degree of hardship on at least one
 other attendee.
 
 Barring major developments, the next meeting will proceed the same, 14:00
 UTC next Tuesday, December 13th.
 
 
 
 ___
 OpenStack-operators mailing list
 OpenStack-operators@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
>>> 
>>> 
>>> -- 
>>> Shintaro MIZUNO (水野伸太郎)
>>> NTT Software Innovation Center
>>> TEL: 0422-59-4977
>>> E-mail: mizuno.shint...@lab.ntt.co.jp
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>> 
>> 
>> 
>> -- 
>> Chris Morgan 
> 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Appending a security group to a Neutron port

2016-12-13 Thread Paul Browne


Hello Operators,

One of the operations I find myself doing quite often in our OpenStack 
is appending a new security group to a Neutron port (rather than a full 
instance) which already has several security groups defined on it.


As far as I can tell (possibly wrongly!), there seems to be no easy way 
to do this. For a Neutron port with existing security groups A & B on 
it, with a new one to be added C, the closest operation via API calls 
from the older Neutron client would seem to be;


neutron port-update --security-group A --security-group B 
--security-group C *Neutron Port UUID*


, as there seems to be no in-built way to merely append a new 
security-group to a port's existing ones (a full list must be provided).


Am I incorrect in thinking this? I would love to find out that that is 
the case!


Currently I find myself doing a fair bit of JSON-munging of the existing 
security-groups on a port (in order to add a new one to the port without 
wiping out its existing security groups), so I'd love to know if any 
Operators also often do this operation and, if so, how they best go 
about it.


Kind regards,
Paul Browne

--
***
Paul Browne
Research Computing Platforms
University Information Services
Roger Needham Building
JJ Thompson Avenue
University of Cambridge
Cambridge
United Kingdom
E-Mail: pf...@cam.ac.uk
Tel: 0044-1223-46548
***


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

Re: [Openstack-operators] operators meetups team meetings

2016-12-13 Thread Mariano Cunietti

sorry guys, can’t find the right room, openstack-meeting-3 is empty, and 
eavesdrop doesn’t help at all
any hint


NOTICE: my email address has changed from mcunie...@enter.it to 
mcunie...@enter.eu. Former address will work for some weeks before it’s been 
shut.


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you have received this email in error please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and delete 
this e-mail from your system. If you are not the intended recipient you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

> On 13 Dec 2016, at 15:13, Matt Van Winkle  wrote:
> 
> Traveling today to meetings at one of our DC's, but I am fine if we ant to 
> move to 15:00.  Just let me know if the new time sticks.
> 
> Sent from my iPhone
> 
> On Dec 13, 2016, at 5:52 AM, Chris Morgan  > wrote:
> 
>> Yes almost all responses were in favor and shintaro can (just about) manage 
>> it. We can discuss whether that's the new standard time during today's 
>> meeting 
>> 
>> Chris 
>> 
>> Sent from my iPhone
>> 
>> On Dec 13, 2016, at 5:11 AM, Matt Jarvis > > wrote:
>> 
>>> Are we definitely moving this meeting to 1500 today ? 
>>> 
>>> Matt
>>> 
>>> On Fri, Dec 9, 2016 at 8:49 PM, Chris Morgan >> > wrote:
>>> Please note: all responses regarding timing of weekly openstack operators 
>>> meetups team IRC meetings are in favor (or at least not against) moving the 
>>> meeting to 15:00 UTC. Unless more responses are received changing this, I 
>>> propose we move next weeks meeting to Tuesday 15:00 UTC.
>>> 
>>> Chris
>>> 
>>> On Wed, Dec 7, 2016 at 8:08 PM, Shintaro Mizuno 
>>> > 
>>> wrote:
>>> 1500UTC (2400JST) would work, but no later please :)
>>> 
>>> Shintaro
>>> 
>>> On 2016/12/07 0:07, Chris Morgan wrote:
>>> Today's meeting was held at 14:00 UTC, minutes here
>>> http://eavesdrop.openstack.org/meetings/ops_meetups_team/ 
>>> 
>>> 2016/ops_meetups_team.2016-12-06-14 .25.html
>>> 
>>> Actually though the meeting started late and was thinly attended. I would
>>> like to ask attendees and prospective attendees whether moving this regular
>>> meeting might help attendance. There are several in favor of pushing it to
>>> 15:00 UTC, although this places some degree of hardship on at least one
>>> other attendee.
>>> 
>>> Barring major developments, the next meeting will proceed the same, 14:00
>>> UTC next Tuesday, December 13th.
>>> 
>>> 
>>> 
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org 
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Shintaro MIZUNO (水野伸太郎)
>>> NTT Software Innovation Center
>>> TEL: 0422-59-4977
>>> E-mail: mizuno.shint...@lab.ntt.co.jp 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org 
>>> 
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Chris Morgan >
>>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org 
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators 
>> 
> 
> -- 
> Questo messaggio e' stato analizzato con Libra ESVA ed e' risultato non 
> infetto. 
> Clicca qui per segnalarlo come spam. 
>  
> Clicca qui per metterlo in blacklist 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
>

Re: [Openstack-operators] operators meetups team meetings

2016-12-13 Thread Chris Morgan

it's #openstack-operators on free node

On Tue, Dec 13, 2016 at 10:14 AM, Mariano Cunietti 
wrote:

> sorry guys, can’t find the right room, openstack-meeting-3 is empty, and
> eavesdrop doesn’t help at all
> any hint
>
>
> *NOTICE:* my email address has changed from mcunie...@enter.it to 
> *mcunie...@enter.eu
> *. Former address will work for some weeks before it’s
> been shut.
>
> 
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed.
> If you have received this email in error please notify the system manager.
> This message contains confidential information and is intended only for the
> individual named. If you are not the named addressee you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
> delete this e-mail from your system. If you are not the intended recipient
> you are notified that disclosing, copying, distributing or taking any
> action in reliance on the contents of this information is strictly
> prohibited.
>
> On 13 Dec 2016, at 15:13, Matt Van Winkle  wrote:
>
> Traveling today to meetings at one of our DC's, but I am fine if we ant to
> move to 15:00.  Just let me know if the new time sticks.
>
> Sent from my iPhone
>
> On Dec 13, 2016, at 5:52 AM, Chris Morgan  wrote:
>
> Yes almost all responses were in favor and shintaro can (just about)
> manage it. We can discuss whether that's the new standard time during
> today's meeting
>
> Chris
>
> Sent from my iPhone
>
> On Dec 13, 2016, at 5:11 AM, Matt Jarvis  wrote:
>
> Are we definitely moving this meeting to 1500 today ?
>
> Matt
>
> On Fri, Dec 9, 2016 at 8:49 PM, Chris Morgan  wrote:
>
>> Please note: all responses regarding timing of weekly openstack operators
>> meetups team IRC meetings are in favor (or at least not against) moving the
>> meeting to 15:00 UTC. Unless more responses are received changing this, I
>> propose we move next weeks meeting to Tuesday 15:00 UTC.
>>
>> Chris
>>
>> On Wed, Dec 7, 2016 at 8:08 PM, Shintaro Mizuno <
>> mizuno.shint...@lab.ntt.co.jp> wrote:
>>
>>> 1500UTC (2400JST) would work, but no later please :)
>>>
>>> Shintaro
>>>
>>> On 2016/12/07 0:07, Chris Morgan wrote:
>>>
 Today's meeting was held at 14:00 UTC, minutes here
 http://eavesdrop.openstack.org/meetings/ops_meetups_team/
 2016/ops_meetups_team.2016-12-06-14.25.html

 Actually though the meeting started late and was thinly attended. I
 would
 like to ask attendees and prospective attendees whether moving this
 regular
 meeting might help attendance. There are several in favor of pushing it
 to
 15:00 UTC, although this places some degree of hardship on at least one
 other attendee.

 Barring major developments, the next meeting will proceed the same,
 14:00
 UTC next Tuesday, December 13th.



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


>>>
>>> --
>>> Shintaro MIZUNO (水野伸太郎)
>>> NTT Software Innovation Center
>>> TEL: 0422-59-4977
>>> E-mail: mizuno.shint...@lab.ntt.co.jp
>>>
>>>
>>>
>>>
>>> ___
>>> OpenStack-operators mailing list
>>> OpenStack-operators@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>>
>>
>> --
>> Chris Morgan 
>>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> --
> Questo messaggio e' stato analizzato con Libra ESVA ed e' risultato non
> infetto.
> Clicca qui per segnalarlo come spam.
> 
> Clicca qui per metterlo in blacklist
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>


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

Re: [Openstack-operators] operators meetups team meetings

2016-12-13 Thread Chris Morgan

see https://wiki.openstack.org/wiki/IRC

On Tue, Dec 13, 2016 at 10:15 AM, Chris Morgan  wrote:

> it's #openstack-operators on free node
>
> On Tue, Dec 13, 2016 at 10:14 AM, Mariano Cunietti 
> wrote:
>
>> sorry guys, can’t find the right room, openstack-meeting-3 is empty, and
>> eavesdrop doesn’t help at all
>> any hint
>>
>>
>> *NOTICE:* my email address has changed from mcunie...@enter.it to 
>> *mcunie...@enter.eu
>> *. Former address will work for some weeks before it’s
>> been shut.
>>
>> 
>> This email and any files transmitted with it are confidential and
>> intended solely for the use of the individual or entity to whom they are
>> addressed. If you have received this email in error please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee
>> you should not disseminate, distribute or copy this e-mail. Please notify
>> the sender immediately by e-mail if you have received this e-mail by
>> mistake and delete this e-mail from your system. If you are not the
>> intended recipient you are notified that disclosing, copying, distributing
>> or taking any action in reliance on the contents of this information is
>> strictly prohibited.
>>
>> On 13 Dec 2016, at 15:13, Matt Van Winkle  wrote:
>>
>> Traveling today to meetings at one of our DC's, but I am fine if we ant
>> to move to 15:00.  Just let me know if the new time sticks.
>>
>> Sent from my iPhone
>>
>> On Dec 13, 2016, at 5:52 AM, Chris Morgan  wrote:
>>
>> Yes almost all responses were in favor and shintaro can (just about)
>> manage it. We can discuss whether that's the new standard time during
>> today's meeting
>>
>> Chris
>>
>> Sent from my iPhone
>>
>> On Dec 13, 2016, at 5:11 AM, Matt Jarvis  wrote:
>>
>> Are we definitely moving this meeting to 1500 today ?
>>
>> Matt
>>
>> On Fri, Dec 9, 2016 at 8:49 PM, Chris Morgan  wrote:
>>
>>> Please note: all responses regarding timing of weekly openstack
>>> operators meetups team IRC meetings are in favor (or at least not against)
>>> moving the meeting to 15:00 UTC. Unless more responses are received
>>> changing this, I propose we move next weeks meeting to Tuesday 15:00 UTC.
>>>
>>> Chris
>>>
>>> On Wed, Dec 7, 2016 at 8:08 PM, Shintaro Mizuno <
>>> mizuno.shint...@lab.ntt.co.jp> wrote:
>>>
 1500UTC (2400JST) would work, but no later please :)

 Shintaro

 On 2016/12/07 0:07, Chris Morgan wrote:

> Today's meeting was held at 14:00 UTC, minutes here
> http://eavesdrop.openstack.org/meetings/ops_meetups_team/
> 2016/ops_meetups_team.2016-12-06-14.25.html
>
> Actually though the meeting started late and was thinly attended. I
> would
> like to ask attendees and prospective attendees whether moving this
> regular
> meeting might help attendance. There are several in favor of pushing
> it to
> 15:00 UTC, although this places some degree of hardship on at least one
> other attendee.
>
> Barring major developments, the next meeting will proceed the same,
> 14:00
> UTC next Tuesday, December 13th.
>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k-operators
>
>

 --
 Shintaro MIZUNO (水野伸太郎)
 NTT Software Innovation Center
 TEL: 0422-59-4977
 E-mail: mizuno.shint...@lab.ntt.co.jp




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

>>>
>>>
>>>
>>> --
>>> Chris Morgan 
>>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> --
>> Questo messaggio e' stato analizzato con Libra ESVA ed e' risultato non
>> infetto.
>> Clicca qui per segnalarlo come spam.
>> 
>> Clicca qui per metterlo in blacklist
>> 
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>>
>
>
> --
> Chris Morgan 
>



-- 
Chris Morgan 
___
OpenStack-operators mailing list

[Openstack-operators] [scientific][scientific-wg] Reminder: Scientific WG meeting Tuesday 2100 UTC

2016-12-13 Thread Stig Telfer

Greetings all - 

We have a Scientific WG IRC meeting on Tuesday at 2100 UTC on channel 
#openstack-meeting.

The agenda is available here[1] and full IRC meeting details are here[2].

This week we’d like to discuss how GPUs are handled in virtualised 
environments.  Bring and share guidance for getting started and best practice 
for optimisation, advanced topics, etc.

Best wishes,
Stig

[1] 
https://wiki.openstack.org/wiki/Scientific_working_group#IRC_Meeting_December_13th_2016
 

[2] http://eavesdrop.openstack.org/#Scientific_Working_Group 
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] operators meetups team meetings

2016-12-13 Thread Matt Van Winkle

Traveling today to meetings at one of our DC's, but I am fine if we ant to move 
to 15:00.  Just let me know if the new time sticks.

Sent from my iPhone

On Dec 13, 2016, at 5:52 AM, Chris Morgan 
> wrote:

Yes almost all responses were in favor and shintaro can (just about) manage it. 
We can discuss whether that's the new standard time during today's meeting

Chris

Sent from my iPhone

On Dec 13, 2016, at 5:11 AM, Matt Jarvis 
> wrote:

Are we definitely moving this meeting to 1500 today ?

Matt

On Fri, Dec 9, 2016 at 8:49 PM, Chris Morgan 
> wrote:
Please note: all responses regarding timing of weekly openstack operators 
meetups team IRC meetings are in favor (or at least not against) moving the 
meeting to 15:00 UTC. Unless more responses are received changing this, I 
propose we move next weeks meeting to Tuesday 15:00 UTC.

Chris

On Wed, Dec 7, 2016 at 8:08 PM, Shintaro Mizuno 
> wrote:
1500UTC (2400JST) would work, but no later please :)

Shintaro

On 2016/12/07 0:07, Chris Morgan wrote:
Today's meeting was held at 14:00 UTC, minutes here
http://eavesdrop.openstack.org/meetings/ops_meetups_team/
2016/ops_meetups_team.2016-12-06-14.25.html

Actually though the meeting started late and was thinly attended. I would
like to ask attendees and prospective attendees whether moving this regular
meeting might help attendance. There are several in favor of pushing it to
15:00 UTC, although this places some degree of hardship on at least one
other attendee.

Barring major developments, the next meeting will proceed the same, 14:00
UTC next Tuesday, December 13th.

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

--
Shintaro MIZUNO (?)
NTT Software Innovation Center
TEL: 0422-59-4977
E-mail: mizuno.shint...@lab.ntt.co.jp

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

--
Chris Morgan >

___
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] [ops-meetups] Reminder meeting today at 1500 UTC

2016-12-13 Thread Matt Jarvis

Hi All

Just a reminder that todays meeting has been moved to 1500 UTC, in
openstack-operators as usual.

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

[Openstack-operators] Ops Meetups Team - time of weekly meetings

2016-12-13 Thread Chris Morgan

Hello all,

We seem to have consensus around moving to 15:00 UTC for our weekly meeting
on IRC. I recorded this in today's minutes and also updated the official
wiki page

https://wiki.openstack.org/wiki/Ops_Meetups_Team

Links around today's meeting here:

Meeting ended Tue Dec 13 16:00:21 2016 UTC. Information about MeetBot at
http://wiki.debian.org/MeetBot . (v 0.1.4)
11:00 AM Minutes:
http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-12-13-15.03.html
11:00 AM Minutes (text):
http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-12-13-15.03.txt
11:00 AM Log:
http://eavesdrop.openstack.org/meetings/ops_meetups_team/2016/ops_meetups_team.2016-12-13-15.03.log.html

Next week we expect to start thrashing out the agenda for the Milan meetup
in February and also begin to discuss Intel's proposal to host the August
meetup (see
https://etherpad.openstack.org/p/ops-meetup-venue-discuss-aug-2017)

Please join this meeting if you can help us arrange these meetups (meeting
details are on the wiki linked at top of this message).

Thanks!

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

[Openstack-operators] DVR ARP cache update loop delaying launch of metadata proxy

2016-12-13 Thread Gustavo Randich

Hi Openstackers,

We have the folowing issue (using Mitaka / DVR / Xenial), perhaps someone
can help ;)

When our hosts boots up, the ARP cache population loop of L3 Agent is
delaying the start of neutron-ns-metadata-proxy for around a minute -- see
logs below; then, when nova-compute launches VMs, all of cloud-init runs
fail with timeout when reading metadata

To workaround this, we've made a systemd unit on which nova-compute is
dependent; this unit waits for ns-metadata-proxy process to appear, and
only then nova-compute starts

Curiously, in dvr_local_router.py, in _update_arp_entry function, there is
a comment saying "# TODO(mrsmith): optimize the calls below for bulk
calls"...

By now we have a single virtual router with 170 VMs, but the number of VMs
will grow, so my questions are

Should this be issue of concern?

Is there a better / faster / bulk way to execute those "ip neigh" commands?

Or simply, metadata proxy should launch before ARP cache population?




PD: I've also seen (obviously) this ARP cache population in the L3 agent of
Neutron Nodes, and I hope it does not affect / delay the HA failover
mechanism... (didn't test yet)




# journalctl -u neutron-l3-agent | grep "COMMAND=/usr/bin/neutron-rootwrap
/etc/neutron/rootwrap.conf" | sed 's,neutron : TTY=unknown ;
PWD=/var/lib/neutron ; USER=root ; COMMAND=/usr/bin/neutron-rootwrap
/etc/neutron/rootwrap.conf,,g' | head -25

Dec 13 13:33:43 e71-host15 sudo[20157]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 neutron-ns-metadata-proxy
--pid_file=/var/lib/neutron/external/pids/6149559f-fa54-493c-bf37-7d1827181228.pid
--metadata_proxy_socket=/var/
Dec 13 13:33:55 e71-host15 sudo[20309]:   ip -o netns list
Dec 13 13:33:55 e71-host15 sudo[20315]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 sysctl -w net.ipv4.ip_forward=1
Dec 13 13:33:55 e71-host15 sudo[20322]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 sysctl -w
net.ipv6.conf.all.forwarding=1
Dec 13 13:33:56 e71-host15 sudo[20331]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show rfp-6149559f-f
Dec 13 13:33:56 e71-host15 sudo[20336]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:56 e71-host15 sudo[20342]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:56 e71-host15 sudo[20345]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip addr show qr-24f3070a-d4
permanent
Dec 13 13:33:56 e71-host15 sudo[20348]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -4 route list dev
qr-24f3070a-d4 scope link
Dec 13 13:33:56 e71-host15 sudo[20354]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -6 route list dev
qr-24f3070a-d4 scope link
Dec 13 13:33:56 e71-host15 sudo[20357]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 arping -A -I qr-24f3070a-d4 -c
3 -w 4.5 10.96.0.1
Dec 13 13:33:57 e71-host15 sudo[20368]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:57 e71-host15 sudo[20372]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -4 neigh replace
10.96.0.100 lladdr fa:16:3e:1b:d6:cd nud permanent dev qr-24f3070a-d4
Dec 13 13:33:57 e71-host15 sudo[20375]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:57 e71-host15 sudo[20378]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -4 neigh replace
10.96.0.101 lladdr fa:16:3e:b4:12:28 nud permanent dev qr-24f3070a-d4
Dec 13 13:33:58 e71-host15 sudo[20384]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:58 e71-host15 sudo[20387]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -4 neigh replace
10.96.0.102 lladdr fa:16:3e:3f:bb:58 nud permanent dev qr-24f3070a-d4
Dec 13 13:33:58 e71-host15 sudo[20390]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:58 e71-host15 sudo[20393]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -4 neigh replace
10.96.0.103 lladdr fa:16:3e:5a:90:67 nud permanent dev qr-24f3070a-d4
Dec 13 13:33:58 e71-host15 sudo[20399]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:58 e71-host15 sudo[20402]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -4 neigh replace
10.96.0.104 lladdr fa:16:3e:ba:fc:f3 nud permanent dev qr-24f3070a-d4
Dec 13 13:33:58 e71-host15 sudo[20405]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -o link show qr-24f3070a-d4
Dec 13 13:33:59 e71-host15 sudo[20411]:   ip netns exec
qrouter-6149559f-fa54-493c-bf37-7d1827181228 ip -4 neigh replace
10.96.0.105 lladdr fa:16:3e:0a:16:d1 nud permanent dev qr-24f3070a-d4
...
...
...
# journalctl -u neutron-l3-agent | grep "COMMAND=/usr/bin/neutron-rootwrap

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

[Openstack-operators] [telecom-nfv] Meeting #15

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

Re: [Openstack-operators] [all] Known issue with CentOS 7.3 and qemu-kvm(-ev) 2.6.0

Re: [Openstack-operators] operators meetups team meetings

[Openstack-operators] Appending a security group to a Neutron port

Re: [Openstack-operators] operators meetups team meetings

Re: [Openstack-operators] operators meetups team meetings

Re: [Openstack-operators] operators meetups team meetings

[Openstack-operators] [scientific][scientific-wg] Reminder: Scientific WG meeting Tuesday 2100 UTC

Re: [Openstack-operators] operators meetups team meetings

[Openstack-operators] [ops-meetups] Reminder meeting today at 1500 UTC

[Openstack-operators] Ops Meetups Team - time of weekly meetings

[Openstack-operators] DVR ARP cache update loop delaying launch of metadata proxy

16 matches

Site Navigation

Mail list logo

Footer information