Re: [openstack-dev] [puppet] Ubuntu problems + Help needed

[Andrew Woodward]

Some pointers for perusal as to the observed problems would be helpful,
Thanks!

On Wed, Dec 20, 2017 at 11:09 AM Chuck Short  wrote:

> Hi Mohammed,
>
> I might be able to help where can I find this info?
>
> Thanks
> chuck
>
> On Wed, Dec 20, 2017 at 12:03 PM, Mohammed Naser 
> wrote:
>
>> Hi everyone,
>>
>> I'll get right into the point.
>>
>> At the moment, the Puppet OpenStack modules don't have much
>> contributors which can help maintain the Ubuntu support.  We deploy on
>> CentOS (so we try to get all the fixes in that we can) and there is a
>> lot of activity from the TripleO team as well which does their
>> deployments on CentOS which means that the CentOS support is very
>> reliable and CI is always sought after.
>>
>> However, starting a while back, we started seeing occasional failures
>> with Ubuntu deploys which lead us set the job to non-voting.  At the
>> moment, the Puppet integration jobs for Ubuntu are always failing
>> because of some Tempest issue.  This means that with every Puppet
>> change, we're wasting ~80 minutes of CI run time for a job that will
>> always fail.
>>
>> We've had a lot of support from the packaging team at RDO (which are
>> used in Puppet deployments) and they run our integration before
>> promoting packages which makes it helpful in finding issues together.
>> However, we do not have that with Ubuntu neither has there been anyone
>> who is taking initiative to look and investigate those issues.
>>
>> I understand that there are users out there who use Ubuntu with Puppet
>> OpenStack modules.  We need your help to come and try and clear those
>> issues out. We'd be more than happy to give assistance to lead you in
>> the right way to help fix those issues.
>>
>> Unfortunately, if we don't have any folks stepping up to resolving
>> this, we'll be forced to drop all CI for Ubuntu and make a note to
>> users that Ubuntu is not fully tested and hope that as users run into
>> issues, they can contribute fixes back (or that someone can work on
>> getting Ubuntu gating working again).
>>
>> Thanks for reading through this, I am quite sad that we'd have to drop
>> support for such a major operating system, but there's only so much we
>> can do with a much smaller team.
>>
>> Thank you,
>> Mohammed
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Andrew Woodward
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0

[Renat Akhmerov]

Ok, we’ll look at it in Queens.

Thanks

Renat Akhmerov
@Nokia

On 20 Dec 2017, 23:57 +0700, Matthew Thode , wrote:
> On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote:
> > Hi,
> >
> > There is an open bug in launchpad about the new release of Networkx 2.0, 
> > that is backward incompatible with versions 1.x [1].
> > Is there a plan to change the Networkx version in the global requirements 
> > in Queens? We need to make some code refactoring in Vitrage, and I’m trying 
> > to understand how urgent it is.
> >
> > [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576
> >
>
> Mistral, Vitrage, Octavia, Taskflow, Watcher
>
> Those are the projects using NetworkX that'd need to be updated.
> http://codesearch.openstack.org/?q=networkx=nope=.*requirements.*=
>
> I'm open to uncapping networkx if these projects have buyin.
>
> --
> Matthew Thode (prometheanfire)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova][oslo] Random ResourceClosedError failure in TestNovaMigrationsMySQL

[Matt Riedemann]

I noticed this tonight and reported this bug:

https://bugs.launchpad.net/nova/+bug/1739517

This fails at a decent rate (67 hits in 7 days), check and gate queues 
and on master and stable branches, which is the really weird thing. 
Seems to only be in the TestNovaMigrationsMySQL job. I'm not sure what 
to make of the actual failure though.


This is also showing up over a week, so it's longer than we've had this 
change:


https://review.openstack.org/#/q/I6bf0fa19b72887803e77b66698587c2108c9372a

I'm not sure what to make of the actual failure.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] the cpu util

[Jaze Lee]

2017-12-20 23:48 GMT+08:00 gordon chung :
>
>
> On 2017-12-20 10:06 AM, Jaze Lee wrote:
>> Yes, i notice it. But when there will be vcpu.*.time? Which libvirt version?
>> We use libvirt 3.2.0 and it does not have vcpu.*.time, so it will go
>> to fall back.
>
> i have:
>
> virsh # version
> Compiled against library: libvirt 3.2.0
> Using library: libvirt 3.2.0
> Using API: QEMU 3.2.0
> Running hypervisor: QEMU 2.9.0
>
> and it works fine. possibly related to your qemu version?
No. the same as yours

>
>>
>> The fall back is so coarse, do you think we should have it?
>
> are you overcommiting your cpu? that is exactly the case that breaks
> down as the patch i sent you mentions. please look at the bugs and
> related threads on that patch.
I found the root cause. Becuase we use quickstart in libivrt. The vm running
on host is ok. But the vm running in libvirt vm can not get vcpu.x.time.

Thanks gord.


>
> --
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
谦谦君子

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Leaving the Cinder core team

[Jay S Bryant]

Patrick,

Thank you for your past contributions to Cinder and to letting us know 
your current ability to work on Cinder.


Good luck in your future endeavors.

Jay



*From:* Patrick East [mailto:patrick.e...@purestorage.com]
*Sent:* Wednesday, December 20, 2017 6:10 PM
*To:* OpenStack Development Mailing List (not for usage questions) 


*Subject:* [openstack-dev] [cinder] Leaving the Cinder core team

Hi Everyone,

Wanted to let the group know that I'll be stepping away from my 
position on the Cinder Core team.


I've got mixed feelings about it, but with my current responsibilities 
and priorities my focus will be elsewhere. I will be unable to 
dedicate the level of time and energy to Cinder reviews and core 
feature/bug contributions that I've had the privilege of in the past.


My involvement with Cinder won't change much from the last release or 
so, just setting expectations that I don't plan to increase my 
commitment upstream. I will still be on IRC and involved in 
bugs/reviews/etc where I can, primarily in areas I am very familiar 
with (os-brick, replication, volume drivers, etc). Feel free to ping 
me or cc me on reviews/bugs.


Thanks,

Patrick East

patrick.e...@purestorage.com 



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cinder] Leaving the Cinder core team

[Arkady.Kanevsky]

Good luck.
We will miss you.

From: Patrick East [mailto:patrick.e...@purestorage.com]
Sent: Wednesday, December 20, 2017 6:10 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [cinder] Leaving the Cinder core team

Hi Everyone,

Wanted to let the group know that I'll be stepping away from my position on the 
Cinder Core team.

I've got mixed feelings about it, but with my current responsibilities and 
priorities my focus will be elsewhere. I will be unable to dedicate the level 
of time and energy to Cinder reviews and core feature/bug contributions that 
I've had the privilege of in the past.

My involvement with Cinder won't change much from the last release or so, just 
setting expectations that I don't plan to increase my commitment upstream. I 
will still be on IRC and involved in bugs/reviews/etc where I can, primarily in 
areas I am very familiar with (os-brick, replication, volume drivers, etc). 
Feel free to ping me or cc me on reviews/bugs.

Thanks,

Patrick East
patrick.e...@purestorage.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Fei Long Wang]

On 21/12/17 12:57, McLellan, Steven wrote:
>
> On 12/20/17, 5:29 PM, "Matt Riedemann"  wrote:
>
> On 12/20/2017 3:21 PM, Matt Riedemann wrote:
> > On 12/20/2017 9:30 AM, Zane Bitter wrote:
> >> To answer the question from your other mail about user-space 
> >> notifications:
> >>
> >>> We (Zaqar team) have been asked many times about this area but 
> without a
> >>> support from more services, it's hard. I know Heat has some best
> >>> practice using Zaqar, is it possible to "copy" it to 
> >>> Nova/Cinder/Neutron?
> >>
> >> Sure, it would be dead easy, but Nova cores have made it abundantly 
> >> clear that under no circumstances would they ever accept any code like 
> >> this in Nova. Hence it's on this list.
> > 
> > Again, this is news to me. Why isn't this proposed as a community-wide 
> > goal for Rocky?
> > 
> > And if it would be dead easy, why aren't we trying to get part time or 
> > new contributors to work on this, like OSIC was for awhile around the 
> > time of the Austin summit?
> > 
> 
> Now I know.
> 
> 
> http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-20.log.html#t2017-12-20T21:46:11
> 
> -- 
> 
> Since in that IRC conversation ceilometer's notification consumer was 
> mentioned: there was some prototype work done on this (publishing messages to 
> Zaqar off the notification bus to Zaqar) by Lei Zhang in the searchlight 
> codebase - https://review.openstack.org/#/c/271958/. It would be reasonably 
> straightforward to add a service to Zaqar to consume messages off the bus, 
> and I would imagine that it's going to be easier in terms of getting things 
> done to take the notifications (which are a well established format and 
> mechanism) and the transformation to publish them in Zaqar than add a new 
> component to all the individual services.
>
> Steve

Yep, that one is another try in this area. And we (Zaqar team) will
seriously consider the option consuming messages off the infra bus.

> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Cheers & Best regards,
Feilong Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-- 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Multi-tenant network with multiple port

[Hieu LE]

Hi Vasyl,

Thanks for your reply, will try and give feedback! :)

Regards,
Hieu

On Wed, Dec 20, 2017 at 9:49 PM, Vasyl Saienko 
wrote:

> Hello,
>
> We using the following order when picking candidate port/portgroups when
> attaching VIFs:
>
>- For Ironic <= Ocata
>1. portgroups
>   2. ports with pxe_enabled=True
>   3. any other ports
>
>   - For Ironic >= Pike (port has new attribute physical_netowrk:
>   1. portgroups with physical_network field set
>   2. ports with physical_network field set
>   3. portgroups without physical_network field
>   4. ports without physical_network field
>   5. ports with pxe_enabled = True
>   6. other ports
>
> In both cases pxe_enabled ports are prefered when connecting tenant VIF
> compare to non-pxe ports.
> You can configure fake portgroup with 1 port if you using Ironic <= Ocata
> and Ironic will attach tenant VIF to portgroup (which will be actually your
> second port). The drawback here is that nova will do portgroup
> configuration via cloudinit on the instance.
> Or add physical_network field to port you want to connect tenant network
> to, but do not add it to other ports. Will work with ironic >= Pike
>
>
> https://github.com/openstack/ironic/blob/stable/pike/
> ironic/drivers/modules/network/common.py#L506
>
> On Wed, Dec 20, 2017 at 3:10 PM, Hieu LE  wrote:
>
>> Hello Ironic guys,
>>
>> In my lab environment, I have finished setting up the multi-tenant
>> network environment for Ironic using networking-generic-switch (Cisco IOS
>> device). The official Ironic doc only talked about one BM node with one
>> port for provisioning and tenant network.
>>
>> My process here: I have created 2 ports, 01 port with pxe_enabled for
>> provisioning network and remaining port with pxe disabled; then using nova
>> boot with --nic option, hoping it can get network information via Neutron.
>> But it failed.
>>
>> So my question here is:
>> 1. Is this possible for enroll a node, then start provisioning it via one
>> port and then configuring tenant network via another port?
>> 2. Is my process correct, if not, could you provide some guides for the
>> right way?
>>
>> Thanks,
>> Hieu.
>>
>> --
>> -BEGIN GEEK CODE BLOCK-
>> Version: 3.1
>> GCS/CM/IT/M/MU d-@? s+(++):+(++) !a C()$ ULC(++)$ P
>> L++(+++)$ E !W N* o+ K w O- M V- PS+ PE++ Y+ PGP+ t 5 X R tv+ b+(++)>+++
>> DI- D+ G e++(+++) h-- r(++)>+++ y-
>> --END GEEK CODE BLOCK--
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS/CM/IT/M/MU d-@? s+(++):+(++) !a C()$ ULC(++)$ P L++(+++)$ E
!W N* o+ K w O- M V- PS+ PE++ Y+ PGP+ t 5 X R tv+ b+(++)>+++ DI- D+ G
e++(+++) h-- r(++)>+++ y-
--END GEEK CODE BLOCK--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Ihar Hrachyshka]

Please tell me who from the OVN group is ready to take the burden, and
I will make you part of neutron-stable-maint. I think it's ok to be
more laissez faire with backports for subprojects than we were used
to, with the recent drop in core team membership and reduced capacity.

Ihar

On Wed, Dec 20, 2017 at 10:58 AM, Armando M.  wrote:
>
>
> On 20 December 2017 at 00:27, Miguel Angel Ajo Pelayo 
> wrote:
>>
>> If we could have one member from networking-ovn on the
>> neutron-stable-maint team that would be great. That means the member would
>> have to be trusted not to handle neutron-patches when not knowing what he's
>> doing, and of course, follow the stable guidelines, which are absolutely
>> important. But I believe everybody takes the role seriously.
>
>
> It'll still take two +2 to push a patch in, and the oversight from more
> seasoned stable reviewers is still there to assist more inexperienced ones.
> Aside from the occasional lag, I don't believe that backports linger as much
> as they used to, but with the help of the dashboard and the initiative of
> the individual project maintainers velocity should increase. To be honest, I
> am not sure why we didn't do that before, similar review rights apply to
> things like specs reviews and neutron-lib changes. As for your concern about
> people stepping out of their own turf, I honestly don't believe that's a
> problem in reality, and even if it was, I always encourage people to reach
> out on IRC or other means.
>
> I don't have admin rights to the neutron-stable-maint team, fo that someone
> has to nudge Ihar :)
>
> HTH
> Armando
>
> [1] https://docs.openstack.org/project-team-guide/stable-branches.html
>
>>
>>
>> If that's not a reasonable solution, then I'd vote for the specific stable
>> maintainers instead. But we need something to help us handle issues quicker
>> and at
>> the same time, in a controlled manner.
>>
>> Best,
>> Miguel Ángel.
>>
>> On Tue, Dec 19, 2017 at 5:48 PM Armando M.  wrote:
>>>
>>> On 19 December 2017 at 08:21, Lucas Alvares Gomes 
>>> wrote:

 Hi all,

 Just sending this email to try to understand the model for stable branch
 maintenance in networking-ovn (potentially other neutron drivers too).

 Right now, only members of the ``neutron-stable-maint`` gerrit group are
 able to approve patches for the stable branches; this can cause some delays
 when fixing things (e.g [0]) because we don't have any member in that group
 that is also a ``networking-ovn-core`` member. So, sometimes we have to go
 around and ping people to take a look at the patches and it kinda sucks.
>>>
>>>
>>> We had a Gerrit dashboard that helped stable reviewers stay on top of
>>> things [1], but it looks like it doesn't seem to work anymore. My suggestion
>>> would be to look into that as the lack of visibility might be the source of
>>> the recent delay.
>>>
>>> [1]
>>> https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards
>>>

 Is there any reason why things are set up in that way ?

 I was wondering if it would make sense to create a new group to help
 maintaining the stable branches in networking-ovn. The new group could
 include some of the core members willing to do the work +
 ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think
 about it?
>>>
>>>
>>> Rather than create yet another group(s), it makes sense to have an
>>> individual from each neutron project participate in the neutron-stable-maint
>>> team (whose admin rights I think are held by Ihar as neutron member), for
>>> those of whom have actually an interest in reviewing stable patches :)
>>>
>>> HTH
>>> Armando
>>>

 [0] https://review.openstack.org/#/c/523623/

 Cheers,
 Lucas


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

[openstack-dev] [cinder] Leaving the Cinder core team

[Patrick East]

Hi Everyone,

Wanted to let the group know that I'll be stepping away from my position on
the Cinder Core team.

I've got mixed feelings about it, but with my current responsibilities and
priorities my focus will be elsewhere. I will be unable to dedicate the
level of time and energy to Cinder reviews and core feature/bug
contributions that I've had the privilege of in the past.

My involvement with Cinder won't change much from the last release or so,
just setting expectations that I don't plan to increase my commitment
upstream. I will still be on IRC and involved in bugs/reviews/etc where I
can, primarily in areas I am very familiar with (os-brick, replication,
volume drivers, etc). Feel free to ping me or cc me on reviews/bugs.

Thanks,

Patrick East
patrick.e...@purestorage.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[McLellan, Steven]

On 12/20/17, 5:29 PM, "Matt Riedemann"  wrote:

On 12/20/2017 3:21 PM, Matt Riedemann wrote:
> On 12/20/2017 9:30 AM, Zane Bitter wrote:
>> To answer the question from your other mail about user-space 
>> notifications:
>>
>>> We (Zaqar team) have been asked many times about this area but without a
>>> support from more services, it's hard. I know Heat has some best
>>> practice using Zaqar, is it possible to "copy" it to 
>>> Nova/Cinder/Neutron?
>>
>> Sure, it would be dead easy, but Nova cores have made it abundantly 
>> clear that under no circumstances would they ever accept any code like 
>> this in Nova. Hence it's on this list.
> 
> Again, this is news to me. Why isn't this proposed as a community-wide 
> goal for Rocky?
> 
> And if it would be dead easy, why aren't we trying to get part time or 
> new contributors to work on this, like OSIC was for awhile around the 
> time of the Austin summit?
> 

Now I know.


http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-20.log.html#t2017-12-20T21:46:11

-- 

Since in that IRC conversation ceilometer's notification consumer was 
mentioned: there was some prototype work done on this (publishing messages to 
Zaqar off the notification bus to Zaqar) by Lei Zhang in the searchlight 
codebase - https://review.openstack.org/#/c/271958/. It would be reasonably 
straightforward to add a service to Zaqar to consume messages off the bus, and 
I would imagine that it's going to be easier in terms of getting things done to 
take the notifications (which are a well established format and mechanism) and 
the transformation to publish them in Zaqar than add a new component to all the 
individual services.

Steve

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Matt Riedemann]

On 12/20/2017 3:21 PM, Matt Riedemann wrote:

On 12/20/2017 9:30 AM, Zane Bitter wrote:
To answer the question from your other mail about user-space 
notifications:



We (Zaqar team) have been asked many times about this area but without a
support from more services, it's hard. I know Heat has some best
practice using Zaqar, is it possible to "copy" it to 
Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly 
clear that under no circumstances would they ever accept any code like 
this in Nova. Hence it's on this list.


Again, this is news to me. Why isn't this proposed as a community-wide 
goal for Rocky?


And if it would be dead easy, why aren't we trying to get part time or 
new contributors to work on this, like OSIC was for awhile around the 
time of the Austin summit?




Now I know.

http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-12-20.log.html#t2017-12-20T21:46:11

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [octavia] Weekly IRC meeting 12/27/17 cancelled

[Michael Johnson]

Hi everyone,

With many member of the Octavia team taking an end-of-year vacation we
are cancelling the next weekly meeting on 12/27/2017.  We will resume
our regular weekly meetings on 1/3/18.

Michael

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Matt Riedemann]

On 12/20/2017 9:30 AM, Zane Bitter wrote:

To answer the question from your other mail about user-space notifications:


We (Zaqar team) have been asked many times about this area but without a
support from more services, it's hard. I know Heat has some best
practice using Zaqar, is it possible to "copy" it to Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly 
clear that under no circumstances would they ever accept any code like 
this in Nova. Hence it's on this list.


Again, this is news to me. Why isn't this proposed as a community-wide 
goal for Rocky?


And if it would be dead easy, why aren't we trying to get part time or 
new contributors to work on this, like OSIC was for awhile around the 
time of the Austin summit?


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Matt Riedemann]

On 12/19/2017 9:15 PM, Fei Long Wang wrote:

That's one of the changes we (at least me and Rob Cresswell) would like
to improve in Horizon. The idea is services (Nova, Cinder, Nutron, etc)
putting notifications into Zaqar queue and then Horizon can easily get
the resources status instead of doing stupid polling. And it could be
easily doing the thing shown on above link.


Why can't you listen on the existing nova notifications over RPC 
(versioned notifications preferably)?


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Matt Riedemann]

On 12/19/2017 2:29 PM, Joshua Harlow wrote:
* Clear workflow state (and transition) 'machine' that is followed in 
code and can be used by operators/others such as UI developers to get a 
view on what nova is or is not doing (may fit under the broad topic of 
observability?)


Take for example http://flower.readthedocs.io/en/latest/screenshots.html 
and ask yourself why nova-compute (or nova-conductor or 
nova-scheduler...) doesn't have an equivalent kind of 'viewer' (and no 
it doesn't need to be flower, that's just an example...)


OK...first I've heard of this too. Is this something that the majority 
of people deploying, operating and/or using Nova are asking for as a 
priority?


Also, this doesn't just seem like a nova thing - this smells like a 
community-wide goal.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Matt Riedemann]

On 12/19/2017 1:20 PM, Zane Bitter wrote:

Getting off-topic, but since you walked in to this one ;)


I sure did.



On 14/12/17 21:43, Matt Riedemann wrote:
What are the real problems that the Nova team is not working on and 
apparently is a priority to everyone else in the OpenStack ecosystem 
but we are somehow oblivious?


* Providing a secure channel to get credentials to guests so that 
applications running on them can authenticate to OpenStack APIs.


OK yeah, forgot about that one. I remember forum sessions on this in 
Boston and there were some TODOs from that, but I can't say I remember 
off the top of my head what the TODOs were and who the owners were, but 
I thought I remember Monty signing up for something. I might have just 
totally thrown him under the bus though.




* Providing reliable, user-space notifications of events that may 
require application or application-operator intervention (e.g. VM 
reboot, hypervisor died, ).




This one is news to me.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kolla] no meeting 27th Dec

[Michał Jastrzębski]

Because merry Christmas everyone:)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] Ubuntu problems + Help needed

[Chuck Short]

Hi Mohammed,

I might be able to help where can I find this info?

Thanks
chuck

On Wed, Dec 20, 2017 at 12:03 PM, Mohammed Naser 
wrote:

> Hi everyone,
>
> I'll get right into the point.
>
> At the moment, the Puppet OpenStack modules don't have much
> contributors which can help maintain the Ubuntu support.  We deploy on
> CentOS (so we try to get all the fixes in that we can) and there is a
> lot of activity from the TripleO team as well which does their
> deployments on CentOS which means that the CentOS support is very
> reliable and CI is always sought after.
>
> However, starting a while back, we started seeing occasional failures
> with Ubuntu deploys which lead us set the job to non-voting.  At the
> moment, the Puppet integration jobs for Ubuntu are always failing
> because of some Tempest issue.  This means that with every Puppet
> change, we're wasting ~80 minutes of CI run time for a job that will
> always fail.
>
> We've had a lot of support from the packaging team at RDO (which are
> used in Puppet deployments) and they run our integration before
> promoting packages which makes it helpful in finding issues together.
> However, we do not have that with Ubuntu neither has there been anyone
> who is taking initiative to look and investigate those issues.
>
> I understand that there are users out there who use Ubuntu with Puppet
> OpenStack modules.  We need your help to come and try and clear those
> issues out. We'd be more than happy to give assistance to lead you in
> the right way to help fix those issues.
>
> Unfortunately, if we don't have any folks stepping up to resolving
> this, we'll be forced to drop all CI for Ubuntu and make a note to
> users that Ubuntu is not fully tested and hope that as users run into
> issues, they can contribute fixes back (or that someone can work on
> getting Ubuntu gating working again).
>
> Thanks for reading through this, I am quite sad that we'd have to drop
> support for such a major operating system, but there's only so much we
> can do with a much smaller team.
>
> Thank you,
> Mohammed
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Armando M.]

On 20 December 2017 at 00:27, Miguel Angel Ajo Pelayo 
wrote:

> If we could have one member from networking-ovn on the
> neutron-stable-maint team that would be great. That means the member would
> have to be trusted not to handle neutron-patches when not knowing what he's
> doing, and of course, follow the stable guidelines, which are absolutely
> important. But I believe everybody takes the role seriously.
>

It'll still take two +2 to push a patch in, and the oversight from more
seasoned stable reviewers is still there to assist more inexperienced ones.
Aside from the occasional lag, I don't believe that backports linger as
much as they used to, but with the help of the dashboard and the initiative
of the individual project maintainers velocity should increase. To be
honest, I am not sure why we didn't do that before, similar review rights
apply to things like specs reviews and neutron-lib changes. As for your
concern about people stepping out of their own turf, I honestly don't
believe that's a problem in reality, and even if it was, I always encourage
people to reach out on IRC or other means.

I don't have admin rights to the neutron-stable-maint team, fo that someone
has to nudge Ihar :)

HTH
Armando

[1] https://docs.openstack.org/project-team-guide/stable-branches.html


>
> If that's not a reasonable solution, then I'd vote for the specific stable
> maintainers instead. But we need something to help us handle issues quicker
> and at
> the same time, in a controlled manner.
>
> Best,
> Miguel Ángel.
>
> On Tue, Dec 19, 2017 at 5:48 PM Armando M.  wrote:
>
>> On 19 December 2017 at 08:21, Lucas Alvares Gomes 
>> wrote:
>>
>>> Hi all,
>>>
>>> Just sending this email to try to understand the model for stable branch
>>> maintenance in networking-ovn (potentially other neutron drivers too).
>>>
>>> Right now, only members of the ``neutron-stable-maint`` gerrit group are
>>> able to approve patches for the stable branches; this can cause some delays
>>> when fixing things (e.g [0]) because we don't have any member in that group
>>> that is also a ``networking-ovn-core`` member. So, sometimes we have to go
>>> around and ping people to take a look at the patches and it kinda sucks.
>>>
>>
>> We had a Gerrit dashboard that helped stable reviewers stay on top of
>> things [1], but it looks like it doesn't seem to work anymore. My
>> suggestion would be to look into that as the lack of visibility might be
>> the source of the recent delay.
>>
>> [1] https://docs.openstack.org/neutron/latest/
>> contributor/dashboards/index.html#gerrit-dashboards
>>
>>
>>> Is there any reason why things are set up in that way ?
>>>
>>> I was wondering if it would make sense to create a new group to help
>>> maintaining the stable branches in networking-ovn. The new group could
>>> include some of the core members willing to do the work +
>>> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think
>>> about it?
>>>
>>
>> Rather than create yet another group(s), it makes sense to have an
>> individual from each neutron project participate in the
>> neutron-stable-maint team (whose admin rights I think are held by Ihar as
>> neutron member), for those of whom have actually an interest in reviewing
>> stable patches :)
>>
>> HTH
>> Armando
>>
>>
>>> [0] https://review.openstack.org/#/c/523623/
>>>
>>> Cheers,
>>> Lucas
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>>> unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][stable] What nova needs to get to newton end of life

[Matt Riedemann]

On 12/19/2017 8:16 PM, Matt Riedemann wrote:

A quick update here.

There are no outstanding newton backports proposed. I put up the final 
release request earlier today.


However, tonight mnaser reported a bug which impacts Pike+ because of a 
regression introduced in an online data migration from Newton:


https://bugs.launchpad.net/nova/+bug/1739318

I have two patches up for this bug so far. One fixes the actual 
migration, which would help anyone that hasn't run it yet (people 
upgrading from mitaka or older). The other works around the bug for 
anyone that has run the migration and is now hitting the side effect in 
Pike or Queens.


At this point, I'm not sure if we should hold newton up for the first 
fix. It's super simple though, and is low risk to backport.


On the other hand, we have the workaround which we can also backport to 
stable/pike.


Anyway, it's late and I wanted to bring these up so people can ponder.


I have backports proposed for the fix with the online data migration 
regression introduced in Newton:


https://review.openstack.org/#/q/I214a44f0eee7d90be5cd89f32f6e0017b19a3fd6

I've also updated the final newton release patch to depend on that fix 
merging in stable/newton.


--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [puppet] Ubuntu problems + Help needed

[Mohammed Naser]

Hi everyone,

I'll get right into the point.

At the moment, the Puppet OpenStack modules don't have much
contributors which can help maintain the Ubuntu support.  We deploy on
CentOS (so we try to get all the fixes in that we can) and there is a
lot of activity from the TripleO team as well which does their
deployments on CentOS which means that the CentOS support is very
reliable and CI is always sought after.

However, starting a while back, we started seeing occasional failures
with Ubuntu deploys which lead us set the job to non-voting.  At the
moment, the Puppet integration jobs for Ubuntu are always failing
because of some Tempest issue.  This means that with every Puppet
change, we're wasting ~80 minutes of CI run time for a job that will
always fail.

We've had a lot of support from the packaging team at RDO (which are
used in Puppet deployments) and they run our integration before
promoting packages which makes it helpful in finding issues together.
However, we do not have that with Ubuntu neither has there been anyone
who is taking initiative to look and investigate those issues.

I understand that there are users out there who use Ubuntu with Puppet
OpenStack modules.  We need your help to come and try and clear those
issues out. We'd be more than happy to give assistance to lead you in
the right way to help fix those issues.

Unfortunately, if we don't have any folks stepping up to resolving
this, we'll be forced to drop all CI for Ubuntu and make a note to
users that Ubuntu is not fully tested and hope that as users run into
issues, they can contribute fixes back (or that someone can work on
getting Ubuntu gating working again).

Thanks for reading through this, I am quite sad that we'd have to drop
support for such a major operating system, but there's only so much we
can do with a much smaller team.

Thank you,
Mohammed

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Joshua Harlow]

Zane Bitter wrote:

On 19/12/17 22:15, Fei Long Wang wrote:



On 20/12/17 09:29, Joshua Harlow wrote:

Zane Bitter wrote:

Getting off-topic, but since you walked in to this one ;)

On 14/12/17 21:43, Matt Riedemann wrote:

What are the real problems that the Nova team is not working on and
apparently is a priority to everyone else in the OpenStack ecosystem
but we are somehow oblivious?


* Providing a secure channel to get credentials to guests so that
applications running on them can authenticate to OpenStack APIs.

* Providing reliable, user-space notifications of events that may
require application or application-operator intervention (e.g. VM
reboot, hypervisor died, ).


I'll add on.

* Clear workflow state (and transition) 'machine' that is followed in
code and can be used by operators/others such as UI developers to get
a view on what nova is or is not doing (may fit under the broad topic
of observability?)

Take for example
http://flower.readthedocs.io/en/latest/screenshots.html and ask
yourself why nova-compute (or nova-conductor or nova-scheduler...)
doesn't have an equivalent kind of 'viewer' (and no it doesn't need to
be flower, that's just an example...)



That's one of the changes we (at least me and Rob Cresswell) would like
to improve in Horizon. The idea is services (Nova, Cinder, Nutron, etc)
putting notifications into Zaqar queue and then Horizon can easily get
the resources status instead of doing stupid polling. And it could be
easily doing the thing shown on above link.


What you're talking about is really an expansion of my second item
above. What Josh means is using the taskflow library to co-ordinate all
of the steps involved internally to Nova to boot an instance
(scheduling, attaching volumes & ports, actually creating the VM, ) -
it's not really a user-space thing.


I'm fine also with not using taskflow, just use something (vs nothing) ;)



To answer the question from your other mail about user-space notifications:


We (Zaqar team) have been asked many times about this area but without a
support from more services, it's hard. I know Heat has some best
practice using Zaqar, is it possible to "copy" it to Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly
clear that under no circumstances would they ever accept any code like
this in Nova. Hence it's on this list.

cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [requirements][mistral][vitrage][octavia][taskflow][watcher] Networkx version 2.0

[Matthew Thode]

On 17-12-20 15:51:17, Afek, Ifat (Nokia - IL/Kfar Sava) wrote:
> Hi,
> 
> There is an open bug in launchpad about the new release of Networkx 2.0, that 
> is backward incompatible with versions 1.x [1].
> Is there a plan to change the Networkx version in the global requirements in 
> Queens? We need to make some code refactoring in Vitrage, and I’m trying to 
> understand how urgent it is.
> 
> [1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576
> 

Mistral, Vitrage, Octavia, Taskflow, Watcher

Those are the projects using NetworkX that'd need to be updated.
http://codesearch.openstack.org/?q=networkx=nope=.*requirements.*=

I'm open to uncapping networkx if these projects have buyin.

-- 
Matthew Thode (prometheanfire)


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cinder] No Weekly meeting 12/27 or 1/3/2018 ...

[Jay S Bryant]

All,

With the approaching holidays the team decided today that we would skip 
the 12/27/2017 and 1/3/2018 weekly meetings.


If you have anything that needs to be discussed before 1/10/2018 please 
find the team in the #openstack-cinder channel.


I wish you all a Merry Christmas and a safe and happy New Year!

Sincerely,

Jay (jungleboyj)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [requirements][vitrage] Networkx version 2.0

[Afek, Ifat (Nokia - IL/Kfar Sava)]

Hi,

There is an open bug in launchpad about the new release of Networkx 2.0, that 
is backward incompatible with versions 1.x [1].
Is there a plan to change the Networkx version in the global requirements in 
Queens? We need to make some code refactoring in Vitrage, and I’m trying to 
understand how urgent it is.

[1] https://bugs.launchpad.net/diskimage-builder/+bug/1718576

Thanks,
Ifat.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] the cpu util

[gordon chung]

On 2017-12-20 10:06 AM, Jaze Lee wrote:
> Yes, i notice it. But when there will be vcpu.*.time? Which libvirt version?
> We use libvirt 3.2.0 and it does not have vcpu.*.time, so it will go
> to fall back.

i have:

virsh # version
Compiled against library: libvirt 3.2.0
Using library: libvirt 3.2.0
Using API: QEMU 3.2.0
Running hypervisor: QEMU 2.9.0

and it works fine. possibly related to your qemu version?

> 
> The fall back is so coarse, do you think we should have it?

are you overcommiting your cpu? that is exactly the case that breaks 
down as the patch i sent you mentions. please look at the bugs and 
related threads on that patch.

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Switching to longer development cycles

[Zane Bitter]

On 19/12/17 22:15, Fei Long Wang wrote:



On 20/12/17 09:29, Joshua Harlow wrote:

Zane Bitter wrote:

Getting off-topic, but since you walked in to this one ;)

On 14/12/17 21:43, Matt Riedemann wrote:

What are the real problems that the Nova team is not working on and
apparently is a priority to everyone else in the OpenStack ecosystem
but we are somehow oblivious?


* Providing a secure channel to get credentials to guests so that
applications running on them can authenticate to OpenStack APIs.

* Providing reliable, user-space notifications of events that may
require application or application-operator intervention (e.g. VM
reboot, hypervisor died, ).


I'll add on.

* Clear workflow state (and transition) 'machine' that is followed in
code and can be used by operators/others such as UI developers to get
a view on what nova is or is not doing (may fit under the broad topic
of observability?)

Take for example
http://flower.readthedocs.io/en/latest/screenshots.html and ask
yourself why nova-compute (or nova-conductor or nova-scheduler...)
doesn't have an equivalent kind of 'viewer' (and no it doesn't need to
be flower, that's just an example...)



That's one of the changes we (at least me and Rob Cresswell) would like
to improve in Horizon. The idea is services (Nova, Cinder, Nutron, etc)
putting notifications into Zaqar queue and then Horizon can easily get
the resources status instead of doing stupid polling. And it could be
easily doing the thing shown on above link.


What you're talking about is really an expansion of my second item 
above. What Josh means is using the taskflow library to co-ordinate all 
of the steps involved internally to Nova to boot an instance 
(scheduling, attaching volumes & ports, actually creating the VM, ) - 
it's not really a user-space thing.


To answer the question from your other mail about user-space notifications:


We (Zaqar team) have been asked many times about this area but without a
support from more services, it's hard. I know Heat has some best
practice using Zaqar, is it possible to "copy" it to Nova/Cinder/Neutron?


Sure, it would be dead easy, but Nova cores have made it abundantly 
clear that under no circumstances would they ever accept any code like 
this in Nova. Hence it's on this list.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Tis the season...for a cloud reboot

[Joe Talerico]

On Wed, Dec 20, 2017 at 9:08 AM, Ben Nemec  wrote:
>
>
> On 12/19/2017 05:34 PM, Joe Talerico wrote:
>>
>> On Tue, Dec 19, 2017 at 5:45 PM, Derek Higgins  wrote:
>>>
>>>
>>>
>>> On 19 December 2017 at 22:23, Brian Haley  wrote:


 On 12/19/2017 04:00 PM, Ben Nemec wrote:
>
>
>
>
> On 12/19/2017 02:43 PM, Brian Haley wrote:
>>
>>
>> On 12/19/2017 11:53 AM, Ben Nemec wrote:
>>>
>>>
>>> The reboot is done (mostly...see below).
>>>
>>> On 12/18/2017 05:11 PM, Joe Talerico wrote:


 Ben - Can you provide some links to the ovs port exhaustion issue
 for
 some background?
>>>
>>>
>>>
>>> I don't know if we ever had a bug opened, but there's some discussion
>>> of it in
>>>
>>> http://lists.openstack.org/pipermail/openstack-dev/2016-December/109182.html
>>> I've also copied Derek since I believe he was the one who found it
>>> originally.
>>>
>>> The gist is that after about 3 months of tripleo-ci running in this
>>> cloud we start to hit errors creating instances because of problems
>>> creating
>>> OVS ports on the compute nodes.  Sometimes we see a huge number of
>>> ports in
>>> general, other times we see a lot of ports that look like this:
>>>
>>> Port "qvod2cade14-7c"
>>>   tag: 4095
>>>   Interface "qvod2cade14-7c"
>>>
>>> Notably they all have a tag of 4095, which seems suspicious to me.  I
>>> don't know whether it's actually an issue though.
>>
>>
>>
>> Tag 4095 is for "dead" OVS ports, it's an unused VLAN tag in the
>> agent.
>>
>> The 'qvo' here shows it's part of the VETH pair that os-vif created
>> when
>> it plugged in the VM (the other half is 'qvb'), and they're created so
>> that
>> iptables rules can be applied by neutron.  It's part of the "old" way
>> to do
>> security groups with the OVSHybridIptablesFirewallDriver, and can
>> eventually
>> go away once the OVSFirewallDriver can be used everywhere (requires
>> newer
>> OVS and agent).
>>
>> I wonder if you can run the ovs_cleanup utility to clean some of these
>> up?
>
>
>
> As in neutron-ovs-cleanup?  Doesn't that wipe out everything, including
> any ports that are still in use?  Or is there a different tool I'm not
> aware
> of that can do more targeted cleanup?



 Crap, I thought there was an option to just cleanup these dead devices,
 I
 should have read the code, it's either neutron ports (default) or all
 ports.
 Maybe that should be an option.
>>>
>>>
>>>
>>> iirc neutron-ovs-cleanup was being run following the reboot as part of a
>>> ExecStartPre= on one of the neutron services this is what essentially
>>> removed the ports for us.
>>>
>>>
>>
>> There is actually unit files for cleanup (netns|ovs|lb), specifically
>> for ovs-cleanup[1]
>>
>> Maybe this can be ran to mitigate the need for a reboot?
>
>
> That's what Brian suggested too, but running it with instances on the node
> will cause an outage because it cleans up everything, including in-use
> ports.  The reason a reboot works is basically that it causes this unit to
> run when the node comes back up because it's a dep of the other services.
> So it's possible we could use this to skip the complete reboot, but that's
> not the time-consuming part of the process.  It's waiting for all the
> instances to cycle off so we don't cause spurious failures when we wipe the
> ovs ports.  Actually rebooting the nodes takes about five minutes (and it's
> only that long because of an old TripleO bug).

ack. There are options you can pass with the cleanup to not nuke everything.

I wonder if it is a combination of ovs-cleanup + restarting the
ovs-agent? Anyway, doesn't seem that big of a problem then. /me gets
off his uptime soapbox

Joe

>
>
>>
>> [1]
>> [Unit]
>> Description=OpenStack Neutron Open vSwitch Cleanup Utility
>> After=syslog.target network.target openvswitch.service
>> Before=neutron-openvswitch-agent.service neutron-dhcp-agent.service
>> neutron-l3-agent.service openstack-nova-compute.service
>>
>> [Service]
>> Type=oneshot
>> User=neutron
>> ExecStart=/usr/bin/neutron-ovs-cleanup --config-file
>> /usr/share/neutron/neutron-dist.conf --config-file
>> /etc/neutron/neutron.conf --config-file
>> /etc/neutron/plugins/ml2/openvswitch_agent.ini --config-dir
>> /etc/neutron/conf.d/common --config-dir
>> /etc/neutron/conf.d/neutron-ovs-cleanup --log-file
>> /var/log/neutron/ovs-cleanup.log
>> ExecStop=/usr/bin/neutron-ovs-cleanup --config-file
>> /usr/share/neutron/neutron-dist.conf --config-file
>> /etc/neutron/neutron.conf --config-file
>> /etc/neutron/plugins/ml2/openvswitch_agent.ini --config-dir
>> /etc/neutron/conf.d/common --config-dir
>> 

Re: [openstack-dev] [ceilometer] the cpu util

[Jaze Lee]

2017-12-20 22:29 GMT+08:00 gordon chung :
>
>
> On 2017-12-20 03:14 AM, Jaze Lee wrote:
>> Hello,
>> We use ceilometer newton, and also master calculates cpu same as newton.
>> It is in 
>> https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L183
>>
>> I test with a two vcpu vm, and find using this method as line 183
>> we can not get cpu util 100, always 50 or 52.
>>
>> The test script is here(run on compute node, and there is only one vm)
>> #!/bin/bash
>>
>> cpu_time_begin=`virsh  domstats --cpu-total | grep cpu.time| awk -F
>> '=' '{print $2}'`
>> sleep 1
>> cpu_time_end=`virsh  domstats --cpu-total | grep cpu.time| awk -F '='
>> '{print $2}'`
>>
>> cpu_util=$(((cpu_time_end - cpu_time_begin) * 100 / 10**9))
>> echo "cpu util is ", $cpu_util
>>
>> The output will be 100 or 101, if we divide cpu_util with core number,
>> then we definitely get 50. But in the vm we watch with top and find
>> all core is 99%.
>>
>> Can someone tell me why we only use cpu_time here? May be we should
>> add cpu.user and cpu.system? It is insane only get 50% when the vm is
>> totally 100%
>>
>
> does adding cpu.user and cpu.system make sense or are you just adding
> random numbers in hopes it gets you to right number? :P
The latter one. :)


>
> i'm not a libvirt/qemu dev but it seems cpu.system is already part of
> cpu.time[1]
>
> if you look further into the code, you should see that the agent tries
> to first use vcpu.*.time to build more accurate cpu.time value. if you
> look at patch[3], it should give you more information as to why and what
> requirements you need.

Yes, i notice it. But when there will be vcpu.*.time? Which libvirt version?
We use libvirt 3.2.0 and it does not have vcpu.*.time, so it will go
to fall back.

The fall back is so coarse, do you think we should have it?


>
>
> [1]
> https://stackoverflow.com/questions/40468370/what-does-cpu-time-represent-exactly-in-libvirt
> [2]
> https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L175-L176
> [3]
> https://github.com/openstack/ceilometer/commit/a4ec0911a3ed4137a1c832fbd7c8fee80c7d4601
>
> cheers,
>
> --
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
谦谦君子

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [QA] No QA meetings until next year

[Andrea Frittoli]

Dear all,

due to the holiday season, there will be no QA meetings until 2018.

Andrea Frittoli (andreaf)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Ironic] Multi-tenant network with multiple port

[Vasyl Saienko]

Hello,

We using the following order when picking candidate port/portgroups when
attaching VIFs:

   - For Ironic <= Ocata
   1. portgroups
  2. ports with pxe_enabled=True
  3. any other ports

  - For Ironic >= Pike (port has new attribute physical_netowrk:
  1. portgroups with physical_network field set
  2. ports with physical_network field set
  3. portgroups without physical_network field
  4. ports without physical_network field
  5. ports with pxe_enabled = True
  6. other ports

In both cases pxe_enabled ports are prefered when connecting tenant VIF
compare to non-pxe ports.
You can configure fake portgroup with 1 port if you using Ironic <= Ocata
and Ironic will attach tenant VIF to portgroup (which will be actually your
second port). The drawback here is that nova will do portgroup
configuration via cloudinit on the instance.
Or add physical_network field to port you want to connect tenant network
to, but do not add it to other ports. Will work with ironic >= Pike


https://github.com/openstack/ironic/blob/stable/pike/ironic/drivers/modules/network/common.py#L506

On Wed, Dec 20, 2017 at 3:10 PM, Hieu LE  wrote:

> Hello Ironic guys,
>
> In my lab environment, I have finished setting up the multi-tenant network
> environment for Ironic using networking-generic-switch (Cisco IOS device).
> The official Ironic doc only talked about one BM node with one port for
> provisioning and tenant network.
>
> My process here: I have created 2 ports, 01 port with pxe_enabled for
> provisioning network and remaining port with pxe disabled; then using nova
> boot with --nic option, hoping it can get network information via Neutron.
> But it failed.
>
> So my question here is:
> 1. Is this possible for enroll a node, then start provisioning it via one
> port and then configuring tenant network via another port?
> 2. Is my process correct, if not, could you provide some guides for the
> right way?
>
> Thanks,
> Hieu.
>
> --
> -BEGIN GEEK CODE BLOCK-
> Version: 3.1
> GCS/CM/IT/M/MU d-@? s+(++):+(++) !a C()$ ULC(++)$ P L++(+++)$
> E !W N* o+ K w O- M V- PS+ PE++ Y+ PGP+ t 5 X R tv+ b+(++)>+++ DI- D+ G
> e++(+++) h-- r(++)>+++ y-
> --END GEEK CODE BLOCK--
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [acceleration]Cancellation of Cyborg Weekly Meeting for Xmas and New Year vacation

[Zhipeng Huang]

Hi team,

Let's cancel the weekly team meeting until after new year. However we could
still asyncly chat on IRC channel and via other means if necessary.

Meery Xmas and happy new year to you all :)

-- 
Zhipeng (Howard) Huang

Standard Engineer
IT Standard & Patent/IT Product Line
Huawei Technologies Co,. Ltd
Email: huangzhip...@huawei.com
Office: Huawei Industrial Base, Longgang, Shenzhen

(Previous)
Research Assistant
Mobile Ad-Hoc Network Lab, Calit2
University of California, Irvine
Email: zhipe...@uci.edu
Office: Calit2 Building Room 2402

OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO][Off topic] Merry Christmas to everyone!

[Ben Nemec]

I kind of want an owl ornament now. :-)

On 12/20/2017 05:42 AM, Carlos Camacho Gonzalez wrote:

Hello everyone!

Thank you for all your effort and support this year making a better 
product for our users. I hope you enjoy this holiday time.


Here you have a digital TripleO Christmas card :)

Merry Christmas

As usual, sources are available on GitHub: 
https://github.com/ccamacho/tripleo-graphics


Cheers,
Carlos.

Inline image 1


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Help with fixing python-pint fixing failed tests with last python-numpy

[Akihiro Motoki]

btw, python-pint is used in horizon.utils.units but the module is
actually not used anywhere.
It was used in the metering panel (ceilometer support) but the panel
was dropped long ago.
In addition, there seems no horizon plugins that consume the module [1]
(daisycloud-core import the module but it has a copy of horizon code
in its repo, so it looks unrelated)

I guess horizon can drop horizon.utils.units.
Any objection?

[1] http://codesearch.openstack.org/?q=import%20units=nope==

2017-12-20 22:28 GMT+09:00 Thomas Goirand :
> Hi list!
>
> Pint is a (test) dependency for horizon (and therefore, an indirect
> dependency for all Horizon plugins).
>
> Since the update of python-numpy in Debian Sid, pint fails to build. The
> issue was reported to the Debian BTS:
>
> https://bugs.debian.org/876921
>
> and to the upstream github:
> https://github.com/hgrecco/pint/issues/577
>
> None of these bug entries received patches. I attempted to understand
> myself, though it is above my skills.
>
> Could anyone help and provide a patch?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ceilometer] the cpu util

[gordon chung]

On 2017-12-20 03:14 AM, Jaze Lee wrote:
> Hello,
> We use ceilometer newton, and also master calculates cpu same as newton.
> It is in 
> https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L183
> 
> I test with a two vcpu vm, and find using this method as line 183
> we can not get cpu util 100, always 50 or 52.
> 
> The test script is here(run on compute node, and there is only one vm)
> #!/bin/bash
> 
> cpu_time_begin=`virsh  domstats --cpu-total | grep cpu.time| awk -F
> '=' '{print $2}'`
> sleep 1
> cpu_time_end=`virsh  domstats --cpu-total | grep cpu.time| awk -F '='
> '{print $2}'`
> 
> cpu_util=$(((cpu_time_end - cpu_time_begin) * 100 / 10**9))
> echo "cpu util is ", $cpu_util
> 
> The output will be 100 or 101, if we divide cpu_util with core number,
> then we definitely get 50. But in the vm we watch with top and find
> all core is 99%.
> 
> Can someone tell me why we only use cpu_time here? May be we should
> add cpu.user and cpu.system? It is insane only get 50% when the vm is
> totally 100%
> 

does adding cpu.user and cpu.system make sense or are you just adding 
random numbers in hopes it gets you to right number? :P

i'm not a libvirt/qemu dev but it seems cpu.system is already part of 
cpu.time[1]

if you look further into the code, you should see that the agent tries 
to first use vcpu.*.time to build more accurate cpu.time value. if you 
look at patch[3], it should give you more information as to why and what 
requirements you need.


[1] 
https://stackoverflow.com/questions/40468370/what-does-cpu-time-represent-exactly-in-libvirt
[2] 
https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L175-L176
[3] 
https://github.com/openstack/ceilometer/commit/a4ec0911a3ed4137a1c832fbd7c8fee80c7d4601

cheers,

-- 
gord
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Tis the season...for a cloud reboot

[Ben Nemec]

On 12/19/2017 05:34 PM, Joe Talerico wrote:

On Tue, Dec 19, 2017 at 5:45 PM, Derek Higgins  wrote:



On 19 December 2017 at 22:23, Brian Haley  wrote:


On 12/19/2017 04:00 PM, Ben Nemec wrote:




On 12/19/2017 02:43 PM, Brian Haley wrote:


On 12/19/2017 11:53 AM, Ben Nemec wrote:


The reboot is done (mostly...see below).

On 12/18/2017 05:11 PM, Joe Talerico wrote:


Ben - Can you provide some links to the ovs port exhaustion issue for
some background?



I don't know if we ever had a bug opened, but there's some discussion
of it in
http://lists.openstack.org/pipermail/openstack-dev/2016-December/109182.html
I've also copied Derek since I believe he was the one who found it
originally.

The gist is that after about 3 months of tripleo-ci running in this
cloud we start to hit errors creating instances because of problems creating
OVS ports on the compute nodes.  Sometimes we see a huge number of ports in
general, other times we see a lot of ports that look like this:

Port "qvod2cade14-7c"
  tag: 4095
  Interface "qvod2cade14-7c"

Notably they all have a tag of 4095, which seems suspicious to me.  I
don't know whether it's actually an issue though.



Tag 4095 is for "dead" OVS ports, it's an unused VLAN tag in the agent.

The 'qvo' here shows it's part of the VETH pair that os-vif created when
it plugged in the VM (the other half is 'qvb'), and they're created so that
iptables rules can be applied by neutron.  It's part of the "old" way to do
security groups with the OVSHybridIptablesFirewallDriver, and can eventually
go away once the OVSFirewallDriver can be used everywhere (requires newer
OVS and agent).

I wonder if you can run the ovs_cleanup utility to clean some of these
up?



As in neutron-ovs-cleanup?  Doesn't that wipe out everything, including
any ports that are still in use?  Or is there a different tool I'm not aware
of that can do more targeted cleanup?



Crap, I thought there was an option to just cleanup these dead devices, I
should have read the code, it's either neutron ports (default) or all ports.
Maybe that should be an option.



iirc neutron-ovs-cleanup was being run following the reboot as part of a
ExecStartPre= on one of the neutron services this is what essentially
removed the ports for us.




There is actually unit files for cleanup (netns|ovs|lb), specifically
for ovs-cleanup[1]

Maybe this can be ran to mitigate the need for a reboot?


That's what Brian suggested too, but running it with instances on the 
node will cause an outage because it cleans up everything, including 
in-use ports.  The reason a reboot works is basically that it causes 
this unit to run when the node comes back up because it's a dep of the 
other services.  So it's possible we could use this to skip the complete 
reboot, but that's not the time-consuming part of the process.  It's 
waiting for all the instances to cycle off so we don't cause spurious 
failures when we wipe the ovs ports.  Actually rebooting the nodes takes 
about five minutes (and it's only that long because of an old TripleO bug).




[1]
[Unit]
Description=OpenStack Neutron Open vSwitch Cleanup Utility
After=syslog.target network.target openvswitch.service
Before=neutron-openvswitch-agent.service neutron-dhcp-agent.service
neutron-l3-agent.service openstack-nova-compute.service

[Service]
Type=oneshot
User=neutron
ExecStart=/usr/bin/neutron-ovs-cleanup --config-file
/usr/share/neutron/neutron-dist.conf --config-file
/etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/ml2/openvswitch_agent.ini --config-dir
/etc/neutron/conf.d/common --config-dir
/etc/neutron/conf.d/neutron-ovs-cleanup --log-file
/var/log/neutron/ovs-cleanup.log
ExecStop=/usr/bin/neutron-ovs-cleanup --config-file
/usr/share/neutron/neutron-dist.conf --config-file
/etc/neutron/neutron.conf --config-file
/etc/neutron/plugins/ml2/openvswitch_agent.ini --config-dir
/etc/neutron/conf.d/common --config-dir
/etc/neutron/conf.d/neutron-ovs-cleanup --log-file
/var/log/neutron/ovs-cleanup.log
PrivateTmp=true
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
~




-Brian



Oh, also worth noting that I don't think we have os-vif in this cloud
because it's so old.  There's no os-vif package installed anyway.



-Brian


I've had some offline discussions about getting someone on this cloud
to debug the problem.  Originally we decided not to pursue it since it's not
hard to work around and we didn't want to disrupt the environment by trying
to move to later OpenStack code (we're still back on Mitaka), but it was
pointed out to me this time around that from a downstream perspective we
have users on older code as well and it may be worth debugging to make sure
they don't hit similar problems.

To that end, I've left one compute node un-rebooted for debugging
purposes.  The downstream discussion is ongoing, but I'll update here if we
find anything.



Thanks,
Joe

On Mon, Dec 18, 2017 at 10:43 

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Miguel Angel Ajo Pelayo]

That may help, of course, but I gues it could also be capacity related.

On Wed, Dec 20, 2017 at 11:42 AM Takashi Yamamoto 
wrote:

> On Wed, Dec 20, 2017 at 7:18 PM, Lucas Alvares Gomes
>  wrote:
> > Hi,
> >
> >>> Hi all,
> >>>
> >>> Just sending this email to try to understand the model for stable
> branch maintenance in networking-ovn (potentially other neutron drivers
> too).
> >>>
> >>> Right now, only members of the ``neutron-stable-maint`` gerrit group
> are able to approve patches for the stable branches; this can cause some
> delays when fixing things (e.g [0]) because we don't have any member in
> that group that is also a ``networking-ovn-core`` member. So, sometimes we
> have to go around and ping people to take a look at the patches and it
> kinda sucks.
> >>
> >>
> >> We had a Gerrit dashboard that helped stable reviewers stay on top of
> things [1], but it looks like it doesn't seem to work anymore. My
> suggestion would be to look into that as the lack of visibility might be
> the source of the recent delay.
> >>
> >> [1]
> https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards
> >
> > ++ indeed, lack of visibility is a problem as well.
>
> and lack of visibility of the fix of the dashboard? :-)
> https://review.openstack.org/#/c/479138/
>
> >
> >>> Is there any reason why things are set up in that way ?
> >>>
> >>> I was wondering if it would make sense to create a new group to help
> maintaining the stable branches in networking-ovn. The new group could
> include some of the core members willing to do the work +
> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think
> about it?
> >>
> >>
> >> Rather than create yet another group(s), it makes sense to have an
> individual from each neutron project participate in the
> neutron-stable-maint team (whose admin rights I think are held by Ihar as
> neutron member), for those of whom have actually an interest in reviewing
> stable patches :)
> >>
> >
> > Having a member in the current group will help, if you are comfortable
> > with adding a new member to the current group that would be great.
> >
> > The reason why I was leaning towards having another group is because
> > of scope limitation. Members of the ``neutron-stable-maint`` group can
> > approve patches for all neutron-related projects stable branches. By
> > having a separated group, members would only be able to approve things
> > for a specific project.
> >
> > The new group would also have the ``neutron-stable-maint`` as a
> > sub-group to it , so the members of the original group would still
> > able approve things everywhere.
> >
> > Anyway, either ideas would help with the original problem, I'm good
> > with whatever approach people thinks is best.
> >
> > Cheers,
> > Lucas
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa][all] QA Office Hours on 21st Dec, 2017

[Chandan kumar]

Hello All,

a kind reminder that tomorrow at 9:00 UTC we'll start office hours for
the QA team in the #openstack-qa channel.
Please join us with any question/comment you may have related to
tempest plugin split community goal, tempest and others QA tools.

We'll triage bugs for QA projects from the past 7 days and then extend
the time frame if there is time left.

Thanks,

Chandan Kumar

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Help with fixing python-pint fixing failed tests with last python-numpy

[Thomas Goirand]

Hi list!

Pint is a (test) dependency for horizon (and therefore, an indirect
dependency for all Horizon plugins).

Since the update of python-numpy in Debian Sid, pint fails to build. The
issue was reported to the Debian BTS:

https://bugs.debian.org/876921

and to the upstream github:
https://github.com/hgrecco/pint/issues/577

None of these bug entries received patches. I attempted to understand
myself, though it is above my skills.

Could anyone help and provide a patch?

Cheers,

Thomas Goirand (zigo)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [infra] Gerrit issues

[Mohammed Naser]

Hi Gary,

It looks like Gerrit is having some issues indeed and they are getting
worked on at the moment.

Thanks,
Mohammed

On Wed, Dec 20, 2017 at 8:00 AM, Gary Kotton  wrote:
> Hi,
>
> Anyone else experience problems accessing gerrit?
>
> Thanks
>
> Gary
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Ironic] Multi-tenant network with multiple port

[Hieu LE]

Hello Ironic guys,

In my lab environment, I have finished setting up the multi-tenant network
environment for Ironic using networking-generic-switch (Cisco IOS device).
The official Ironic doc only talked about one BM node with one port for
provisioning and tenant network.

My process here: I have created 2 ports, 01 port with pxe_enabled for
provisioning network and remaining port with pxe disabled; then using nova
boot with --nic option, hoping it can get network information via Neutron.
But it failed.

So my question here is:
1. Is this possible for enroll a node, then start provisioning it via one
port and then configuring tenant network via another port?
2. Is my process correct, if not, could you provide some guides for the
right way?

Thanks,
Hieu.

-- 
-BEGIN GEEK CODE BLOCK-
Version: 3.1
GCS/CM/IT/M/MU d-@? s+(++):+(++) !a C()$ ULC(++)$ P L++(+++)$ E
!W N* o+ K w O- M V- PS+ PE++ Y+ PGP+ t 5 X R tv+ b+(++)>+++ DI- D+ G
e++(+++) h-- r(++)>+++ y-
--END GEEK CODE BLOCK--
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [infra] Gerrit issues

[Gary Kotton]

Hi,
Anyone else experience problems accessing gerrit?
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [publiccloud-wg] Reminder for todays meeting

[Tobias Rydberg]

Hi all,

Time again for a meeting for the Public Cloud WG - today at 1400 UTC in 
#openstack-meeting-3


Agenda and etherpad at: https://etherpad.openstack.org/p/publiccloud-wg

See you later!

Tobias Rydberg




smime.p7s
Description: S/MIME Cryptographic Signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cyborg] minutes of FPGA introduction meeting

[Feng, Shaohe]

Date: 2017-12-12


Shaohe and Dolpher gave an introduction about FPGA.

They also do simple POC for FPGA base on Placement schedule and He 
Yongli's PCI management mechanism in nova.


1.  We define a new resource class CUSTOM_FPGA_INTEL_ECHO for a kind of 
FPGA accelerator which is ECHO.


The Cyborg need to implement an interface to get the inventory, then to 
update the provider inventory of placement whit it.


The Cyborg API need to get the inventory data by its FPGA agent running 
on every node.


2.  We need to extend related PCI info of CUSTOM_FPGA_INTEL_ECHO in the 
PCI whitelist, so this kind of PCI device(CUSTOM_FPGA_INTEL_ECHO) can be 
allocated.


Cyborg needs to support to get the related PCI info.

3. we define a new  property "resources:CUSTOM_FPGA_INTEL_ECHO='1' " in 
flavor.


Cyborg needs to translate abstract property to concrete device with PCI 
spec.



The flow is:

Create a VM with a flavor which has a FPGA accelerator resource in it's 
property.


The scheduler will schedule a host with this kind of FPGA accelerator 
base on the placement provider information.  and claim an abstract 
accelerator.


The nova-cpu will claim an related concrete PCI devices from the 
abstract accelerator information.


The driver will start a VM with the PCI devices.


Open

1. Should Cybory will leverage Yongli's PCI management mechanism in 
nova?  or it will maintain a new PCI management mechanism for PCI device?


2. beside, for VGPU accelerator, it is not a PCI device, it is a mdev 
device.


Should Cybory maintain this new kind  device mechanism?

3. The FPGA can be programmed. So should the Cyborg  update the 
whitelist on the fly?



NOTE: the POC does not consider the how to program FPGA.

AR:  Zhu Li  will introduce how to cyborg FPGA model and agent.


BR

Shaohe Feng


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Takashi Yamamoto]

On Wed, Dec 20, 2017 at 7:18 PM, Lucas Alvares Gomes
 wrote:
> Hi,
>
>>> Hi all,
>>>
>>> Just sending this email to try to understand the model for stable branch 
>>> maintenance in networking-ovn (potentially other neutron drivers too).
>>>
>>> Right now, only members of the ``neutron-stable-maint`` gerrit group are 
>>> able to approve patches for the stable branches; this can cause some delays 
>>> when fixing things (e.g [0]) because we don't have any member in that group 
>>> that is also a ``networking-ovn-core`` member. So, sometimes we have to go 
>>> around and ping people to take a look at the patches and it kinda sucks.
>>
>>
>> We had a Gerrit dashboard that helped stable reviewers stay on top of things 
>> [1], but it looks like it doesn't seem to work anymore. My suggestion would 
>> be to look into that as the lack of visibility might be the source of the 
>> recent delay.
>>
>> [1] 
>> https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards
>
> ++ indeed, lack of visibility is a problem as well.

and lack of visibility of the fix of the dashboard? :-)
https://review.openstack.org/#/c/479138/

>
>>> Is there any reason why things are set up in that way ?
>>>
>>> I was wondering if it would make sense to create a new group to help 
>>> maintaining the stable branches in networking-ovn. The new group could 
>>> include some of the core members willing to do the work + 
>>> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think 
>>> about it?
>>
>>
>> Rather than create yet another group(s), it makes sense to have an 
>> individual from each neutron project participate in the neutron-stable-maint 
>> team (whose admin rights I think are held by Ihar as neutron member), for 
>> those of whom have actually an interest in reviewing stable patches :)
>>
>
> Having a member in the current group will help, if you are comfortable
> with adding a new member to the current group that would be great.
>
> The reason why I was leaning towards having another group is because
> of scope limitation. Members of the ``neutron-stable-maint`` group can
> approve patches for all neutron-related projects stable branches. By
> having a separated group, members would only be able to approve things
> for a specific project.
>
> The new group would also have the ``neutron-stable-maint`` as a
> sub-group to it , so the members of the original group would still
> able approve things everywhere.
>
> Anyway, either ideas would help with the original problem, I'm good
> with whatever approach people thinks is best.
>
> Cheers,
> Lucas
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Lucas Alvares Gomes]

Hi,

>> Hi all,
>>
>> Just sending this email to try to understand the model for stable branch 
>> maintenance in networking-ovn (potentially other neutron drivers too).
>>
>> Right now, only members of the ``neutron-stable-maint`` gerrit group are 
>> able to approve patches for the stable branches; this can cause some delays 
>> when fixing things (e.g [0]) because we don't have any member in that group 
>> that is also a ``networking-ovn-core`` member. So, sometimes we have to go 
>> around and ping people to take a look at the patches and it kinda sucks.
>
>
> We had a Gerrit dashboard that helped stable reviewers stay on top of things 
> [1], but it looks like it doesn't seem to work anymore. My suggestion would 
> be to look into that as the lack of visibility might be the source of the 
> recent delay.
>
> [1] 
> https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards

++ indeed, lack of visibility is a problem as well.

>> Is there any reason why things are set up in that way ?
>>
>> I was wondering if it would make sense to create a new group to help 
>> maintaining the stable branches in networking-ovn. The new group could 
>> include some of the core members willing to do the work + 
>> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think 
>> about it?
>
>
> Rather than create yet another group(s), it makes sense to have an individual 
> from each neutron project participate in the neutron-stable-maint team (whose 
> admin rights I think are held by Ihar as neutron member), for those of whom 
> have actually an interest in reviewing stable patches :)
>

Having a member in the current group will help, if you are comfortable
with adding a new member to the current group that would be great.

The reason why I was leaning towards having another group is because
of scope limitation. Members of the ``neutron-stable-maint`` group can
approve patches for all neutron-related projects stable branches. By
having a separated group, members would only be able to approve things
for a specific project.

The new group would also have the ``neutron-stable-maint`` as a
sub-group to it , so the members of the original group would still
able approve things everywhere.

Anyway, either ideas would help with the original problem, I'm good
with whatever approach people thinks is best.

Cheers,
Lucas

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-ovn] Stable branch maintainers for networking-ovn

[Miguel Angel Ajo Pelayo]

If we could have one member from networking-ovn on the neutron-stable-maint
team that would be great. That means the member would have to be trusted
not to handle neutron-patches when not knowing what he's doing, and of
course, follow the stable guidelines, which are absolutely important. But I
believe everybody takes the role seriously.

If that's not a reasonable solution, then I'd vote for the specific stable
maintainers instead. But we need something to help us handle issues quicker
and at
the same time, in a controlled manner.

Best,
Miguel Ángel.

On Tue, Dec 19, 2017 at 5:48 PM Armando M.  wrote:

> On 19 December 2017 at 08:21, Lucas Alvares Gomes 
> wrote:
>
>> Hi all,
>>
>> Just sending this email to try to understand the model for stable branch
>> maintenance in networking-ovn (potentially other neutron drivers too).
>>
>> Right now, only members of the ``neutron-stable-maint`` gerrit group are
>> able to approve patches for the stable branches; this can cause some delays
>> when fixing things (e.g [0]) because we don't have any member in that group
>> that is also a ``networking-ovn-core`` member. So, sometimes we have to go
>> around and ping people to take a look at the patches and it kinda sucks.
>>
>
> We had a Gerrit dashboard that helped stable reviewers stay on top of
> things [1], but it looks like it doesn't seem to work anymore. My
> suggestion would be to look into that as the lack of visibility might be
> the source of the recent delay.
>
> [1]
> https://docs.openstack.org/neutron/latest/contributor/dashboards/index.html#gerrit-dashboards
>
>
>> Is there any reason why things are set up in that way ?
>>
>> I was wondering if it would make sense to create a new group to help
>> maintaining the stable branches in networking-ovn. The new group could
>> include some of the core members willing to do the work +
>> ``neutron-stable-maint`` as a subgroup. Is that reasonable, what you think
>> about it?
>>
>
> Rather than create yet another group(s), it makes sense to have an
> individual from each neutron project participate in the
> neutron-stable-maint team (whose admin rights I think are held by Ihar as
> neutron member), for those of whom have actually an interest in reviewing
> stable patches :)
>
> HTH
> Armando
>
>
>> [0] https://review.openstack.org/#/c/523623/
>>
>> Cheers,
>> Lucas
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ceilometer] the cpu util

[Jaze Lee]

Hello,
   We use ceilometer newton, and also master calculates cpu same as newton.
   It is in 
https://github.com/openstack/ceilometer/blob/master/ceilometer/compute/virt/libvirt/inspector.py#L183

   I test with a two vcpu vm, and find using this method as line 183
we can not get cpu util 100, always 50 or 52.

The test script is here(run on compute node, and there is only one vm)
#!/bin/bash

cpu_time_begin=`virsh  domstats --cpu-total | grep cpu.time| awk -F
'=' '{print $2}'`
sleep 1
cpu_time_end=`virsh  domstats --cpu-total | grep cpu.time| awk -F '='
'{print $2}'`

cpu_util=$(((cpu_time_end - cpu_time_begin) * 100 / 10**9))
echo "cpu util is ", $cpu_util

The output will be 100 or 101, if we divide cpu_util with core number,
then we definitely get 50. But in the vm we watch with top and find
all core is 99%.

Can someone tell me why we only use cpu_time here? May be we should
add cpu.user and cpu.system? It is insane only get 50% when the vm is
totally 100%

Thanks a lot guys...




-- 
谦谦君子

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev