[openstack-dev] [TripleO] Review metrics - what do we want to measure?

[James Polley]

In recent history, we've been looking each week at stats from
http://russellbryant.net/openstack-stats/tripleo-openreviews.html to get a
gauge on how our review pipeline is tracking.

The main stats we've been tracking have been the "since the last revision
without -1 or -2". I've included some history at [1], but the summary is
that our 3rd quartile has slipped from 13 days to 16 days over the last 4
weeks or so. Our 1st quartile is fairly steady lately, around 1 day (down
from 4 a month ago) and median is unchanged around 7 days.

There was lots of discussion in our last meeting about what could be
causing this[2]. However, the thing we wanted to bring to the list for the
discussion is:

Are we tracking the right metric? Should we be looking to something else to
tell us how well our pipeline is performing?

The meeting logs have quite a few suggestions about ways we could tweak the
existing metrics, but if we're measuring the wrong thing that's not going
to help.

I think that what we are looking for is a metric that lets us know whether
the majority of patches are getting feedback quickly. Maybe there's some
other metric that would give us a good indication?




[1] Current "Stats since the last revision without -1 or -2" :

Average wait time: 10 days, 17 hours, 6 minutes
1st quartile wait time: 1 days, 1 hours, 36 minutes
Median wait time: 7 days, 5 hours, 33 minutes
3rd quartile wait time: 16 days, 8 hours, 16 minutes

At last week's meeting we had: 3rd quartile wait time: 15 days, 13 hours,
47 minutes
A week before that: 3rd quartile wait time: 13 days, 9 hours, 11 minutes
The week before that was the mid-cycle, but the week before that:

19:53:38  Stats since the last revision without -1 or -2 :
19:53:38  Average wait time: 10 days, 17 hours, 49 minutes
19:53:38  1st quartile wait time: 4 days, 7 hours, 57 minutes
19:53:38  Median wait time: 7 days, 10 hours, 52 minutes
19:53:40  3rd quartile wait time: 13 days, 13 hours, 25 minutes

[2] Some of the things suggested as potential causes of the long 3rd median
times:

* We have small number of really old reviews that have only positive scores
but aren't being landed
* Some reviews get a -1 but then sit for a long time waiting for the author
to reply
* We have some really old reviews that suddenly get revived after a long
period being in WIP or abandoned, which reviewstats seems to miscount
* Reviewstats counts weekends, we don't (so a change that gets pushed at
5pm US Friday and gets reviewed at 9am Aus Monday would be seen by us as
having no wait time, but by reviewstats as ~36 hours)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?

[James Polley]

After some more discussion and several attempts at different ways to solve
this problem, here's the message I've just added to
https://review.openstack.org/#/c/97657/


I spoke to xu haiwei about this change a few days ago and agreed to have a
stab at switching from using environment variables to command-line flags,
in line with the comments above. The best way i could see to do this was to
store the password file location in $TE_DATAFILE. I wanted to check if this
was a sensible idea so I jumped into #tripleo

This led to some discussion in-channel where we (bnemec, lifeless, myself)
tried to step back, look at what problem we're trying to solve, and look
for a good way to solve it.

We think, if our understanding is correct, that we're trying to do a few
different things here:

1) The current logic (look in $CWD for passwords first, then look in
$TRIPLEO_ROOT) is confusing, especially for someone reading the code - we
think it's not particularly clear what's happening or why
2) We (who were discussing it at the time) think that we (the broader
TripleO team) want to make sure that users can drive multiple stacks - eg,
running multiple overclouds out of one undercloud - and have different
credentials for each. We (who were discussing it at the time) don't
actually know of anyone who does this, so we're only speculating that this
something that some people *might* find useful - if we could talk to
someone who needs this functionality, it would help us make sure we're
doing something useful for them
3) Looking to the future, these passwords should eventually be stored in
Barbican or something similar. In the shorter term, it would probably be a
good idea to move the passwords into $TE_DATAFILE. However, the work
required to do that today is non-trivial as we'd need to find all the
places the passwords are currently used and change the way the password is
looked up.

Looking at the history of this change, it seems that it was originally
trying to solve (1) by making the logic for finding passwords simpler and
cleaner. However, that broke (2); in trying to make (2) work again, this
change got made more complex, even though we haven't found anyone who
actually relies on this functionality working. We seem to have a solution
(put the filenames into $TE_DATAFILE) which achieves (1) and preserves the
ability to do (2) - but any work we do on it will have to be tweaked again
(probably soon) when we work on (3)

So, assuming I've understood the motivations of this change correctly,
here's what I plan to do:

1) Wait for people to tell me I've misunderstood the intent of this change
(this is a non-blocking step, other steps will proceed in parallel with
waiting)
2) Raise https://bugs.launchpad.net/tripleo/+bug/1358600 about getting a
solution for (3) (which will enable (2) and help with (1) )
3) Raise a new CR (I12d013196b0c533a0550167b9b8209e590e3bd49) which
attempts to add some docs into the scripts to clarify the existing logic

I'll copy this message onto the mailing list as well - if we've
misunderstood what's needed here, or these plans don't meet your needs,
please follow up there with some more details.


On Thu, Jul 3, 2014 at 9:10 AM, James Polley  wrote:

>
>
>
> On Thu, Jul 3, 2014 at 5:33 AM, Sullivan, Jon Paul <
> jonpaul.sulli...@hp.com> wrote:
>
>> > -Original Message-
>> > From: Giulio Fidente [mailto:gfide...@redhat.com]
>> > Sent: 01 July 2014 13:08
>> > Subject: Re: [openstack-dev] [TripleO] Time to break backwards
>> > compatibility for *cloud-password file location?
>> >
>> > On 06/25/2014 11:25 AM, mar...@redhat.com wrote:
>> > > On 25/06/14 10:52, James Polley wrote:
>> > >> Until https://review.openstack.org/#/c/83250/, the setup-*-password
>> > >> scripts used to drop password files into $CWD, which meant that if
>> > >> you ran the script from a different location next time, your old
>> > >> passwords wouldn't be found.
>> > >>
>> > >> https://review.openstack.org/#/c/83250/ changed this so that the
>> > >> default behaviour is to put the password files in $TRIPLEO_ROOT; but
>> > >> for backwards compatibility we left the script checking to see if
>> > >> there's a file in the current directory, and using that file in
>> > >> preference to $TRIPLEO_ROOT if it exists.
>> > >>
>> > >> However, this behaviour is still confusing to people. I'm not
>> > >> entirely clear on why it's confusing (it makes perfect sense to
>> > >> me...) but I imagine it's because we still have the problem that the
>> > >> code works fine if run from one directory, but run

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

[James Polley]

On Sat, Aug 23, 2014 at 11:02 AM, Anne Gentle  wrote:

>
>
>
> On Fri, Aug 22, 2014 at 6:17 PM, Rochelle.RochelleGrober <
> rochelle.gro...@huawei.com> wrote:
>
>> /flame-on
>> Ok, this is funny to some of us in the community.  The general populace
>> of this community is so against the idea of management that they will use
>> the term for a despotic dictator as a position name rather than "manager".
>> Sorry, but this needed to be said.
>> /flame-off
>>
>> Specific comments in line:
>>
>> Thierry Carrez wrote:
>> >
>> > Hi everyone,
>> >
>> > We all know being a project PTL is an extremely busy job. That's
>> > because
>> > in our structure the PTL is responsible for almost everything in a
>> > project:
>> >
>> > - Release management contact
>> > - Work prioritization
>> > - Keeping bugs under control
>> > - Communicate about work being planned or done
>> > - Make sure the gate is not broken
>> > - Team logistics (run meetings, organize sprints)
>> > - ...
>> >
>>
>> Point of clarification:  I've heard PTL=Project Technical Lead and
>> PTL=Program Technical Lead. Which is it?  It is kind of important as
>> OpenStack grows, because the first is responsible for *a* project, and the
>> second is responsible for all projects within a program.
>>
>>
> Now Program, formerly Project.
>

I think this is worthy of more exploration. Our docs seem to be very
inconsistent about what a PTL is - and more broadly, what the difference is
between a Project and a Program.

Just a few examples:

https://wiki.openstack.org/wiki/PTLguide says "Program Technical Lead".
https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014 simply says
PTL - but does say that each PTL is elected by/for a Program. However,
Thierry pointed to
https://wiki.openstack.org/wiki/Governance/Foundation/Structure which still
refers to Project Technical Leads and says explicitly that they lead
individual projects, not programs. I actually have edit access to that
page, so I could at least update that with a simple "s/Project/Program/",
if I was sure that was the right thing to do.

http://www.openstack.org/ has a link in the bottom nav that says
"Projects"; it points to http://www.openstack.org/projects/ which redirects
to http://www.openstack.org/software/ which has a list of things like
"Compute" and "Storage" - which as far as I know are Programs, not
Projects. I don't know how to update that link in the nav panel.

I wasn't around when the original Programs/Projects discussion was
happening - which, I suspect, has a lot to do with why I'm confused today -
it seems as though people who were around at the time understand the
difference, but people who have joined since then are relying on multiple
conflicting verbal definitions. I believe, though, that
http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html
was one of the earliest starting points of the discussion. That page points
at https://wiki.openstack.org/wiki/Projects, which today contains a list of
Programs. That page does have a definition of what a Program is, but
doesn't explain what a Project is or how they relate to Programs. This page
seems to be locked down, so I can't edit it.

That page does mention projects, once. The context makes it read, to me, as
though a program can follow one process to "become part of OpenStack" and
then another process to "become an Integrated project and part of the
OpenStack coordinated release" - when my understanding of reality is that
the second process applies to Projects, not Programs.

I've tried to find any other page that talks about what a Project is and
how they relate to Programs, but I haven't been able to find anything.
Perhaps there's some definition locked up in a mailing list thread or some
TC minutes, but I haven't been able to find it.

During the previous megathread, I got the feeling that at least some of the
differing viewpoints we saw were possibly down to some people thinking of a
PTL as responsible for just one project, while others think of a PTL as
being responsible for any projects that might fit within a Program's scope.
As we approach the next PTL elections, I think it would be helpful for us
to recap the discussions that led to the Program/Project split and make
sure our docs are consistent, so that people who weren't following the
discussion this time last year can still be clear what they're voting for.



>
>> I'd also like to set out as an example of a Program that is growing to
>> encompass multiple projects, the Neutron Program.  Look at how it is
>> expanding:
>>
>> Multiple sub-teams for:  LBAAS, DNAAS, GBP, etc.  This model could be
>> extended such that:
>> - the subteam is responsible for code reviews, including the first +2 for
>> design, architecture and code of the sub-project, always also keeping an
>> eye out that the sub-project code continues to both integrate well with the
>> program, and that the program continues to provide the needed code bits,
>> architecture modifications and impro

Re: [openstack-dev] [Openstack][TripleO] What if undercloud machines down, can we reboot overcloud machines?

[James Polley]

That is correct, we intend that the undercloud should be designed with HA
in mind.

In terms of the design of TripleO, the devtest.sh implementation aims to
have this available as a default (see
http://docs.openstack.org/developer/tripleo-incubator/README.html#stage-2-being-worked-on
for some dated and very brief notes about our aims). This is something
that's been receiving a lot of attention over the last cycle, but it's not
quite ready out-of-the-box yet.

In terms of implementation, this will still require the implementor to make
sure that their implementation meets their needs for HA. For instance, it
doesn't matter how many redundant neutron nodes we run if they all hang off
the back of a single physical non-redundant switch...

Are there particular concerns you have with this design?


On Thu, Aug 28, 2014 at 2:20 PM, Jyoti Ranjan  wrote:

> I do agree but it create an extra requirement for Undercloud if we high
> availability is important criteria. Because of this, undercloud has to be
> there 24x7, 365 days and to make it available we need to have HA for this
> also. So, you indirectly mean that undercloud also should be designed
> keeping high availability in mind.
>
>
> On Wed, Aug 27, 2014 at 7:53 PM, Ben Nemec  wrote:
>
>> We probably will at some point, but I don't know that it's a huge
>> priority right now.  The PXE booting method works fine, and as I
>> mentioned we don't intend you to reboot machines without using the
>> undercloud anyway, just like Nova doesn't expect you to reboot vms
>> directly via libvirt (or your driver of choice).
>>
>> It's likely there would be other issues booting a deployed machine if
>> the undercloud is down anyway (nothing to respond to DHCP requests, for
>> one), so I don't see that as something we want to encourage anyway.
>>
>> -Ben
>>
>> On 08/27/2014 04:11 AM, Jyoti Ranjan wrote:
>> > I believe that local boot option is available in Ironic. Will not be a
>> good
>> > idea to boot from local disk instead of relying on PXE boot always?
>> Curious
>> > to know why we are not going this path?
>> >
>> >
>> > On Wed, Aug 27, 2014 at 3:54 AM, 严超  wrote:
>> >
>> >> Thank you very much.
>> >> And sorry for the cross-posting.
>> >>
>> >> *Best Regards！*
>> >>
>> >>
>> >> *Chao Yan--**My twitter：Andy Yan @yanchao727
>> >> *
>> >>
>> >>
>> >> *My Weibo：http://weibo.com/herewearenow
>> >> --*
>> >>
>> >>
>> >> 2014-08-26 23:17 GMT+08:00 Ben Nemec :
>> >>
>> >> Oh, after writing my response below I realized this is cross-posted
>> >>> between openstack and openstack-dev.  Please don't do that.
>> >>>
>> >>> I suppose this probably belongs on the users list, but since I've
>> >>> already written the response I guess I'm not going to argue too much.
>> :-)
>> >>>
>> >>> On 08/26/2014 07:36 AM, 严超 wrote:
>>  Hi, All:
>>  I've deployed undercloud and overcloud on some baremetals.
>> All
>>  overcloud machines are deployed by undercloud.
>>  Then I tried to shutdown undercloud machines. After that, if
>> I
>>  reboot one overcloud machine, it will never boot from net, AKA PXE
>> used
>> >>> by
>>  undercloud.
>> >>>
>> >>> Yes, that's normal.  With the way our baremetal deployments work
>> today,
>> >>> the deployed systems always PXE boot.  After deployment they PXE boot
>> a
>> >>> kernel and ramdisk that use the deployed hard disk image, but it's
>> still
>> >>> a PXE boot.
>> >>>
>>  Is that what TripleO is designed to be ? We can never
>> shutdown
>>  undercloud machines for maintainance of overcloud ?  Please help me
>>  clearify that.
>> >>>
>> >>> Yes, that's working as intended at the moment.  I recall hearing that
>> >>> there were plans to eliminate the PXE requirement after deployment,
>> but
>> >>> you'd have to talk to the Ironic team about that.
>> >>>
>> >>> Also, I don't think it was ever the intent of TripleO that the
>> >>> undercloud would be shut down after deployment.  The idea is that you
>> >>> use the undercloud to manage the overcloud machines, so if you want to
>> >>> reboot one you do it via the undercloud nova, not directly on the
>> system
>> >>> itself.
>> >>>
>> 
>>  *Best Regards！*
>> 
>> 
>>  *Chao Yan--**My twitter：Andy Yan @yanchao727
>>  *
>> 
>> 
>>  *My Weibo：http://weibo.com/herewearenow
>>  --*
>> 
>> 
>> 
>>  ___
>>  OpenStack-dev mailing list
>>  OpenStack-dev@lists.openstack.org
>>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>> >>>
>> >>>
>> >>> ___
>> >>> OpenStack-dev mailing list
>> >>> OpenStack-dev@lists.openstack.org
>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>
>> >>
>> >>
>>

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

[James Polley]

On Thu, Aug 28, 2014 at 10:40 PM, Thierry Carrez 
wrote:

> James Polley wrote:
> >>> Point of clarification:  I've heard PTL=Project Technical Lead
> >>> and PTL=Program Technical Lead. Which is it?  It is kind of
> >>> important as OpenStack grows, because the first is responsible
> >>> for *a* project, and the second is responsible for all projects
> >>> within a program.
> >>
> >> Now Program, formerly Project.
> >
> > I think this is worthy of more exploration. Our docs seem to be very
> > inconsistent about what a PTL is - and more broadly, what the difference
> > is between a Project and a Program.
> >
> > Just a few examples:
> >
> > https://wiki.openstack.org/wiki/PTLguide says "Program Technical
> > Lead". https://wiki.openstack.org/wiki/PTL_Elections_March/April_2014
> > simply says PTL - but does say that each PTL is elected by/for a
> > Program. However, Thierry pointed
> > to https://wiki.openstack.org/wiki/Governance/Foundation/Structure which
> > still refers to Project Technical Leads and says explicitly that they
> > lead individual projects, not programs. I actually have edit access to
> > that page, so I could at least update that with a simple
> > "s/Project/Program/", if I was sure that was the right thing to do.
>
> Don't underestimate how stale wiki pages can become! Yes, fix it.
>

I don't know if I've fixed it, but I've certainly replaced all users of the
word Project with Program.

Whether or not it now matches reality, I'm not sure.

I alsp removed (what I assume is) a stale reference to the PPB and added a
new heading for the TC.


> > http://www.openstack.org/ has a link in the bottom nav that says
> > "Projects"; it points to http://www.openstack.org/projects/ which
> > redirects to http://www.openstack.org/software/ which has a list of
> > things like "Compute" and "Storage" - which as far as I know are
> > Programs, not Projects. I don't know how to update that link in the nav
> > panel.
>
> That's because the same word ("compute") is used for two different
> things: a program name ("Compute") and an "official OpenStack name" for
> a project ("OpenStack Compute a.k.a. Nova"). Basically official
> OpenStack names reduce confusion for newcomers ("What is Nova ?"), but
> they confuse old-timers at some point ("so the Compute program produces
> Nova a.k.a. OpenStack Compute ?").
>

That's confusing to me. I had thought that part of the reason for the
separation was to enable a level of indirection - if the Compute program
team decide that a new project called (for example) SuperNova should be the
main project, that just means that Openstack Compute is now a pointer to a
different project, supported by the same program team.

It sounds like that isn't the intent though?


> > I wasn't around when the original Programs/Projects discussion was
> > happening - which, I suspect, has a lot to do with why I'm confused
> > today - it seems as though people who were around at the time understand
> > the difference, but people who have joined since then are relying on
> > multiple conflicting verbal definitions. I believe, though,
> > that
> http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html
> > was one of the earliest starting points of the discussion. That page
> > points at https://wiki.openstack.org/wiki/Projects, which today contains
> > a list of Programs. That page does have a definition of what a Program
> > is, but doesn't explain what a Project is or how they relate to
> > Programs. This page seems to be locked down, so I can't edit it.
>
> https://wiki.openstack.org/wiki/Projects was renamed to
> https://wiki.openstack.org/wiki/Programs with the wiki helpfully leaving
> a redirect behind. So the content you are seeing here is the "Programs"
> wiki page, which is why it doesn't define "projects".
>
> We don't really use the word "project" that much anymore, we prefer to
> talk about code repositories. Programs are teams working on a set of
> code repositories. Some of those code repositories may appear in the
> integrated release.
>

This explanation of the difference between projects and programs sounds
like it would be useful to add to /Programs - but I can't edit that page.

>
> > That page does mention projects, once. The context makes it read, to me,
> > as though a program can follow one process to "become part of OpenSt

Re: [openstack-dev] [all] [ptls] The Czar system, or how to scale PTLs

[James Polley]

I'm fairly certain the buzzing sound I can hear is a bee in my bonnet... so
I suspect that I'm starting to sound like someone chasing a bee that only
they can hear. I'm not sure if it's helpful to keep this discussion on this
list - would there be a better forum somewhere else?


On Fri, Aug 29, 2014 at 7:34 PM, Thierry Carrez 
wrote:

> James Polley wrote:
> >
> > > However, Thierry pointed
> > > to https://wiki.openstack.org/wiki/Governance/Foundation/Structure
> > which
> > > still refers to Project Technical Leads and says explicitly that
> they
> > > lead individual projects, not programs. I actually have edit
> access to
> > > that page, so I could at least update that with a simple
> > > "s/Project/Program/", if I was sure that was the right thing to do.
> >
> > Don't underestimate how stale wiki pages can become! Yes, fix it.
> >
> > I don't know if I've fixed it, but I've certainly replaced all users of
> > the word Project with Program.
> >
> > Whether or not it now matches reality, I'm not sure.
> >
> > I alsp removed (what I assume is) a stale reference to the PPB and added
> > a new heading for the TC.
>
> It looks correct to me, thanks!
>
> > > http://www.openstack.org/ has a link in the bottom nav that says
> > > "Projects"; it points to http://www.openstack.org/projects/ which
> > > redirects to http://www.openstack.org/software/ which has a list
> of
> > > things like "Compute" and "Storage" - which as far as I know are
> > > Programs, not Projects. I don't know how to update that link in
> > the nav
> > > panel.
> >
> > That's because the same word ("compute") is used for two different
> > things: a program name ("Compute") and an "official OpenStack name"
> for
> > a project ("OpenStack Compute a.k.a. Nova"). Basically official
> > OpenStack names reduce confusion for newcomers ("What is Nova ?"),
> but
> > they confuse old-timers at some point ("so the Compute program
> produces
> > Nova a.k.a. OpenStack Compute ?").
> >
> >
> > That's confusing to me. I had thought that part of the reason for the
> > separation was to enable a level of indirection - if the Compute program
> > team decide that a new project called (for example) SuperNova should be
> > the main project, that just means that Openstack Compute is now a
> > pointer to a different project, supported by the same program team.
> >
> > It sounds like that isn't the intent though?
>
> That's more of a side-effect than the intent, IMHO. The indirection we
> created is between teams and code repositories.


> > > I wasn't around when the original Programs/Projects discussion was
> > > happening - which, I suspect, has a lot to do with why I'm confused
> > > today - it seems as though people who were around at the time
> > understand
> > > the difference, but people who have joined since then are relying
> on
> > > multiple conflicting verbal definitions. I believe, though,
> > > that
> >
> http://lists.openstack.org/pipermail/openstack-dev/2013-June/010821.html
> > > was one of the earliest starting points of the discussion. That
> page
> > > points at https://wiki.openstack.org/wiki/Projects, which today
> > contains
> > > a list of Programs. That page does have a definition of what a
> Program
> > > is, but doesn't explain what a Project is or how they relate to
> > > Programs. This page seems to be locked down, so I can't edit it.
> >
> > https://wiki.openstack.org/wiki/Projects was renamed to
> > https://wiki.openstack.org/wiki/Programs with the wiki helpfully
> leaving
> > a redirect behind. So the content you are seeing here is the
> "Programs"
> > wiki page, which is why it doesn't define "projects".
> >
> > We don't really use the word "project" that much anymore, we prefer
> to
> > talk about code repositories. Programs are teams working on a set of
> > code repositories. Some of those code repositories may appear in the
> > integrated release.
> >
> > This explanation of the difference between projects and programs sounds
> > like it would be useful to add to /Programs - but I can't edit that pa

[openstack-dev] [TripleO] Review velocity and core reviewer commitments

[James Polley]

One recurring topic in our weekly meetings over the last few months has
been the fact that it's taking us longer and longer to review and land
patches. Right now, http://www.nemebean.com/reviewstats/tripleo-open.html
has the following stats:

   - Stats since the latest revision:
  1. Average wait time: 10 days, 14 hours, 37 minutes
  2. 1st quartile wait time: 4 days, 8 hours, 45 minutes
  3. Median wait time: 7 days, 10 hours, 50 minutes
  4. 3rd quartile wait time: 15 days, 9 hours, 57 minutes
  5. Number waiting more than 7 days: 63
   - Stats since the last revision without -1 or -2 :
  1. Average wait time: 11 days, 22 hours, 21 minutes
  2. 1st quartile wait time: 4 days, 10 hours, 55 minutes
  3. Median wait time: 8 days, 3 hours, 49 minutes
  4. 3rd quartile wait time: 18 days, 23 hours, 20 minutes

 There are many things that can contribute to this; for instance, a patch
that has no negative reviews but also can't be approved (because it isn't
passing CI, or because it depends on other changes that are more
contentious) will increase these average wait times. I kicked off a
discussion about the possibility that we're measuring the wrong thing a few
weeks ago (
http://lists.openstack.org/pipermail/openstack-dev/2014-August/042960.html)
- if you've got suggestions about what we should be measuring, please
follow up there.

There's one trend I'm seeing that seems as though it's exacerbating our
sluggishness: many of our core reviewers are not meeting their commitment
to 3 reviews per day. http://www.nemebean.com/reviewstats/tripleo-30.txt
currently shows just 9 cores (and 2 non-cores!) meeting have exceeded 60
reviews over the last 30 days; 10 cores have not[1]. This isn't just a
short-term glitch either: the 90-day stats show the same numbers, although
a slightly different set of reviewers on either side of the cutoff.

The commitment to 3 reviews per day is one of the most important things we
ask of our core reviewers. We want their reviews to be good quality to help
make sure our code is also good quality - but if they can't commit to 3
reviews per day, they are slowing the project down by making it harder for
even good quality code to land. There's little point in us having good
quality code if it's perpetually out of date.

I'd like to call on all existing cores to make a concerted effort to meet
the commitment they made when they were accepted as core reviewers. We need
to ensure that patches are being reviewed and landed, and we can't do that
unless cores take the time to do reviews. If you aren't able to meet the
commitment you made when you became a core, it would be helpful if you
could let us know - or undertake a meta-review so we can consider possibly
adding some new cores (it seems like we might have 2 strong candidates, if
the quality of their reviews matches the quantity)

I'd like to call on everyone else (myself included - I've only managed 13
reviews over the last 30 days!) to help out as well. It's easier for cores
to review patchsets that already have several +1s. If you're looking for a
place to start,  http://www.nemebean.com/reviewstats/tripleo-open.html has
a list of the oldest patches that are looking for reviews, and
https://wiki.openstack.org/wiki/TripleO#Review_team has a link to a
dashboard that has sections for reviews that have been a long time without
feedback.

If you have ideas for other things we can or should measure, please follow
up on the other thread, or in our weekly meeting.

[1] lxsli and jonpaul-sullivan are cores since the conclusion of the thread
starting at
http://lists.openstack.org/pipermail/openstack-dev/2014-July/039762.html,
but not shown as such. https://review.openstack.org/#/c/118483 will correct
this.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Review metrics - what do we want to measure?

[James Polley]

There was some discussion of this topic during today's meeting.

Full notes are at
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html
starting around 19:24

To summarise, we had one action item, and one comment from dprince which
attracted broad agreement, and which I think is worth repeating here:

19:34:26  #action bnemec to look at adding a report of items that
have a -1 from a core but no response for 14 days, as a first step towards
possibly auto-WIPing these patches

19:41:54  I sort of feel like all the focus on stats in our
meetings is going to encourage people to game them (i.e. fly by reviews)
19:42:13  when what we really need is ownershipt to push through
the important things...
19:42:45 * dprince thinkgs stats are becoming a TripleO waste of time
19:44:12  stats not important, being active and responsive enough
to not push new contributors away does matter
19:44:51  jp_at_hp: I agree; the stats are a tool, not the thing
itself.

On Fri, Sep 5, 2014 at 9:47 PM, Sullivan, Jon Paul 
wrote:

> > -Original Message-
> > From: Jay Dobies [mailto:jason.dob...@redhat.com]
> > Sent: 04 September 2014 18:24
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [TripleO] Review metrics - what do we want
> > to measure?
> >
> > >> It can, by running your own... but again it seems far better for core
> > >> reviewers to decide if a change has potential or needs to be
> > >> abandoned--that way there's an accountable human making that
> > >> deliberate choice rather than the review team hiding behind an
> > >> automated process so that no one is to blame for hurt feelings
> > >> besides the infra operators who are enforcing this draconian measure
> > >> for you.
> > >
> > > The thing is that it's also pushing more work onto already overloaded
> > > core review teams.  Maybe submitters don't like auto-abandon, but I
> > > bet they like having a core reviewer spending time cleaning up dead
> > > reviews instead of reviewing their change even less.
> > >
> > > TBH, if someone's offended by the bot then I can't imagine how
> > > incensed they must be when a human does the same thing.  The bot
> > > clearly isn't making it personal, and even if the human isn't either
> > > it's much easier to have misunderstandings (see also every over-
> > reaction to a -1 ever).
> > >
> > > I suppose it makes it easier for cores to ignore reviews, but from the
> > > other discussions I've read that hasn't gone away just because
> > > auto-abandon did, so I'm not convinced that's a solution anyway.
> >
> > +1, I don't think it'll come as much of a shock if a -1 review gets
> > closed due to time without progress.
>
> +1 to auto-abandon.
>
> Taking an excerpt from Dereks mail:
>
> > A patch got negative feedback and we're automating the process
> > to prompt the submitter to deal with it. It may be more friendly if it
> > was a 2 step process
> >   1. (after a few days if inactivity) Add a comment saying you got
> > negative feedback with suggestions of how to proceed and information
> > that the review will be autoabandoned if nothing is done in X number of
> > days.
> >   2. Auto abandon patch, with as much information as possible on how to
> > reopen if needed.
>
> This sounds like the best solution.  A 1 week warning and a 2 week
> abandoning.
>
> It is about as welcoming as this sort of thing could be for a new
> committer, whilst also avoiding an ever-growing backlog of changes that
> will never see attention because the submitter has moved on to other things.
>
> There is also the benefit of prompting submitters into action when things
> get auto-abandoned, rather than them having sitting at priority #2 or #3
> forever.
>
> I was never particularly upset over the auto-abandon, just click a single
> button in the ui and get on with it.
>
> >
> > > /2 cents
> > >
> > >>
> > >>> To make the whole process a little friendlier we could increase
> > >>> the time frame from 1 week to 2.
> > >>
> > >> How about just automatically abandon any new change as soon
> > >> as it's published, and if the contributor really feels it's
> > >> important they'll unabandon it.
> > >>
> > >
> > >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Thanks,
> Jon-Paul Sullivan ☺ Cloud Services - @hpcloud
>
> Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park,
> Galway.
> Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John
> Rogerson's Quay, Dublin 2.
> Registered Number: 361933
>
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have rec

Re: [openstack-dev] [all] Bringing back auto-abandon

[James Polley]

On Thu, Sep 11, 2014 at 6:52 AM, James E. Blair  wrote:

> Steven Hardy  writes:
>
> > Yeah, I don't know what the optimal solution is - my attention has
> recently
> > been drawn to queries generated via gerrit-dash-creator, which I'm
> finding
> > help a lot.
>
> This is one of several great solutions to the problem.  Any query in
> Gerrit can include an age specifier.  To get the old behavior, just add
> "age:-2week" (that translates to "last updated less than 2 weeks ago")
> to any query -- whether a dashboard or your own bookmarked query like
> this one:
>
>
> https://review.openstack.org/#/q/status:open+age:-2week+project:openstack/nova,n,z


If someone uploads a patch, and 15 days later it's had no comments at all,
would it be visible in this query? My understanding is that it wouldn't, as
it was last updated more than two weeks ago

In my mind, a patch that's had no comments in two weeks should be high on
the list of thing that need feedback. As far as I know, Gerrit doesn't have
any way to sort by oldest-first though, so even if a two-week-old patch was
visible in the query, it would be at the bottom of the list.


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

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

[James Polley]

On Wed, Sep 17, 2014 at 6:26 PM, mar...@redhat.com 
wrote:

> Hi,
>
> as part of general housekeeping on our reviews, it was discussed at last
> week's meeting [1] that we should set workflow -1 for stale reviews
> (like gerrit used to do when I were a lad).
>
> The specific criteria discussed was 'items that have a -1 from a core
> but no response from author for 14 days'. This topic came up again
> during today's meeting and it wasn't clear if the intention was for
> cores to start enforcing this? So:
>
> Do we start setting WIP/workflow -1 for those reviews that have a -1
> from a core but no response from author for 14 days
>

I'm in favour of doing this; as long as we make it clear that we're doing
it to help us focus review effort on things that are under active
development - it doesn't mean we think the patch shouldn't land, it just
means we know it's not ready yet so we don't want reviewers to be looking
at it until it moves forward.

For the sake of making sure new developers don't get put off, I'd like to
see us leaving a comment explaining why we're WIPing the change and noting
that uploading a new revision will remove the WIP automatically

>
> thanks, marios
>
> [1]
>
> http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

[James Polley]

On Thu, Sep 18, 2014 at 8:24 AM, James E. Blair  wrote:

> "Sullivan, Jon Paul"  writes:
>
> > I think this highlights exactly why this should be an automated
> > process.  No errors in application, and no errors in interpretation of
> > what has happened.
> >
> > So the -1 from Jenkins was a reaction to the comment created by adding
> > the workflow -1.  This is going to happen on all of the patches that
> > have their workflow value altered (tests will run, result would be
> > whatever the result of the test was, of course).
>
> Jenkins only runs tests in reaction to comments if they say "recheck".
>
> > But I also agree that the Jenkins vote should not be included in the
> > determination of marking a patch WIP, but a human review should (So
> > Code-Review and not Verified column).
> >
> > And in fact, for the specific example to hand, the last Jenkins vote
> > was actually a +1, so as I understand it should not have been marked
> > WIP.
>
> I'd like to help you see the reviews you want to see without
> externalizing your individual workflow onto contributors.  What tool do
> you use to find reviews?
>

We updated our wiki back in June to point people at:

https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack%2Ftripleo-incubator+OR+project%3Aopenstack%2Ftripleo-image-elements+OR+project%3Aopenstack%2Ftripleo-heat-templates+OR+project%3Aopenstack%2Ftripleo-specs+OR+project%3Aopenstack%2Fos-apply-config+OR+project%3Aopenstack%2Fos-collect-config+OR+project%3Aopenstack%2Fos-refresh-config+OR+project%3Aopenstack%2Fos-cloud-config+OR+project%3Aopenstack%2Fdiskimage-builder+OR+project%3Aopenstack%2Fdib-utils+OR+project%3Aopenstack-infra%2Ftripleo-ci+OR+project%3Aopenstack%2Ftuskar+OR+project%3Aopenstack%2Fpython-tuskarclient%29+status%3Aopen+NOT+label%3AWorkflow%3C%3D-1+NOT+label%3ACode-Review%3C%3D-2&title=TripleO+Inbox&My+Patches+Requiring+Attention=owner%3Aself+%28label%3AVerified-1%252cjenkins+OR+label%3ACode-Review-1%29&TripleO+Specs=NOT+owner%3Aself+project%3Aopenstack%2Ftripleo-specs&Needs+Approval=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+label%3ACode-Review%3E%3D2+NOT+label%3ACode-Review-1&5+Days+Without+Feedback=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%2Ftripleo-specs+NOT+label%3ACode-Review%3C%3D2+age%3A5d&No+Negative+Feedback=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%2Ftripleo-specs+NOT+label%3ACode-Review%3C%3D-1+NOT+label%3ACode-Review%3E%3D2+limit%3A50&Other=label%3AVerified%3E%3D1%252cjenkins+NOT+owner%3Aself+NOT+project%3Aopenstack%2Ftripleo-specs+label%3ACode-Review-1+limit%3A20

It's probably not the only thing people use, but it should give you an idea
of what we'd find useful.

>
> If it's gerrit's webui, have you tried using the Review Inbox dashboard?
> Here it is for the tripleo-image-elements project:
>
>
> https://review.openstack.org/#/projects/openstack/tripleo-image-elements,dashboards/important-changes:review-inbox-dashboard


That gave me an error: Error in operator label:Code-Review>=0,self

After trying a few times I realised I hadn't logged in yet. After logging
in, it works. It'd be nice if it triggered the login sequence instead of
just giving me an error.


>
> If you would prefer something else, we can customize those dashboards to
> do whatever you want, including ignoring changes that have not been
> updated in 2 weeks.
>

I'd love to be able to sort by least-recently-updated, to encourage a FIFO
pattern. At present, even on our dashboard above, the best we've been able
to do is highlight things that are (for instance) >2 weeks without review -
but even then, the things that are just barely two weeks without review sit
at the top, while things that have been 60 days or more without review are
hidden further down.


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

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

[James Polley]

On Thu, Sep 18, 2014 at 5:21 PM, mar...@redhat.com 
wrote:

> On 17/09/14 16:40, Charles Crouch wrote:
> >
> >
> > - Original Message -
> >> Hi,
> >>
> >> as part of general housekeeping on our reviews, it was discussed at last
> >> week's meeting [1] that we should set workflow -1 for stale reviews
> >> (like gerrit used to do when I were a lad).
> >>
> >> The specific criteria discussed was 'items that have a -1 from a core
> >> but no response from author for 14 days'. This topic came up again
> >> during today's meeting and it wasn't clear if the intention was for
> >> cores to start enforcing this? So:
> >>
> >> Do we start setting WIP/workflow -1 for those reviews that have a -1
> >> from a core but no response from author for 14 days
> >>
> >> thanks, marios
> >>
> >> [1]
> >>
> http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-09-09-19.04.log.html
> >
> > So it looks like this has already started..
> >
> > https://review.openstack.org/#/c/105275/
> >
> > I think we need to document on the wiki *precisely* the criteria for
> setting
> > WIP/workflow -1. For example that review above has a Jenkins failure but
> no
> > core reviews at all.
>
> +1 on being precise - another case in point:
>
> https://review.openstack.org/#/c/102304/
>
> this review has a *-2* from core, which seems to 'stick' for future
> revisions; the last revision is from > 14 days ago, so does this fulfill
> the criteria (I'd say it doesn't)?
>
> Not sure if you were also suggesting that -1 from Jenkins also counts,
> which imo makes sense...
>
> 'items that have a -1 from core or jenkins, or a -2 from core on the
> latest revision, and no response from author for 14 days'
>
> Really this needs to be put as a motion and voted on in the next meeting,
>

My understanding has always been that we don't make decisions based on
votes on IRC meetings, because it's hard to get a time for the meeting that
allows the whole team to be easily present. I wouldn't feel comfortable
doing this at the US-timezone meeting as it excludes most of APAC; nor at
the EU-timezone meeting as it excludes most of the US.

If we're looking for consensus, I'd suggest we use Gerrit to collect votes.
We could model this is a change to the CONTRIBUTING.rst[1], or perhaps we
could draft a spec around the expected workflow (perhaps formalising some
of our expectations around cores averaging 3 reviews/workday + 1 spec
review/workday at the same time?

But perhaps I'm overthinking and making this far more formal than it has to
be. We've had a fair bit of discussion on the list and we seem to be
broadly in agreement; perhaps we just need someone to propose some details
and see if we can get consensus here.

[1] What's that you say? We don't have a CONTRIBUTING.rst? One second, let
me fix that *tap tap tap* We will as soon as
https://review.openstack.org/#/c/122350/ lands!


> thanks, marios
>
>
> >
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Set WIP for stale patches?

[James Polley]

On 18 Sep 2014, at 6:06 pm, Sullivan, Jon Paul  wrote:

>> -Original Message-
>> From: James E. Blair [mailto:cor...@inaugust.com]
>> Sent: 17 September 2014 23:24
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [TripleO] Set WIP for stale patches?
>> 
>> "Sullivan, Jon Paul"  writes:
>> 
>>> I think this highlights exactly why this should be an automated
>>> process.  No errors in application, and no errors in interpretation of
>>> what has happened.
>>> 
>>> So the -1 from Jenkins was a reaction to the comment created by adding
>>> the workflow -1.  This is going to happen on all of the patches that
>>> have their workflow value altered (tests will run, result would be
>>> whatever the result of the test was, of course).
>> 
>> Jenkins only runs tests in reaction to comments if they say "recheck".
> 
> This is not my experience.
> 
> In my experience if the check results are not fresh enough the recheck is 
> automatically run.  I am not on the infra team, so without looking up code I 
> am just guessing, but my guess is that the workflow score change triggers the 
> check on the presumption that it has been approved, not accounting for the 
> recent(ish) update that move wip to the workflow score.
>
>> 
>>> But I also agree that the Jenkins vote should not be included in the
>>> determination of marking a patch WIP, but a human review should (So
>>> Code-Review and not Verified column).
>>> 
>>> And in fact, for the specific example to hand, the last Jenkins vote
>>> was actually a +1, so as I understand it should not have been marked
>>> WIP.
>> 
>> I'd like to help you see the reviews you want to see without
>> externalizing your individual workflow onto contributors.  What tool do
>> you use to find reviews?
>> 
>> If it's gerrit's webui, have you tried using the Review Inbox dashboard?
>> Here it is for the tripleo-image-elements project:
>> 
>>  https://review.openstack.org/#/projects/openstack/tripleo-image-
>> elements,dashboards/important-changes:review-inbox-dashboard
>> 
>> If you would prefer something else, we can customize those dashboards to
>> do whatever you want, including ignoring changes that have not been
>> updated in 2 weeks.
> 
> This is not solely about finding reviews.  It is about pruning stale reviews. 
>  I think the auto-abandon code was excellent at doing this, but alas, it is 
> no more. 

The only reason i'm aware of for pruning apparently stale reviews is to make it 
easier to find and review things that are being actively worked on.

Do you have other reasons for wanting stale reviews pruned?
> 
>> 
>> -Jim
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> Thanks, 
> Jon-Paul Sullivan ☺ Cloud Services - @hpcloud
> 
> Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park, 
> Galway.
> Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John Rogerson's 
> Quay, Dublin 2. 
> Registered Number: 361933
> 
> The contents of this message and any attachments to it are confidential and 
> may be legally privileged. If you have received this message in error you 
> should delete it from your system immediately and advise the sender.
> 
> To any recipient of this message within HP, unless otherwise stated, you 
> should consider this message and attachments as "HP CONFIDENTIAL".
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] Fwd: [TripleO] mid-cycle meetup?

[James Polley]

I'd love to come, but at this stage I won't be able to travel before
about March 3, which sounds like it's a few weeks later than most
people were thinking of.



-- Forwarded message --
From: Robert Collins
mailto:robe...@robertcollins.net
>>
Date: 24 January 2014 08:47
Subject: [TripleO] mid-cycle meetup?
To:
"openstack-operat...@lists.openstack.org"
mailto:openstack-operat...@lists.openstack.org
>>


Hi, sorry for proposing this at *cough* the mid-way point [christmas
shutdown got in the way of internal acks...], but who would come if
there was a mid-cycle meetup? I'm thinking the HP sunnyvale office as
a venue.

-Rob

--
Robert Collins mailto:rbtcoll...@hp.com >>
Distinguished Technologist
HP Converged Cloud
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Tripleo] tripleo-cd-admins team update / contact info question

[James Polley]

I'm not sure how well it would work here, but I've used Pagerduty.com for 
something similar before.

The big up side of pagerduty is that it is pretty good at contacting people who 
aren't at their computers. 

It supports email notifications and webhooks for people who want to lots of 
control over what to do with alerts; push notifications to iOS or Android; and 
SMS or phone call as a last resort. Each person can configure their own alerts 
to suit them

It handles escalating unhandled alerts, including looping back to the start if 
it can't reach anyone.

It allows incidents to be handed over to arbitrary people regardless of who the 
roster says is on call, and for schedule overrides when a shift has to be 
reassigned.

Incidents can be created via REST, email, or (I think) webhooks, so it's easy 
for users or for automated systems to raise an alarm

It has some drawbacks: it would force us to define a rotation (or several 
rotations, one for each region, if we want to follow the sun), and someone 
needs to pay for it.

I think it handles most of what we want though. It gives infra admins a 
bat-signal to request urgent help, and it gives us a way to ping other team 
members when we need to hand over. It isn't very good for $randoms asking for 
low-priority issues though - it treats every incident as equally urgent.

I haven't used it, but opsgenie seems to have a similar set of features (more, 
if https://www.opsgenie.com/pagerduty is to be believed) 


> On 26 Feb 2014, at 9:30 am, Robert Collins  wrote:
> 
> In the tripleo meeting today we re-affirmed that the tripleo-cd-admins
> team is aimed at delivering production-availability clouds - thats how
> we know the the tripleo program is succeeding (or not !).
> 
> So if you're a member of that team, you're on the hook - effectively
> on call, where production issues will take precedence over development
> / bug fixing etc.
> 
> We have the following clouds today:
> cd-undercloud (baremetal, one per region)
> cd-overcloud (KVM in the HP region, not sure yet for the RH region) -
> multi region.
> ci-overcloud (same as cd-overcloud, and will go away when cd-overcloud
> is robust enough).
> 
> And we have two users:
> - TripleO ATCs, all of whom are eligible for accounts on *-overcloud
> - TripleO reviewers, indirectly via openstack-infra who provide 99%
> of the load on the clouds
> 
> Right now when there is a problem, there's no clearly defined 'get
> hold of someone' mechanism other than IRC in #tripleo.
> 
> And thats pretty good since most of the admins are on IRC most of the time.
> 
> But.
> 
> There are two holes - a) what if its sunday evening :) and b) what if
> someone (for instance Derek) has been troubleshooting a problem, but
> needs to go do personal stuff, or you know, sleep. There's no reliable
> defined handoff mechanism.
> 
> So - I think we need to define two things:
>  - a stock way for $randoms to ask for support w/ these clouds that
> will be fairly low latency and reliable.
>  - a way for us to escalate to each other *even if folk happen to be
> away from the keyboard at the time*.
> And possibly a third:
>  - a way for openstack-infra admins to escalate to us in the event of
> OMG things happening. Like, we send 1000 VMs all at once at their git
> mirrors or something.
> 
> And with that lets open the door for ideas!
> 
> -Rob
> -- 
> Robert Collins 
> Distinguished Technologist
> HP Converged Cloud
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Meeting time update

[James Polley]

On Wed, Sep 3, 2014 at 2:27 PM, Thierry Carrez 
wrote:

> Tomas Sedovic wrote:
> > As you all (hopefully) know, our meetings alternate between Tuesdays
> > 19:00 UTC and Wednesdays 7:00 UTC.
> >
> > Because of the whining^W weekly-expressed preferences[1] of the
> > Europe-based folks, the latter meetings are going to be moved by +1 hour.
> >
> > So the new meeting times are:
> >
> > * Tuesdays at 19:00 UTC (unchanged)
> > * Wednesdays at 8:00 UTC (1 hour later)
> >
> > The first new EU-friendly meeting will take place on Wednesday 17th
> > September.
> >
> > The wiki page has been updated accordingly:
> >
> > https://wiki.openstack.org/wiki/Meetings/TripleO


I've now also updated
https://wiki.openstack.org/wiki/Meetings#TripleO_team_meeting to list the
same time

>
> >
> > but I don't know how to reflect the change in the iCal feed. Anyone
> > willing to do that, please?
>
> Time updated. For some reason I don't get notified on that page change
> anymore. Sigh.
>
> Also:
>
> http://lists.openstack.org/pipermail/openstack-infra/2013-December/000517.html
>


>
> --
> Thierry Carrez (ttx)
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Finding old reviews for action

[James Polley]

At the mid-cycle, there was some discussion around using our weekly meeting
time to find 5 old reviews and assign people to shepherd those reviews -
either marking them as abandoned if there hasn't been any action, or
rounding up reviewers or people to help make changes if required to drive
it forward.

What we didn't nail down at the time was how to find the 5 reviews. Because
of the ambiguity, we spent some time a few weeks ago trying to decide on a
method. Full logs are at [1] but in short we settled on using the "Longest
waiting reviews (based on latest revision):" from [2].

I'm mentioning this on the list so that (A) we can be consistent across
meetings in how we look for issues that need attention, (B) so that other
people can suggest other methods of finding the reviews that need
attention, if this isn't the best method, and (C) in case this set of
reviews is something we might want to surface elsewhere (sadly, I don't
believe it can't be surfaced in a Gerrit dashboard, unless Gerrit can now
handle any sorting other than newest-first)


[1]
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-11-12-08.16.log.html
[2] http://russellbryant.net/openstack-stats/tripleo-openreviews.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Alternate meeting time

[James Polley]

Months ago, I pushed for us to alternate meeting times to something that
was friendlier to me, so we started doing alternate weeks at 0700UTC. That
worked well for me, but wasn't working so well for a few people in Europe,
so we decided to give 0800UTC a try. Then DST changes happened, and wiki
pages got out of sync, and there was confusion about what time the meeting
is at..

The alternate meeting hasn't been very well attended for the last ~3
meetings. Partly I think that's due to summit and travel plans, but it
seems like the 0800UTC time doesn't work very well for quite a few people.

So, instead of trying things at random, I've created
https://etherpad.openstack.org/p/tripleo-alternate-meeting-time as a
starting point for figuring out what meeting time might work well for the
most people. Obviously the world is round, and people have different
schedules, and we're never going to get a meeting time that works well for
everyone - but it'd be nice to try to maximise attendance (and minimise
inconvenience) as much as we can.

If you regularly attend, or would like to attend, the meeting, please take
a moment to look at the etherpad to register your vote for which time works
best for you. There's even a section for you to cast your vote if the
UTC1900 meeting (aka the "main" or "US-Friendly" meeting) works better for
you!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Alternate meeting time

[James Polley]

On Tue, Dec 2, 2014 at 3:22 PM, marios  wrote:

> On 02/12/14 16:10, James Polley wrote:
> > Months ago, I pushed for us to alternate meeting times to something that
> > was friendlier to me, so we started doing alternate weeks at 0700UTC.
> > That worked well for me, but wasn't working so well for a few people in
> > Europe, so we decided to give 0800UTC a try. Then DST changes happened,
> > and wiki pages got out of sync, and there was confusion about what time
> > the meeting is at..
> >
> > The alternate meeting hasn't been very well attended for the last ~3
> > meetings. Partly I think that's due to summit and travel plans, but it
> > seems like the 0800UTC time doesn't work very well for quite a few
> people.
> >
> > So, instead of trying things at random, I've
> > created https://etherpad.openstack.org/p/tripleo-alternate-meeting-time
> > as a starting point for figuring out what meeting time might work well
> > for the most people. Obviously the world is round, and people have
> > different schedules, and we're never going to get a meeting time that
> > works well for everyone - but it'd be nice to try to maximise attendance
> > (and minimise inconvenience) as much as we can.
> >
> > If you regularly attend, or would like to attend, the meeting, please
> > take a moment to look at the etherpad to register your vote for which
> > time works best for you. There's even a section for you to cast your
> > vote if the UTC1900 meeting (aka the "main" or "US-Friendly" meeting)
> > works better for you!
>
> slight clarification - are we discussing which time would suit best for
> the alternative meeting, or that we are scrapping the alternate, and
> re-voting for the best main meeting time. In either case the proposed
> times are still mostly not EU friendly (I guess the 1800 UTC would be ok
> for UK),
>
> thanks, marios
>

I was only intending to talk about the best time for the alternate meeting.

The main/US/original meeting time still seems to have been fairly well
attended lately, aside from the interruption due to summit; I haven't been
aware of any meetings that got abandoned or shortened due to lack of
participants in that timezone (except for the week of summit), and I
haven't heard anyone in that meeting talking about how hard it is for them
to make the meeting.

But perhaps I'm not hearing the people who'd like to be at that meeting -
maybe because they can't *be* at the meeting to be heard?

Derek has suggested a Doodle poll to help us look at which hours across the
week people would find it possible to make the meeting - I think the data
it gathers would help us figure out if it's worth considering moving the US
meeting time as well.

If there are other people who'd like to move the time of the US meeting so
they can make it, now is probably a good time to speak up!


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

Re: [openstack-dev] [TripleO] Alternate meeting time

[James Polley]

On Tue, Dec 2, 2014 at 4:12 PM, Giulio Fidente  wrote:

> On 12/02/2014 03:45 PM, Derek Higgins wrote:
>
>> On 02/12/14 14:10, James Polley wrote:
>>
>>> Months ago, I pushed for us to alternate meeting times to something that
>>> was friendlier to me, so we started doing alternate weeks at 0700UTC.
>>> That worked well for me, but wasn't working so well for a few people in
>>> Europe, so we decided to give 0800UTC a try. Then DST changes happened,
>>> and wiki pages got out of sync, and there was confusion about what time
>>> the meeting is at..
>>>
>>> The alternate meeting hasn't been very well attended for the last ~3
>>> meetings. Partly I think that's due to summit and travel plans, but it
>>> seems like the 0800UTC time doesn't work very well for quite a few
>>> people.
>>>
>>> So, instead of trying things at random, I've
>>> created https://etherpad.openstack.org/p/tripleo-alternate-meeting-time
>>> as a starting point for figuring out what meeting time might work well
>>> for the most people. Obviously the world is round, and people have
>>> different schedules, and we're never going to get a meeting time that
>>> works well for everyone - but it'd be nice to try to maximise attendance
>>> (and minimise inconvenience) as much as we can.
>>>
>>> If you regularly attend, or would like to attend, the meeting, please
>>> take a moment to look at the etherpad to register your vote for which
>>> time works best for you. There's even a section for you to cast your
>>> vote if the UTC1900 meeting (aka the "main" or "US-Friendly" meeting)
>>> works better for you!
>>>
>>
>>
>> Can I suggest an alternative data gathering method, I've put each hour
>> in a week in a poll, for each slot you have 3 options
>>
>
> I think it is great, but would be even better if we could trim it to just
> a *single* day and once we agreed on the timeframe, we decide on the day as
> that probably won't count much so long as it is a weekday I suppose


*hand-waggle*

I thought that at first too, but then I remembered that I had regular
commitments on thursday nights all of last year, but this year it's shifted
to wednesday night. I'd prefer to keep those nights more free than other
nights, if I can.


> --
> Giulio Fidente
> GPG KEY: 08D733BA
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Meeting purpose

[James Polley]

Hi all,

The other topic that has come up a few times in our meetings is: what value
do we get from these meetings?

There's no doubt that regular meetings provide value - but that doesn't
mean that everything we do in them is valuable.

As an example of something that I think doesn't add much value in the
meeting - DerekH has already been giving semi-regular CI/CD status reports
via email. I'd like to make these weekly update emails regular, and take
the update off the meeting agenda. I'm offering to share the load with him
to make this easier to achieve.

Are there other things on our regular agenda that you feel aren't offering
much value? Are there things you'd like to see moved onto, or off, the
agenda?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Alternate meeting time

[James Polley]

Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we've had
10 people respond so far. The winning time so far is Monday 2100UTC - 7
"yes" and one "If I have to".

... but the 2 people who can't make that time work in UTC or CET. Finding a
time that includes those people rules out people who work in Eastern
Australia and New Zealand. Purely in terms of getting the biggest numbers
in, Monday 2100UTC seems like the most workable time so far.

On Tue, Dec 2, 2014 at 4:25 PM, Derek Higgins  wrote:

> On 02/12/14 15:12, Giulio Fidente wrote:
> > On 12/02/2014 03:45 PM, Derek Higgins wrote:
> >> On 02/12/14 14:10, James Polley wrote:
> >>> Months ago, I pushed for us to alternate meeting times to something
> that
> >>> was friendlier to me, so we started doing alternate weeks at 0700UTC.
> >>> That worked well for me, but wasn't working so well for a few people in
> >>> Europe, so we decided to give 0800UTC a try. Then DST changes happened,
> >>> and wiki pages got out of sync, and there was confusion about what time
> >>> the meeting is at..
> >>>
> >>> The alternate meeting hasn't been very well attended for the last ~3
> >>> meetings. Partly I think that's due to summit and travel plans, but it
> >>> seems like the 0800UTC time doesn't work very well for quite a few
> >>> people.
> >>>
> >>> So, instead of trying things at random, I've
> >>> created
> https://etherpad.openstack.org/p/tripleo-alternate-meeting-time
> >>> as a starting point for figuring out what meeting time might work well
> >>> for the most people. Obviously the world is round, and people have
> >>> different schedules, and we're never going to get a meeting time that
> >>> works well for everyone - but it'd be nice to try to maximise
> attendance
> >>> (and minimise inconvenience) as much as we can.
> >>>
> >>> If you regularly attend, or would like to attend, the meeting, please
> >>> take a moment to look at the etherpad to register your vote for which
> >>> time works best for you. There's even a section for you to cast your
> >>> vote if the UTC1900 meeting (aka the "main" or "US-Friendly" meeting)
> >>> works better for you!
> >>
> >>
> >> Can I suggest an alternative data gathering method, I've put each hour
> >> in a week in a poll, for each slot you have 3 options
> >
> > I think it is great, but would be even better if we could trim it to
> > just a *single* day and once we agreed on the timeframe, we decide on
> > the day as that probably won't count much so long as it is a weekday I
> > suppose
>
> I think leaving the whole week in there is better, some people may have
> different schedules on different weekdays, me for example ;-)
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Alternate meeting time

[James Polley]

On Thu, Dec 4, 2014 at 11:40 AM, marios  wrote:

> On 04/12/14 11:40, James Polley wrote:
> > Just taking a look at http://doodle.com/27ffgkdm5gxzr654 again - we've
> > had 10 people respond so far. The winning time so far is Monday 2100UTC
> > - 7 "yes" and one "If I have to".
>
> for me it currently shows 1200 UTC as the preferred time.
>

You're the 11th responder :) And yes, 1200/1400/1500 are now all leading
 with 8/0/3.

>
> So to be clear, we are voting here for the alternate meeting. The
> 'original' meeting is at 1900UTC. If in fact 2100UTC ends up being the
> most popular, what would be the point of an alternating meeting that is
> only 2 hours apart in time?
>

To me the point would be to get more people able to come along to the
meeting. But if the difference *was* that small, I'd be wanting to ask if
changing the format or content of the meeting could convince more people to
join the 1900UTC meeting - I think that having just one meeting for the
whole team would be preferable, if we could manage it.

But at present, it looks like if we want to maximise attendance, we should
be focusing on European early afternoon. That unfortunately means that it's
going to be very hard for those of us in Australia/New Zealand/China/Japan
to make it - 1400UTC is 1am Sydney, 10pm Beijing. It's 7:30pm New Delhi,
which might be doable, but I don't know of anyone working there who would
regularly attend.

>
>
>
> >
> > ... but the 2 people who can't make that time work in UTC or CET.
> > Finding a time that includes those people rules out people who work in
> > Eastern Australia and New Zealand. Purely in terms of getting the
> > biggest numbers in, Monday 2100UTC seems like the most workable time so
> far.
> >
>
>
>
> > On Tue, Dec 2, 2014 at 4:25 PM, Derek Higgins  > <mailto:der...@redhat.com>> wrote:
> >
> > On 02/12/14 15:12, Giulio Fidente wrote:
> > > On 12/02/2014 03:45 PM, Derek Higgins wrote:
> > >> On 02/12/14 14:10, James Polley wrote:
> > >>> Months ago, I pushed for us to alternate meeting times to
> > something that
> > >>> was friendlier to me, so we started doing alternate weeks at
> > 0700UTC.
> > >>> That worked well for me, but wasn't working so well for a few
> > people in
> > >>> Europe, so we decided to give 0800UTC a try. Then DST changes
> > happened,
> > >>> and wiki pages got out of sync, and there was confusion about
> > what time
> > >>> the meeting is at..
> > >>>
> > >>> The alternate meeting hasn't been very well attended for the
> last ~3
> > >>> meetings. Partly I think that's due to summit and travel plans,
> > but it
> > >>> seems like the 0800UTC time doesn't work very well for quite a
> few
> > >>> people.
> > >>>
> > >>> So, instead of trying things at random, I've
> > >>> created
> > https://etherpad.openstack.org/p/tripleo-alternate-meeting-time
> > >>> as a starting point for figuring out what meeting time might
> > work well
> > >>> for the most people. Obviously the world is round, and people
> have
> > >>> different schedules, and we're never going to get a meeting time
> > that
> > >>> works well for everyone - but it'd be nice to try to maximise
> > attendance
> > >>> (and minimise inconvenience) as much as we can.
> > >>>
> > >>> If you regularly attend, or would like to attend, the meeting,
> > please
> > >>> take a moment to look at the etherpad to register your vote for
> > which
> > >>> time works best for you. There's even a section for you to cast
> your
> > >>> vote if the UTC1900 meeting (aka the "main" or "US-Friendly"
> > meeting)
> > >>> works better for you!
> > >>
> > >>
> > >> Can I suggest an alternative data gathering method, I've put each
> > hour
> > >> in a week in a poll, for each slot you have 3 options
> > >
> > > I think it is great, but would be even better if we could trim it
> to
> > > just a *single* day and once we agreed on the timeframe, we decide
> on
> > > the day as that probably won't count much so

Re: [openstack-dev] [TripleO] Meeting purpose

[James Polley]

On Thu, Dec 4, 2014 at 3:35 PM, Jay Dobies  wrote:

> As an example of something that I think doesn't add much value in the
>>> meeting - DerekH has already been giving semi-regular CI/CD status
>>> reports via email. I'd like to make these weekly update emails
>>> regular, and take the update off the meeting agenda. I'm offering to
>>> share the load with him to make this easier to achieve.
>>>
>>
> The Tuskar item is the same way. Not sure how that was added as an
> explicit agenda item, but I don't see why we'd call out to one particular
> project within TripleO. Anything we'd need eyes on should be covered when
> we chime in about specs or reviews needing eyes.
>
>  Are there other things on our regular agenda that you feel aren't
>>> offering much value?
>>>
>>
>> I'd propose we axe the regular agenda entirely and let people promote
>> things in open discussion if they need to. In fact the regular agenda
>> often seems like a bunch of motions we go through... to the extent that
>> while the TripleO meeting was going on we've actually discussed what was
>> in my opinion the most important things in the normal #tripleo IRC
>> channel. Is getting through our review stats really that important!?
>>
>
> I think the review stats would be better handled in e-mail format like
> Derek's CI status e-mails. We don't want the reviews to get out of hand,
> but the time spent pasting in the links and everyone looking at the stats
> during the meeting itself are wasteful. I could see bringing it up if it's
> becoming a problem, but the number crunching doesn't need to be part of the
> meeting.


I agree; I think it's useful to make sure we keep on top of the stats, but
I don't think it needs to be done in the meeting.


>
>
>Are there things you'd like to see moved onto, or off, the agenda?
>>>
>>
>> Perhaps a streamlined agenda like this would work better:
>>
>>   * Bugs
>>
>
> This one is valuable and I like the idea of keeping it.
>
>* Projects needing releases
>>
>
> Is this even needed as well? It feels like for months now the answer is
> always "Yes, release the world".
>

But the next question is: "Who is going to release the world?" and that is
usually a volunteer from the meeting.

Perhaps if we had a regular release team this could be arranged outside of
the meeting.


>
> I think our cadence on those release can be slowed down as well (the last
> few releases I've done have had minimal churn at best), but I'm not trying
> to thread jack into that discussion. I bring it up because we could remove
> that from the meeting and do an entirely new model where we get the release
> volunteer through other means on a (potentially) less frequent release
> basis.
>
>* Open Discussion (including important SPECs, CI, or anything needing
>> attention). ** Leader might have to drive this **
>>
>
> I like the idea of a specific Specs/Reviews section. It should be quick,
> but a specific point in time where people can #info a review they need eyes
> on. I think it appeals to my OCD to have this more structured than
> interspersed with other topics in open discussion.


One issue I have with these is that I don't know if they get seen by people
who aren't at the meeting. Perhaps a weekly email pointing to the minutes
and hilighing these would help?


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

Re: [openstack-dev] [neutron][TripleO] Clear all flows when ovs agent start? why and how avoid?

[James Polley]

On Fri, Oct 31, 2014 at 3:28 PM, Ben Nemec  wrote:

> On 10/29/2014 10:17 AM, Kyle Mestery wrote:
> > On Wed, Oct 29, 2014 at 7:25 AM, Hly  wrote:
> >>
> >>
> >> Sent from my iPad
> >>
> >> On 2014-10-29, at 下午8:01, Robert van Leeuwen <
> robert.vanleeu...@spilgames.com> wrote:
> >>
> > I find our current design is remove all flows then add flow by
> entry, this
> > will cause every network node will break off all tunnels between
> other
> > network node and all compute node.
>  Perhaps a way around this would be to add a flag on agent startup
>  which would have it skip reprogramming flows. This could be used for
>  the upgrade case.
> >>>
> >>> I hit the same issue last week and filed a bug here:
> >>> https://bugs.launchpad.net/neutron/+bug/1383674
> >>>
> >>> From an operators perspective this is VERY annoying since you also
> cannot push any config changes that requires/triggers a restart of the
> agent.
> >>> e.g. something simple like changing a log setting becomes a hassle.
> >>> I would prefer the default behaviour to be to not clear the flows or
> at the least an config option to disable it.
> >>>
> >>
> >> +1, we also suffered from this even when a very little patch is done
> >>
> > I'd really like to get some input from the tripleo folks, because they
> > were the ones who filed the original bug here and were hit by the
> > agent NOT reprogramming flows on agent restart. It does seem fairly
> > obvious that adding an option around this would be a good way forward,
> > however.
>
> Since nobody else has commented, I'll put in my two cents (though I
> might be overcharging you ;-).  I've also added the TripleO tag to the
> subject, although with Summit coming up I don't know if that will help.
>

Summit did lead to some delays - I started this response and then got
distracted, and only just found the draft again

>
> Anyway, if the bug you're referring to is the one I think, then our
> issue was just with the flows not existing.  I don't think we care
> whether they get reprogrammed on agent restart or not as long as they
> somehow come into existence at some point.
>

Is https://bugs.launchpad.net/bugs/1290486 the bug in you'rethinking of?

That seems to have been solved with https://review.openstack.org/#/c/96919/

My memory of that problem is that prior to 96919, when the daemon was
restarted, existing flows were thrown away. We'd end up with just a NORMAL
flow, which didn't route the traffic where we need it.

The fix implemented there seems to have been to implement a canary rule to
detect when this happens - ie, detect that all the existing flows had been
thrown away. Once we know they've been thrown away, we know we need to
recreate the flows that were thrown away when the daemon restarted.

If my memory is correct (and it may not be, I'm not 100% sure I fully
understood the problem at the time), the root cause here is not the change
added in 96919 - by the time that code is triggered and the flows are
reprogrammed, they've already been lost.



> It's possible I'm wrong about that, and probably the best person to talk
> to would be Robert Collins since I think he's the one who actually
> tracked down the problem in the first place.
>

I think (if I'm looking at the right bug) that you're referring to his
comment:

we're trying to do things before ovs-db is up and running and neutron-
openvswitch-agent is not handling ovs-db being down properly - it should
back off and retry, or alternatively, do a full sync once the db is
available.


As far as I can tell, everything after that point (ie, once I got involved)
focused on the latter, which is why we ended up with the canary and the
reprogramming. Assuming he's right about the race condition, it sounds as
though fixing that might be preferable. Later discussion on this thread has
centered around a full flow-synchornization approach: it sounds to me as
though handling the db being unavailable will need to be part of that
approach (we don't want to synchronize towards "no rules" just because we
can't get a canonical list of rules from the DB)


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

Re: [openstack-dev] [TripleO] Bug Squashing Day

[James Polley]

How do you find the Australian at the international online meeting?

You don't, they'll find you and make loud pointed remarks about your lack
of understanding of the ramifications of the world being round, the IDL,
and so on.

On Wed, Dec 10, 2014 at 10:36 PM, Gregory Haynes 
wrote:

> A couple weeks ago we discussed having a bug squash day. AFAICT we all
> forgot, and we still have a huge bug backlog. I'd like to propose we
> make next Wed. (12/17, in whatever 24 window is Wed. in your time zone)
> a bug squashing day. Hopefully we can add this as an item to our weekly
> meeting on Tues. to help remind everyone the day before.
>

Luckily next week's meeting is the UTC1900 meeting - so for Europe that's
Tuesday night, and for Christchurch and Sydney that's 9am and 6am
respectively. The meeting we had earlier today was  at 9am Wednesday CET
(still time for a reminder) - 10pm/8pm Wednesday in Christchurch/Sydney.

On any case, I've added a note to the agenda (
https://wiki.openstack.org/wiki/Meetings/TripleO#One-off_agenda_items) and
linked it back to the original discussion (
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-02-19.06.log.html#l-32
)

>
> Cheers,
> Greg
>
> --
>   Gregory Haynes
>   g...@greghaynes.net
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Bug Squashing Day

[James Polley]

My previous email is a long-winded whinging-aussie way of saying that I
think the bug-squashing day is a great idea, and I think Wednesday sounds
like a great day for it.

On Wed, Dec 10, 2014 at 11:01 PM, James Polley  wrote:

> How do you find the Australian at the international online meeting?
>
> You don't, they'll find you and make loud pointed remarks about your lack
> of understanding of the ramifications of the world being round, the IDL,
> and so on.
>
> On Wed, Dec 10, 2014 at 10:36 PM, Gregory Haynes 
> wrote:
>
>> A couple weeks ago we discussed having a bug squash day. AFAICT we all
>> forgot, and we still have a huge bug backlog. I'd like to propose we
>> make next Wed. (12/17, in whatever 24 window is Wed. in your time zone)
>> a bug squashing day. Hopefully we can add this as an item to our weekly
>> meeting on Tues. to help remind everyone the day before.
>>
>
> Luckily next week's meeting is the UTC1900 meeting - so for Europe that's
> Tuesday night, and for Christchurch and Sydney that's 9am and 6am
> respectively. The meeting we had earlier today was  at 9am Wednesday CET
> (still time for a reminder) - 10pm/8pm Wednesday in Christchurch/Sydney.
>
> On any case, I've added a note to the agenda (
> https://wiki.openstack.org/wiki/Meetings/TripleO#One-off_agenda_items)
> and linked it back to the original discussion (
> http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-02-19.06.log.html#l-32
> )
>
>>
>> Cheers,
>> Greg
>>
>> --
>>   Gregory Haynes
>>   g...@greghaynes.net
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleP] CI report: 2014-12-5 - 2014-12-11

[James Polley]

In the week since the last email we've had no major CI failures. This makes
it very easy for me to write my first CI report.

There was a brief period where all the Ubuntu tests failed while an update
was rolling out to various mirrors. DerekH worked around this quickly by
dropping in a DNS hack, which remains in place. A long term fix for this
problem probably involves setting up our own apt mirrors.

check-tripleo-ironic-overcloud-precise-ha remains flaky, and hence
non-voting.

As always more details can be found here (although this week there's
nothing to see)
https://etherpad.openstack.org/p/tripleo-ci-breakages
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] CI report: 2014-12-5 - 2014-12-11

[James Polley]

Resending with correct subject tag. Never send email before coffee.

On Fri, Dec 12, 2014 at 9:33 AM, James Polley  wrote:

> In the week since the last email we've had no major CI failures. This
> makes it very easy for me to write my first CI report.
>
> There was a brief period where all the Ubuntu tests failed while an update
> was rolling out to various mirrors. DerekH worked around this quickly by
> dropping in a DNS hack, which remains in place. A long term fix for this
> problem probably involves setting up our own apt mirrors.
>
> check-tripleo-ironic-overcloud-precise-ha remains flaky, and hence
> non-voting.
>
> As always more details can be found here (although this week there's
> nothing to see)
> https://etherpad.openstack.org/p/tripleo-ci-breakages
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] mid-cycle details -- CONFIRMED Feb. 18 - 20

[James Polley]

Is there a group hotel booking being arranged?

On Tue, Dec 16, 2014 at 5:26 AM, Clint Byrum  wrote:
>
> I'm happy to announce we've cleared the schedule and the Mid-Cycle is
> confirmed for February 18 - 20 in Seattle, WA at HP's downtown offices.
>
> Please refer to the etherpad linked below for details including address
> and instructions for access to the building.
>
> PLEASE make sure you add yourself to the list of confirmed attendees
> on the etherpad *BEFORE* booking travel. We have a hard limit of 30
> participants, so if you are not certain you have a spot, please contact
> me before booking travel.
>
> Excerpts from Clint Byrum's message of 2014-12-01 14:58:58 -0800:
> > Hello! I've received confirmation that our venue, the HP offices in
> > downtown Seattle, will be available for the most-often-preferred
> > least-often-cannot week of Feb 16 - 20.
> >
> > Our venue has a maximum of 20 participants, but I only have 16 possible
> > attendees now. Please add yourself to that list _now_ if you will be
> > joining us.
> >
> > I've asked our office staff to confirm Feb 18 - 20 (Wed-Fri). When they
> > do, I will reply to this thread to let everyone know so you can all
> > start to book travel. See the etherpad for travel details.
> >
> > https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][gerrit] Showing all inline comments from all patch sets

[James Polley]

I was looking at the new change screen on https://review.openstack.org
today[1] and it seems to do something vaguely similar.

Rather than saying "James polley made 4 inline comments", the contents of
the comments are shown, along with a link to the file so you can see the
context.

Have you seen this? It seems fairly similar to what you're wanting.

Have
[1] To activate it, go to
https://review.openstack.org/#/settings/preferences and set "Change view"
to "New Screen", then look at a change screen (such as
https://review.openstack.org/#/c/127283/)

On Tue, Dec 16, 2014 at 4:45 PM, Jeremy Stanley  wrote:
>
> On 2014-12-16 17:19:55 +0200 (+0200), Radoslav Gerganov wrote:
> > We don't need GoogleAppEngine if we decide that this is useful. We
> > simply need to put the html page which renders the view on
> > https://review.openstack.org. It is all javascript which talks
> > asynchronously to the Gerrit backend.
> >
> > I am using GAE to simply illustrate the idea without having to
> > spin up an entire Gerrit server.
>
> That makes a lot more sense--thanks for the clarification!
>
> > I guess I can also submit a patch to the infra project and see how
> > this works on https://review-dev.openstack.org if you want.
>
> If there's a general desire from the developer community for it,
> then that's probably the next step. However, ultimately this seems
> like something better suited as an upstream feature request for
> Gerrit (there may even already be thread-oriented improvements in
> the works for the new change screen--I haven't kept up with their
> progress lately).
> --
> Jeremy Stanley
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] py33 jobs seem to be failing

[James Polley]

Tweaking subject as this seems to be broader than just the clients

It's been seen on os-apply-config as well; I've marked 1403557 as a dupe
1403510. It's also been reported on stackforge/yaql as well as
python-*client

There's been some discussion of this in #openstack-infra and it seems
dstufft has identified the cause; I'll update 1403510 once we have
confirmation that we know what the problem is.

On Wed, Dec 17, 2014 at 5:09 PM, Steve Martinelli 
wrote:
>
> Wondering if anyone can shed some light on this, it seems like a few of
> the clients have been unable to build py33 environments lately:
>
>
> http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiTmFtZUVycm9yOiBuYW1lICdTdGFuZGFyZEVycm9yJyBpcyBub3QgZGVmaW5lZFwiIGJ1aWxkX3N0YXR1czonRkFJTFVSRSciLCJmaWVsZHMiOlsibWVzc2FnZSIsImJ1aWxkX25hbWUiLCJidWlsZF9zdGF0dXMiXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI0MzIwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjE0MTg4MzIzNzM5ODl9
>
> If you want to see additional logs I went ahead and opened a bug against
> python-openstackclient since that's where I saw it first:
> https://bugs.launchpad.net/python-openstackclient/+bug/1403557
>
> Though it seems at least glanceclient/neutronclient/keystoneclient are
> affected as well.
>
> The stack trace leads me to believe that docutils or sphinx is the
> culprit, but neither has released a new version in the time the bug has
> been around, so I'm not sure what the root cause of the problem is.
>
> Steve
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][gerrit] Showing all inline comments from all patch sets

[James Polley]

But equally I think finding out why the "New Screen" still doesn't do what
you want is valuable - it's likely other people want something similar to
what you want, so this kind of feedback can be used to decide on future
features

On Wed, Dec 17, 2014 at 8:38 AM, Radoslav Gerganov 
wrote:
>
> I am aware of this "New Screen" but it is not useful to me.  I'd like to
> see comments grouped by patchset, file and commented line rather than a
> flat view mixed with everything else.  Anyway, I guess there is no
> one-size-fits-all solution for this and everyone has different preferences
> which is cool.
>
> -Rado
>
> On 12/17/14, 8:58 AM, James Polley wrote:
>
>> I was looking at the new change screen on https://review.openstack.org
>> today[1] and it seems to do something vaguely similar.
>>
>> Rather than saying "James polley made 4 inline comments", the contents
>> of the comments are shown, along with a link to the file so you can see
>> the context.
>>
>> Have you seen this? It seems fairly similar to what you're wanting.
>>
>> Have
>> [1] To activate it, go to
>> https://review.openstack.org/#/settings/preferences and set "Change
>> view" to "New Screen", then look at a change screen (such as
>> https://review.openstack.org/#/c/127283/)
>>
>> On Tue, Dec 16, 2014 at 4:45 PM, Jeremy Stanley > <mailto:fu...@yuggoth.org>> wrote:
>>
>> On 2014-12-16 17:19:55 +0200 (+0200), Radoslav Gerganov wrote:
>> > We don't need GoogleAppEngine if we decide that this is useful. We
>> > simply need to put the html page which renders the view on
>> >https://review.openstack.org. It is all javascript which talks
>> > asynchronously to the Gerrit backend.
>> >
>> > I am using GAE to simply illustrate the idea without having to
>> > spin up an entire Gerrit server.
>>
>> That makes a lot more sense--thanks for the clarification!
>>
>> > I guess I can also submit a patch to the infra project and see how
>> > this works onhttps://review-dev.openstack.org if you want.
>>
>> If there's a general desire from the developer community for it,
>> then that's probably the next step. However, ultimately this seems
>> like something better suited as an upstream feature request for
>> Gerrit (there may even already be thread-oriented improvements in
>> the works for the new change screen--I haven't kept up with their
>> progress lately).
>> --
>> Jeremy Stanley
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> <mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Weekly meeting roundup - midcycle confirmation, nomergepy blockage

[James Polley]

We had a few topics come up in this week's meeting which we thought are
worth drawing everyone's attention to

You can see the full meeting logs at
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-12-16-19.01.log.html
(the shorter meeting notes don't have much information)

*No mergepy - blocked by bug 1401929*
As part of our plans to move away from needing merge.py, Tomas Sedovic
raised https://review.openstack.org/#/c/140375/ to make the f20 job use the
no-mergepy options.

Unfortunately this has run into a roadblock, discussed in
https://bugs.launchpad.net/heat/+bug/1401929 (Overzealous validation of
images in empty ResourceGroups).

Steve Hardy is (I believe) working on a fix, targeted at kilo-2. In the
meantime it'd be nice if we could find a workaround...

*Mid-cycle dates confirmed - please RSVP*
Clint has confirmed that we have the Seattle office booked for Feb 18-20.
We have limisted space, so if you're planning to attend, *please
visit https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
 and add
your name to the confirmed list, even if you previously indicated you were
coming. *Currently we only have 8 confirmed attendees

The etherpad also has a draft schedule and venue details. We aren't
planning to arrange a group rate for the hotel, but there are many good
hotels in a short distance from the HP office.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] CI/CD report - 2014-12-12 - 2014-12-19

[James Polley]

Two major CI outages this week

2014-12-12 - 2014-12-15 - pip install MySQL-python failing on fedora
- There was an updated mariadb-devel package, which caused pip install of
the python bindings to fail as gcc could not build using the provided
headers.
 - derekh put in a workaround on the 15th but we have to wait until
upstream provides a fixed package for a permanent resolution

2014-12-17 - failures in many projects on py33 tests
- Caused by an unexpected interaction between new features in pbr and the
way docutils handles python3 compatibility
- derekh resolved this by tweaking the build process to not build pbr -
just download the latest pbr from upstream

As always, more details can be found at
https://etherpad.openstack.org/p/tripleo-ci-breakages

The HP2 region is still struggling along trying to be built. I've created a
trello board at https://trello.com/b/MXbIP2qe/tripleo-cd to track current
roadblocks + the current outstanding patches we're using to build HP2.

If you're a CD admin and would like to help get HP2 up and running, take a
look at the board (and ping me when you hit something I've written in a way
that only makes sense if you already understand the problem). If you're not
a CD admin, a few of the patches need some simple tidyups.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

[James Polley]

Thanks for the alert

The earliest failure I can see because of this is
http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/

I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've put
some preliminary notes on
https://etherpad.openstack.org/p/tripleo-ci-breakages

On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan  wrote:

> check-tripleo-ironic-xxx failed because:
>
> rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
> rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
> Permission denie
>
> see
>
> http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html
>
> search on logstash.openstack.org:
> message:"rm: cannot remove
> `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied"
> there are 59 hits in last 48 hours
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [CI][TripleO][Ironic] check-tripleo-ironic-xxx fails

[James Polley]

as I've said on https://bugs.launchpad.net/tripleo/+bug/1405732, suspecting
this comes from "sudo pip" is a good pointer - but as far as I can tell our
tripleo-ci scripts never run "sudo pip".

This seems to be something that's happening before the testenv gets handed
to the tripleo-ci scripts. I've filed
https://review.openstack.org/#/c/144107/ to clean up all the uses of "sudo
pip" I can find in project-config, but I don't know if that will be
sufficient.

On Fri, Dec 26, 2014 at 12:13 PM, Denis Makogon 
wrote:

>
>
> On Fri, Dec 26, 2014 at 11:01 AM, Adam Gandelman  wrote:
>
>> This is fallout from a new upstream release of pip that went out earlier
>> in the week.  It looks like no formal bug ever got filed, tho the same
>> problem discovered in devstack and trove's integration testing repository.
>> Added some comments comments to the bug.
>>
>
> Proper solution was merged into devstack (see [1]) and proposed for
> trove-integration (see [2]). So, it seems that we've faced with same
> problem across multiple projects that are relaying on pip.
>
>
> [1] https://review.openstack.org/#/c/143501
> [2] https://review.openstack.org/#/c/143746/
>
> Kind regards,
> Denis M.
>
>
>> On Thu, Dec 25, 2014 at 10:59 PM, James Polley 
>> wrote:
>>
>>> Thanks for the alert
>>>
>>> The earliest failure I can see because of this is
>>> http://logs.openstack.org/43/141043/6/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/36c9771/
>>>
>>> I've raised https://bugs.launchpad.net/tripleo/+bug/1405732 and I've
>>> put some preliminary notes on
>>> https://etherpad.openstack.org/p/tripleo-ci-breakages
>>>
>>> On Fri, Dec 26, 2014 at 3:42 AM, ZhiQiang Fan 
>>> wrote:
>>>
>>>> check-tripleo-ironic-xxx failed because:
>>>>
>>>> rm -rf /home/jenkins/.cache/image-create/pypi/mirror/
>>>> rm: cannot remove `/home/jenkins/.cache/image-create/pypi/mirror/':
>>>> Permission denie
>>>>
>>>> see
>>>>
>>>> http://logs.openstack.org/37/143937/1/check-tripleo/check-tripleo-ironic-overcloud-precise-nonha/9be729b/console.html
>>>>
>>>> search on logstash.openstack.org:
>>>> message:"rm: cannot remove
>>>> `/home/jenkins/.cache/image-create/pypi/mirror/\': Permission denied"
>>>> there are 59 hits in last 48 hours
>>>>
>>>>
>>>>
>>>> ___
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev@lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] CI/CD report - 2014-12-20 - 2014-12-27

[James Polley]

It's been a bad week for CI, mostly due to setuptools.

Cores, please review https://review.openstack.org/#/c/144184/ immediately,
as CI is currently broken.

2014-12-19 - Neutron committed a change which had a symlink. This broke
"pip install neutron", which broke CI for around 6 hours.

2014-12-22 - the release of pip 6.0 immediately triggered two distinct
issues. One was fixed by 6.0.2 being released, the other required a patch
to version specifiers in ceilometer. In total, CI was broken for around 24
hours.

2014-12-24 - new nodepool images were built which contained pip 6.0. This
triggered another issue related to the fact that pip now creates ~/.cache
if it doesn't already exist. At the time of writing, CI has been broken for
~3.5 days. https://review.openstack.org/#/c/144184/ seems to fix the
problem, but it needs to get review from cores before it can land.

Not listed here: setuptools 8.4 was released, then pulled after it was
found to have problems installing/upgrading many packages. Because our CI
was already broken, this had no noticeable effect.

As always, most of this information is pulled from DerekH's notes on
https://etherpad.openstack.org/p/tripleo-ci-breakages and more details can
be found there.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] nominating James Polley for tripleo-core

[James Polley]

Thanks for the nomination Clint (and +1s from people who have already
responded)

At this stage, I believe we've traditionally[1] asked[2] the potential new
Core Reviewer to commit to 3 reviews per work-day.

I don't feel that that's a commitment I can make at this point. It's not
something I've been able to achieve in the past - I've come close over the
last 30 days, but the 90 day report shows me barely above 2 per day. I
think my current throughput is something I can commit to maintaining, and
I'd like to think that it can grow over time; but I don't think I can
commit to doing anything more than I've already been able to do.

If the rest of the core reviewers think I'm still making a valuable
contribution, I'm more than happy to accept this nomination.

[1] At least for the last 12 months or so, since I first started working on
TripleO
[2] more accurately, I believe we don't usually nominate a new Core until
they've demonstrated their commitment by having already sustained 3 reviews
per work-day for a few months
[3] http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt

On Wed, Jan 14, 2015 at 6:14 PM, Clint Byrum  wrote:

> Hello! It has been a while since we expanded our review team. The
> numbers aren't easy to read with recent dips caused by the summit and
> holidays. However, I believe James has demonstrated superb review skills
> and a commitment to the project that shows broad awareness of the
> project.
>
> Below are the results of a meta-review I did, selecting recent reviews
> by James with comments and a final score. I didn't find any reviews by
> James that I objected to.
>
> https://review.openstack.org/#/c/133554/ -- Took charge and provided
> valuable feedback. +2
> https://review.openstack.org/#/c/114360/ -- Good -1 asking for better
> commit message and then timely follow-up +1 with positive comments for
> more improvement. +2
> https://review.openstack.org/#/c/138947/ -- Simpler review, +1'd on Dec.
> 19 and no follow-up since. Allowing 2 weeks for holiday vacation, this
> is only really about 7 - 10 working days and acceptable. +2
> https://review.openstack.org/#/c/146731/ -- Very thoughtful -1 review of
> recent change with alternatives to the approach submitted as patches.
> https://review.openstack.org/#/c/139876/ -- Simpler review, +1'd in
> agreement with everyone else. +1
> https://review.openstack.org/#/c/142621/ -- Thoughtful +1 with
> consideration for other reviewers. +2
> https://review.openstack.org/#/c/113983/ -- Thorough spec review with
> grammar pedantry noted as something that would not prevent a positive
> review score. +2
>
> All current tripleo-core members are invited to vote at this time. Thank
> you!
>
> __
> 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] Alternating meeting time for more TZ friendliness

[James Polley]

To revive this thread... I'd really like to see us trying out alternate
meeting times for a while.

> Tuesdays at 14:00 UTC on #openstack-meeting-alt is available.

Looking at the iCal feed it looks like it's actually taken by Solum. But in
any case:

On Thu, Mar 20, 2014 at 11:17 AM, Robert Collins 
 wrote:

> I think we need a timezone to cover the current impossible regions:
>
>  - Australia
>  - China / Japan
>  - India
>

1400UTC is midnight Sydney time, 11pm Tokyo, 7:30pm New Delhi. Personally
that's worse for me than 1700UTC.

I'd prefer to move it significantly later than 1900UTC, especially if we
want a time that's civilized (or at least, achievable) in India. 0700UTC
seems ideal to me - 5pm Sydney, 4pm Tokyo, 12:30pm New Delhi. It's not
 friendly to the US (midnight SF, 3am NYC). but it should work well for
Europe - 8am London, and it gets later in the day as you go east.

What would we need to do to try this time out next week?


On Thu, Mar 20, 2014 at 8:03 PM,  wrote:

> On Wed, 19 Mar 2014, Sullivan, Jon Paul wrote:
>
> > > From: James Slagle [mailto:james.sla...@gmail.com]
> > > Sent: 18 March 2014 19:58
> > > Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ
> > > friendliness
> > >
> > > Our current meeting time is Tuesdays at 19:00 UTC.  I think this works
> > > ok for most folks in and around North America.
> > >
> > > It was proposed during today's meeting to see if there is interest is
> an
> > > alternating meeting time every other week so that we can be a bit more
> > > friendly to those folks that currently can't attend.
> > > If that interests you, speak up :).
> >
> > Speaking up! :D
>
> Also interested.
>
> > Tuesdays at 14:00 UTC on #openstack-meeting-alt is available.
>
> Relatively speaking, that's actually sociable.
>
> --
> Update your address books: j...@ioctl.org  http://ioctl.org/jan/
> perl -e 's?ck?t??print:perl==pants if $_="Just Another Perl Hacker\n"'
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness

[James Polley]

Actually, it's probably best that we don't do the first meeting at a
US-unfriendly timezone in a week that the summit is on in Atlanta.

Maybe the week after summit, or even the second week after summit?


On Tue, May 6, 2014 at 10:49 AM, James Polley  wrote:

> To revive this thread... I'd really like to see us trying out alternate
> meeting times for a while.
>
>
> > Tuesdays at 14:00 UTC on #openstack-meeting-alt is available.
>
> Looking at the iCal feed it looks like it's actually taken by Solum. But
> in any case:
>
>  On Thu, Mar 20, 2014 at 11:17 AM, Robert Collins <
> robe...@robertcollins.net> wrote:
>
> I think we need a timezone to cover the current impossible regions:
>>
>>  - Australia
>>  - China / Japan
>>  - India
>>
>
> 1400UTC is midnight Sydney time, 11pm Tokyo, 7:30pm New Delhi. Personally
> that's worse for me than 1700UTC.
>
> I'd prefer to move it significantly later than 1900UTC, especially if we
> want a time that's civilized (or at least, achievable) in India. 0700UTC
> seems ideal to me - 5pm Sydney, 4pm Tokyo, 12:30pm New Delhi. It's not
>  friendly to the US (midnight SF, 3am NYC). but it should work well for
> Europe - 8am London, and it gets later in the day as you go east.
>
> What would we need to do to try this time out next week?
>
>
> On Thu, Mar 20, 2014 at 8:03 PM,  wrote:
>
>> On Wed, 19 Mar 2014, Sullivan, Jon Paul wrote:
>>
>> > > From: James Slagle [mailto:james.sla...@gmail.com]
>> > > Sent: 18 March 2014 19:58
>> > > Subject: [openstack-dev] [TripleO] Alternating meeting time for more
>> TZ
>> > > friendliness
>> > >
>> > > Our current meeting time is Tuesdays at 19:00 UTC.  I think this works
>> > > ok for most folks in and around North America.
>> > >
>> > > It was proposed during today's meeting to see if there is interest is
>> an
>> > > alternating meeting time every other week so that we can be a bit more
>> > > friendly to those folks that currently can't attend.
>> > > If that interests you, speak up :).
>> >
>> > Speaking up! :D
>>
>> Also interested.
>>
>> > Tuesdays at 14:00 UTC on #openstack-meeting-alt is available.
>>
>> Relatively speaking, that's actually sociable.
>>
>> --
>> Update your address books: j...@ioctl.org  http://ioctl.org/jan/
>> perl -e 's?ck?t??print:perl==pants if $_="Just Another Perl Hacker\n"'
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Use of environment variables in tripleo-incubator

[James Polley]

I spoke to JP offline and confirmed that the link to 85418 should have been
a link to https://review.openstack.org/#/c/88252

I think that
https://etherpad.openstack.org/p/tripleo-incubator-rationalise-ui and
https://etherpad.openstack.org/p/tripleo-devtest.sh-refactoring-blueprintare
the closest things to documentation we've got about this. Now that we
have the specs repo, perhaps we should be creating a spec and moving the
discussion there.




On Tue, May 20, 2014 at 12:06 PM, Sullivan, Jon Paul <
jonpaul.sulli...@hp.com> wrote:

>  Hi,
>
>
>
> There are a number of reviews[1][2] where new environment variables are
> being disliked, leading to -1 or -2 code reviews because new environment
> variables are added.  It is looking like this is becoming a policy.
>
>
>
> If this is a policy, then could that be stated, and an alternate mechanism
> made available so that any reviews adding environment variables can use the
> replacement mechanism, please?
>
>
>
> Otherwise, some guidelines for developers where environment variables are
> acceptable or not would equally be useful.
>
>
>
> [1] https://review.openstack.org/85009
>
> [2] https://review.openstack.org/85418
>
>
>
> Thanks,
>
> ,: jonpaul.sulli...@hp.com J *Cloud Services - @hpcloud*
> (: +353 (91) 75 4169
>
>
>
> Postal Address: Hewlett-Packard Galway Limited, Ballybrit Business Park,
> Galway.
>
> Registered Office: Hewlett-Packard Galway Limited, 63-74 Sir John
> Rogerson's Quay, Dublin 2.
>
> Registered Number: 361933
>
>
>
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have received this message in error
> you should delete it from your system immediately and advise the sender.
>
>
>
> To any recipient of this message within HP, unless otherwise stated, you
> should consider this message and attachments as "HP CONFIDENTIAL".
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Installation instructions

[James Polley]

On Wed, May 21, 2014 at 4:31 PM, Jason Rist  wrote:

> On 05/21/2014 02:22 PM, Sanchez, Cristian A wrote:
> > Hi,
> > In our team we’re planning to make some contributions to TripleO, after
> we met with Robert Collins in an Intel hosted meeting during Summit.
> > As our first step we want to use TripleO to deploy the under-cloud and
> over-cloud. Is there some instructions of how to start with this?
> >
> > Thanks
> >
> > Cristian
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> Hi Cristian - There are quite a few options.  Some of us do devtest:
> https://wiki.openstack.org/wiki/Tuskar/Devtest


There are more docs for devtest at
http://docs.openstack.org/developer/tripleo-incubator/devtest.html - less
RedHat specific, but they won't get you to the point of having Tuskar
running.

That doc links to docs for the devtest_undercloud.sh and
devtest_overcloud.sh scripts, which will show you one way to deploy the
clouds.



>
> Some of us do instack:
> https://github.com/slagle/instack
>
> And some of us do devstack and then fire up another horizon with
> tuskar-ui running:
> https://github.com/openstack/tuskar-ui/blob/master/doc/source/install.rst
>
> -J
>
> --
> Jason E. Rist
> Senior Software Engineer
> OpenStack Management UI
> Red Hat, Inc.
> openuc: +1.972.707.6408
> mobile: +1.720.256.3933
> Freenode: jrist
> github/identi.ca: knowncitizen
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Spec Template Change Proposal

[James Polley]

On Wed, May 21, 2014 at 4:37 PM, Jay Dobies  wrote:

> Currently, there is the following in the template:
>
>
>
> Proposed change
> ===
>
> [snip]
>
> Alternatives
> 
>
> [snip]
>
> Security impact
> ---
>
>
>
> The unit tests assert the top and second level sections are standard, so
> if I add a section at the same level as Alternatives under Proposed Change,
> the tests will fail. If I add a third level section using ^, they pass.
>
> The problem is that you can't add a ^ section under Proposed Change.
> Sphinx complains about a title level inconsistency since I'm skipping the
> second level and jumping to the third. But I can't add a second-level
> section directly under Proposed Change because it will break the unit tests
> that validate the structure.
>
> The proposed change is going to be one of the beefier sections of a spec,
> so not being able to subdivide it is going to make the documentation messy
> and removes the ability to link directly to a portion of a proposed change.
>
> I propose we add a section at the top of Proposed Change called Overview
> that will hold the change itself. That will allow us to use third level
> sections in the change itself while still having the first and section
> section structure validated by the tests.
>

I like all of this plan, except for the name "Overview". To me, "Overview"
suggests a high-level summary rather than being "one of the beefier
sections of a spec". Something like "Detail" or "Detailed overview"
(because the low-level detail will come in the changes that implement the
spec, not in the spec) seem like better descriptions of what we intend to
have there.


> I have no problem making the change to the templates, unit tests, and any
> existing specs (I don't think we have any yet), but before I go through
> that, I wanted to make sure there wasn't a major disagreement.
>
> Thoughts?
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Change of meeting time

[James Polley]

Following a lengthy discussion under the subject "Alternating meeting tmie
for more TZ friendliness", the TripleO meeting now alternates between
Tuesday 1900UTC (the former time) and Wednesday 0700UTC, for better
coverage across Australia, India, China, Japan, and the other parts of the
world that found it impossible to get to our previous meeting time.

https://wiki.openstack.org/wiki/Meetings/TripleO#Weekly_TripleO_team_meetinghas
been updated with a link to the iCal feed so you can figure out which
time we're using each week.

The coming meeting will be our first Wednesday 0700UTC meeting. We look
forward to seeing some fresh faces (well, fresh nicks at least)!
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

[James Polley]

Thanks for putting this together Jaromir!

August 1 may be a problem for those of us from Australia - it's the day of
the OpenStack miniconf at Pycon-AU.

I don't know if any of us intended to go to that, but if we did we'd need
to leave no later than the 4:40pm flight on July 30 in order to make it
back in time - and that would have us arriving in Brisbane at 7am on the
day of the miniconf.

If we stayed till midday Friday and caught the 4:40pm flight out, we'd
arrive in BNE at 7am on the 3rd - just in time for the last day of talks
and the two days of sprints.

As I said, I'm not sure how many other people from this part of the world
had intended to go to Pycon-AU and the openstack miniconf, so I'm not sure
how much of a problem this is.


On Wed, May 28, 2014 at 9:05 PM, Jaromir Coufal  wrote:

> Hi to all,
>
> after previous TripleO & Ironic mid-cycle meetup, which I believe was
> beneficial for all, I would like to suggest that we meet again in the
> middle of Juno cycle to discuss current progress, blockers, next steps and
> of course get some beer all together :)
>
> Last time, TripleO and Ironic merged their meetings together and I think
> it was great idea. This time I would like to invite also Heat team if they
> want to join. Our cooperation is increasing and I think it would be great,
> if we can discuss all issues together.
>
> Red Hat offered to host this event, so I am very happy to invite you all
> and I would like to ask, who would come if there was a mid-cycle meetup in
> following dates and place:
>
> * July 28 - Aug 1
> * Red Hat office, Raleigh, North Carolina
>
> If you are intending to join, please, fill yourselves into this etherpad:
> https://etherpad.openstack.org/p/juno-midcycle-meetup
>
> Cheers
> -- Jarda
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] [Ironic] [Heat] Mid-cycle collaborative meetup

[James Polley]

On Fri, May 30, 2014 at 4:57 AM, Zane Bitter  wrote:

> On 29/05/14 13:33, Mike Spreitzer wrote:
>
>> Devananda van der Veen  wrote on 05/29/2014
>> 01:26:12 PM:
>>
>>  > Hi Jaromir,
>>  >
>>  > I agree that the midcycle meetup with TripleO and Ironic was very
>>  > beneficial last cycle, but this cycle, Ironic is co-locating its
>>  > sprint with Nova. Our focus needs to be working with them to merge
>>  > the nova.virt.ironic driver. Details will be forthcoming as we work
>>  > out the exact details with Nova. That said, I'll try to make the
>>  > TripleO sprint as well -- assuming the dates don't overlap.
>>  >
>>  > Cheers,
>>  > Devananda
>>  >
>>
>>  > On Wed, May 28, 2014 at 4:05 AM, Jaromir Coufal 
>> wrote:
>>  > Hi to all,
>>  >
>>  > after previous TripleO & Ironic mid-cycle meetup, which I believe
>>  > was beneficial for all, I would like to suggest that we meet again
>>  > in the middle of Juno cycle to discuss current progress, blockers,
>>  > next steps and of course get some beer all together :)
>>  >
>>  > Last time, TripleO and Ironic merged their meetings together and I
>>  > think it was great idea. This time I would like to invite also Heat
>>  > team if they want to join. Our cooperation is increasing and I think
>>  > it would be great, if we can discuss all issues together.
>>  >
>>  > Red Hat offered to host this event, so I am very happy to invite you
>>  > all and I would like to ask, who would come if there was a mid-cycle
>>  > meetup in following dates and place:
>>  >
>>  > * July 28 - Aug 1
>>  > * Red Hat office, Raleigh, North Carolina
>>  >
>>  > If you are intending to join, please, fill yourselves into this
>> etherpad:
>>  > https://etherpad.openstack.org/p/juno-midcycle-meetup
>>  >
>>  > Cheers
>>  > -- Jarda
>>
>> Given the organizers, I assume this will be strongly focused on TripleO
>> and Ironic.
>> Would this be a good venue for all the mid-cycle discussion that will be
>> relevant to Heat?
>> Is anyone planning a distinct Heat-focused mid-cycle meetup?
>>
>
> We haven't had one in the past, but the project is getting bigger so,
> given our need to sync with the TripleO folks anyway, this may be a good
> opportunity to try. Certainly it's unlikely that any Heat developers
> attending will spend the _whole_ week working with the TripleO team, so
> there should be time to do something like what you're suggesting. I think
> we just need to see who is willing & able to attend, and work out an agenda
> on that basis.
>
> For my part, I will certainly be there for the whole week if it's July 28
> - Aug 1. If it's the week before I may not be able to make it at all.
>
> BTW one timing option I haven't seen mentioned is to follow Pycon-AU's
> model of running e.g. Friday-Tuesday (July 25-29). I know nobody wants to
> be stuck in Raleigh, NC on a weekend (I've lived there, I understand ;),
> but for folks who have a long ways to travel it's one weekend lost instead
> of two.
>

I quite like this idea. Yes, it means a weekend in Raleigh, but that's
better than spending 1.5 weekends on a plane, which is what I have to do at
the moment. I'll still be spending just as much time on a plane, but doing
it during the week has less of an impact on my work/life balance.

Alternatively maybe we can find somewhere to host the next mid-cycle Down
Under ;)


> cheers,
> Zane.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Adding Tuskar to weekly IRC meetings agenda

[James Polley]

> On 30 May 2014, at 8:13 pm, Jaromir Coufal  wrote:
> 
> Hi All,
> 
> I would like to propose to add Tuskar as a permanent topic to the agenda for 
> our weekly IRC meetings. It is an official TripleO's project, there happening 
> quite a lot around it and we are targeting for Juno to have something solid. 
> So I think that it is important for us to regularly keep track on what is 
> going on there.
> 

Sounds good to me.

What do you think we would talk about under this topic? I'm thinking that a 
brief summary of changes since last week, and any blockers tuskar is seeing 
from the broader project would be a good start?

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

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

[openstack-dev] [TripleO] Reviews - we need your help!

[James Polley]

During yesterday's IRC meeting, we realized that our review stats are
starting to slip again.

Just after summit, our stats were starting to improve. In the 2014-05-20
meeting, the TripleO  "Stats since the last revision without -1 or -2"[1]
looked like this:

1rd quartile wait time: 1 days, 1 hours, 11 minutesMedian wait time: 6
days, 9 hours, 49 minutes3rd quartile wait time: 13 days, 5 hours, 46
minutes


As of yesterdays meeting, we have:

1rd quartile wait time: 4 days, 23 hours, 19 minutesMedian wait time:
7 days, 22 hours, 8 minutes3rd quartile wait time: 13 days, 19 hours,
17 minutes


This really hurts our velocity, and is especially hard on people making
their first commit, as it can take them almost a full work week before they
even get their first feedback.

To get things moving, we need everyone to make a special effort to do a few
reviews every day. It would be most helpful if you can look for older
reviews without a -1 or -2 and help those reviews get over the line.

If you find reviews that are just waiting for a simple fix - typo or syntax
fixes, simple code fixes, or a simple rebase - it would be even more
helpful if you could take a few minutes to make those patches, rather than
just leaving the review waiting for the attention of the original submitter.

Please keep in mind that these stats are based on all of our projects, not
just tripleo-incubator. To save you heading to the wiki, here's a handy
link that shows you all open code reviews in all our projects:

bit.ly/1hQco1N

If you'd prefer the long version:
https://review.openstack.org/#/q/status:open+%28project:openstack/tripleo-incubator+OR+project:openstack/tuskar+OR+project:openstack/tuskar-ui+OR+project:openstack-infra/tripleo-ci+OR+project:openstack/os-apply-config+OR+project:openstack/os-collect-config+OR+project:openstack/os-refresh-config+OR+project:openstack/os-cloud-config+OR+project:openstack/tripleo-image-elements+OR+project:openstack/tripleo-heat-templates+OR+project:openstack/diskimage-builder+OR+project:openstack/python-tuskarclient+OR+project:openstack/tripleo-specs%29,n,z

https://wiki.openstack.org/wiki/TripleO#Bug_Triage has links to reviews for
individual projects as well as more information about how we triage bugs.

[1] http://www.nemebean.com/reviewstats/tripleo-open.html
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Reviews - we need your help!

[James Polley]

Thanks Tomas and Matthew

I've updated https://wiki.openstack.org/wiki/TripleO#Review_team to have a
link to the new dashboard.


On Fri, Jun 13, 2014 at 5:20 PM, Macdonald-Wallace, Matthew <
matthew.macdonald-wall...@hp.com> wrote:

> Thanks Tomas,
>
> http://bit.ly/1lsg3SH now contains the missing projects and has been
> re-ordered slightly so that you see outdated reviews first then the
> Jenkins/-1 stuff.
>
> Cheers,
>
> Matt
>
> > -Original Message-
> > From: Tomas Sedovic [mailto:tsedo...@redhat.com]
> > Sent: 12 June 2014 19:03
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [TripleO] Reviews - we need your help!
> >
> > On 12/06/14 16:02, Macdonald-Wallace, Matthew wrote:
> > > FWIW, I've tried to make a useful dashboard for this using Sean
> > > Dague's gerrit-dash-creator [0].
> > >
> > >
> > >
> > > Short URL is http://bit.ly/1l4DLFS long url is:
> > >
> > >
> > >
> > >
> > https://review.openstack.org/#/dashboard/?foreach=%28project%3Aopenstack
> > %2Ftripleo-incubator+OR+project%3Aopenstack%2Ftripleo-image-
> > elements+OR+project%3Aopenstack%2Ftripleo-heat-
> > templates+OR+project%3Aopenstack%2Ftripleo-
> > specs+OR+project%3Aopenstack%2Fos-apply-
> > config+OR+project%3Aopenstack%2Fos-collect-
> > config+OR+project%3Aopenstack%2Fos-refresh-
> > config+OR+project%3Aopenstack%2Fdiskimage-
> > builder%29+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D-
> > 1+label%3AVerified%3E%3D1%252cjenkins+NOT+label%3ACode-
> > Review%3E%3D-
> > 2%252cself+branch%3Amaster+status%3Aopen&title=TripleO+Reviews&Your+a
> > re+a+reviewer%2C+but+haven%27t+voted+in+the+current+revision=reviewer%
> > 3Aself&Passed+Jenkins%2C+No+Negative+Feedback=NOT+label%3ACode-
> > Review%3C%3D-
> > 1+limit%3A100&Changes+with+no+code+review+in+the+last+48hrs=NOT+label
> > %3ACode-
> > Review%3C%3D2+age%3A48h&Changes+with+no+code+review+in+the+last+5+
> > days=NOT+label%3ACode-
> > Review%3C%3D2+age%3A5d&Changes+with+no+code+review+in+the+last+7+d
> > ays=NOT+label%3ACode-Review%!
> >  3C%3D2+age
> > %3A7d&Some+adjustment+required+%28-1+only%29=label%3ACode-
> > Review%3D-1+NOT+label%3ACode-Review%3D-
> > 2+limit%3A100&Dead+Specs+%28-2%29=label%3ACode-Review%3C%3D-2
> > >
> > >
> > >
> > > I'll add it to my fork and submit a PR if people think it useful.
> >
> > I was about to mention this, too. The gerrit-dash-creator is fantastic.
> >
> > This one is missing the Tuskar-related projects (openstack/tuskar,
> > openstack/tuskar-ui and openstack/python-tuskarclient) and also
> openstack/os-
> > cloud-config, though.
> >
> >
> > >
> > >
> > >
> > > Matt
> > >
> > >
> > >
> > > [0] https://github.com/sdague/gerrit-dash-creator
> > >
> > >
> > >
> > > *From:*James Polley [mailto:j...@jamezpolley.com]
> > > *Sent:* 12 June 2014 06:08
> > > *To:* OpenStack Development Mailing List (not for usage questions)
> > > *Subject:* [openstack-dev] [TripleO] Reviews - we need your help!
> > >
> > >
> > >
> > > During yesterday's IRC meeting, we realized that our review stats are
> > > starting to slip again.
> > >
> > > Just after summit, our stats were starting to improve. In the
> > > 2014-05-20 meeting, the TripleO  "Stats since the last revision
> > > without -1 or -2"[1] looked like this:
> > >
> > > 1rd quartile wait time: 1 days, 1 hours, 11 minutes
> > >
> > > Median wait time: 6 days, 9 hours, 49 minutes
> > >
> > > 3rd quartile wait time: 13 days, 5 hours, 46 minutes
> > >
> > >
> > >
> > > As of yesterdays meeting, we have:
> > >
> > > 1rd quartile wait time: 4 days, 23 hours, 19 minutes
> > >
> > > Median wait time: 7 days, 22 hours, 8 minutes
> > >
> > > 3rd quartile wait time: 13 days, 19 hours, 17 minutes
> > >
> > >
> > >
> > > This really hurts our velocity, and is especially hard on people
> > > making their first commit, as it can take them almost a full work week
> > > before they even get their first feedback.
> > >
> > > To get things moving, we need everyone to make a special effort to do
> > > a few reviews every day. It would be most helpful if you can look for
> > > older reviews witho

Re: [openstack-dev] [heatclient] Jenkins Fail (gate-python-heatclient-pypy FAILURE)

[James Polley]

I believe this is the issue being tracked in
https://bugs.launchpad.net/openstack-ci/+bug/1290562

The latest update to that issue has a suggested workaround.


On Tue, Mar 18, 2014 at 6:32 PM, 黎林果  wrote:

> Hi,
>
>Anybody know the "Jenkins Fail"?  I've encountered this fail in tow
> patches.
>
> 
> gate-python-heatclient-pypy
>  FAILURE in 1m 28s
>
> error: option --single-version-externally-managed not recognized
>
> ERROR: could not install deps 
> [-r/home/jenkins/workspace/gate-python-heatclient-pypy/requirements.txt, 
> -r/home/jenkins/workspace/gate-python-heatclient-pypy/test-requirements.txt]
>
>
> http://logs.openstack.org/58/73558/7/check/gate-python-heatclient-pypy/5157eed/console.html
>
> https://review.openstack.org/#/c/73558/
>
> Thanks!
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness

[James Polley]

> On 20 Mar 2014, at 5:44 am, Clint Byrum  wrote:
> 
> Excerpts from Sullivan, Jon Paul's message of 2014-03-19 09:26:44 -0700:
>>> From: James Slagle [mailto:james.sla...@gmail.com]
>>> Sent: 18 March 2014 19:58
>>> Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ
>>> friendliness
>>> 
>>> Our current meeting time is Tuesdays at 19:00 UTC.  I think this works
>>> ok for most folks in and around North America.
>>> 
>>> It was proposed during today's meeting to see if there is interest is an
>>> alternating meeting time every other week so that we can be a bit more
>>> friendly to those folks that currently can't attend.
>>> If that interests you, speak up :).
>> 
>> Speaking up! :D
>> 
>>> 
>>> For reference, the current meeting schedules are at:
>>> https://wiki.openstack.org/wiki/Meetings
>> 
>> Tuesdays at 14:00 UTC on #openstack-meeting-alt is available.
> 
> If we were to have one at that time, we'd need to move the other time as
> well. One driver for moving it is that our participants on the Eastern
> side of Australia are already joining at 0600 their time, and will be
> joining at 0500 soon.
> 
> If I've done my TZ math right, Tuesdays at 1400 UTC would be Wednesdays
> at 0100 for Sydney.

0100 now,  in a few weeks when DST flips here. I'd prefer 0500 to 

My first priority is making sure that theacimum 
Speaking for myself, I find the current time is slightly painful, but doable. 
0500 will be more painful.

If I'm reading the iCal feed linked from 
https://wiki.openstack.org/wiki/Meetings correctly, it looks like there's a PCI 
passthrough meeting scheduled at that time in -alt. Is that correct? Is the 
iCal feed canonical? I don't see the meeting listed on the page, but maybe 
that's also because of the tiny little screen I'm using right now.

If I'm doing the timezone math right, it looks like the iCal feed says that 
2100UTC Wednesday is free every second week. Once all the DST flips happen, 
that'll be 2100 London, 1500 SF, 0700 Sydney. 

If we ran at that time on alternate weeks I'd have one I could make easily and 
one I could probably make at a stretch.


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

Re: [openstack-dev] [TripleO] Alternating meeting time for more TZ friendliness

[James Polley]

On Thu, Mar 20, 2014 at 7:00 AM, James Polley  wrote:

>
>
> On 20 Mar 2014, at 5:44 am, Clint Byrum  wrote:
>
> Excerpts from Sullivan, Jon Paul's message of 2014-03-19 09:26:44 -0700:
>
> From: James Slagle [mailto:james.sla...@gmail.com 
> ]
>
> Sent: 18 March 2014 19:58
>
> Subject: [openstack-dev] [TripleO] Alternating meeting time for more TZ
>
> friendliness
>
>
> Our current meeting time is Tuesdays at 19:00 UTC.  I think this works
>
> ok for most folks in and around North America.
>
>
> It was proposed during today's meeting to see if there is interest is an
>
> alternating meeting time every other week so that we can be a bit more
>
> friendly to those folks that currently can't attend.
>
> If that interests you, speak up :).
>
>
> Speaking up! :D
>
>
>
> For reference, the current meeting schedules are at:
>
> https://wiki.openstack.org/wiki/Meetings
>
>
> Tuesdays at 14:00 UTC on #openstack-meeting-alt is available.
>
>
>
> If we were to have one at that time, we'd need to move the other time as
> well. One driver for moving it is that our participants on the Eastern
> side of Australia are already joining at 0600 their time, and will be
> joining at 0500 soon.
>
> If I've done my TZ math right, Tuesdays at 1400 UTC would be Wednesdays
> at 0100 for Sydney.
>
>
> 0100 now,  in a few weeks when DST flips here. I'd prefer 0500 to 
>
> My first priority is making sure that theacimum
>

Ah. So that's what happened to the email I was composing on my iPhone - it
got sent! Next time I'll ask my pocket to delete it rather than send it.

As I was trying to say, I think our priority should be maximizing the
number of people who can attend, not maximizing for me attending. I worry
that having alternating meetings will lead to having non-overlapping sets
of people in the meetings, but even if that happens I'm not sure if it's
worse than only having a subset of people in the meeting.

I'd be happy to stick with 1900UTC if it means more people can regularly
make the meeting, even if it means I can't make it all the time. Switching
to alternating 1900 Tuesday and 2100 Wednesday would mean I could make more
meetings, but I don't know how it would affect other people.

Speaking for myself, I find the current time is slightly painful, but
> doable. 0500 will be more painful.
>
> If I'm reading the iCal feed linked from
> https://wiki.openstack.org/wiki/Meetings correctly, it looks like there's
> a PCI passthrough meeting scheduled at that time in -alt. Is that correct?
> Is the iCal feed canonical? I don't see the meeting listed on the page, but
> maybe that's also because of the tiny little screen I'm using right now.
>
> If I'm doing the timezone math right, it looks like the iCal feed says
> that 2100UTC Wednesday is free every second week. Once all the DST flips
> happen, that'll be 2100 London, 1500 SF, 0700 Sydney.
>

Bad time math - I was in the middle of updating this when my phone decided
to send the mail. 2100UTC will be 2200 London, 1400 SF, 0700 Sydney.


>
> If we ran at that time on alternate weeks I'd have one I could make easily
> and one I could probably make at a stretch.
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Bringing back auto-abandon

[James Polley]

On Thu, Sep 11, 2014 at 8:32 AM, James E. Blair  wrote:

> James Polley  writes:
>
> > On Thu, Sep 11, 2014 at 6:52 AM, James E. Blair 
> wrote:
> >
> >> Steven Hardy  writes:
> >>
> >> > Yeah, I don't know what the optimal solution is - my attention has
> >> recently
> >> > been drawn to queries generated via gerrit-dash-creator, which I'm
> >> finding
> >> > help a lot.
> >>
> >> This is one of several great solutions to the problem.  Any query in
> >> Gerrit can include an age specifier.  To get the old behavior, just add
> >> "age:-2week" (that translates to "last updated less than 2 weeks ago")
> >> to any query -- whether a dashboard or your own bookmarked query like
> >> this one:
> >>
> >>
> >>
> https://review.openstack.org/#/q/status:open+age:-2week+project:openstack/nova,n,z
> >
> >
> > If someone uploads a patch, and 15 days later it's had no comments at
> all,
> > would it be visible in this query? My understanding is that it wouldn't,
> as
> > it was last updated more than two weeks ago
> >
> > In my mind, a patch that's had no comments in two weeks should be high on
> > the list of thing that need feedback. As far as I know, Gerrit doesn't
> have
> > any way to sort by oldest-first though, so even if a two-week-old patch
> was
> > visible in the query, it would be at the bottom of the list.
>
> Indeed, however, a slightly different query will get you exactly what
> you're looking for.  This will show changes that are at least 2 days
> old, have no code reviews, are not WIP, and have passed Jenkins:
>
>   project:openstack/nova status:open label:Verified>=1,jenkins NOT
> label:Workflow<=-1 NOT label:Code-Review<=2 age:2d
>
> or the direct link:
>
>
> https://review.openstack.org/#/q/project:openstack/nova+status:open+label:Verified%253E%253D1%252Cjenkins+NOT+label:Workflow%253C%253D-1+NOT+label:Code-Review%253C%253D2+age:2d,n,z


Weeks later I finally went to add this to our dashboard, only to find that
we already have something similar, if I'm reading correctly.

http://git.openstack.org/cgit/stackforge/gerrit-dash-creator/tree/dashboards/tripleo.dash#n15

[section "5 Days Without Feedback"]
query = label:Verified>=1%2cjenkins NOT owner:self NOT
project:openstack/tripleo-specs NOT label:Code-Review<=2 age:5d


(plus the other qualifiers added in the header: status:open NOT
label:Workflow<=-1 NOT label:Code-Review<=-2)

This particular section is okay right now - only one change visible. The
"Needs Approval" section (query = label:Verified>=1%2cjenkins NOT
owner:self label:Code-Review>=2 NOT label:Code-Review-1) is more of a
problem; 43 reviews, with the oldest hidden at the bottom.

I can see a few ways I could improve this; one would be to to split "Needs
approval" into multiple sections - "Needs Approval" for 0-5 days, "Really
needs approval" for 5-10, and so on. Another would be to add something to
enable oldest-first sorting in Gerrit. I'm thinking that it doesn't even
need to be server-side, a client-side script (just like the one that adds
the "Toggle CI" button) would probably suffice to enable the sorting.

If anyone has other ideas before I start tinkering with jquery to make the
tables sortable, I'd love to hear it - but from my limited experience with
jquery I don't think it should be too much of an issue.


>
>
> Incidentally, that is the query in the "Wayward Changes" section of the
> "Review Inbox" dashboard (thanks Sean!); for nova, you can see it here:
>
>
> https://review.openstack.org/#/projects/openstack/nova,dashboards/important-changes:review-inbox-dashboard
>
> The key here is that there are a lot of changes in a lot of different
> states, and one query isn't going to do everything that everyone wants
> it to do.  Gerrit has a _very_ powerful query language that can actually
> help us make sense of all the changes we have in our system without
> externalizing the cost of that onto contributors in the form of
> forced-abandoning of changes.  Dashboards can help us share the
> knowledge of how to get the most out of it.
>
>   https://review.openstack.org/Documentation/user-dashboards.html
>   https://review.openstack.org/Documentation/user-search.html
>
> -Jim
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Summit topics

[James Polley]

The Summit Planning wiki page[1] links to an etherpad[2] for planning
topics for us to discuss at summit.

So far there's only one topic listed - which makes me happy, as it's a
topic I proposed (and will email about again next week after I'm back from
leave). Are there other things we want to talk about in Paris? Is there
somewhere else we're using for planning?

I'm hoping to see some other topics listed on the etherpad over the next
few days :)


[1] https://wiki.openstack.org/wiki/Summit/Planning
[2] https://etherpad.openstack.org/p/kilo-tripleo-summit-topics
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state

[James Polley]

All three of the options presented here seem to assume that UIDs will always be 
allocated at image-build time. I think that's because most of these UIDs will 
be used to write files into the chroot at image-create time - if I could think 
of some way around that, I think we could avoid this problem more neatly by not 
assigning the UIDs until first boot

But since we can't do that, would it be possible to compromise by having the 
UIDs read in from heat metadata, and using the current allocation process if 
none is provided?

This should allow people who prefer to have static UIDs to have simple drop-in 
config, but also allow people who want to dynamically read from existing images 
to scrape the details and then drop them in.

To aid people who have existing images, perhaps we could provide a small tool 
(if one doesn't already exist) that simply reads /etc/passwd and returns a JSON 
username:uid map, to be added into the heat local environment when building the 
next image?

> On 2 Oct 2014, at 11:50, Clint Byrum  wrote:
> 
> Recently we've been testing image based updates using TripleO, and we've
> run into an interesting conundrum.
> 
> Currently, our image build scripts create a user per service for the
> image. We don't, at this time, assert a UID, so it could get any UID in
> the /etc/passwd database of the image.
> 
> However, if we add a service that happens to have its users created
> before a previously existing service, the UID's shift by one. When
> this new image is deployed, the username might be 'ceilometer', but
> /mnt/state/var/lib/ceilometer is now owned by 'cinder'.
> 
> Here are 3 approaches, which are not mutually exclusive to one another.
> There are likely others, and I'd be interested in hearing your ideas.
> 
> * Static UID's for all state-preserving services. Basically we'd just
>  allocate these UID's from a static pool and those are always the UIDs
>  no matter what. This is the simplest solution, but does not help
>  anybody who is already looking to update a TripleO cloud. Also, this
>  would cause problems if TripleO wants to merge with any existing
>  system that might also want to use similar UID's. This also provides
>  no guard against non-static UID's storing things on the state
>  partition.
> 
> * Fix the UID's on image update. We can backup /etc/passwd and
>  /etc/group to /mnt/state, and on bootup we can diff the two, and any
>  UIDs that changed can be migrated. This could be very costly if the
>  swift storage UID changed, with millions of files present on the
>  system. This merge process is also not atomic and may not be
>  reversible, so it is a bit scary to automate this.
> 
> * Assert ownership when registering state path. We could have any
>  state-preserving elements register their desire for any important
>  globs for the state drive to be owned by a particular symbolic
>  username. This is just a different, more manual way to fix the UID's
>  and carries the same cons.
> 
> So, what do people think?
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state

[James Polley]

> On 3 Oct 2014, at 00:25, Clint Byrum  wrote:
> 
> Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
>> All three of the options presented here seem to assume that UIDs will always 
>> be allocated at image-build time. I think that's because most of these UIDs 
>> will be used to write files into the chroot at image-create time - if I 
>> could think of some way around that, I think we could avoid this problem 
>> more neatly by not assigning the UIDs until first boot
> 
> Yeah I don't think we're going to work around that. It is part of the
> magic of images that the metadata is all in place and there's no "churn"
> at boot.

Agree - it would be quite a significant change in how TripleO works, not just a 
workaround.

> 
>> But since we can't do that, would it be possible to compromise by having the 
>> UIDs read in from heat metadata, and using the current allocation process if 
>> none is provided?
> 
> I really, really dislike this. Post-boot tools like Heat are for
> per-server customization and site-wide changes. UIDs seem like plumbing
> under the hood.

I think that the part of this you dislike is specifically storing the data in 
heat?

Would you object less if I phrased it as "a job file to be read at image build 
time", which is closer to what I had in mind?

> 
>> This should allow people who prefer to have static UIDs to have simple 
>> drop-in config, but also allow people who want to dynamically read from 
>> existing images to scrape the details and then drop them in.
> 
> I see your point, and I'm now confused as I don't really understand what
> would make somebody prefer dynamic UID allocation.

I was thinking of a case where an operator might have several existing images 
with different sets of services, or different base distribtions, and hence 
different sets of uids; they'd probably prefer to have the build process 
extract the details from the previous image rather than having a single fixed 
map of uids.

Someone starting fresh might prefer to provide a static map of pre-assigned UIDs


>> To aid people who have existing images, perhaps we could provide a small 
>> tool (if one doesn't already exist) that simply reads /etc/passwd and 
>> returns a JSON username:uid map, to be added into the heat local environment 
>> when building the next image?
> 
> Or a tool that reads the image, and returns /etc/passwd and /etc/group.

Sure, but I think it would be handy if it could accept data from another source 
as well as the previous image, to cater for people who want to be more 
prescriptive about which UIDs are used but don't have adv Bing existing image 
yet.

I don't know if this is a real use case though - maybe I'm just remembering bad 
experiences from a previous pre-cloud life.

> 
> Thanks very much for your thoughts. :)
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [TripleO] a need to assert user ownership in preserved state

[James Polley]

> On 3 Oct 2014, at 02:57, James Polley  wrote:
> 
> 
> 
> 
> 
>> On 3 Oct 2014, at 00:25, Clint Byrum  wrote:
>> 
>> Excerpts from James Polley's message of 2014-10-01 22:37:25 -0700:
>>> All three of the options presented here seem to assume that UIDs will 
>>> always be allocated at image-build time. I think that's because most of 
>>> these UIDs will be used to write files into the chroot at image-create time 
>>> - if I could think of some way around that, I think we could avoid this 
>>> problem more neatly by not assigning the UIDs until first boot
>> 
>> Yeah I don't think we're going to work around that. It is part of the
>> magic of images that the metadata is all in place and there's no "churn"
>> at boot.
> 
> Agree - it would be quite a significant change in how TripleO works, not just 
> a workaround.
> 
>> 
>>> But since we can't do that, would it be possible to compromise by having 
>>> the UIDs read in from heat metadata, and using the current allocation 
>>> process if none is provided?
>> 
>> I really, really dislike this. Post-boot tools like Heat are for
>> per-server customization and site-wide changes. UIDs seem like plumbing
>> under the hood.
> 
> I think that the part of this you dislike is specifically storing the data in 
> heat?
> 
> Would you object less if I phrased it as "a job file to be read at image 
> build time", which is closer to what I had in mind?
> 
>> 
>>> This should allow people who prefer to have static UIDs to have simple 
>>> drop-in config, but also allow people who want to dynamically read from 
>>> existing images to scrape the details and then drop them in.
>> 
>> I see your point, and I'm now confused as I don't really understand what
>> would make somebody prefer dynamic UID allocation.
> 
> I was thinking of a case where an operator might have several existing images 
> with different sets of services, or different base distribtions, and hence 
> different sets of uids; they'd probably prefer to have the build process 
> extract the details from the previous image rather than having a single fixed 
> map of uids.

> Someone starting fresh might prefer to provide a static map of pre-assigned 
> UIDs

To be clear - I don't think either of these is novel - these are cases 1 and  2 
from the mail that started the thread.

The point I'm ineptly trying to make (why am I sending email at 3am?) is that I 
think we can easily support both 1 and 2 simply by thinking of "read list of 
UIDs from an existing image" and "apply existing list of UIDs to new image" as 
separate tasks and implement both separately 

> 
> 
>>> To aid people who have existing images, perhaps we could provide a small 
>>> tool (if one doesn't already exist) that simply reads /etc/passwd and 
>>> returns a JSON username:uid map, to be added into the heat local 
>>> environment when building the next image?
>> 
>> Or a tool that reads the image, and returns /etc/passwd and /etc/group.
> 
> Sure, but I think it would be handy if it could accept data from another 
> source as well as the previous image, to cater for people who want to be more 
> prescriptive about which UIDs are used but don't have adv Bing existing image 
> yet.
> 
> I don't know if this is a real use case though - maybe I'm just remembering 
> bad experiences from a previous pre-cloud life.
> 
>> 
>> Thanks very much for your thoughts. :)
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [TripleO] Kilo Mid-Cycle Meetup Planning

[James Polley]

> On 10 Oct 2014, at 07:32, Gregory Haynes  wrote:
> 
> Hello TripleO-ers,
> 
> Last time around there was a lot of feedback that we should plan our
> mid-cycle metup a lot sooner, so lets do that! I've created a (mostly
> bare) etherpad here:
> 
> https://etherpad.openstack.org/p/kilo-tripleo-midcycle-meetup
> 
> Note that there are currently no possible venues listed. If you are able
> to provide a possible venue (Thank you!) please reply and/or add it to
> the etherpad.
> 
> I have also listed a few possible Mon-Fri meetup dates. Do not take this
> as any indication that Mon-Fri is an ideal meetup length or time of
> week, and feel free to add feedback / combinations of your own.
> Personally, I felt pretty burned out by Friday last time so maybe
> Mon-Wed is a better size?

Assuming it's in the US or Europe, Mon-Fri gives me about 3 useful days, once 
you take out the time I lose to jet lag. That's barely worth the 48 hours or so 
I spent in transit last time.

I would strongly prefer not to reduce the length of the mid-cycle. I agree that 
it can be quite draining but reducing the length would make it much more 
draining for me. 

I'd feel different if it was hosted somewhere localish to me, and I think it's 
reasonable that we plan the mid-cycle around what works for the majority of 
attendees rather than the minority. But even so, my personal preference is for 
a full week.
> 
> Cheers,
> Greg
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [TripleO] prep-source-repos - new tool for managing repos+patchsets?

[James Polley]

I've got a new tool, currently called prep-source-repos, that I'd like to
set up as a new project. Most of the work was done by adamg and lifeless,
with a bit of polish from me to make it ready to be packaged.

The tool is something the tripleo-cd-admins have been using to let us
deploy a cloud from trunk + unlanded patchsets from Gerrit. It takes a YAML
file with a list of repos to clone, then allows for individual gerrit
patches to be added on top. It also creates a file with all the DIB_REPO*
variables required to have DIB use these local patched repos rather than
the upstream repos.

This allows us to test out patches - to TripleO tools, but also to any of
the other openstack tools we install from source - without needing to wait
for them to land.

I believe it's something that can be useful in other places as well though:

* I think that it could replace
http://git.openstack.org/cgit/openstack/tripleo-incubator/tree/scripts/pull-tools
as something we use inside TripleO to pull and update the tools we use
* In https://review.openstack.org/#/c/118426/ jp_at_hp proposed a simpler
tool that applies patches from gerrit to individual repos; I think
prep-source-repos solves the need for this as well
* At one point I was running Gertty from trunk with a whole bunch of
un-landed patches from lifeless and I. To make things easier on myself, I'd
pushed my changes to Gerrit as being a big dependency chain, which didn't
reflect reality. push-source-repose would make it easy to run Gerrit from
upstream trunk + pull in all my unlanded patches, without needed to set up
a fake dependency tree.

The code is currently sitting at
https://github.com/jamezpolley/prep-source-repos, but I'd like to add it to
git.openstack.org, (probably as a stackforge project) if there's consensus
that this is something we'd find useful.

So, right now, I've got two questions for the team:

* Can you think of a better name? prep-source-repos sounds a bit clumsy to
me, but I haven't been able to come up with anything I like better.
* Am I wrong in thinking that this tool is useful enough to be worth
splitting out into its own repo?
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] Weekly meeting

[James Polley]

Minutes are at
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.html
(or
http://eavesdrop.openstack.org/meetings/tripleo/2014/tripleo.2014-06-25-06.59.txt
if you prefer plain-text). For your convenience I've pasted them below.

During the meeting it was suggested we add a "Specs" item to the agenda for
any specs people want to ask for more eyeballs on. I've added this to the
agenda for next week.

I don't plan to regularly mail these minutes (they're always at
http://eavesdrop.openstack.org/meetings/tripleo) but we had particularly
low attendance today and we have a couple of time-sensitive one-off items.
#openstack-meeting-alt: tripleoMeeting started by tchaypo at 06:59:56 UTC (full
logs

).

Meeting summary

   1. *bugs* (tchaypo
   
,
   07:01:20)
  1. https://bugs.launchpad.net/tripleo/ (tchaypo
  
,
  07:01:29)
  2. https://bugs.launchpad.net/diskimage-builder/ (tchaypo
  
,
  07:01:32)
  3. https://bugs.launchpad.net/os-refresh-config (tchaypo
  
,
  07:01:34)
  4. https://bugs.launchpad.net/os-apply-config (tchaypo
  
,
  07:01:36)
  5. https://bugs.launchpad.net/os-collect-config (tchaypo
  
,
  07:01:38)
  6. https://bugs.launchpad.net/os-cloud-config (tchaypo
  
,
  07:01:40)
  7. https://bugs.launchpad.net/tuskar (tchaypo
  
,
  07:01:42)
  8. https://bugs.launchpad.net/python-tuskarclient (tchaypo
  
,
  07:01:44)
  9. https://review.openstack.org/#/c/98758/ (GheRivero
  
,
  07:06:07)

   2. *reviews* (tchaypo
   
,
   07:07:40)
  1. There's a new dashboard linked from
  https://wiki.openstack.org/wiki/TripleO#Review_team - look for
  "TripleO Inbox Dashboard" (tchaypo
  
,
  07:07:44)
  2. http://russellbryant.net/openstack-stats/tripleo-openreviews.html (
  tchaypo
  
,
  07:07:47)
  3. http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt (
  tchaypo
  
,
  07:07:49)
  4. http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt (
  tchaypo
  
,
  07:07:51)
  5. 3rd quartile has dropped from 13 days 12 hours to 11 days 21 hours
  over the last week, other quartiles roughly unchanged (tchaypo
  
,
  07:10:20)
  6. stackforge/gertty is a tty-based locally-caching client for
  gerrit, so you can do reviews on a plane (tchaypo
  
,
  07:14:41)

   3. *Projects needing releases* (tchaypo
   
,
   07:18:20)
  1. shadower will release all the things (shadower
  
,
  07:21:46)
  2. https://wiki.openstack.org/wiki/TripleO/ReleaseManagement (tchaypo
  
,
  07:22:24)

   4. *CD Cloud status* (tchaypo
   
,
   07:22:37)
  1. https://review.openstack.org/#/c/102291/ should land before
  releasing dif-utils (shadower
  

[openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?

[James Polley]

Until https://review.openstack.org/#/c/83250/, the setup-*-password scripts
used to drop password files into $CWD, which meant that if you ran the
script from a different location next time, your old passwords wouldn't be
found.

https://review.openstack.org/#/c/83250/ changed this so that the default
behaviour is to put the password files in $TRIPLEO_ROOT; but for backwards
compatibility we left the script checking to see if there's a file in the
current directory, and using that file in preference to $TRIPLEO_ROOT if it
exists.

However, this behaviour is still confusing to people. I'm not entirely
clear on why it's confusing (it makes perfect sense to me...) but I imagine
it's because we still have the problem that the code works fine if run from
one directory, but run from a different directory it can't find passwords.

There are two open patches which would break backwards compatibility and
only ever use the files in $TRIPLEO_ROOT:

https://review.openstack.org/#/c/93981/
https://review.openstack.org/#/c/97657/

The latter review is under more active development, and has suggestions
that the directory containing the password files should be parameterised,
defaulting to $TRIPLEO_ROOT. This would still break for anyone who relies
on the password files being in the directory they run the script from, but
at least there would be a fairly easy fix for them.

To help decide if it's time to break backwards compatibility in this case
(and if so, how), I'd love to see some more comments on 97657. If we don't
want to break backwards compatibility, maybe comments about a better way to
handle the ambiguity would be helpful.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] Time to break backwards compatibility for *cloud-password file location?

[James Polley]

On Thu, Jul 3, 2014 at 5:33 AM, Sullivan, Jon Paul 
wrote:

> > -Original Message-
> > From: Giulio Fidente [mailto:gfide...@redhat.com]
> > Sent: 01 July 2014 13:08
> > Subject: Re: [openstack-dev] [TripleO] Time to break backwards
> > compatibility for *cloud-password file location?
> >
> > On 06/25/2014 11:25 AM, mar...@redhat.com wrote:
> > > On 25/06/14 10:52, James Polley wrote:
> > >> Until https://review.openstack.org/#/c/83250/, the setup-*-password
> > >> scripts used to drop password files into $CWD, which meant that if
> > >> you ran the script from a different location next time, your old
> > >> passwords wouldn't be found.
> > >>
> > >> https://review.openstack.org/#/c/83250/ changed this so that the
> > >> default behaviour is to put the password files in $TRIPLEO_ROOT; but
> > >> for backwards compatibility we left the script checking to see if
> > >> there's a file in the current directory, and using that file in
> > >> preference to $TRIPLEO_ROOT if it exists.
> > >>
> > >> However, this behaviour is still confusing to people. I'm not
> > >> entirely clear on why it's confusing (it makes perfect sense to
> > >> me...) but I imagine it's because we still have the problem that the
> > >> code works fine if run from one directory, but run from a different
> > directory it can't find passwords.
> > >>
> > >> There are two open patches which would break backwards compatibility
> > >> and only ever use the files in $TRIPLEO_ROOT:
> > >>
> > >> https://review.openstack.org/#/c/93981/
> > >> https://review.openstack.org/#/c/97657/
> > >>
> > >> The latter review is under more active development, and has
> > >> suggestions that the directory containing the password files should
> > >> be parameterised, defaulting to $TRIPLEO_ROOT. This would still break
> > >> for anyone who relies on the password files being in the directory
> > >> they run the script from, but at least there would be a fairly easy
> > fix for them.
> > >>
> > >
> > > How about we:
> > >
> > > * parameterize as suggested by Fabio in the review @
> > > https://review.openstack.org/#/c/97657/
>
> +1
>
> > >
> > > * move setting of this param to more visible location (setup, like
> > > devtest_variables or testenv). We can then give this better visibility
> > > in the dev/test autodocs with a warning about the 'old' behaviour
>
> +1
>
> > >
> > > * add a deprecation warning to the code that reads from
> > > $CWD/tripleo-overcloud-passwords to say that this will now need to be
> > > set as a parameter in ... wherever. How long is a good period for
> > this?
> >
> > +1
>
> +1
>
> Would it make sense to copy the passwords across such that the users
> behaviour is not changed were they to delete their old passwords file.  The
> deprecation warning would read that they can set  to point to the
> passwords file they are currently using, or delete  to pick
> up the new default location of  (which has defaulted to TRIPLEO_ROOT)
>

This sounds like something I was trying in the first 10 revisions of
https://review.openstack.org/#/c/83250. I ended up ditching it because it
seemed like the logic was getting too complex.

Eg, if someone has multiple sets of password files, this is fine when we
see the first set  - we just copy it to $TRIPLEO_ROOT and print the
deprecation warning.

But later on if we see a second file - do we clobber the one in
$TRIPLEO_ROOT? Do we skip the copy and just print the deprecation warning,
maybe with an addendum to point out that we've seen two different files? Do
we diff the one in $CWD and the one in $TRIPLEO_ROOT to check if they're
the same?

At the time I was working on 83250 I decided it was simplest to not make
any attempt to clean up, but maybe it's time to revisit that decision.

>
> actually, I have probably being the first suggesting that we should
> parametrize the path to the password files so I want to add my
> motivations here
>
> the big win that I see here is that people may want to customize only
> some of the passwords, for example, the undercloud admin
>
> the script creating the password files is *already* capable of pushing
> in the file only new passwords, without regenerating passwords which
> could have been manually set in there already
>
> this basically implements the 'feature' I mentioned except people ju

Re: [openstack-dev] Using tmux instead of screen in devstack

[James Polley]

On Thu, Jul 3, 2014 at 12:55 AM, Anita Kuno  wrote:

> On 07/01/2014 08:52 AM, CARVER, PAUL wrote:
> > Anant Patil wrote:
> >> I use tmux (an alternative to screen) a lot and I believe lot of other
> developers use it.
> >> I have been using devstack for some time now and would like to add the
> option of
> >> using tmux instead of screen for creating sessions for openstack
> services.
> >> I couldn't find a way to do that in current implementation of devstack.
> >
> > Is it just for familiarity or are there specific features lacking in
> screen that you think
> > would benefit devstack? I’ve tried tmux a couple of times but didn’t
> find any
> > compelling reason to switch from screen. I wouldn’t argue against anyone
> who
> > wants to use it for their day to day needs. But don’t just change
> devstack on a whim,
> > list out the objective benefits.
> >
> > Having a configuration option to switch between devstack-screen and
> devstack-tmux
> > seems like it would probably add more complexity than benefit,
> especially if there
> > are any functional differences. If there are functional differences it
> would be better
> > to decide which one is best (for devstack, not necessarily best for
> everyone in the world)
> > and go with that one only.
> >
> >
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> Actually as a tmux user I really like that devstack uses screen, that
> way when I have screen running in tmux, I can decide (since they have
> different default key combinations, Control+A for screen and Control+B
> for tmux) which utility I am talking to, screen or tmux.
>
> Thanks,
> Anita.
>

As a long-time nested-screen user I've run into this a lot. I've always run
a local screen session on my desktop/laptop; and then another session on
the machine I use to do real work.

When I used screen I always used to use "escape ^ee" on my local session
(as I used it less) and left the remote at the default, so that I could
choose which session I was controlling.

Now that I've switched to tmux, I do the same - but with tmux the command
is "set prefix C-e". I find tmux easier to get set up than screen because I
can have a simple shell script on my local machine that sets it up as a
"master" session.

If we did move from screen to tmux (it sounds like we have a long way to go
before we're convinced it's worth the effort), I don't think the key
bindings will be something that should sway the decision one way or the
other - they're very easy to change.


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

[openstack-dev] [TripleO] pypi-mirror is now unsupported - what do we do now?

[James Polley]

It may not have been clear from the below email, but clarkb clarifies on
https://bugs.launchpad.net/openstack-ci/+bug/1294381 that the infra team is
no longer maintaining pypi-mirror

This has been a very useful tool for tripleo. It's much simpler for new
developers to set up and use than a full bandersnatch mirror (and requires
less disk space), and it can create a local cache of wheels which saves
build time.

But it's now unsupported.

To me it seems like we have two options:

A) Deprecate usage of pypi-mirror; update docs to instruct new devs in
setting up a local bandersnatch mirror instead
or
B) Take on care-and-feeding of the tool.
or, I guess,
C) Continue to recommend people use an unsupported unmaintained known-buggy
tool (it works reasonably well for us today, but it's going to work less
and less well as time goes by)

Are there other options I haven't thought of?

Do you have thoughts on which option is preferred?


-- Forwarded message --
From: Clark Boylan 
Date: Tue, Jul 8, 2014 at 8:50 AM
Subject: Re: [openstack-dev] Policy around Requirements Adds (was: New
class of requirements for Stackforge projects)
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>


On Mon, Jul 7, 2014 at 3:45 PM, Joe Gordon  wrote:
>
> On Jul 7, 2014 4:48 PM, "Sean Dague"  wrote:
>>
>> This thread was unfortunately hidden under a project specific tag (I
>> have thus stripped all the tags).
>>
>> The crux of the argument here is the following:
>>
>> Is a stackforge project project able to propose additions to
>> global-requirements.txt that aren't used by any projects in OpenStack.
>>
>> I believe the answer is firmly *no*.
>
> ++
>
>>
>> global-requirements.txt provides a way for us to have a single point of
>> vetting for requirements for OpenStack. It lets us assess licensing,
>> maturity, current state of packaging, python3 support, all in one place.
>> And it lets us enforce that integration of OpenStack projects all run
>> under a well understood set of requirements.
>>
>> The requirements sync that happens after requirements land is basically
>> just a nicety for getting openstack projects to the tested state by
>> eventual consistency.
>>
>> If a stackforge project wants to be limited by global-requirements,
>> that's cool. We have a mechanism for that. However, they are accepting
>> that they will be limited by it. That means they live with how the
>> OpenStack project establishes that list. It specifically means they
>> *don't* get to propose any new requirements.
>>
>> Basically in this case Solum wants to have it's cake and eat it to. Both
>> be enforced on requirements, and not be enforced. Or some 3rd thing that
>> means the same as that.
>>
>> The near term fix is to remove solum from projects.txt.
>
> The email included below mentions an additional motivation for using
> global-requirements is to avoid using pypi.python.org and instead use
> pypi.openstack.org for speed and reliability. Perhaps there is a way we
can
> support use case for stackforge projects not in projects.txt? I thought I
> saw something the other day about adding a full pypi mirror to OpenStack
> infra.
>
This is done. All tests are now run against a bandersnatch built full
mirror of pypi. Enforcement of the global requirements is performed
via the enforcement jobs.
>>
>> On 06/26/2014 02:00 AM, Adrian Otto wrote:
>> > Ok,
>> >
>> > I submitted and abandoned a couple of reviews[1][2] for a solution
aimed
>> > to meet my goals without adding a new per-project requirements file.
The
>> > flaw with this approach is that pip may install other requirements when
>> > installing the one(s) loaded from the fallback mirror, and those may
>> > conflict with the ones loaded from the primary mirror.
>> >
>> > After discussing this further in #openstack-infra this evening, we
>> > should give serious consideration to adding python-mistralclient to
>> > global requirements. I have posted a review[3] for that to get input
>> > from the requirements review team.
>> >
>> > Thanks,
>> >
>> > Adrian
>> >
>> > [1] https://review.openstack.org/102716
>> > [2] https://review.openstack.org/102719
>> > [3] https://review.openstack.org/102738
>> > 
>> >
>> > On Jun 25, 2014, at 9:51 PM, Matthew Oliver > > > wrote:
>> >
>> >>
>> >> On Jun 26, 2014 12:12 PM, "Angus Salkeld" > >> > wrote:
>> >> >
>> > On 25/06/14 15:13, Clark Boylan wrote:
>> >> On Tue, Jun 24, 2014 at 9:54 PM, Adrian Otto
>> >>> mailto:adrian.o...@rackspace.com>> wrote:
>> >>> Hello,
>> >>>
>> >>> Solum has run into a constraint with the current scheme for
>> >>> requirements management within the OpenStack CI system. We have a
>> >>> proposal for dealing with this constraint that involves making a
>> >>> contribution to openstack-infra. This message explains the
constraint,
>> >>> and our proposal for addressing it.
>> >>>
>

Re: [openstack-dev] [TripleO] pypi-mirror is now unsupported - what do we do now?

[James Polley]

On Mon, Jul 14, 2014 at 2:58 AM, Monty Taylor  wrote:

> On 07/10/2014 02:44 PM, Richard Jones wrote:
> > On 10 July 2014 23:27, Mulcahy, Stephen  wrote:
> >> When I last tested bandersnatch, it didn’t work well behind a proxy (in
> > fact most of the existing pypi mirroring tools suffered from the same
> > problem) – pypi-mirror has worked extremely well for mirroring a subset
> of
> > pypi and doing so behind a proxy. I’d also echo the requirement for a
> tool
> > that provides wheels as we have seen significant performance improvement
> > from using wheels with TripleO
> >
> > devpi works behind a proxy. If bandersnatch doesn't then that bug should
> be
> > addressed ASAP. I'm in contact with its author regarding that.
> >
> > I'm currently investigating a sensible approach to having wheels be
> > automatically built (for the most sensible value of "automatic" that we
> can
> > determine ).
>
> We're also thinking about how we continue to offer the pre-built wheels
> for each of our build platforms. For infra, what I'm thinking is:
>
> On each mirror slave (We have one for each OS combo we use), do
> something similar to:
>
> pip wheel -r global-requirements.txt
> rsync $wheelhouse pypi.openstack.org/$(lsb_release)
>
> This may require keeping pypi-mirror and using an option to only do
> wheel building so that we can get the directory publication split. Ok. I
> got bored and wrote that:
>
> https://review.openstack.org/106638
>
> So if we land that, you can do;
>
> pip wheel -r global-requirements.txt
> run-mirror --wheels-only --wheelhouse=wheelhouse --wheeldest=mirror
> rsync -avz mirror pypi.openstack.org:/srv/mirror
>
> If we went the devpi route, we could do;
>
> pip wheel -r global-requirements.txt
> for pkg in $wheelhouse; do
>   devpi upload $pkg
> done
>
> And put that into a cron.


Obviously "keeping pypi-mirror" would require the least amount of change to
how we suggest developers set up their systems.

I think the devpi option seems fairly reasonable too. It looks like it's
easier (and faster, and less bandwidth-consuming) than setting up
bandersnatch or apt-mirror, which we currently suggest people consider. It
doesn't look any more heavyweight than having a squid proxy for caching,
which we currently suggest as a bare minimum.

For an individual dev testing their own setup, I think we need a slightly
different approach from the infra approach listed above though. I'm
assuming that it's possible to probe the package index to determine if a
wheel is available for a particular version of a package yet. If that's the
case, we should be able to tweak tools like os-svc-install to notice when
no wheel is available, and build and upload the wheel.

I think this should give us a good balance between making sure that each
build (except the first) uses wheels to save time, still gets the latest
packages (since the last time the system was online at least), and the user
doesn't need to remember to manually update the wheels when they're online.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TripleO] pypi-mirror is now unsupported - what do we do now?

[James Polley]

> On 14 Jul 2014, at 08:08, Gregory Haynes  wrote:
> 
>  
>> On Sun, Jul 13, 2014, at 02:36 PM, James Polley wrote:
>>  
>> We're also thinking about how we continue to offer the pre-built wheels
>> for each of our build platforms. For infra, what I'm thinking is:
>>  
>> On each mirror slave (We have one for each OS combo we use), do
>> something similar to:
>>  
>> pip wheel -r global-requirements.txt
>> rsync $wheelhouse pypi.openstack.org/$(lsb_release)
>>  
>> This may require keeping pypi-mirror and using an option to only do
>> wheel building so that we can get the directory publication split. Ok. I
>> got bored and wrote that:
>>  
>> https://review.openstack.org/106638
>>  
>> So if we land that, you can do;
>>  
>> pip wheel -r global-requirements.txt
>> run-mirror --wheels-only --wheelhouse=wheelhouse --wheeldest=mirror
>> rsync -avz mirror pypi.openstack.org:/srv/mirror
>>  
>> If we went the devpi route, we could do;
>>  
>> pip wheel -r global-requirements.txt
>> for pkg in $wheelhouse; do
>>   devpi upload $pkg
>> done
>>  
>> And put that into a cron.
>>  
>> Obviously "keeping pypi-mirror" would require the least amount of change to 
>> how we suggest developers set up their systems.
>>  
>> I think the devpi option seems fairly reasonable too. It looks like it's 
>> easier (and faster, and less bandwidth-consuming) than setting up 
>> bandersnatch or apt-mirror, which we currently suggest people consider. It 
>> doesn't look any more heavyweight than having a squid proxy for caching, 
>> which we currently suggest as a bare minimum.
>>  
>> For an individual dev testing their own setup, I think we need a slightly 
>> different approach from the infra approach listed above though. I'm assuming 
>> that it's possible to probe the package index to determine if a wheel is 
>> available for a particular version of a package yet. If that's the case, we 
>> should be able to tweak tools like os-svc-install to notice when no wheel is 
>> available, and build and upload the wheel.
>>  
>> I think this should give us a good balance between making sure that each 
>> build (except the first) uses wheels to save time, still gets the latest 
>> packages (since the last time the system was online at least), and the user 
>> doesn't need to remember to manually update the wheels when they're online.
>  
> This gave me an idea:
> There was talk about pip being able to use a wheel cache (wheelhouse). Can we 
> bind-mount an arch-specific wheelhouse from the hypervisor into our chroots 
> as we build? This would let people get most of the wheel speedup while doing 
> almost no specifal configuration.

Pip still doesn't handle case insensitivity on file:// indexurls as well as its 
does for http:// - that should be fixed with a 1.6.0 release. There's some 
chance that we'll run into issues with this that we wouldn't hit using http, 
but i don't expect any major issues.

This still leaves us needing to build that arch-specific wheelhouse though


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

[openstack-dev] [TripleO] No weekly meeting this week

[James Polley]

Due to the fact that the vast majority of the TripleO team are in a room
staring at me as I write this email, the weekly IRC meeting won't be
happening this week.

If you have any issues that need to be discussed this week, please bring
them up on IRC in #tripleo or via email.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] periodic-stable job reports (was Re: [Openstack-stable-maint] Stable check of $THINGS failed)

[James Polley]

As exciting as these emails are, I find them a bit unexciting. They don't
give me any context to let me know whether this was a one-off or if
something has been broken for a while.

Long term, having a dashboard (see https://review.openstack.org/#/c/192253/
for the spec) will help us get better visibility into what these jobs are
doing.

But purely to scratch my own itch to get a better handle on what's
happening right now, I grabbed some code Derek H has been using for a
dashboard for the TripleO jobs and bashed at it a bit to make it a bit more
generic. I've put the reports up at http://bruce.jamezpolley.com/reports/

This is *not* a first draft of the dashboard described in the spec, nor a
prototype; it's purely something I pulled together to help me understand
what data we can already pull out of Jenkins to help show the history of
our jobs. But since I've got it online, I figured I may as well share it in
case it's useful to anyone else as well.

If you think having some kind of dashboard would be more useful than these
emails, please go check out that spec so that we can start to make progress
towards something useful.

On Sun, Jul 19, 2015 at 4:22 PM A mailing list for the OpenStack Stable
Branch test reports.  wrote:

> Build failed.
>
> - periodic-ironic-docs-juno
> http://logs.openstack.org/periodic-stable/periodic-ironic-docs-juno/943be60/
> : FAILURE in 5m 51s
> - periodic-ironic-python26-juno
> http://logs.openstack.org/periodic-stable/periodic-ironic-python26-juno/0d25bc4/
> : FAILURE in 6m 36s
> - periodic-ironic-python27-juno
> http://logs.openstack.org/periodic-stable/periodic-ironic-python27-juno/b8bcec1/
> : FAILURE in 6m 51s
> - periodic-ironic-docs-kilo
> http://logs.openstack.org/periodic-stable/periodic-ironic-docs-kilo/47ee329/
> : SUCCESS in 6m 06s
> - periodic-ironic-python27-kilo
> http://logs.openstack.org/periodic-stable/periodic-ironic-python27-kilo/c426b36/
> : SUCCESS in 8m 17s
>
> ___
> Openstack-stable-maint mailing list
> openstack-stable-ma...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint
>
__
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] BUG in OpenVSwitch Version ovs-vswitchd (Open vSwitch) 1.4.6

[James Polley]

On Sat, Feb 7, 2015 at 5:09 AM, masoom alam 
wrote:

> raise DistributionNotFound(req)\npkg_resources.DistributionNotFound:
> alembic<0.6.4,>=0.4.1\n'
>

It looks like your system is failing to find a version of alembic that
satisfies those requirements.

In your last post on this issue you said you had alembic 0.7.4 installed
already. That doesn't satisfy the requirement for a version <0.6.4. Perhaps
you need to uninstall that version, or downgrade to something that meets
the requirements?

Alternatively - it seems as though you may have a very old version of
neutron-rootwrap. I don't know much about Neutron so maybe I'm reading this
wrong, but "require(\'neutron==2013.2.4.dev32\')" suggests old age to me.
Perhaps it would be possible to upgrade your version?

FWIW, I tested in a virtualenv; with just alembic==0.7.4 installed, "pip
install -r requirements.txt" on a file that contained "alembic<0.6.4,>=0.4.1"
was able to downgrade my environment from 0.7.4 to 0.6.3. It seems possible
that maybe you could be talking to a PyPi proxy that is missing the older
alembic packages, and that adding those packages to the proxy so they can
be downloaded might possibly resolve your issue
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][pbr] splitting our deployment vs install dependencies

[James Polley]

On Mon, Apr 13, 2015 at 9:12 AM, Monty Taylor  wrote:

> On 04/12/2015 06:43 PM, Robert Collins wrote:
> > Right now we do something that upstream pip considers wrong: we make
> > our requirements.txt be our install_requires.
> >
> > Upstream there are two separate concepts.
> >
> > install_requirements, which are meant to document what *must* be
> > installed to import the package, and should encode any mandatory
> > version constraints while being as loose as otherwise possible. E.g.
> > if package A depends on package B version 1.5 or above, it should say
> > B>=1.5 in A's install_requires. They should not specify maximum
> > versions except when that is known to be a problem: they shouldn't
> > borrow trouble.
> >
> > deploy requirements - requirements.txt - which are meant to be *local
> > to a deployment*, and are commonly expected to specify very narrow (or
> > even exact fit) versions.
>

That sounds, to me, very similar to a discussion we had a few weeks ago in
the context of our stable branches.

In that context, we have two competing requirements. One requirement is
that our CI system wants a very tightly pinned requirements, as do
downstream CI systems and deployers that want to test and deploy exact
known-tested versions of things. On the other hand, downstream distributors
(including OS packagers) need to balance OpenStack's version requirements
with version requirements from all the other packages in their
distribution; the tighter the requirements we list are, the harder it is
for the requirements to work with the requirements of other packages in the
distribution.


> tl;dr - I'm mostly in support of what you're saying - but I'm going to
> bludgeon it some.
>
> To be either fair or unfair, depending on how you look at it - some
> people upstream consider those two to be a pattern, but it is not
> encoded anywhere except in hidden lore that is shared between secret
> people. Upstream's tools have bumpkiss for support for this, and if we
> hadn't drawn a line in the sand encoding SOME behavior there would still
> be nothing.
>
> Nor, btw, is it the right split. It optimizes for the wrong thing.
>
> rust gets it wright. There is a Cargo.toml and a Cargo.lock, which are
> understood by the tooling in a manner similar to what you have
> described, and it is not just understood but DOCUMENTED that an
> _application_ should ship with a Cargo.lock and a _library_ should not.
>

This sounds similar to a solution that was proposed for the stable
branches: a requirements.in with mandatory version constraints while being
as loose as otherwise possible, which is used to generate a
requirements.txt which has the "local to deployment" exact versions that
are used in our CI. The details of the proposal are in
https://review.openstack.org/#/c/161047/


> Without the library/application distinction, the effort in
> differentiating is misplaced, I believe - because it's libraries that
> need flexible depends - and applications where the specific set of
> depends that were tested in CI become important to consumers.
>
> > What pbr, which nearly if not all OpenStack projects use, does, is to
> > map the contents of requirements.txt into install_requires. And then
> > we use the same requirements.txt in our CI to control whats deployed
> > in our test environment[*]. and there we often have tight constraints
> > like seen here -
> >
> http://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt#n63
>
> That is, btw, because that's what the overwhelming majority of consumers
> assume those files mean. I take "overwhelming majority" from the days
> when we had files but did not process them automatically and everyone
> was confused.
>
> > I'd like to align our patterns with those of upstream, so that we're
> > not fighting our tooling so much.
>
> Ok. I mean, they don't have a better answer, but if it makes "python"
> hate us less, sweet.
>
> > Concretely, I think we need to:
> >  - teach pbr to read in install_requires from setup.cfg, not
> requirements.txt
> >  - when there are requirements in setup.cfg, stop reading
> requirements.txt
> >  - separate out the global intall_requirements from the global CI
> > requirements, and update our syncing code to be aware of this
> >
> > Then, setup.cfg contains more open requirements suitable for being on
> > PyPI, requirements.txt is the local CI set we know works - and can be
> > much more restrictive as needed.
> >
> > Thoughts? If there's broad apathy-or-agreement I can turn this into a
> > spec for fine coverage of ramifications and corner cases.
>
> I'm concerned that it adds a layer of difference that is confusing to
> people for the sole benefit of pleasing someone else's pedantic worldview.
>
> I'm also concerned that dstufft is actively wanting to move towards a
> world where the build tooling is not needed or used as part of the
> install pipeline (metadata 2.0) -- so I'm concerned that we're aligning
> with a pattern that isn't very robus