[openstack-dev] [QA] Meeting Thursday Feb 22nd at 8:00 UTC

[Ghanshyam Mann]

Hello everyone,

Hope everyone is back from vacation. QA team is resuming the regular
weekly meeting from today. OpenStack QA team IRC meeting will be
Thursday, Feb 22nd at 8:00 UTC in the #openstack-meeting channel.

The agenda for the meeting can be found here:
 
https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Agenda_for_Feb_22nd_2018_.280800_UTC.29

Anyone is welcome to add an item to the agenda.

-gmann

__
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] [PTL][SIG][PTG]Team Photos

[Jeffrey Zhang]

Kendall,

I added the Kolla Team to 10:20-10:30 on Thursday

On Thu, Feb 22, 2018 at 7:48 AM, Kendall Nelson 
wrote:

> Hello Everyone!
>
> I just wanted to remind you all that you have till *Monday Feburary 26th*
> to sign up if your team or group is interested in a team photo on the Croke
> Park pitch! We still have slots available Tuesday afternoon and Thursday
> morning.
>
> -Kendall (diablo_rojo)
>
> On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson 
> wrote:
>
>> This link might work better for everyone:
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoT
>> ypX66eNURsopQY/edit?usp=sharing
>>
>> -Kendall (diablo_rojo)
>>
>>
>> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
>> wrote:
>>
>>> Hello PTLs and SIG Chairs!
>>>
>>> So here's the deal, we have 50 spots that are first come, first
>>> served. We have slots available before and after lunch both Tuesday and
>>> Thursday.
>>>
>>> The google sheet here[1] should be set up so you have access to edit,
>>> but if you can't for some reason just reply directly to me and I can add
>>> your team to the list (I need team/sig name and contact email).
>>>
>>> I will be locking the google sheet on *Monday February 26th so I need
>>> to know if your team is interested by then. *
>>>
>>> See you soon!
>>>
>>> - Kendall Nelson (diablo_rojo)
>>>
>>> [1] https://docs.google.com/spreadsheets/d/
>>> 1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>>
>>>
>>>
>>>
> __
> 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
>
>


-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
__
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] [all][release] "why do I have new tags for old versions?"

[Doug Hellmann]

The release team is doing some housekeeping work in openstack/releases
and in the course of that work we modified the deliverable files
for some very old series. Including all the way back to Austin.

Because those files changed, the tag-releases job ran. And because,
apparently, some of the very very old tags had never been imported
into git, they were added today based on the SHAs we had established
when we first imported the history into the repository. So, if you
notice very old tags like "2010.1" showing up in places, that's why.

Our shiny and modern build machinery doesn't work with the state
of those repos from that long ago, so aside from the tags we don't
think anything else was rebuilt (no build artifacts on tarballs.o.o
were changed, for example).

Doug

__
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] Vancouver Community Contrbutor Awards

[Kendall Nelson]

Hello Everyone :)

While its still a few months away from the Vancouver Summit, I'd like to
kickoff another round of Community Contributor Awards early to allow more
time for submissions.

The idea is to give recognition to those that are undervalued, don't know
their are appreciated, bind the community together, keep things fun, or
challenge some norm. It can be someone that does a dirty job no one wants
to do, someone that steps up into an new role, or someone that is new to
the community but giving it their all. Basically nominate anyone you think
deserves an award :) [1]

There are A LOT of people out there that could use a pat on the back and
affirmation that they do good work for the community.

Please submit your nominations by
*May 14th. *

Winners will be announced at the feedback session in Vancouver.

-Kendall Nelson (diablo_rojo)

[1]
https://openstackfoundation.formstack.com/forms/cca_nominations_vancouver
__
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] [PTL][SIG][PTG]Team Photos

[Kendall Nelson]

Hello Everyone!

I just wanted to remind you all that you have till *Monday Feburary 26th*
to sign up if your team or group is interested in a team photo on the Croke
Park pitch! We still have slots available Tuesday afternoon and Thursday
morning.

-Kendall (diablo_rojo)

On Thu, Feb 8, 2018 at 10:21 AM Kendall Nelson 
wrote:

> This link might work better for everyone:
>
> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>
> -Kendall (diablo_rojo)
>
>
> On Wed, Feb 7, 2018 at 9:15 PM Kendall Nelson 
> wrote:
>
>> Hello PTLs and SIG Chairs!
>>
>> So here's the deal, we have 50 spots that are first come, first
>> served. We have slots available before and after lunch both Tuesday and
>> Thursday.
>>
>> The google sheet here[1] should be set up so you have access to edit, but
>> if you can't for some reason just reply directly to me and I can add your
>> team to the list (I need team/sig name and contact email).
>>
>> I will be locking the google sheet on *Monday February 26th so I need to
>> know if your team is interested by then. *
>>
>> See you soon!
>>
>> - Kendall Nelson (diablo_rojo)
>>
>> [1]
>> https://docs.google.com/spreadsheets/d/1J2MRdVQzSyakz9HgTHfwYPe49PaoTypX66eNURsopQY/edit?usp=sharing
>>
>>
>>
>>
>>
__
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] [libvrit] Can QEMU or LIBVIRT know VM is powering-off

[Chris Friesen]

On 02/21/2018 03:19 PM, Kwan, Louie wrote:

When turning off a VM by doing nova stop,  the Status and Task State is there
for Nova. But can Libvirt / qemu programmatically figure out the ‘Task State’
that the VM is trying to powering-off ?.

For libvirt, it seems only know the “Power State”? Anyway to read the
“powering-off” info?


The fact that you have asked nova to power off the instance means nothing to 
libvirt/qemu.


In the "nova stop" case nova will do some housekeeping stuff, optionally tell 
libvirt to shutdown the domain cleanly, then tell libvirt to destroy the domain, 
then do more housekeeping stuff.


Chris


__
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] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Tony Breeds]

On Wed, Feb 21, 2018 at 08:53:09PM +0100, Alfredo Moralejo Alonso wrote:
 
> Short version is:
> 
> 1. We generate a review to rdoinfo (RDO's package database) every time a
> change is detected in upper-constraints.txt proposing it as candidate in
> dependencies repo.
> 2. A job in rdoinfo gate detects if the required version is available in
> fedora. If so, it tries to rebuild it for CentOS and add it to CentOS
> dependencies repo. If the version is not available in fedora or can not be
> rebuilt for CentOS, the review fails in gate and a manual action is
> required.
> 3. If the dependency can be rebuilt from fedora, a change is proposed to
> promote it to the testing phase (the one used in upstream gate jobs for
> master). A set of jobs deploying OpenStack with packstack,
> puppet-openstack-integration and tripleo are executed to gate the
> dependency update. When the review is merged, the new or updated dependency
> is pushed to the RDO repo.

See it was just my lack of imagination.  I guess I was getting hung up
on step 2 but the fall back to manual action is pretty reasonable there.
It'll be interesting to see how often that happens, and also what
happens in the scenario where the RDO package has diverged slightly from
Fedora.
 
> If you are interested i can discuss the implementation details.

Yeah I'd very much like to grab 10-15 mins of your time next week, if
you're cool with that.

Yours Tony.


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] [PTG] StoryBoard Discussion Planning

[Kendall Nelson]

Hello Everyone!

We have tentatively scheduled StoryBoard discussions Wednesday morning and
will officialize it in the PTGbot soon. If there are specific things you
wish to discuss please add them to our planning etherpad[1]! If you think
you might attend, please also add your name to the list so we know you're
interested.

See you all next week!

-Kendall (diablo_rojo)

[1] https://etherpad.openstack.org/p/StoryBoard-Rocky-PTG
__
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] [k8s] SIG-K8s Scheduling for Dublin PTG

[Chris Hoge]

SIG-K8s has a planning etherpad available for the Dublin PTG. We have
space scheduled for Tuesday, with approximately eight forty-minute work
blocks. For the K8s on OpenStack side of things, we've identified a core
set of priorities that we'll be working on that day, including:

* Moving openstack-cloud-controller-manager into OpenStack git repo.
* Enabling and improving testing across multiple platforms.
* Identifying documentation gaps.

Some of these items have some collaboration points with the Infra and
QA teams. If members of those teams could help us identify when they
would be available to work on repository creation and enabling testing,
that would help us to schedule the appropriate times for those topics.

The work of the SIG-K8s groups also covers other Kubernetes and OpenStack
integrations, including deploying OpenStack on top of Kubernetes. If
anyone from the Kolla, OpenStack-Helm, Loci, Magnum, Kuryr, or Zun
teams would like to schedule cross-project work sessions, please add your
requests and preferred times to the planning etherpad. Additionally, I
can be available to attend work sessions for any of those projects.

https://etherpad.openstack.org/p/sig-k8s-2018-dublin-ptg

Thanks!
Chris


__
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] [release][ptl] Final Queens RC Deadline

[Sean McGinnis]

February!! I meant February!!

Gaah!

On Feb 21 2018, at 2:36 pm, Sean McGinnis  wrote:
> One more reminder that tomorrow, *March* 22, is the deadline for any 
> additional
> RCs. There are a few repos that have merged commits, so if you are one of 
> those
> and plan on having those changes as part of Queens, please propose a new RC
> release within ~24 hours.
>
> This is also the final release deadline for cycle-with-intermediary projects.
>
> Sean
>
> On Mon, Feb 19, 2018 at 11:50:21AM -0500, David Moreau Simard wrote:
> > On Mon, Feb 19, 2018 at 10:44 AM, Sean McGinnis  
> > wrote:
> > > Hey everyone,
> > >
> > > Just a quick reminder that Thursday, 22 March, is the deadline for any 
> > > final
> > > Queens release candidates. After this point we will enter a quiet period 
> > > for a
> > > week in preparation of tagging the final Queens release during the PTG 
> > > week.
> >
> > February, right ?
> >
> > David Moreau Simard
> > Senior Software Engineer | OpenStack RDO
> >
> > dmsimard = [irc, github, twitter]
> >
> > __
> > 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] [cinder] cinder 12.0.0.0rc2 (queens)

[no-reply]

Hello everyone,

A new release candidate for cinder for the end of the Queens
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/cinder/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Queens release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/queens release
branch at:

http://git.openstack.org/cgit/openstack/cinder/log/?h=stable/queens

Release notes for cinder can be found at:

http://docs.openstack.org/releasenotes/cinder/




__
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] [libvrit] Can QEMU or LIBVIRT know VM is powering-off

[Kwan, Louie]

When turning off a VM by doing nova stop,  the Status and Task State is there 
for Nova. But can Libvirt / qemu programmatically figure out the 'Task State' 
that the VM is trying to powering-off ?.



For libvirt, it seems only know the "Power State"? Anyway to read the 
"powering-off" info?





+--+--++--+-++



| ID   | Name | Status | Task State   | Power 
State | Networks   |



+--+--++--+-++



| 09d65498-b1fe-4a99-9f43-4c365a79ff36 | c1   | ACTIVE | -| Running 
| public=172.24.4.6, 2001:db8::3 |



| 565da9ba-3c0c-4087-83ca-32a5a1b00a55 | iim1 | ACTIVE | powering-off | Running 
| public=172.24.4.5, 2001:db8::7 |



+--+--++--+-++



+--+--+-++-++



| ID   | Name | Status  | Task State | Power 
State | Networks   |



+--+--+-++-++



| 09d65498-b1fe-4a99-9f43-4c365a79ff36 | c1   | ACTIVE  | -  | Running  
   | public=172.24.4.6, 2001:db8::3 |



| 565da9ba-3c0c-4087-83ca-32a5a1b00a55 | iim1 | SHUTOFF | -  | Shutdown 
   | public=172.24.4.5, 2001:db8::7 |







Thanks.



Louie
__
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] Contrail VIF TAP plugging broken

[Matt Riedemann]

On 2/21/2018 4:30 AM, Édouard Thuleau wrote:

Hi Seán, Michael,

Since patch [1] moved Contrail VIF plugging under privsep, Nova fails to 
plug TAP on the Contrail software switch (named vrouter) [2]. I proposed 
a fix in the beginning of the year [3] but it still pending approval 
even it got a couple of +1 and no negative feedback. It's why I'm 
writing that email to get your attention.
That issue appeared during the Queens development cycle and we need to 
fix that before it was released (hope we are not to late).
Contrail already started to move on os-vif driver [4]. A first VIF type 
driver is there for DPDK case [5], we plan to do the same for the TAP 
case in the R release and remove the Nova VIF plugging code for the vrouter.


[1] https://review.openstack.org/#/c/515916/
[2] https://bugs.launchpad.net/nova/+bug/1742963
[3] https://review.openstack.org/#/c/533212/
[4] https://github.com/Juniper/contrail-nova-vif-driver
[5] https://review.openstack.org/#/c/441183/

Regards,
Édouard.


__
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



Approved the change on master and working on the backport to 
stable/queens. We'll be cutting an RC3 tomorrow so I'll make sure this 
gets into that.


--

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] [k8s] SIG-K8s Scheduling for Dublin PTG

[Andrea Frittoli]

On Wed, Feb 21, 2018 at 7:41 PM Chris Hoge  wrote:

> SIG-K8s has a planning etherpad available for the Dublin PTG. We have
> space scheduled for Tuesday, with approximately eight forty-minute work
> blocks. For the K8s on OpenStack side of things, we've identified a core
> set of priorities that we'll be working on that day, including:
>
> * Moving openstack-cloud-controller-manager into OpenStack git repo.
> * Enabling and improving testing across multiple platforms.
> * Identifying documentation gaps.
>
> Some of these items have some collaboration points with the Infra and
> QA teams. If members of those teams could help us identify when they
> would be available to work on repository creation and enabling testing,
> that would help us to schedule the appropriate times for those topics.
>

I'm interested in participating. It's a bit unfortunate that Tuesday
overlaps with
the QA/infra help room, but as long as the current discussion is published
via PTG bot I should be able to switch rooms when needed.

Andrea Frittoli (andreaf)


>
> The work of the SIG-K8s groups also covers other Kubernetes and OpenStack
> integrations, including deploying OpenStack on top of Kubernetes. If
> anyone from the Kolla, OpenStack-Helm, Loci, Magnum, Kuryr, or Zun
> teams would like to schedule cross-project work sessions, please add your
> requests and preferred times to the planning etherpad. Additionally, I
> can be available to attend work sessions for any of those projects.
>
> https://etherpad.openstack.org/p/sig-k8s-2018-dublin-ptg
>
> Thanks!
> Chris
>
>
> __
> 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] [heat] heat-dashboard is non-free, with broken unit test env

[Thomas Goirand]

On 02/21/2018 05:54 PM, Corey Bryant wrote:
> 
> 
> On Wed, Feb 21, 2018 at 9:35 AM, Thomas Goirand  > wrote:
> 
> Hi there!
> 
> I'm having big trouble package heat-dashboard for Debian. I hope I can
> get help through this list.
> 
> In here:
> 
> 
> heat_dashboard/static/dashboard/project/heat_dashboard/template_generator/js/
> 
> we have minified *only* versions of Javascript.
> 
> 
> There's also a bug open for this:
> https://bugs.launchpad.net/heat-dashboard/+bug/1747687
> 
> Regards,
> Corey

Thanks for the link and filing this bug.

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-dev] [nova] queens retrospective etherpad

[melanie witt]

Greetings Stackers,

FYI we also have a retrospective etherpad [1] for Queens which we’ll cover at 
the PTG on Wednesday at 9:00 - 10:00 AM.

Please add your thoughts to the etherpad on what you think went well in Queens 
and what you think could use some improvement going forward into the Rocky 
cycle, so we can discuss them and identify actionable things we can do to make 
things better in Rocky.

Thanks,
-melanie

[1] https://etherpad.openstack.org/p/nova-queens-retrospective
__
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] [release][ptl] Final Queens RC Deadline

[Sean McGinnis]

One more reminder that tomorrow, *March* 22, is the deadline for any additional
RCs. There are a few repos that have merged commits, so if you are one of those
and plan on having those changes as part of Queens, please propose a new RC
release within ~24 hours.

This is also the final release deadline for cycle-with-intermediary projects.

Sean

On Mon, Feb 19, 2018 at 11:50:21AM -0500, David Moreau Simard wrote:
> On Mon, Feb 19, 2018 at 10:44 AM, Sean McGinnis  wrote:
> > Hey everyone,
> >
> > Just a quick reminder that Thursday, 22 March, is the deadline for any final
> > Queens release candidates. After this point we will enter a quiet period 
> > for a
> > week in preparation of tagging the final Queens release during the PTG week.
> 
> February, right ?
> 
> David Moreau Simard
> Senior Software Engineer | OpenStack RDO
> 
> dmsimard = [irc, github, twitter]
> 
> __
> 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] [docs] About the convention to use '.' instead of 'source'.

[Petr Kovar]

On Sun, 18 Feb 2018 15:44:04 -0500
Doug Hellmann  wrote:

> Excerpts from Jeremy Stanley's message of 2018-02-18 16:01:52 +:
> > On 2018-02-18 03:55:51 -0600 (-0600), Monty Taylor wrote:
> > [...]
> > > I'd honestly argue in favor of assuming bash and using 'source'
> > > because it's more readable. We don't make allowances for alternate
> > > shells in our examples anyway.
> > > 
> > > I personally try to use 'source' vs . and $() vs. `` as
> > > aggressively as I can.
> > > 
> > > That said - I completely agree with fungi on the description of
> > > the tradeoffs of each direction, and I do think it's valuable to
> > > pick one for the docs.
> > 
> > Yes, it's not my call but I too would prefer more readable examples
> > over a strict adherence to POSIX. As long as we say somewhere that
> > our examples assume the user is in a GNU bash(1) environment and
> > that the examples may require minor adjustment for other shells, I
> > think that's a perfectly reasonable approach. If there's a
> > documentation style guide, that too would be a great place to
> > encourage examples following certain conventions such as source
> > instead of ., $() instead of ``, [] instead of test, an so on... and
> > provide a place to explain the rationale so that reviewers have a
> > convenient response they can link for bulk "improvements" which seem
> > to indicate ignorance of our reasons for these choices.
> 
> I've proposed reverting the style-guide change that seems to have led to
> this discussion in https://review.openstack.org/#/c/545718/2

FYI, we've just approved this.
 
Thanks,
pk

__
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] [yaql] [tripleo] Backward incompatible change in YAQL minor version

[Alfredo Moralejo Alonso]

On Tue, Feb 20, 2018 at 12:24 AM, Tony Breeds 
wrote:

> On Mon, Feb 19, 2018 at 06:10:56PM +0100, Alfredo Moralejo Alonso wrote:
>
> > Recently, we have added a job in post pipeline for openstack/requirements
> > in https://review.rdoproject.org to
> > automatically post updates in RDO dependencies repo when changes are
> > detected in upper-constraints. This
> > job will try to automatically update the dependencies when possible or
> > notify to take required manual actions
> > in some cases.
> >
> > I expect this will improve dependencies management in RDO in next
> releases.
>
> That's cool.  Can you point me at how that's done?  I'm not sure how
> you'd automate the builds but that's probably just lack of imagination
> on my part ;P
>
>
My fault for not having the documentation ready yet, I will share when
ready.

Short version is:

1. We generate a review to rdoinfo (RDO's package database) every time a
change is detected in upper-constraints.txt proposing it as candidate in
dependencies repo.
2. A job in rdoinfo gate detects if the required version is available in
fedora. If so, it tries to rebuild it for CentOS and add it to CentOS
dependencies repo. If the version is not available in fedora or can not be
rebuilt for CentOS, the review fails in gate and a manual action is
required.
3. If the dependency can be rebuilt from fedora, a change is proposed to
promote it to the testing phase (the one used in upstream gate jobs for
master). A set of jobs deploying OpenStack with packstack,
puppet-openstack-integration and tripleo are executed to gate the
dependency update. When the review is merged, the new or updated dependency
is pushed to the RDO repo.

If you are interested i can discuss the implementation details.

Best regards,

Alfredo


> Yours Tony.
>
> __
> 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] [Neutron] Queens retrospective

[Miguel Lavalle]

Hi Neutrinos and broader OpenStack community,

I have started an etherpad to collect your thoughts on the retrospective
for the Queens cycle:
https://etherpad.openstack.org/p/neutron-queens-retrospective. Everyone is
welcome to provide feedback so we can improve our contribution to the
community in the future. The retrospective session is scheduled for
Wednesday 28th from 9 to 10

Looking forward to see you all in Dublin

Safe travels

Miguel
__
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] [heat] heat-dashboard is non-free, with broken unit test env

[Akihiro Motoki]

2018-02-21 23:35 GMT+09:00 Thomas Goirand :
> Hi there!
>
> I'm having big trouble package heat-dashboard for Debian. I hope I can
> get help through this list.
>
> In here:
>
> heat_dashboard/static/dashboard/project/heat_dashboard/template_generator/js/
>
> we have minified *only* versions of Javascript.
>
> 1/ Why is there only minified versions? That's non-free to me, Debian,
> and probably any other distro caring about OpenStack.
> 2/ Why do we even have a folder called "vendors"? Doesn't this sound
> really a bad practice?
> 3/ Why is there so many angular-*.min.js files? Do we need them all?
> 4/ Why isn't the package using xstatic-angular and friends?

IIUC, these javascript files are only used by the template generator
which was newly added after split out from horizon.
If you can provide only the Pike-compatible feature from, horizon,
code related to the template generator can be excluded.
I know it is not ideal and am not sure this is acceptable workaround.

Horizon docs contains a guideline on javascript and it discourages
embedded JS files.
https://docs.openstack.org/horizon/latest/contributor/topics/packaging.html
heat-dashboard choice does not look the right way.

Akihiro

>
> As it stands, I can't upload heat-dashboard to Debian for Queens, and
> it's been removed from Horizon... :(
>
> Oh, and I almost forgot! When running unit tests, I get:
>
> PYTHON=python$i NOSE_WITH_OPENSTACK=1 \
> NOSE_OPENSTACK_COLOR=1 \
> NOSE_OPENSTACK_RED=0.05 \
> NOSE_OPENSTACK_YELLOW=0.025 \
> NOSE_OPENSTACK_SHOW_ELAPSED=1 \
> DJANGO_SETTINGS_MODULE=heat_dashboard.test.settings \
> python$i
> /home/zigo/sources/openstack/queens/services/heat-dashboard/build-area/heat-dashboard-1.0.2/manage.py
> test heat_dashboard.test --settings=heat_dashboard.test.settings
>
> No local_settings file found.
> Traceback (most recent call last):
>   File
> "/home/zigo/sources/openstack/queens/services/heat-dashboard/build-area/heat-dashboard-1.0.2/manage.py",
> line 23, in 
> execute_from_command_line(sys.argv)
>
> [ ... some stack dump ...]
>
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 147, in acquire
> self._do_open()
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 119, in _do_open
> self.lockfile = open(self.path, 'a')
> PermissionError: [Errno 13] Permission denied:
> '/usr/lib/python3/dist-packages/openstack_dashboard/local/_usr_lib_python3_dist-packages_openstack_dashboard_local_.secret_key_store.lock'
>
> What thing is attempting to write in my read only /usr, while Horizon is
> correctly installed, and writing its secret key material as it should,
> in /var/lib/openstack-dashboard? It's probably due to me, but here, how
> can I make heat-dashboard unit test behave during package build? What's
> this "No local_settings file found" thing? Other dashboards didn't
> complain in this way...
>
> 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

[openstack-dev] [Neutron] Weekly IRC meeting canceled on February 27th

[Miguel Lavalle]

Dear Neutrinos,

Due to the PTG in Dublin, we will cancel our weekly meeting on Tuesday
February 27th. We will resume them normally on March 5th 2100 UTC

Safe travels

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

[openstack-dev] [Neutron][Drivers] Weekly IRC meeting cancelled on February 22nd and March 2nd

[Miguel Lavalle]

Dear Neutron Drivers,

Due to the PTG next week and the involved traveling to get to Dublin, we
will cancel our weekly meetings on February 22nd and March 2nd. We will
resume our meetings normally on March 8th at 2200UTC.

Safe travels

Miguel
__
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] [heat] heat-dashboard is non-free, with broken unit test env

[Corey Bryant]

On Wed, Feb 21, 2018 at 9:35 AM, Thomas Goirand  wrote:

> Hi there!
>
> I'm having big trouble package heat-dashboard for Debian. I hope I can
> get help through this list.
>
> In here:
>
> heat_dashboard/static/dashboard/project/heat_dashboard/template_generator/
> js/
>
> we have minified *only* versions of Javascript.
>
>
There's also a bug open for this:
https://bugs.launchpad.net/heat-dashboard/+bug/1747687

Regards,
Corey


> 1/ Why is there only minified versions? That's non-free to me, Debian,
> and probably any other distro caring about OpenStack.
> 2/ Why do we even have a folder called "vendors"? Doesn't this sound
> really a bad practice?
> 3/ Why is there so many angular-*.min.js files? Do we need them all?
> 4/ Why isn't the package using xstatic-angular and friends?
>
> As it stands, I can't upload heat-dashboard to Debian for Queens, and
> it's been removed from Horizon... :(
>
> Oh, and I almost forgot! When running unit tests, I get:
>
> PYTHON=python$i NOSE_WITH_OPENSTACK=1 \
> NOSE_OPENSTACK_COLOR=1 \
> NOSE_OPENSTACK_RED=0.05 \
> NOSE_OPENSTACK_YELLOW=0.025 \
> NOSE_OPENSTACK_SHOW_ELAPSED=1 \
> DJANGO_SETTINGS_MODULE=heat_dashboard.test.settings \
> python$i
> /home/zigo/sources/openstack/queens/services/heat-
> dashboard/build-area/heat-dashboard-1.0.2/manage.py
> test heat_dashboard.test --settings=heat_dashboard.test.settings
>
> No local_settings file found.
> Traceback (most recent call last):
>   File
> "/home/zigo/sources/openstack/queens/services/heat-
> dashboard/build-area/heat-dashboard-1.0.2/manage.py",
> line 23, in 
> execute_from_command_line(sys.argv)
>
> [ ... some stack dump ...]
>
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 147, in acquire
> self._do_open()
>   File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
> 119, in _do_open
> self.lockfile = open(self.path, 'a')
> PermissionError: [Errno 13] Permission denied:
> '/usr/lib/python3/dist-packages/openstack_dashboard/
> local/_usr_lib_python3_dist-packages_openstack_dashboard_
> local_.secret_key_store.lock'
>
> What thing is attempting to write in my read only /usr, while Horizon is
> correctly installed, and writing its secret key material as it should,
> in /var/lib/openstack-dashboard? It's probably due to me, but here, how
> can I make heat-dashboard unit test behave during package build? What's
> this "No local_settings file found" thing? Other dashboards didn't
> complain in this way...
>
> 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

[openstack-dev] [Neutron][L3-subteam] Weekly IRC meeting cancelled on February 22nd and March 1st

[Miguel Lavalle]

Dear L3 sub-team members,

Due to the PTG next week and the involved traveling to get to Dublin, we
will cancel our weekly meetings on February 22nd and March 1st. We will
resume our meetings normally on March 8th at 1500UTC.

Safe travels

Miguel
__
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] [docs] Documentation meeting minutes for 2018-02-21

[Petr Kovar]

===
#openstack-doc: docteam
===


Meeting started by pkovar at 16:01:11 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/docteam/2018/docteam.2018-02-21-16.01.log.html
.



Meeting summary
---

* Rocky PTG  (pkovar, 16:05:12)
  * Planning etherpad for docs+i18n available  (pkovar, 16:05:17)
  * LINK: https://etherpad.openstack.org/p/docs-i18n-ptg-rocky  (pkovar,
16:05:23)
  * Sign up and tell us your ideas on what to discuss in the docs room
(pkovar, 16:05:28)
  * pkovar planning on organizing project docs helproom at the ptg, will
send a separate email about it  (pkovar, 16:06:23)
  * similarly to last year, the help room days to correlate with project
days to allow project teams to work with docs people  (pkovar,
16:07:08)

* Vancouver Summit  (pkovar, 16:09:04)
  * Looking to have a shared 10+10 mins project update slot with i18n
(pkovar, 16:09:09)
  * Looking for interested (co-)speakers  (pkovar, 16:09:15)

* Bug Triage Team  (pkovar, 16:11:28)
  * you can help the docs team with bug triaging by signing up  (pkovar,
16:12:30)
  * LINK: https://wiki.openstack.org/wiki/Documentation/SpecialityTeams
(pkovar, 16:12:38)

* Open discussion  (pkovar, 16:13:18)
  * see you at the ptg next week!  (pkovar, 16:13:32)



Meeting ended at 16:20:26 UTC.



People present (lines said)
---

* pkovar (20)
* openstack (3)
* openstackgerrit (1)



Generated by `MeetBot`_ 0.1.4


__
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] [QA][all] Migration of Tempest / Grenade jobs to Zuul v3 native

[Michael Johnson]

FYI, Octavia has started to use the new devstack-tempest parent here:
https://review.openstack.org/#/c/543034/17/zuul.d/jobs.yaml
There is a lot of work still left to do on our tempest-plugin but we
are making progress.

Thanks for the communication out!

Michael


On Tue, Feb 20, 2018 at 1:22 PM, Andrea Frittoli
 wrote:
> Dear all,
>
> updates:
>
> - host/group vars: zuul now supports declaring host and group vars in the
> job definition [0][1] - thanks corvus and infra team!
>   This is a great help towards writing the devstack and tempest base
> multinode jobs [2][3]
>   * NOTE: zuul merges dict variables through job inheritance. Variables in
> host/group_vars override global ones. I will write some examples further
> clarify this.
>
> - stable/pike: devstack ansible changes have been backported to stable/pike,
> so we can now run zuulv3 jobs against stable/pike too - thank you tosky!
>   next change in progress related to pike is to provide tempest-full-pike
> for branchless repositories [4]
>
> - documentation: devstack now publishes documentation on its ansible roles
> [5].
>   More devstack documentation patches are in progress to provide jobs
> reference, examples and a job migration how-to [6].
>
>
> Andrea Frittoli (andreaf)
>
> [0]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.host_vars
> [1]
> https://docs.openstack.org/infra/zuul/user/config.html#attr-job.group_vars
> [2] https://review.openstack.org/#/c/545696/
> [3] https://review.openstack.org/#/c/545724/
> [4] https://review.openstack.org/#/c/546196/
> [5] https://docs.openstack.org/devstack/latest/roles.html
> [6] https://review.openstack.org/#/c/545992/
>
>
> On Mon, Feb 19, 2018 at 2:46 PM Andrea Frittoli 
> wrote:
>>
>> Dear all,
>>
>> updates:
>> - tempest-full-queens and tempest-full-py3-queens are now available for
>> testing of branchless repositories [0]. They are used for tempest and
>> devstack-gate. If you own a tempest plugin in a branchless repo, you may
>> consider adding similar jobs to your plugin if you use it for tests on
>> stable/queen as well.
>> - if you have migrated jobs based on devstack-tempest please let me know,
>> I'm building reference docs and I'd like to include as many examples as
>> possible
>> - work on multi-node is in progress, but not ready still - you can follow
>> the patches in the multinode branch [1]
>> - updates on some of the points from my previous email are inline below
>>
>> Andrea Frittoli (andreaf)
>>
>> [0] http://git.openstack.org/cgit/openstack/tempest/tree/.zuul.yaml#n73
>> [1]
>> https://review.openstack.org/#/q/status:open++branch:master+topic:multinode
>>
>>
>> On Thu, Feb 15, 2018 at 11:31 PM Andrea Frittoli
>>  wrote:
>>>
>>> Dear all,
>>>
>>> this is the first or a series of ~regular updates on the migration of
>>> Tempest / Grenade jobs to  Zuul v3 native.
>>>
>>> The QA team together with the infra team are working on providing the
>>> OpenStack community with a set of base Tempest / Grenade jobs that can be
>>> used as a basis to write new CI jobs / migrate existing legacy ones with a
>>> minimal effort and very little or no Ansible knowledge as a precondition.
>>>
>>> The effort is tracked in an etherpad [0]; I'm trying to keep the etherpad
>>> up to date but it may not always be a source of truth.
>>>
>>> Useful jobs available so far:
>>> - devstack-tempest [0] is a simple tempest/devstack job that runs
>>> keystone glance nova cinder neutron swift and tempest *smoke* filter
>>> - tempest-full [1] is similar but runs a full test run - it replaces the
>>> legacy tempest-dsvm-neutron-full from the integrated gate
>>> - tempest-full-py3 [2] runs a full test run on python3 - it replaces the
>>> legacy tempest-dsvm-py35
>>
>>
>> Some more details on this topic: what I did not mention in my previous
>> email is that the autogenerated Tempest / Grenade CI jobs (legacy-*
>> playbooks) are not meant to be used as a basis for Zuul V3 native jobs. To
>> create Zuul V3 Tempest / Grenade native jobs for your projects you need to
>> through away the legacy playbooks and defined new jobs in .zuul.yaml, as
>> documented in the zuul v3 docs [2].
>> The parent job for a single node Tempest job will usually be
>> devstack-tempest. Example migrated jobs are avilable, for instance: [3] [4].
>>
>> [2]
>> https://docs.openstack.org/infra/manual/zuulv3.html#howto-update-legacy-jobs
>> [3]
>> http://git.openstack.org/cgit/openstack/sahara-tests/tree/.zuul.yaml#n21
>> [4] https://review.openstack.org/#/c/543048/5
>>
>>>
>>>
>>> Both tempest-full and tempest-full-py3 are part of integrated-gate
>>> templates, starting from stable/queens on.
>>> The other stable branches still run the legacy jobs, since devstack
>>> ansible changes have not been backported (yet). If we do backport it will be
>>> up to pike maximum.
>>>
>>> Those jobs work in single node mode only at the moment. Enabling
>>> multinode 

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

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

Hi Paul,

I suggest that you do the following:

· Add a LOG message at the end of _get_alarms to print all alarms that 
are returned by this function

· Restart vitrage-graph and send me its log. I’d like to see if there 
is any difference between the alarm that is raised and the alarm that is 
deleted.

Thanks,
Ifat.

From: Paul Vaduva 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 21 February 2018 at 16:30
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: Ciprian Barbu 
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

I attached also the driver.py that I am using.

From: Paul Vaduva [mailto:paul.vad...@enea.com]
Sent: Wednesday, February 21, 2018 3:22 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Ciprian Barbu 
Subject: [Attachment removed] Re: [openstack-dev] [vitrage] Vitrage alarm 
processing behavior

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Cc: Ciprian Barbu >
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 

Re: [openstack-dev] [ptg] Lightning talks

[Mike Perez]

I would like to extend the deadline for Lightning Talks at the PTG to February
23rd 23:59 UTC to fill in the few more slots we have available. Details quoted
below, thanks!

-- 
Mike Perez (thingee)

On 02:36 Feb 13, Mike Perez wrote:
> On 11:25 Feb 08, Mike Perez wrote:
> > Hey all!
> > 
> > I'm looking for six 5-minute lightning talks for the PTG in Dublin. This 
> > will
> > be on Friday March 2nd at 13:00-13:30 local time.
> > 
> > Appropriate 5 minute talk examples:
> > * Neat features in libraries like oslo that we should consider adopting in 
> > our
> >   community wide goals.
> > * Features and tricks in your favorite editor that makes doing work easier.
> > * Infra tools that maybe not a lot of people know about yet. Zuul v3 
> > explained
> >   in five minutes anyone?
> > * Some potential API specification from the API SIG that we should adopt as
> >   a community wide goal.
> > 
> > Please email me DIRECTLY the following information:
> > 
> > Title:
> > Speaker(s) full name:
> > Abstract:
> > Link to presentation or attachment if you have it already. Laptop on stage 
> > will
> > be loaded with your presentation already. I'll have open office available so
> > odp, odg, otp, pdf, limited ppt format support.


pgpruIXfUoXrO.pgp
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

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Sorry forgot to add you.

From: Paul Vaduva
Sent: Wednesday, February 21, 2018 4:31 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Ciprian Barbu 
Subject: RE: [openstack-dev] [vitrage] Vitrage alarm processing behavior

I attached also the driver.py that I am using.

From: Paul Vaduva [mailto:paul.vad...@enea.com]
Sent: Wednesday, February 21, 2018 3:22 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Cc: Ciprian Barbu >
Subject: [Attachment removed] Re: [openstack-dev] [vitrage] Vitrage alarm 
processing behavior

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Cc: Ciprian Barbu >
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume
[2] 

[openstack-dev] [heat] heat-dashboard is non-free, with broken unit test env

[Thomas Goirand]

Hi there!

I'm having big trouble package heat-dashboard for Debian. I hope I can
get help through this list.

In here:

heat_dashboard/static/dashboard/project/heat_dashboard/template_generator/js/

we have minified *only* versions of Javascript.

1/ Why is there only minified versions? That's non-free to me, Debian,
and probably any other distro caring about OpenStack.
2/ Why do we even have a folder called "vendors"? Doesn't this sound
really a bad practice?
3/ Why is there so many angular-*.min.js files? Do we need them all?
4/ Why isn't the package using xstatic-angular and friends?

As it stands, I can't upload heat-dashboard to Debian for Queens, and
it's been removed from Horizon... :(

Oh, and I almost forgot! When running unit tests, I get:

PYTHON=python$i NOSE_WITH_OPENSTACK=1 \
NOSE_OPENSTACK_COLOR=1 \
NOSE_OPENSTACK_RED=0.05 \
NOSE_OPENSTACK_YELLOW=0.025 \
NOSE_OPENSTACK_SHOW_ELAPSED=1 \
DJANGO_SETTINGS_MODULE=heat_dashboard.test.settings \
python$i
/home/zigo/sources/openstack/queens/services/heat-dashboard/build-area/heat-dashboard-1.0.2/manage.py
test heat_dashboard.test --settings=heat_dashboard.test.settings

No local_settings file found.
Traceback (most recent call last):
  File
"/home/zigo/sources/openstack/queens/services/heat-dashboard/build-area/heat-dashboard-1.0.2/manage.py",
line 23, in 
execute_from_command_line(sys.argv)

[ ... some stack dump ...]

  File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
147, in acquire
self._do_open()
  File "/usr/lib/python3/dist-packages/fasteners/process_lock.py", line
119, in _do_open
self.lockfile = open(self.path, 'a')
PermissionError: [Errno 13] Permission denied:
'/usr/lib/python3/dist-packages/openstack_dashboard/local/_usr_lib_python3_dist-packages_openstack_dashboard_local_.secret_key_store.lock'

What thing is attempting to write in my read only /usr, while Horizon is
correctly installed, and writing its secret key material as it should,
in /var/lib/openstack-dashboard? It's probably due to me, but here, how
can I make heat-dashboard unit test behave during package build? What's
this "No local_settings file found" thing? Other dashboards didn't
complain in this way...

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] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

I attached also the driver.py that I am using.

From: Paul Vaduva [mailto:paul.vad...@enea.com]
Sent: Wednesday, February 21, 2018 3:22 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Ciprian Barbu 
Subject: [Attachment removed] Re: [openstack-dev] [vitrage] Vitrage alarm 
processing behavior

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
>
Cc: Ciprian Barbu >
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume
[2] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/zabbix
[3] 

Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

[Paul Vaduva]

Hi Ifat,

Sorry for the late reply.
To answer your questions
I started as an example from the doctor datasource (or a porting of it for the 
1.3.0 version of vitrage) but will call it something different so no need to 
worry about conflicting with present doctor datasource.
I added polling alarms to it but I have a more particular use case:
* I get compute host down alarm on event
* I can't get host up event or it's an intricate sollution to implement

I tried to see if I can make the following scenario work:
Let's call Scenario I
* Get a compute host down event (Raisng an alarm)
* Periodically poll for the status of the compute in method "def 
_get_alarms(self):" of the Driver object
Both type of Interactions seem to work (polling and event based).
However now comes the tricky part. I would need for the alarms (with status up 
/ compute host up) returned by method "def _get_alarms(self):" of this Driver 
object to cancel/clear the compute host down alarms raised by event. This 
unfortunatelly does not happen.

Oddely enough there is a mimic of this scenario that works but is not robust 
enough for out needs.
Let's call Scenario II:
* Gettting an event with compute host down(when one of our compute actually 
goes down)
* Polling alarm (also compute host down) is raised and somehow overwrites the 
event based one (I can see the updated time).
* After a while the actual compute reboots and polling for the alarms returns 
an alarm with status up that in this case clears the previous (I assume polling 
type now) alarm.

Now I can't understand why this second scenario works and the first one does 
not.
It seems as the same alarm type (compute host down with status down) obtained 
by polling can overwrite an identical type and status alarm raised by event, 
but An alarm with an updated status (i. e. up) got by polling mode cannot 
overwrite / clear and alarm with status down got by an event.
I am wondering if there is a reason of this behavior and if there is a way to 
modify it or is it a bug.

For the event's generation I use modified version of zabbix_vitrage.py script 
that publishes to rabbitmq
vitrage_notifications.info queue. I have attached this python script.
The code is still experimental But I wanted to know if it's logically posible 
to create The scenario we need, Scenario I.

Best Regards
Paul

From: Afek, Ifat (Nokia - IL/Kfar Sava) [mailto:ifat.a...@nokia.com]
Sent: Wednesday, February 7, 2018 7:16 PM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: Ciprian Barbu 
Subject: Re: [openstack-dev] [vitrage] Vitrage alarm processing behavior

Hi Paul,

I’m glad that my fix helped.

Regarding the Doctor datasource: the purpose of this datasource was to be used 
by the Doctor test scripts. Do you intend to modify it, or to create a new 
similar datasource that also supports polling? Modifying the existing 
datasource could be problematic, since we need to make sure the existing 
functionality and tests stay the same.

In general, most of our datasources support both polling and notifications. A 
simple example is the Cinder datasource [1]. For example of an alarm 
datasource, you can look at Zabbix datasource [2]. You can also go over the 
documentation of how to add a new datasource [3].

As for your question, it is the responsibility of the datasource to clear the 
alarms that it created. For the Doctor datasource, you can send an event with 
“status”:”up” in the details and the datasource will clear the alarm.

[1] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/cinder/volume
[2] 
https://github.com/openstack/vitrage/tree/master/vitrage/datasources/zabbix
[3] 
https://docs.openstack.org/vitrage/latest/contributor/add-new-datasource.html


Best Regards,
Ifat.


From: Paul Vaduva >

[openstack-dev] [docs] Documentation meeting today

[Petr Kovar]

Hi all,

The docs meeting will continue today at 16:00 UTC in
#openstack-doc, as scheduled. For more details, see the meeting page:

https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting

Cheers,
pk

__
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] Contrail VIF TAP plugging broken

[Édouard Thuleau]

Hi Seán, Michael,

Since patch [1] moved Contrail VIF plugging under privsep, Nova fails to
plug TAP on the Contrail software switch (named vrouter) [2]. I proposed a
fix in the beginning of the year [3] but it still pending approval even it
got a couple of +1 and no negative feedback. It's why I'm writing that
email to get your attention.
That issue appeared during the Queens development cycle and we need to fix
that before it was released (hope we are not to late).
Contrail already started to move on os-vif driver [4]. A first VIF type
driver is there for DPDK case [5], we plan to do the same for the TAP case
in the R release and remove the Nova VIF plugging code for the vrouter.

[1] https://review.openstack.org/#/c/515916/
[2] https://bugs.launchpad.net/nova/+bug/1742963
[3] https://review.openstack.org/#/c/533212/
[4] https://github.com/Juniper/contrail-nova-vif-driver
[5] https://review.openstack.org/#/c/441183/

Regards,
Édouard.
__
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] [kolla]Fwd: [Openstack-stable-maint] Stable check of openstack/kolla failed

[Matthias Runge]

On 19/02/18 08:27, Matthias Runge wrote:
> On Sun, Feb 18, 2018 at 05:15:18AM -0600, Sean McGinnis wrote:
>> Hello kolla team,
>>
>> It looks like stable builds for kolla have been failing for some time now. 
>> Just forwarding this on to make sure the team is aware of it before the need 
>> for a stable release comes up.
>>
>>> Build failed.
>>>

Looking at this again, for example the centos-binary push job times out.
Especially, this here[1] is apparently started, but has not ended.
Unfortunately, I haven't been able to find any logs regarding docker push

2018-02-21 07:08:57.101374 | primary | 92bd2d995bd5: Pushed
2018-02-21 07:08:58.693761 | POST-RUN END RESULT_TIMED_OUT: [untrusted :
git.openstack.org/openstack/kolla/tests/playbooks/publish.yml@stable/ocata]
2018-02-21 07:08:58.693989 | POST-RUN START: [untrusted :
git.openstack.org/openstack/kolla/tests/playbooks/post.yml@stable/ocata]
2018-02-21 07:09:00.270882 |
2018-02-21 07:09:00.271153 | PLAY [all]
2018-02-21 07:09:00.416795 |
2018-02-21 07:09:00.417030 | TASK [shell]
2018-02-21 07:09:01.129686 | primary | /usr/bin/journalctl
2018-02-21 07:09:01.394259 | primary | Warning: Unable to open /dev/sr0
read-write (Read-only file system).  /dev/sr0
2018-02-21 07:09:01.394390 | primary | has been opened read-only.
2018-02-21 07:09:01.395668 | primary | Error: /dev/sr0: unrecognised
disk label
2018-02-21 07:09:02.797357 | primary | WARNING: bridge-nf-call-iptables
is disabled
2018-02-21 07:09:02.797457 | primary | WARNING: bridge-nf-call-ip6tables
is disabled
2018-02-21 07:09:06.029466 | primary | ok: Runtime: 0:00:04.787576
2018-02-21 07:09:06.079653 |
2018-02-21 07:09:06.079927 | TASK [synchronize]



[1]
http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-binary/dc859f1/ara/reports/a1a13a4a-3e90-4290-82e4-e031ce6029ad.html
-- 
Matthias Runge 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham,
Michael O'Neill, Eric Shander

__
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