Re: [openstack-dev] The first Vietnam OSUG upstream contribution mentoring webinar

[Nguyen, Van Duc]

Thank you and the Vietnamese user group for your contributions. I look forward 
to participating in the webinar. +1 ☺

From: Trinh Nguyen 
Sent: Friday, November 02, 2018 9:41 AM
To: OpenStack Development Mailing List (not for usage questions) 

Cc: commun...@lists.openstack.org
Subject: [openstack-dev] The first Vietnam OSUG upstream contribution mentoring 
webinar

Hello,

The Vietnam OpenStack User Group has planned to organize an upstream 
contribution mentoring program for a while and finally, we decided the first 
webinar will be on next Monday, 5 November. Attendees will be anyone who is 
interested in the development process of OpenStack (mostly Vietnamese, 
students, developer, etc.). Mentors will be some experienced OpenStack upstream 
developers, core members of some projects, etc. You can check out the details 
on the Meetup link below [1].

We also want to say thank to the work of Ian Y. Choi and the Korea user group 
[2]. You inspired us.

[1] https://www.meetup.com/VietOpenStack/events/hpcglqyxpbhb/
[2] 
http://lists.openstack.org/pipermail/community/2018-October/001909.html?fbclid=IwAR0nTZFMzc56PYT0jMDf02Wci2qbaGxhay3EU53Wfd_RntgFqZ0ybwzpFY8

Bests,

--
Trinh Nguyen
www.edlab.xyz

__
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] The first Vietnam OSUG upstream contribution mentoring webinar

[Trinh Nguyen]

Hello,

The Vietnam OpenStack User Group has planned to organize an upstream
contribution mentoring program for a while and finally, we decided the
first webinar will be on next Monday, 5 November. Attendees will be anyone
who is interested in the development process of OpenStack (mostly
Vietnamese, students, developer, etc.). Mentors will be some experienced
OpenStack upstream developers, core members of some projects, etc. You can
check out the details on the Meetup link below [1].

We also want to say thank to the work of Ian Y. Choi and the Korea user
group [2]. You inspired us.

[1] https://www.meetup.com/VietOpenStack/events/hpcglqyxpbhb/
[2]
http://lists.openstack.org/pipermail/community/2018-October/001909.html?fbclid=IwAR0nTZFMzc56PYT0jMDf02Wci2qbaGxhay3EU53Wfd_RntgFqZ0ybwzpFY8

Bests,

-- 
*Trinh Nguyen*
*www.edlab.xyz *
__
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] StoryBoard Forum Session: Remaining Blockers

[Kendall Nelson]

Hello Everyone!

We've made a lot of progress in StoryBoard-land over the last couple of
releases cleaning up bugs, fixing UI annoyances, and adding features that
people have requested. All along we've also continued to migrate projects
as they've become unblocked. While there are still a few blockers on our
to-do list, we want to make sure our list is complete[1].

We have a session at the upcoming forum to collect any remaining blockers
that you may have encountered while messing around with the dev
storyboard[2] site or using the real storyboard interacting with projects
that have already migrated. If you encountered any issues that  are
blocking your project from migrating, please come share them with with
us[3]. Hope to see you there!

-Kendall (diablo_rojo) & the StoryBoard team

[1] https://storyboard.openstack.org/#!/worklist/493
[2] https://storyboard-dev.openstack.org/
[2]
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22839/storyboard-migration-the-remaining-blockers
__
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] [senlin] Meeting cancelled for Nov 2

[Duc Truong]

Everyone,

There isn't much to talk about this week so I'm cancelling the weekly meeting.

The only thing that needs attention is the upgrade checker patch set:
https://review.openstack.org/#/c/613788/

If anybody has time, please take a look and see if you can figure out
why it is not working.

Thanks,

Duc

__
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] about use nfs driver to backup the volume snapshot

[Jay Bryant]

On Thu, Nov 1, 2018, 10:44 AM Rambo  wrote:

> Hi,all
>
>  Recently, I use the nfs driver as the cinder-backup backend, when I
> use it to backup the volume snapshot, the result is return the
> NotImplementedError[1].And the nfs.py doesn't has the
> create_volume_from_snapshot function. Does the community plan to achieve
> it which is as nfs as the cinder-backup backend?Can you tell me about
> this?Thank you very much!
>
> Rambo,

The NFS driver doesn't have full snapshot support. I am not sure if that
function missing was an oversight or not. I would reach out to Eric Harney
as he implemented that code.

Jay

>
>
> [1]
> https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L2142
>
>
>
>
>
>
>
>
> Best Regards
> Rambo
> __
> 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] [tripleo] Proposing Bob Fournier as core reviewer

[Bob Fournier]

On Thu, Nov 1, 2018 at 4:26 PM Emilien Macchi  wrote:

> done, you're now core in TripleO; Thanks Bob for your hard work!
>

Thank you Emilien, Juan, and everyone else!


>
> On Mon, Oct 22, 2018 at 4:55 PM Jason E. Rist  wrote:
>
>> On 10/19/2018 06:23 AM, Juan Antonio Osorio Robles wrote:
>> > Hello!
>> >
>> >
>> > I would like to propose Bob Fournier (bfournie) as a core reviewer in
>> > TripleO. His patches and reviews have spanned quite a wide range in our
>> > project, his reviews show great insight and quality and I think he would
>> > be a addition to the core team.
>> >
>> > What do you folks think?
>> >
>> >
>> > Best Regards
>> >
>> >
>> >
>> >
>> __
>> > 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
>> >
>> yup.
>>
>> --
>> Jason E. Rist
>> Senior Software Engineer
>> OpenStack User Interfaces
>> Red Hat, Inc.
>> Freenode: jrist
>> github/twitter: knowncitizen
>>
>> __
>> 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
>>
>
>
> --
> Emilien Macchi
> __
> 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] [tripleo] Proposing Bob Fournier as core reviewer

[Emilien Macchi]

done, you're now core in TripleO; Thanks Bob for your hard work!

On Mon, Oct 22, 2018 at 4:55 PM Jason E. Rist  wrote:

> On 10/19/2018 06:23 AM, Juan Antonio Osorio Robles wrote:
> > Hello!
> >
> >
> > I would like to propose Bob Fournier (bfournie) as a core reviewer in
> > TripleO. His patches and reviews have spanned quite a wide range in our
> > project, his reviews show great insight and quality and I think he would
> > be a addition to the core team.
> >
> > What do you folks think?
> >
> >
> > Best Regards
> >
> >
> >
> >
> __
> > 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
> >
> yup.
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack User Interfaces
> Red Hat, Inc.
> Freenode: jrist
> github/twitter: knowncitizen
>
> __
> 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
>


-- 
Emilien Macchi
__
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] Stein summit forum sessions and presentations of interest

[melanie witt]

Howdy all,

We've made a list of cross-project forum sessions and nova-related 
sessions/presentations that you might be interested in attending at the 
summit and added them to our forum etherpad:


https://etherpad.openstack.org/p/nova-forum-stein

The "Cross-project Forum sessions that should include nova 
participation" section contains a list of community sessions where it 
would be nice to have a nova representative in attendance. Please feel 
free to add your name to sessions you think you could attend and bring 
back any interesting info to the team.


Let know if I've missed any cross-project sessions or nova-related 
sessions/presentations and I can add them.


Looking forward to seeing you all at the summit!

Cheers,
-melanie

__
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] gate issues please do not approve/recheck

[Wesley Hayutin]

Thanks Alex!

On Thu, Nov 1, 2018 at 10:27 AM Alex Schultz  wrote:

> Ok since the podman revert patche has been successfully merged and
> we've landed most of the non-voting scenario patches, it should be OK
> to restore/recheck.  It would be a good idea to prioritized things to
> land and if it's not critical, let's hold off on approving until we're
> sure the gate is much better.
>
> Thanks,
> -Alex
>
> On Wed, Oct 31, 2018 at 9:39 AM Alex Schultz  wrote:
> >
> > Hey folks,
> >
> > So we have identified an issue that has been causing a bunch of
> > failures and proposed a revert of our podman testing[0].  We have
> > cleared the gate and are asking that you not approve or recheck any
> > patches at this time.  We will let you know when it is safe to start
> > approving things.
> >
> > Thanks,
> > -Alex
> >
> > [0] https://review.openstack.org/#/c/614537/
>
> __
> 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
>
-- 

Wes Hayutin

Associate MANAGER

Red Hat



whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay


View my calendar and check my availability for meetings HERE

__
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] [goals][python3][heat][manila][qinling][zaqar][magnum][keystone][congress] switching python package jobs

[Doug Hellmann]

Doug Hellmann  writes:

> Doug Hellmann  writes:
>
> I asked the owners of the name "heat" to allow us to use it, and they
> rejected the request. So, I proposed a change to heat to update the
> sdist name to "openstack-heat".
>
> * https://review.openstack.org/606160

This patch is now passing tests. Please prioritize reviewing it, because
it is going to block releases of heat.

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] [tc][all][goals] selecting community-wide goals for T development cycle

[Doug Hellmann]

We will have a session at the forum to discuss the community-wide goals
[0] we want to select for the T cycle. That's a long way off, but given
the fact that we don't have a PTG between Berlin and Denver, and that
we've recently had feedback that we need to have tools finished better
before starting, I think we do need to begin the conversation now.

The Forum session is on Thursday at 17:10, at the end of the Forum
[1]. There's an etherpad up [2] for folks to start offering
suggestions. And the etherpad with the archives of past ideas is also
still online [3].

Let's use this thread to talk about the Forum session. If you want to
propose a specific goal, please start a *new* thread here on
openstack-dev so that we can keep all of the discussion clearly
separated. Please keep in mind that these goals should apply to most, if
not all, projects. Work to integrate 2 services can be managed through
the normal feature prioritization processes of the teams involved.

I will be moderating the discussion at the Forum, but I am not signing
up as a goal champion or to drive the goal selection. If you are
interested in helping with either of those things, please let me know.

Doug

[0] https://governance.openstack.org/tc/goals/index.html
[1] 
https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22814/t-series-community-goal-discussion
[2] https://etherpad.openstack.org/p/BER-t-series-goals
[3] https://etherpad.openstack.org/p/community-goals


__
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] Zuul Queue backlogs and resource usage

[Ben Nemec]

On 10/30/18 4:16 PM, Clark Boylan wrote:

On Tue, Oct 30, 2018, at 1:01 PM, Ben Nemec wrote:



On 10/30/18 1:25 PM, Clark Boylan wrote:

On Tue, Oct 30, 2018, at 10:42 AM, Alex Schultz wrote:

On Tue, Oct 30, 2018 at 11:36 AM Ben Nemec  wrote:


Tagging with tripleo since my suggestion below is specific to that project.

On 10/30/18 11:03 AM, Clark Boylan wrote:

Hello everyone,

A little while back I sent email explaining how the gate queues work and how 
fixing bugs helps us test and merge more code. All of this still is still true 
and we should keep pushing to improve our testing to avoid gate resets.

Last week we migrated Zuul and Nodepool to a new Zookeeper cluster. In the 
process of doing this we had to restart Zuul which brought in a new logging 
feature that exposes node resource usage by jobs. Using this data I've been 
able to generate some report information on where our node demand is going. 
This change [0] produces this report [1].

As with optimizing software we want to identify which changes will have the 
biggest impact and to be able to measure whether or not changes have had an 
impact once we have made them. Hopefully this information is a start at doing 
that. Currently we can only look back to the point Zuul was restarted, but we 
have a thirty day log rotation for this service and should be able to look at a 
month's worth of data going forward.

Looking at the data you might notice that Tripleo is using many more node 
resources than our other projects. They are aware of this and have a plan [2] 
to reduce their resource consumption. We'll likely be using this report 
generator to check progress of this plan over time.


I know at one point we had discussed reducing the concurrency of the
tripleo gate to help with this. Since tripleo is still using >50% of the
resources it seems like maybe we should revisit that, at least for the
short-term until the more major changes can be made? Looking through the
merge history for tripleo projects I don't see a lot of cases (any, in
fact) where more than a dozen patches made it through anyway*, so I
suspect it wouldn't have a significant impact on gate throughput, but it
would free up quite a few nodes for other uses.



It's the failures in gate and resets.  At this point I think it would
be a good idea to turn down the concurrency of the tripleo queue in
the gate if possible. As of late it's been timeouts but we've been
unable to track down why it's timing out specifically.  I personally
have a feeling it's the container download times since we do not have
a local registry available and are only able to leverage the mirrors
for some levels of caching. Unfortunately we don't get the best
information about this out of docker (or the mirrors) and it's really
hard to determine what exactly makes things run a bit slower.


We actually tried this not too long ago 
https://git.openstack.org/cgit/openstack-infra/project-config/commit/?id=22d98f7aab0fb23849f715a8796384cffa84600b
 but decided to revert it because it didn't decrease the check queue backlog 
significantly. We were still running at several hours behind most of the time.


I'm surprised to hear that. Counting the tripleo jobs in the gate at
positions 11-20 right now, I see around 84 nodes tied up in long-running
jobs and another 32 for shorter unit test jobs. The latter probably
don't have much impact, but the former is a non-trivial amount. It may
not erase the entire 2300+ job queue that we have right now, but it
seems like it should help.



If we want to set up better monitoring and measuring and try it again we can do 
that. But we probably want to measure queue sizes with and without the change 
like that to better understand if it helps.


This seems like good information to start capturing, otherwise we are
kind of just guessing. Is there something in infra already that we could
use or would it need to be new tooling?


Digging around in graphite we currently track mean in pipelines. This is 
probably a reasonable metric to use for this specific case.

Looking at the check queue [3] shows the mean time enqueued in check during the rough 
period window floor was 10 and [4] shows it since then. The 26th and 27th are bigger 
peaks than previously seen (possibly due to losing inap temporarily) but otherwise a 
queue backlog of ~200 minutes was "normal" in both time periods.

[3] 
http://graphite.openstack.org/render/?from=20181015=20181019=scale(stats.timers.zuul.tenant.openstack.pipeline.check.resident_time.mean,%200.166)
[4] 
http://graphite.openstack.org/render/?from=20181019=20181030=scale(stats.timers.zuul.tenant.openstack.pipeline.check.resident_time.mean,%200.166)

You should be able to change check to eg gate or other queue names and poke 
around more if you like. Note the scale factor scales from milliseconds to 
minutes.

Clark



Cool, thanks. Seems like things have been better for the past couple of 
days, but I'll keep this in my back pocket for 

Re: [openstack-dev] [vitrage] I have some problems with Prometheus alarms in vitrage.

[Ifat Afek]

Hi,

On Wed, Oct 31, 2018 at 11:00 AM Won  wrote:

> Hi,
>
>>
>> This is strange. I would expect your original definition to work as well,
>> since the alarm key in Vitrage is defined by a combination of the alert
>> name and the instance. We will check it again.
>> BTW,  we solved a different bug related to Prometheus alarms not being
>> cleared [1]. Could it be related?
>>
>
> Using the original definition, no matter how different the instances are,
> the alarm names are recognized as the same alarm in vitrage.
> And I tried to install the rocky version and the master version on the new
> server and retest but the problem was not solved. The latest bugfix seems
> irrelevant.
>

Ok. We will check this issue. For now your workaround is ok, right?


> Does the wrong timestamp appear if you run 'vitrage alarm list' cli
>> command? please try running 'vitrage alarm list --debug' and send me the
>> output.
>>
>
> I have attached 'vitrage-alarm-list.txt.'
>

I believe that you attached the wrong file. It seems like another log of
vitrage-graph.


>
>
>> Please send me vitrage-collector.log and vitrage-graph.log from the time
>> that the problematic vm was created and deleted. Please also create and
>> delete a vm on your 'ubuntu' server, so I can check the differences in the
>> log.
>>
>
> I have attached 'vitrage_log_on_compute1.zip' and
> 'vitrage_log_on_ubuntu.zip' files.
> When creating a vm on computer1, a vitrage-collect log occurred, but no
> log occurred when it was removed.
>

Looking at the logs, I see two issues:
1. On ubuntu server, you get a notification about the vm deletion, while on
compute1 you don't get it.
Please make sure that Nova sends notifications to 'vitrage_notifications' -
it should be configured in /etc/nova/nova.conf.

2. Once in 10 minutes (by default) nova.instance datasource queries all
instances. The deleted vm is supposed to be deleted in Vitrage at this
stage, even if the notification was lost.
Please check in your collector log for the a message of "novaclient.v2.client
[-] RESP BODY" before and after the deletion, and send me its content.

Br,
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] [tripleo] gate issues please do not approve/recheck

[Alex Schultz]

Ok since the podman revert patche has been successfully merged and
we've landed most of the non-voting scenario patches, it should be OK
to restore/recheck.  It would be a good idea to prioritized things to
land and if it's not critical, let's hold off on approving until we're
sure the gate is much better.

Thanks,
-Alex

On Wed, Oct 31, 2018 at 9:39 AM Alex Schultz  wrote:
>
> Hey folks,
>
> So we have identified an issue that has been causing a bunch of
> failures and proposed a revert of our podman testing[0].  We have
> cleared the gate and are asking that you not approve or recheck any
> patches at this time.  We will let you know when it is safe to start
> approving things.
>
> Thanks,
> -Alex
>
> [0] https://review.openstack.org/#/c/614537/

__
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] about use nfs driver to backup the volume snapshot

[Rambo]

Hi,all


 Recently, I use the nfs driver as the cinder-backup backend, when I use it 
to backup the volume snapshot, the result is return the 
NotImplementedError[1].And the nfs.py doesn't has the 
create_volume_from_snapshot function. Does the community plan to achieve it 
which is as nfs as the cinder-backup backend?Can you tell me about this?Thank 
you very much!






[1]https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L2142
















Best Regards
Rambo__
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-job-failures][release][infra] Tag of openstack/keystone failed

[Sean McGinnis]

On Thu, Nov 01, 2018 at 03:08:09PM +, Jeremy Stanley wrote:
> On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote:
> > Jeremy Stanley  writes:
> > 
> > > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
> > > [...]
> > >> Did I miss any options or issues with this approach?
> > >
> > > https://review.openstack.org/578557
> > 
> > How high of a priority is rolling that feature out? It does seem to
> > eliminate this particular issue (even the edge cases described in the
> > commit message shouldn't affect us based on our typical practices), but
> > until we have one of the two changes in place we're going to have this
> > issue with every release we tag.
> 
> It was written as a potential solution to this problem back when we
> first discussed it in June, but at the time we thought it might be
> solvable via job configuration with minimal inconvenience so that
> feature was put on hold as a fallback option in case we ended up
> needing it. I expect since it's already seen some review and is
> passing tests it could probably be picked back up fairly quickly now
> that alternative solutions have proven more complex than originally
> envisioned.
> -- 
> Jeremy Stanley

Doug's option 3 made sense to me as a way to address this for now. I could see
doing that for the time being, but if this is coming in the near future, we can
wait and go with it as option 4.

Sean

__
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-job-failures][release][infra] Tag of openstack/keystone failed

[Jeremy Stanley]

On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote:
> Jeremy Stanley  writes:
> 
> > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
> > [...]
> >> Did I miss any options or issues with this approach?
> >
> > https://review.openstack.org/578557
> 
> How high of a priority is rolling that feature out? It does seem to
> eliminate this particular issue (even the edge cases described in the
> commit message shouldn't affect us based on our typical practices), but
> until we have one of the two changes in place we're going to have this
> issue with every release we tag.

It was written as a potential solution to this problem back when we
first discussed it in June, but at the time we thought it might be
solvable via job configuration with minimal inconvenience so that
feature was put on hold as a fallback option in case we ended up
needing it. I expect since it's already seen some review and is
passing tests it could probably be picked back up fairly quickly now
that alternative solutions have proven more complex than originally
envisioned.
-- 
Jeremy Stanley


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

Re: [openstack-dev] [tc] agenda for TC meeting 1 Nov 1400 UTC

[Doug Hellmann]

Doug Hellmann  writes:

> TC members,
>
> The TC will be meeting on 1 Nov at 1400 UTC in #openstack-tc to discuss
> some of our ongoing initiatives. Here is the agenda for this week.
>
> * meeting procedures
>
> * discussion of topics for joint leadership meeting at Summit in
>   Berlin
>
> * completing TC liaison assignments
> ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Project_Teams
>
> * documenting chair responsibilities
> ** https://etherpad.openstack.org/p/tc-chair-responsibilities
>
> * reviewing the health-check check list
> ** https://wiki.openstack.org/wiki/OpenStack_health_tracker#Health_check_list
>
> * deciding next steps on technical vision statement
> ** https://review.openstack.org/592205
>
> * deciding next steps on python 3 and distro versions for PTI
> ** https://review.openstack.org/610708 Add optional python3.7 unit test 
> enablement to python3-first
> ** https://review.openstack.org/611010 Make Python 3 testing requirement less 
> specific
> ** https://review.openstack.org/611080 Explicitly declare Stein supported 
> runtimes
> ** https://review.openstack.org/613145 Resolution on keeping up with Python 3 
> releases
>
> * reviews needing attention
> ** https://review.openstack.org/613268 Indicate relmgt style for each 
> deliverable
> ** https://review.openstack.org/613856 Remove Dragonflow from the official 
> projects list
>
> If you have suggestions for topics for the next meeting (6 Dec), please
> add them to the wiki at
> https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda_Suggestions
>
> 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

The logs for this meeting are available now at

Minutes:
http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.html
Minutes (text): 
http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.txt
Log:
http://eavesdrop.openstack.org/meetings/tc/2018/tc.2018-11-01-14.01.log.html

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] [nova] Is anyone running their own script to purge old instance_faults table entries?

[Matt Riedemann]

I came across this bug [1] in triage today and I thought this was fixed 
already [2] but either something regressed or there is more to do here.


I'm mostly just wondering, are operators already running any kind of 
script which purges old instance_faults table records before an instance 
is deleted and archived/purged? Because if so, that might be something 
we want to add as a nova-manage command.


[1] https://bugs.launchpad.net/nova/+bug/1800755
[2] https://review.openstack.org/#/c/409943/

--

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] [Release-job-failures][release][infra] Tag of openstack/keystone failed

[Doug Hellmann]

Jeremy Stanley  writes:

> On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> Did I miss any options or issues with this approach?
>
> https://review.openstack.org/578557

How high of a priority is rolling that feature out? It does seem to
eliminate this particular issue (even the edge cases described in the
commit message shouldn't affect us based on our typical practices), but
until we have one of the two changes in place we're going to have this
issue with every release we tag.

Doug

>
> -- 
> Jeremy Stanley
> __
> 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] [Release-job-failures][release][infra] Tag of openstack/keystone failed

[Jeremy Stanley]

On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote:
[...]
> Did I miss any options or issues with this approach?

https://review.openstack.org/578557

-- 
Jeremy Stanley


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] [tc] publishing openstack_governance library to PyPI

[Doug Hellmann]

TC members,

I have a series of patches up for review starting at [1] to create a
small library for reading and manipulating the project reference data in
the YAML files in the openstack/governance repository. After copying
similar code into a 3rd repository that wants to consume it last cycle,
I thought I ought to just go ahead and do this properly.

The patch in [2] is an example of how the releases repository can take
advantage of having a library like this.

Please add the series to your review queue.

Doug

[1] https://review.openstack.org/#/c/614597
[2] https://review.openstack.org/614606

__
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] [release] Release countdown for week R-22, November 5-9

[Sean McGinnis]

Development Focus
-

Teams should now be focused on feature development and completion of release
goals [0].

[0] https://governance.openstack.org/tc/goals/stein/index.html

General Information
---

We are now past the Stein-1 milestone. Following the changes described in [0]
we have release most of the cycle-with-intermediary libraries. It is a good
time to think about any additional client (or deliverables marked as
type:"other") releases. All projects with these deliverables should try to have
a release done before Stein-2.

All cycle-with-milestone deliverables have been switched over to be
cycle-with-rc [1]. Just a reminder that we can still do milestone beta releases
if there is a need for them, but we want to avoid doing so just because that is
what we've historically done.

Any questions about these changes, or any release planning or process questions
in general, please reach out to us in the #openstack-release channel or on the
mailing list.

[0] http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html
[1] 
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135088.html

Upcoming Deadlines & Dates
--

Forum at OpenStack Summit in Berlin: November 13-15
Start using openstack-discuss ML: November 19
Stein-2 Milestone: January 10

-- 
Sean McGinnis (smcginnis)

__
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-job-failures][release][infra] Tag of openstack/keystone failed

[Doug Hellmann]

Doug Hellmann  writes:

> z...@openstack.org writes:
>
>> Build failed.
>>
>> - publish-openstack-releasenotes-python3 
>> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/
>>  : POST_FAILURE in 13m 53s
>> - publish-openstack-releasenotes 
>> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/
>>  : SUCCESS in 13m 54s
>>
>> ___
>> Release-job-failures mailing list
>> release-job-failu...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures
>
> Keystone is configured in stable/queens with the release-notes-jobs
> project template and in master with the release-notes-jobs-python3
> template. This is, AFAICT, exactly what we said should be done. However,
> both of the templates include jobs in the "tag" pipeline, and tags are
> not branch-aware. That means we end up running both versions of the
> release notes publishing jobs when we tag a release, and the results may
> be unpredictable. This problem will affect other projects as well.
>
> I think we have a few options.
>
> 1. Move the job settings out of the source repository into
>project-config, like we do for the release jobs, so that we always
>run the same version in all cases.
>
>This has two downsides.
>
>First, we would have to support the python3 variant even on very old
>stable branches. That shouldn't be a very big concern, though,
>because that job does not install the source for the project or its
>dependencies.
>
>Second, we would have to modify all of the zuul configurations for
>all of our old branches, again. As much as I'm enjoying the jokes
>about how I'm padding my contribution stats this cycle, I don't
>really want to do that.
>
> 2. Make the job itself smart enough to figure out whether to run with
>python 2 or 3.
>
>We could update both jobs to look at some setting in the repo to
>decide which version to use. This feels excessively complicated,
>might still result in having to modify some settings in the stable
>branches, and would mean we would have to customize the shared
>versions of the jobs defined in the zuul-jobs repo.
>
> 3. Modify the python 2 version of the project template
>("release-notes-jobs") to remove the "tag" pipeline settings.
>
>This would let us continue to use the python 2 variant for tests and
>when patches merge, and only use the python 3 job for tags. As with
>option 1, we would have to be sure that the release notes job works
>under python 3 for all repos, but as described above that isn't a big
>concern.
>
> I think we should take option 3, and will be preparing a patch to do
> that shortly.
>
> Did I miss any options or issues with this approach?
>
> Doug

See https://review.openstack.org/614758

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

Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed

[Doug Hellmann]

z...@openstack.org writes:

> Build failed.
>
> - publish-openstack-releasenotes-python3 
> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes-python3/7347218/
>  : POST_FAILURE in 13m 53s
> - publish-openstack-releasenotes 
> http://logs.openstack.org/86/86022835fb39cb318e28994ed0290caddfb451be/tag/publish-openstack-releasenotes/a4c2e21/
>  : SUCCESS in 13m 54s
>
> ___
> Release-job-failures mailing list
> release-job-failu...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures

Keystone is configured in stable/queens with the release-notes-jobs
project template and in master with the release-notes-jobs-python3
template. This is, AFAICT, exactly what we said should be done. However,
both of the templates include jobs in the "tag" pipeline, and tags are
not branch-aware. That means we end up running both versions of the
release notes publishing jobs when we tag a release, and the results may
be unpredictable. This problem will affect other projects as well.

I think we have a few options.

1. Move the job settings out of the source repository into
   project-config, like we do for the release jobs, so that we always
   run the same version in all cases.

   This has two downsides.

   First, we would have to support the python3 variant even on very old
   stable branches. That shouldn't be a very big concern, though,
   because that job does not install the source for the project or its
   dependencies.

   Second, we would have to modify all of the zuul configurations for
   all of our old branches, again. As much as I'm enjoying the jokes
   about how I'm padding my contribution stats this cycle, I don't
   really want to do that.

2. Make the job itself smart enough to figure out whether to run with
   python 2 or 3.

   We could update both jobs to look at some setting in the repo to
   decide which version to use. This feels excessively complicated,
   might still result in having to modify some settings in the stable
   branches, and would mean we would have to customize the shared
   versions of the jobs defined in the zuul-jobs repo.

3. Modify the python 2 version of the project template
   ("release-notes-jobs") to remove the "tag" pipeline settings.

   This would let us continue to use the python 2 variant for tests and
   when patches merge, and only use the python 3 job for tags. As with
   option 1, we would have to be sure that the release notes job works
   under python 3 for all repos, but as described above that isn't a big
   concern.

I think we should take option 3, and will be preparing a patch to do
that shortly.

Did I miss any options or issues with this approach?

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] [Oslo][nova][openstack-ansible] About Rabbitmq warning problems on nova-compute side

[BİLGEM BTE]

Hi folks, 

I have problems about rabbitmq on nova-compute side. I see lots of warnings in 
log file like that “client unexpectedly closed TCP connection”.[1] 

I have a HA OpenStack environment on ubuntu 16.04.5 which is installed with 
Openstack Ansible Project. My OpenStack environment version is Pike. My 
environment consists of 3 controller nodes ,23 compute nodes and 1 log node. 
Cinder volume service is installed on compute nodes and I am using NetApp 
Storage. 

I tried lots of configs on nova about oslo messaging and rabbitmq side, but I 
didn’t resolve this problem. My latest configs are below: 

rabbitmq.config is : http://paste.openstack.org/show/733767/ 

nova.conf is: [ http://paste.openstack.org/show/733768/ | 
http://paste.openstack.org/show/733768/ ] 

Services versions are : http://paste.openstack.org/show/733769/ 




Can you share your experiences on rabbitmq side and How can I solve these 
warnings on nova-compute side ? What will you advice ? 




[1] http://paste.openstack.org/show/733766/ 
__
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] reducing our upstream CI footprint

[Derek Higgins]

On Wed, 31 Oct 2018 at 17:22, Alex Schultz  wrote:
>
> Hey everyone,
>
> Based on previous emails around this[0][1], I have proposed a possible
> reducing in our usage by switching the scenario001--011 jobs to
> non-voting and removing them from the gate[2]. This will reduce the
> likelihood of causing gate resets and hopefully allow us to land
> corrective patches sooner.  In terms of risks, there is a risk that we
> might introduce breaking changes in the scenarios because they are
> officially non-voting, and we will still be gating promotions on these
> scenarios.  This means that if they are broken, they will need the
> same attention and care to fix them so we should be vigilant when the
> jobs are failing.
>
> The hope is that we can switch these scenarios out with voting
> standalone versions in the next few weeks, but until that I think we
> should proceed by removing them from the gate.  I know this is less
> than ideal but as most failures with these jobs in the gate are either
> timeouts or unrelated to the changes (or gate queue), they are more of
> hindrance than a help at this point.
>
> Thanks,
> -Alex

While on the topic of reducing the CI footprint

something worth considering when pushing up a string of patches would
be to remove a bunch of the check jobs at the start of the patch set.

e.g. If I'm working on t-h-t and have a series of 10 patches, while
looking for feedback I could remove most of the jobs from
zuul.d/layout.yaml in patch 1 so all 10 patches don't run the entire
suite of CI jobs. Once it becomes clear that the patchset is nearly
ready to merge, I change patch 1 leave zuul.d/layout.yaml as is.

I'm not suggesting everybody does this but anybody who tends to push
up multiple patch sets together could consider it to not tie up
resources for hours.

>
> [0] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-October/136141.html
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2018-October/135396.html
> [2] 
> https://review.openstack.org/#/q/topic:reduce-tripleo-usage+(status:open+OR+status:merged)
>
> __
> 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] [openlab] October Report

[Melvin Hillsman]

Hi everyone,

Here are some highlights from OpenLab for the month of October:

CI additions
  - cluster-api-provider-openstack
  - AdoptOpenJDK
- very important open source project
- many Java developers
- strategic for open source ecosystem

Website redesign completed
  - fielding resource and support requests via GitHub
  - ML sign up via website
  - Community page
  - CI Infrastructure and High level request pipeline still manual but
driven by Google Sheets
  - closer to being fully automated; easier to manage via spreadsheet
instead of website backend

Promotion
  - OSN Day Dallas, November 6th, 2018
https://events.linuxfoundation.org/events/osn_days_2018/north-america/
dallas/
  - Twitter account is live - @askopenlab

Mailing List - https://lists.openlabtesting.org
  - running latest mailman
  - postorious frontend
  - net new members - 7

OpenLab Tests
  (October)
- total number of tests run - 3504
  - SUCCESS - 2421
  - FAILURE - 871
  - POST_FAILURE- 72
  - RETRY_LIMIT - 131
  - TIMED_OUT - 9
  - NODE_FAILURE - 0
  - SKIPPED - 0
- 69.0925% : 30.9075% (success to fail/other job ratio)

  (September)
- total number of tests run - 4350
  - SUCCESS - 2611
  - FAILURE - 1326
  - POST_FAILURE- 336
  - RETRY_LIMIT - 66
  - TIMED_OUT - 11
  - NODE_FAILURE - 0
  - SKIPPED - 0
- 60.0230% : 39.9770% (success to fail/other job ratio)

  Delta
- 9.0695% increase in success to fail/other job ratio
  - testament to great support by Chenrui and Liusheng "keeping the
lights on".

  Additional Infrastructure
- Packet
  - 80 vCPUs, 80G RAM, 1000G Disk
- ARM
  - ARM-based OpenStack Cloud
- Managed by codethink.co.uk
  - single compute node - 96 vCPUs, 128G RAM, 800G Disk
- Massachusetts Open Cloud
  - in progress
  - small project for now
  - academia partner


Build Status Legend:
SUCCESS
job executed correctly and exited without failure
FAILURE
job executed correctly, but exited with a failure
RETRY_LIMIT
pre-build tasks/plays failed more than the maximum number of retry
attempts
POST_FAILURE
post-build tasks/plays failed
SKIPPED
one of the build dependencies failed and this job was not executed
NODE_FAILURE
no device available to run the build
TIMED_OUT
build got stuck at some point and hit the timeout limit

Thank you to everyone who has read through this month’s update. If you have
any question/concerns please feel free to start a thread on the mailing
list or if it is something not to be shared publicly right now you can
email i...@openlabtesting.org

Kind regards,

OpenLab Governance Team


-- 
Kind regards,

Melvin Hillsman
mrhills...@gmail.com
mobile: (832) 264-2646
__
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] Team gathering at the Forum?

[Dmitry Tantsur]

Hi,

You mean Lindenbrau, right? I was thinking of changing the venue, but if you're 
there, I think we should go there too! I just hope they can still fit 15 ppl :) 
Will try reserving tomorrow.


Dmitry

On 11/1/18 12:11 AM, Stig Telfer wrote:

Hello Ironicers -

We’ve booked the same venue for the Scientific SIG for Wednesday evening, and 
hopefully we’ll see you there.  There’s plenty of cross-over between our 
groups, particularly at an operator level.

Cheers,
Stig



On 29 Oct 2018, at 14:58, Dmitry Tantsur  wrote:

Hi folks!

This is your friendly reminder to vote on the day. Even if you're fine with all 
days, please leave a vote, so that we know how many people are coming. We will 
need to make a reservation, and we may not be able to accommodate more people 
than voted!

Dmitry

On 10/22/18 6:06 PM, Dmitry Tantsur wrote:

Hi ironicers! :)
We are trying to plan an informal Ironic team gathering in Berlin. If you care 
about Ironic and would like to participate, please fill in 
https://doodle.com/poll/iw5992px765nthde. Note that the location is tentative, 
also depending on how many people sign up.
Dmitry



__
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] [oslo] No complains about rabbitmq SSL problems: could we have this in the logs?

[Thomas Goirand]

On 10/31/18 2:40 PM, Mohammed Naser wrote:
> For what it’s worth: I ran into the same issue.  I think the problem lies a 
> bit deeper because it’s a problem with kombu as when debugging I saw that 
> Oslo messaging tried to connect and hung after. 
> 
> Sent from my iPhone
> 
>> On Oct 31, 2018, at 2:29 PM, Thomas Goirand  wrote:
>>
>> Hi,
>>
>> It took me a long long time to figure out that my SSL setup was wrong
>> when trying to connect Heat to rabbitmq over SSL. Unfortunately, Oslo
>> (or heat itself) never warn me that something was wrong, I just got
>> nothing working, and no log at all.
>>
>> I'm sure I wouldn't be the only one happy about having this type of
>> problems being yelled out loud in the logs. Right now, it does work if I
>> turn off SSL, though I'm still not sure what's wrong in my setup, and
>> I'm given no clue if the issue is on rabbitmq-server or on the client
>> side (ie: heat, in my current case).
>>
>> Just a wishlist... :)
>> Cheers,
>>
>> Thomas Goirand (zigo)

I've opened a bug here:

https://bugs.launchpad.net/oslo.messaging/+bug/1801011

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