[OpenStack-Infra] Resigning from infra-core

[Joshua Hesketh]

Hello all,

I've been dreading writing this for a while now but all good things must
come to an end. Due to changes at work and my inability to sustain any
significant contributions to the project I think that regrettably it is
time to resign from infra-core.

It has been a wonderful experience contributing to OpenStack and OpenDev
I'll miss working with everybody and it has been an absolute pleasure to
get to know some of you both professionally and personally. I will
certainly miss you all and cannot understate how thrilled I am to have had
this chance to work with everyone. It has been a highlight of both my
career and in some cases my life.

Having said that, I will still be around, so please do not hesitate to
contact me should you need my input on anything or if there is something I
can do to help. I also intend to still be involved with Zuul in whatever
capacity I can.

I hope that our paths will cross again in the near future, and wish you all
all the best with the projects going forward.

Kind regards,
Josh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] [infra] OpenDev feedback forum session summary

[Joshua Hesketh]

Thank you for the update, it's much appreciated for those who couldn't make
it :-)

On Tue, Dec 11, 2018 at 4:34 AM Jeremy Stanley  wrote:

> Wednesday afternoon at the OpenStack Summit we met to discuss the
> plan for the upcoming transition of the OpenStack Infrastructure
> team to an independent effort named OpenDev. Notes were recorded at
> https://etherpad.openstack.org/p/BER-opendev-feedback-and-missing-features
> and form the basis of the summary with follows.
>
> For those unfamiliar with this topic, the announcement at
>
> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136403.html
> provides some background and context. Much of what follows may be a
> reiteration of things also covered there, so please excuse any
> redundancy on my part.
>
> To start out, we (re)announced that we have chosen a name (OpenDev)
> and a domain (opendev.org), so can more effectively plan for DNS
> changes for most of the services we currently host under the
> "legacy" (for us) openstack.org domain. It was also pointed out that
> while we expect to maintain convenience redirects and aliases from
> old hostnames for all services we reasonably can so as to minimize
> disruption, there will still be some unavoidable discontinuities for
> users from time to time as we work through this.
>
> We talked for a bit about options for decentralizing GitHub
> repository mirroring so that the current team no longer needs to
> maintain it, and how to put it in control of people who want to
> manage those organizations there for themselves instead. Doing this
> with a job in Zuul's post pipeline (using encrypted secrets for
> authentication) was suggested as one possible means to avoid users
> all maintaining their own separate automation to accomplish the same
> thing.
>
> Interest in bare metal CI nodes in nodepool was brought up again. To
> reiterate, there's not really any technical reason we can't use
> them, more that prior offers to donate access to Nova/Ironic-managed
> nodes for this purpose never panned out. If you work for an
> organization which maintains a "bare metal cloud" we could reach
> over the open Internet and you'd consider carving out some of your
> capacity for our CI system, please do get in touch with us!
>
> We spent a bit of time covering user concerns about the transition
> to OpenDev and what reassurances we ought to provide. For starters,
> our regular contributors and root systems administrators will
> continue to be just as reachable and responsive as ever via IRC and
> mailing lists, even if the names of the channels and MLs may change
> as part of this transition. Similarly, our operations will remain as
> open and transparent as they are today... really nothing about how
> we maintain our systems is changing substantively as a part of the
> OpenDev effort, though certainly the ways in which we maintain our
> systems do still change and evolve over time as we seek to improve
> them so that will of course continue to be the case.
>
> Paul Belanger raised concerns that announcing OpenDev could result
> in a flood of new requests to host more projects. Well, really, I
> think that's what we hope for. I (apparently) pointed out that even
> when StackForge was first created back at the beginning of 2012,
> there wasn't much restriction as to what we would be willing to
> host. As interest in OpenDev spreads to new audiences, interest in
> participating in its maintenance and development should too grow.
> That said, we acknowledge that there are some scalability
> bottlenecks and manual/human steps in certain aspects of new project
> onboarding for now, so should be very up-front with any new projects
> about that fact. We're also not planning for any big marketing push
> to seek out additional projects at this point, but are happy to talk
> to any who discover us and are interested in the services we offer.
>
> Next, Paul Belanger brought up the possibility of "bring your own
> cloud" options for projects providing CI resources themselves. While
> we expect nodepool to have support for tenant-specific resources in
> the not-too-distant future, Jim Blair and Clark Boylan agreed the
> large pool of generic resources we operate with now is really where
> we see a lot of benefit and ability to drive efficiencies of scale.
> Then Monty Taylor talked for a while, according to the notes in the
> pad, and said things about earmarked resources potentially requiring
> a sort of "commons tax" or... something.
>
> Jim Rollenhagen asked whether we would potentially start to test and
> gate projects on GitHub too rather than just our Gerrit. Clark
> Boylan and Jim Blair noted that the current situation where we're
> testing pull requests for Kata's repositories is a bit of an
> experiment in that direction today and the challenges we've faced
> suggest that, while we'll likely continue to act as a third-party CI
> system for some projects hosted on GitHub (we're doing that with
> Ansible for 

Re: [OpenStack-Infra] Proposed changes to how we run our meeting

[Joshua Hesketh]

I admit that I rarely attend the meeting these days but I do generally keep
an eye on the agenda and minutes. So for me I really appreciate that we
have an agenda and generally follow it. Being more structured and prepared
with it though would allow me to see which meetings I should make an effort
to attend. I have no objection to the meeting being held each week with any
standing items or even items from the floor, but clearly those that are
published with enough notice are more likely to get attendance.

Cheers,
Josh

On Wed, Nov 21, 2018 at 7:55 AM Clark Boylan  wrote:

> On Tue, Nov 20, 2018, at 11:49 AM, Ian Wienand wrote:
> > On Sun, Nov 18, 2018 at 11:09:29AM -0800, Clark Boylan wrote:
> > > Both ideas seem sound to me and I think we should try to implement
> > > them for the Infra team. I propose that we require agenda updates 24
> > > hours prior to the meeting start time and if there are no agenda
> > > updates we cancel the meeting. Curious to hear if others think this
> > > will be helpful and if 24 hours is enough lead time to be helpful.
> >
> > My concern here is that we have standing items of priority tasks
> > updates that are essentially always there, and action item follow-up
> > from the prior meeting.  Personally I often find them very useful.
> >
> > Having attended many in-person waffling weekly "status update"
> > meetings etc. I feel the infra one *is* very agenda focused.  I also
> > think there is never an expectation anyone is in the meeting; in fact
> > more so that we actively understand and expect people aren't there.
> >
> > So I think it would be fine to send out the agenda 24 hours in
> > advance, and make a rule that new items post that will skip to the
> > next week, so that if there's nothing of particular interest people
> > can plan to skip.
> >
> > This would involve managing the wiki page better IMO.  I always try to
> > tag my items with my name and date for discussion because clearing it
> > out is an asychronous operation.  What if we made the final thing in
> > the meeting after general discussion "reset agenda" so we have a
> > synchronisation point, and then clearly mark on the wiki page that
> > it's now for the next meeting date?
> >
> > But I don't like that infra in general skips the meeting.  Apart from
> > the aforementioned standing items, people start thinking "oh my thing
> > is just little, I don't want to call a meeting for it" which is the
> > opposite of what we want to keep communication flowing.  For people
> > actively involved but remote like myself, it's a loss of a very
> > valuable hour to catch up on what's happening even with just the
> > regular updates.
> >
> > -i
>
> Given that the goal here is to better accommodate those in timezones where
> the meeting may not be the easiest to attend I think this feedback is
> important.
>
> What if instead of canceling meetings we allowed for standing agenda items
> with the expectation that the meeting continues to be weekly, but ask that
> any new agenda items be in place 24 hours before the meeting start time.
> Anything that comes in after that can be deferred to the next meeting.
>
> This allows people to prepare as necessary and skip the meeting if it
> doesn't directly impact them.
>
> To summarize: "Meeting agenda items should be in place 24 hours prior to
> meeting start. We will continue to have standing items for priority efforts
> and meetings will occur weekly. If a specific agenda doesn't directly
> affect you, you should feel free to skip the meeting and eat dinner or get
> some rest"
>
> Clark
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Control Plane Server Upgrade Sprint Planning

[Joshua Hesketh]

On Tue, Sep 18, 2018 at 9:09 AM Clark Boylan  wrote:

> Hello everyone,
>
> We still have a few Trusty servers hanging around. We should work to
> upgrade them either to Xenial (using puppet deployment) or Bionic (using
> ansible and containers?). We've made good progress in the past using a
> sprint type setup where the majority of us are focused on making progress
> on this sort of work. Can we plan another sprint to complete this task?
>
> Looking at a calendar I think many of us are still recovering from PTG
> travel this week, week after next is Ansiblefest, then I have a local
> Portland conference the week after that. Long story short October 15-19 may
> be our best week for this. Does that week work? Any other suggestions?
>

FYI I'm on vacation most of October so will only be around very
intermittently and unable to help sorry.



> I think we can (and should) work on this outside of the sprint as well and
> I will be trying to upgrade the etherpad servers in the near future. Let me
> know if you are working on upgrading any servers/services and I will do
> what I can to help review changes and make that happen as well.
>
> Thank you,
> Clark
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Moving logs into swift (redux)

[Joshua Hesketh]

Hey all,

I like this plan as a kind of next steps for OpenStack-Infra. I have some
thoughts on how zuul might better improve it's logging story but will post
those on the other thread.

I do, however, share both of Clark's concerns.

At the moment zuul_swift_uploads makes a POST request for each individual
file. I do believe we can group them up to a limit, but that limit is still
small and complicated by things such as the total size of the data (which
is probably why the script does them individually but I don't recall). This
is just to say that we need to test how it will go uploading a lot of files
and the time that it may take.

I know the CDN was complicated with the cloud provider we were using at the
time. However, I'm unsure what the CDN options are these days. Will there
be an API we can use to turn the CDN on per container and get the public
URL for example?

If the above two items turn out sub-optimal, I'm personally not opposed to
continuing to run our own middleware. We don't necessarily need that to be
in os_loganalyze as the returned URL could be a new middleware. The
middleware can then handle the ARA and possibly even work as our own CDN
choosing the correct container as needed (if we can't get CDN details
otherwise).

Cheers,
Josh

On Tue, Jul 17, 2018 at 8:27 AM, James E. Blair  wrote:

> Hi,
>
> As you may know, all of the logs from Zuul builds are currently uploaded
> to a single static fileserver with about 14TB of storage available in
> one large filesystem.  This was easy to set up, but scales poorly, and
> we live in constant fear of filesystem corruption necessitating a
> lengthy outage for repair or loss of data (an event which happens, on
> average, once or twice a year and takes several days to resolve).
>
> Our most promising approaches to solving this involve moving log storage
> to swift.  We (mostly Joshua) have done considerable work in the past
> but kept hitting blockers.  I think the situation has changed enough
> that the issues we hit before won't be a problem now.  I believe we can
> use this work as a foundation to, relatively quickly, move our log
> storage into swift.  Once there, there's a number of possibilities to
> improve the experience around logs and artifacts in Zuul and general.
>
> This email is going to focus mostly on how OpenStack Infra can move our
> current log storage and hosting to swift.  I will follow it up with an
> email to the zuul-discuss list about further work that we can do that's
> more generally applicable to all Zuul users.
>
> This email is the result of a number of previous discussions, especially
> with Monty, and many of the ideas here are his.  It also draws very
> heavily on Joshua's previous work.  Here's the general idea:
>
> Pre-generate any content for which we currently rely on middleware
> running on logs.openstack.org.  Then upload all of that to swift.
> Return a direct link to swift for serving the content.
>
> In more detail:
>
> In addition to using swift as the storage backend, we would also like to
> avoid running a server as an intermediary.  This is one of the obstacles
> we hit last time.  We started to make os-loganalyze (OSLA) a smart proxy
> which could serve files from disk and swift.  It threatened to become
> very complicated and tax the patience of OSLA's reviewers.  OSLA's
> primary author and reviewer isn't really around anymore, so I suspect
> the appetite for major changes to OSLA is even less than it may have
> been in the past (we have merged 2 changes this year so far).
>
> There are three kinds of automatically generated content on logs.o.o:
>
> * Directory indexes
> * OSLA HTMLification of logs
> * ARA
>
> If we pre-generate all of those, we don't need any of the live services
> on logs.o.o.  Joshua's zuul_swift_upload script already generates
> indexes for us.  OSLA can already be used to HTMLify files statically.
> And ARA has a mode to pre-generate its output as well (which we used
> previously until we ran out of inodes.  So today, we basically have what
> we need to pre-generate this data and store it in swift.
>
> Another issue we ran into previously was the transition from filesystem
> storage to swift.  This was because in Zuul v2, we could not dynamically
> change the log reporting URL.  However, in Zuul v3, since the job itself
> reports the final log URL, we can handle the transition by creating new
> roles to perform the swift upload and return the swift URL.  We can
> begin by using these roles in a new base job so that we can verify
> correct operation.  Then, when we're ready, we can switch the default
> base job.  All jobs which upload logs to swift will report the new swift
> URL; the existing logs.o.o URLs will continue to function until they age
> out.
>
> The Zuul dashboard makes finding the location of logs for jobs
> (especially post jobs) simpler.  So we no longer need logs.o.o to find
> the storage location (files or swift) for post jobs -- a user can just
> follow the 

Re: [openstack-dev] Winterscale: a proposal regarding the project infrastructure

[Joshua Hesketh]

On Fri, Jun 1, 2018 at 7:23 AM, James E. Blair  wrote:

> Joshua Hesketh  writes:
>
> > So the "winterscale infrastructure council"'s purview is quite limited in
> > scope to just govern the services provided?
> >
> > If so, would you foresee a need to maintain some kind of "Infrastructure
> > council" as it exists at the moment to be the technical design body?
>
> For the foreseeable future, I think the "winterscale infrastructure
> team" can probably handle that.  If it starts to sprawl again, we can
> make a new body.
>
> > Specifically, wouldn't we still want somewhere for the "winterscale
> > infrastructure team" to be represented and would that expand to any
> > infrastructure-related core teams?
>
> Can you elaborate on this?  I'm not following.
>


I think your first response answers this a little bit. That is, the
"winterscale infrastructure team" serves the purpose of technical design
(that is currently done by the "Infrastructure Council", so we've got some
change in terminology that will be initially confusing).

Currently though the "Infrastructure Council" includes "All members of any
infrastructure project core team" which would include people from say
git-review core. My question was how do we still include
infrastructure-related core members (such as git-review-core) in the new
world order?

Hope that makes more sense.

Cheers,
Josh



>
> -Jim
>
> __
> 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] Winterscale: a proposal regarding the project infrastructure

[Joshua Hesketh]

On Thu, May 31, 2018 at 2:25 AM, James E. Blair  wrote:

> Hi,
>
> With recent changes implemented by the OpenStack Foundation to include
> projects other than "OpenStack" under its umbrella, it has become clear
> that the "Project Infrastructure Team" needs to change.
>
> The infrastructure that is run for the OpenStack project is valued by
> other OpenStack Foundation projects (and beyond).  Our community has not
> only produced an amazing cloud infrastructure system, but it has also
> pioneered new tools and techniques for software development and
> collaboration.
>
> For some time it's been apparent that we need to alter the way we run
> services in order to accommodate other Foundation projects.  We've been
> talking about this informally for at least the last several months.  One
> of the biggest sticking points has been a name for the effort.  It seems
> very likely that we will want a new top-level domain for hosting
> multiple projects in a neutral environment (so that people don't have to
> say "hosted on OpenStack's infrastructure").  But finding such a name is
> difficult, and even before we do, we need to talk about it.
>
> I propose we call the overall effort "winterscale".  In the best
> tradition of code names, it means nothing; look for no hidden meaning
> here.  We won't use it for any actual services we provide.  We'll use it
> to refer to the overall effort of restructuring our team and
> infrastructure to provide services to projects beyond OpenStack itself.
> And we'll stop using it when the restructuring effort is concluded.
>
> This is my first proposal: that we acknowledge this effort is underway
> and name it as such.
>
> My second proposal is an organizational structure for this effort.
> First, some goals:
>
> * The infrastructure should be collaboratively run as it is now, and
>   the operational decisions should be made by the core reviewers as
>   they are now.
>
> * Issues of service definition (i.e., what services we offer and how
>   they are used) should be made via a collaborative process including
>   the infrastructure operators and the projects which use it.
>
> To that end, I propose that we:
>
> * Work with the Foundation to create a new effort independent of the
>   OpenStack project with the goal of operating infrastructure for the
>   wider OpenStack Foundation community.
>
> * Work with the Foundation marketing team to help us with the branding
>   and marketing of this effort.
>
> * Establish a "winterscale infrastructure team" (to be renamed)
>   consisting of the current infra-core team members to operate this
>   effort.
>
> * Move many of the git repos currently under the OpenStack project
>   infrastructure team's governance to this new team.
>
> * Establish a "winterscale infrastructure council" (to be renamed) which
>   will govern the services that the team provides by vote.  The council
>   will consist of the PTL of the winterscale infrastructure team and one
>   member from each official OpenStack Foundation project.  Currently, as
>   I understand it, there's only one: OpenStack.  But we expect kata,
>   zuul, and others to be declared official in the not too distant
>   future.  The winterscale representative (the PTL) will have
>   tiebreaking and veto power over council decisions.
>


So the "winterscale infrastructure council"'s purview is quite limited in
scope to just govern the services provided?

If so, would you foresee a need to maintain some kind of "Infrastructure
council" as it exists at the moment to be the technical design body?

Specifically, wouldn't we still want somewhere for the "winterscale
infrastructure team" to be represented and would that expand to any
infrastructure-related core teams?

Cheers,
Josh




>
>   (This is structured loosely based on the current Infrastructure
>   Council used by the OpenStack Project Infrastructure Team.)
>
> None of this is obviously final.  My goal here is to give this effort a
> name and a starting point so that we can discuss it and make progress.
>
> -Jim
>
> __
> 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] Overriding project-templates in Zuul

[Joshua Hesketh]

>
> I think in actuality, both operations would end up as intersections:
>
>     ===  ===
> Matcher   Template  Project  Result
>     ===  ===
> files ABBC   B
> irrelevant-files  ABBC   B
>     ===  ===
>
> So with the "combine" method, it's always possible to further restrict
> where the job runs, but never to expand it.



Ignoring the 'files' above, in the example of 'irrelevant-files' haven't
you just combined the results to expand when it runs? ie, A and C are /not/
excluded and therefore the job will run when there are changes to A or C?

I would expect the table to be something like:
    ===  ===
Matcher   Template  Project  Result
    ===  ===
files ABBC   B
irrelevant-files  ABBC   ABC
    ===  ===



> > So a job with "files: tests/" and "irrelevant-files: docs/" would do
> > whatever it is that happens when you specify both.
>
> In this case, I'm pretty sure that would mean it reduces to just "files:
> tests/", but I've never claimed to understand irrelevant-files and I
> won't start now.
>


Yes, I think you are right that this would reduce to that. However, what
about the use case of:
  files: tests/*
  irrelevant-files: tests/docs/*

I could see a use case where both of those would be helpful. Yes you could
describe that as one regex but to the end user the above may be expected to
work. Unless we make the two options mutually exclusive I feel like this is
a feature we should support. (That said, it's likely a separate
feature/functionality than what is being described now).

Anyway, I feel like Proposal #2 is more how I would expect the system to
behave.

I can see an argument for combining the results (and feel like you could
evaulate that at the end after combining the branch-matching variants) to
give something like:
    ===  ===
Matcher   Template  Project  Result
    ===  ===
files ABBC   ABC
irrelevant-files  ABBC   ABC
    ===  ===

However, that gives the user no way to remove a previously listed option.
Thus overwriting may be the better solution (ie proposal #2 as written)
unless we want to explore the option of allowing a syntax that says
"extend" or "overwrite".

Yours in hoping that made sense,
Josh
__
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] Overriding project-templates in Zuul

[Joshua Hesketh]

On Tue, May 1, 2018 at 1:58 AM, James E. Blair  wrote:

> Hi,
>
> If you've had difficulty overriding jobs in project-templates, please
> read and provide feedback on this proposed change.
>
> We tried to make the Zuul v3 configuration language as intuitive as
> possible, and incorporated a lot that we learned from our years running
> Zuul v2.  One thing that we didn't anticipate was how folks would end up
> wanting to use a job in both project-templates *and* local project
> stanzas.
>
> Essentially, we had assumed that if you wanted to control how a job was
> run, you would add it to a project stanza directly rather that use a
> project-template.  It's easy to do so if you use one or the other.
> However, it turns out there are lots of good reasons to use both.  For
> example, in a project-template we may want to establish a recommended
> way to run a job, or that a job should always be run with a set of
> related jobs.  Yet a project may still want to indicate that job should
> only run on certain changes in that specific repo.
>
> To be very specific -- a very commonly expressed frustration is that a
> project can't specify a "files" or "irrelevant-files" matcher to
> override a job that appears in a project-template.
>
> Reconciling those is difficult, largely because once Zuul decides to run
> a job (for example, by a declaration in a project-template) it is
> impossible to dissuade it from running that job by adding any extra
> configuration to a project.  We need to tread carefully when fixing
> this, because quite a number of related concepts could be affected.  For
> instance, we need to preserve branch independence (a change to stop
> running a job in one branch shouldn't affect others).  And we need to
> preserve the ability for job variants to layer on to each other (a
> project-local variant should still be able to alter a variant in a
> project-template).
>
> I propose that we remedy this by making a small change to how Zuul
> determines that a job should run:
>
> When a job appears multiple times on a project (for instance if it
> appears in a project-template and also on the project itself), all of
> the project-local variants which match the item's branch must also match
> the item in order for the job to run.  In other words, if a job appears
> in a project-template used by a project and on the project, then both
> must match.
>

I might be misunderstanding at which point a job is chosen to be ran and
therefore when it's too late to dissuade it. However, if possible, would it
make more sense for the project-local copy of a job to overwrite the
supplied files and irrelevant-files? This would allow a project to run a
job when it otherwise doesn't match.

What happens when something is in both files and irrelevant-files? If the
project-template is trying to say A is in 'files', but the project-local
says A is in 'irrelevant-files', should that overwrite it?

Cheers,
Josh



>
> This effectively causes the "files" and "irrelevant-files" attributes on
> all of the project-local job definitions matching a given branch to be
> combined.  The combination of multiple files matchers behaves as a
> union, and irrelevant-files matchers as an intersection.
>
>     ===  ===
> Matcher   Template  Project  Result
>     ===  ===
> files ABBC   ABC
> irrelevant-files  ABBC   B
>     ===  ===
>
> I believe this will address the shortcoming identified above, but before
> we get too far in implementing it, I'd like to ask folks to take a
> moment and evaluate whether it will address the issues you've seen, or
> if you foresee any problems which I haven't anticipated.
>
> Thanks,
>
> Jim
>
> __
> 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-Infra] PTG September 10-14 in Denver

[Joshua Hesketh]

If I get the opportunity I would love to come. Unsure what the likelihood
is though.

On Sat, Apr 21, 2018 at 4:02 AM, Melvin Hillsman 
wrote:

> Planning on being in attendance (travel approval pending)
>
> On Fri, Apr 20, 2018 at 12:58 PM, Jeremy Stanley 
> wrote:
>
>> On 2018-04-20 10:42:48 -0700 (-0700), Clark Boylan wrote:
>> [...]
>> > Let me know (doesn't have to be to the list if you aren't
>> > comfortable with that) and thanks!
>>
>> You can expect me there. Not only was the venue great, the
>> restaurants within walking distance were just my speed and, as icing
>> on the cake, Denver is one of the few airports to/from which I can
>> get direct flights!
>> --
>> Jeremy Stanley
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>
>
>
> --
> Kind regards,
>
> Melvin Hillsman
> mrhills...@gmail.com
> mobile: (832) 264-2646
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack] which SDK to use?

[Joshua Hesketh]

There is also nothing stopping you from using both. For example, you could
use the OpenStack SDK for most things but if you hit an edge case where you
need something specific you can then import the particular client lib.

Cheers,
Josh

On Thu, Apr 19, 2018 at 1:05 AM, Chris Friesen 
wrote:

> I should preface this with the fact that I don't use OpenStack SDK, so you
> may want to check with the project developers.
>
> One example is that a bit over a year ago nova added a microversion to
> include the flavor information directly in the server information rather
> than returning a link to a flavor (that may have been modified or deleted
> in the meantime).
>
> To my knowledge, the Openstack SDK does not yet support this functionality.
>
> Chris
>
>
>
> On 04/17/2018 02:24 PM, Volodymyr Litovka wrote:
>
>> Hi Chris and colleagues,
>>
>> based on your experience, can you specify an average delay between new OS
>> release / new feature introduction and appearance of corresponding
>> support in
>> Unified Openstack SDK if you were experiencing such issues?
>>
>> Thanks.
>>
>> On 4/17/18 7:23 PM, Chris Friesen wrote:
>>
>>> On 04/17/2018 07:13 AM, Jeremy Stanley wrote:
>>>
>>> The various "client libraries" (e.g. python-novaclient,
 python-cinderclient, et cetera) can also be used to that end, but
 are mostly for service-to-service communication these days, aren't
 extremely consistent with each other, and tend to eventually drop
 support for older OpenStack APIs so if you're going to be
 interacting with a variety of different OpenStack deployments built
 on different releases you may need multiple versions of the client
 libraries (depending on what it is you're trying to do).

>>>
>>> The above is all good information.
>>>
>>> I'd like to add that if you need bleeding-edge functionality in nova it
>>> will
>>> often be implemented first in python-novaclient.
>>>
>>> Chris
>>>
>>> ___
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to : openstack@lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>
>>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
> k
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax

[Joshua Hesketh]

Perhaps we need to consider a backport of the syntax to the 2.5 series?

It could help with the transition for those who need to upgrade. However,
on the other hand it might make deployers more complacent to do so.

On Tue, Feb 20, 2018 at 2:03 AM, Jeremy Stanley  wrote:

> On 2018-02-18 19:25:07 -0800 (-0800), Emilien Macchi wrote:
> [...]
> > My recommendation for TripleO devs: use the old syntax if you want your
> > code to be tested by RDO Third party CI
> [...]
>
> This is hopefully only a temporary measure? I think I've heard it
> mentioned that planning is underway to switch that CI system to Zuul
> v3 (perhaps after 3.0.0 officially releases soon).
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [OpenStack-Infra] Zuul mailing lists

[Joshua Hesketh]

On Tue, Jan 9, 2018 at 10:46 AM, James E. Blair  wrote:

> Hi,
>
> We recently completed the work needed to host mailing lists for projects
> at their own domains.  With our expanded focus in Zuul v3 on users
> beyond those related to the OpenStack project, now seems like a good
> time to create dedicated Zuul mailing lists.
>
> I'd like to create the following two lists to start:
>
> zuul-annou...@lists.zuul-ci.org  --  A list for release announcements
> and to disseminate information about job definition changes (including
> information about the shared zuul-jobs repos).
>
> zuul-disc...@lists.zuul-ci.org  --  A list for general discussion about
> using Zuul and development work.
>
> Note in particular that, at the moment, I'm not proposing a dev/user
> mailing list split.  Much of our dev work directly impacts users and
> needs broad discussion.  Likewise, we're better developers when we dive
> into real user problems.  So to the extent possible, I'd like to avoid
> creating a split where one isn't necessary.
>
> Of course, if that doesn't work out, or if circumstances change, we can
> add new lists as necessary.  It seems like the most conservative
> approach is to create only one discussion list and add more if needed.
>
> It's also worth noting that some of us wear multiple hats related to
> OpenStack and Zuul.  It will still be reasonable for folks to have
> Zuul-related discussions on this list, or openstack-dev, when they
> relate entirely to OpenStack's use of Zuul.  We might discuss adding new
> executors on openstack-infra, and we might promulgate a new role for
> working with devstack logs on openstack-dev.  Neither of those
> discussions need to happen on the new lists.  However, like any project
> used heavily by another, people involved in OpenStack with a significant
> interest in Zuul should subscribe to the new lists, so they can interact
> with the rest of the Zuul community.
>
> How does that sound?
>

Sounds good :-)


>
> Thanks,
>
> Jim
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Sydney Infra evening

[Joshua Hesketh]

+1

FYI I'll meet ya'll at the pub.

On Wed, Nov 8, 2017 at 10:20 AM, Ricardo Carrillo Cruz <
ricardo.carrillo.c...@gmail.com> wrote:

> Thanks for setting this up, I'm in.
>
> Cheers
>
> 2017-11-07 20:13 GMT+01:00 Ian Wienand :
>
>> Let's meet at the swirlly fountain pit about 6:10pm
>>
>> Preliminary plan is a ferry, dinner, walk and drinks
>>
>> Not to sound like your Mum/Mom but a light jacket and comfortable shoes
>> suggested :)
>>
>> -i
>>
>> On 1 Nov. 2017 10:59 am, "Ian Wienand"  wrote:
>>
>> On 10/18/2017 05:37 PM, Ian Wienand wrote:
>>
>>> Hi all,
>>>
>>> As discussed in the meeting, I've started a page for planning an infra
>>> evening in Sydney (but note -- ALL welcome)
>>>
>>>https://ethercalc.openstack.org/lx7zv5denrb9
>>>
>>
>> It looks like Wednesday night (8th) and the more active/pub crawl
>> option for those interested.
>>
>> Cheers,
>>
>> -i
>>
>>
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Sydney Infra evening

[Joshua Hesketh]

Hey Ian,

Thanks for starting that and putting in some great options to show infra a
bit of Sydney and Australia :-).

I'll definitely be coming and will fill in my availability once I know more.

Looking forward to catching up with everybody!

Cheers,
Josh

On Wed, Oct 18, 2017 at 5:37 PM, Ian Wienand  wrote:

> Hi all,
>
> As discussed in the meeting, I've started a page for planning an infra
> evening in Sydney (but note -- ALL welcome)
>
>   https://ethercalc.openstack.org/lx7zv5denrb9
>
> I put an active, less active and easy option.  Just fill it in and
> we'll see where we're at.
>
> Cheers,
>
> -i
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [all] Marking <= mitaka EOL

[Joshua Hesketh]

Hi All,

I've processed the list that Tony sent through this morning, removing the
branches and tagging their positions as described.

The only exception being that openstack/zaqar doesn't have stable/liberty
or stable/liberty2 branches to EOL.

Let me know if I've missed anything.

Cheers,
Josh

On Wed, Sep 20, 2017 at 11:03 AM, Tony Breeds 
wrote:

> On Thu, Aug 24, 2017 at 01:14:56PM +1000, Tony Breeds wrote:
> > Hello all,
> > We have a number of old stable/* branches hanging around and I'd
> > like to mark anything <= stable/mitaka as EOL.  I've highlighted a few
> > projects on the subject line:
> >
> > QA: Are the older branches of grenade safe to go?  IIUC we don't use
> > them as we don't do grenade testing on $oldest stable branch
> > group-based-policy: In the past you've requested your old branches stay
> > around Do you still need this?  Is there value in
> > the *all* staying active?
> > zaqar: I see that liberty was EOL and then reactivated do you still need
> >liberty2?
> > packaging_deb: As these repos have the $project origin using the
> >standard series-eol tag doesn't make sense  for exaxple
> >deb-nova gets a mitaka-eol from the nova repo.   So I've
> >picked mitaka-eol-dpkg.
> > fuel, networking-*: There are several entries for these projects groups
> > so I'm calling them out here for attention.
> >
> > I'm proposing we do this removal during the PTG.  Once we've done the
> > series based branches we can look at old versioned releases like
> > stable/16.04 etc.
> >
> > It's hard to present the data in a clear way so given infra will be the
> > ultimate actioners of this list I present this as a shell script:
>
> Per previous discussion here's the list to EOL everything <= mitaka
> except for:
> openstack/group-based-policy,
> openstack/group-based-policy-automation,
> openstack/group-based-policy-ui,
> openstack/python-group-based-policy-client
> and openstack/networking-bigswitch
>
> ---
> eol-branch.sh -- stable/essex essex-eol openstack/anvil
> eol-branch.sh -- stable/folsom folsom-eol openstack/anvil
> eol-branch.sh -- stable/grizzly grizzly-eol openstack/anvil
> eol-branch.sh -- stable/havana havana-eol openstack/openstack
> eol-branch.sh -- stable/icehouse icehouse-eol \
>  openstack/astara openstack/networking-brocade \
>  openstack/networking-cisco openstack/networking-mlnx \
>  openstack/networking-odl openstack/networking-plumgrid \
>  openstack/nova-solver-scheduler \
>  openstack/sahara-image-elements openstack/tricircle \
>  openstack/trio2o openstack/vmware-nsx
> eol-branch.sh -- stable/icehouse icehouse-eol-dpkg \
>  openstack/deb-networking-cisco \
>  openstack/deb-networking-mlnx openstack/deb-networking-odl
> eol-branch.sh -- stable/juno juno-eol \
>  openstack/astara openstack/astara-appliance \
>  openstack/astara-horizon openstack/astara-neutron \
>  openstack/group-based-policy \
>  openstack/group-based-policy-automation \
>  openstack/group-based-policy-ui openstack/mistral \
>  openstack/mistral-dashboard openstack/mistral-extra \
>  openstack/networking-bigswitch \
>  openstack/networking-brocade openstack/networking-cisco \
>  openstack/networking-mlnx openstack/networking-odl \
>  openstack/networking-plumgrid \
>  openstack/nova-solver-scheduler \
>  openstack/openstack-resource-agents \
>  openstack/powervc-driver openstack/proliantutils \
>  openstack/puppet-n1k-vsm openstack/puppet-vswitch \
>  openstack/python-group-based-policy-client \
>  openstack/python-mistralclient \
>  openstack/python-muranoclient openstack/vmware-nsx
> eol-branch.sh -- stable/juno juno-eol-dpkg \
>  openstack/deb-mistral openstack/deb-networking-cisco \
>  openstack/deb-networking-mlnx
> openstack/deb-networking-odl \
>  openstack/deb-python-mistralclient \
>  openstack/deb-python-muranoclient \
>  openstack/deb-python-proliantutils
> eol-branch.sh -- stable/kilo kilo-eol \
>  openstack-dev/grenade openstack/murano-apps \
>  openstack/networking-h3c openstack/requirements
> eol-branch.sh -- stable/kilo kilo-eol1 \
>  openstack/group-based-policy \
>  openstack/group-based-policy-automation \
>  openstack/group-based-policy-ui \
>  openstack/python-group-based-policy-client
> eol-branch.sh -- stable/kilo_v2 kilo_v2-eol openstack/networking-bigswitch
> eol-branch.sh 

Re: [OpenStack-Infra] Tag stable/mitaka as eol for Monasca Ceilometer

[Joshua Hesketh]

Howdy,

I have eol'd the mitaka branch for monasca-ceilometer. Please let me know
if you find any mistakes.

Cheers,
Josh

On Thu, Aug 3, 2017 at 5:15 AM, Hochmuth, Roland M 
wrote:

> Hi Ashwin and Andreas, Yes, you can eol stable/mitaka for
> openstack/monasca-ceilometer. Regards --Roland
>
> On 7/25/17, 12:03 PM, "Ashwin Agate"  wrote:
>
> Hi Roland,
>
> Can you please confirm? I think we can safely eol stable/mitaka for
> monasca-ceilometer. Should we bring it up in the weekly meeting
> tomorrow?
>
> Thanks
> Ashwin
>
> On Thu, 2017-07-20 at 08:45 +0200, Andreas Jaeger wrote:
> > On 2017-07-19 20:29, Ashwin Agate wrote:
> > >
> > > Hi,
> > >
> > > Can you please delete stable/mitaka branch for openstack/monasca-
> > > ceilometer project and create a mitaka-eol tag?
> > >
> > > Please see https://review.openstack.org/#/c/484494/6 for some
> > > discussion with Andreas Jaeger on this subject.
> >
> > Roland, as PTL, can you confirm, please?
> >
> > Andreas
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Request to EOL Puppet OpenStack Mitaka

[Joshua Hesketh]

On Wed, Jul 5, 2017 at 11:31 PM, Emilien Macchi <emil...@redhat.com> wrote:

> On Wed, Jul 5, 2017 at 5:29 AM, Emilien Macchi <emil...@redhat.com> wrote:
> > On Wed, Jul 5, 2017 at 6:13 AM, Joshua Hesketh <joshua.hesk...@gmail.com>
> wrote:
> >> Hello Emilien,
> >>
> >> My apologies for not getting to this sooner. I've processed the list
> that
> >> Tony put together which included the puppet repos. Please let me know if
> >> I've missed anything.
>
> Actually we missed something in the request: could you please EOL
> puppet-ceph stable/hammer too?
>
>
No worries, done.



> Thanks again,
>
> > It's perfect, thanks a lot for your help- :)
> >
> >> Cheers,
> >> Josh
> >>
> >> On Wed, Jul 5, 2017 at 6:19 AM, Emilien Macchi <emil...@redhat.com>
> wrote:
> >>>
> >>> On Fri, Jun 23, 2017 at 12:19 AM, Emilien Macchi <emil...@redhat.com>
> >>> wrote:
> >>> > On Wed, Jun 21, 2017 at 6:42 PM, Jeremy Stanley <fu...@yuggoth.org>
> >>> > wrote:
> >>> >> On 2017-06-21 09:03:47 -0400 (-0400), Emilien Macchi wrote:
> >>> >> [...]
> >>> >>> Can anyone have a look please?
> >>> >>> We would like to EOL Puppet OpenStack Mitaka.
> >>>
> >>> Hey it's me again :-)
> >>> If someone has little time to help me on this process, I would buy
> >>> him/her Canadian beers (some said they're better than US but I don't
> >>> want to get in trouble here) at next summit in Vancouver.
> >>>
> >>> Thanks,
> >>>
> >>> >> It's not forgotten, Infra's just spread thin and some weeks
> >>> >> (especially when lots of people go to conferences) it's about all we
> >>> >> can do to keep the lights on. For larger non-urgent requests like
> >>> >> this to be deprioritized and take more than a week to address is,
> >>> >> unfortunately, not atypical.
> >>> >>
> >>> >> Making matters worse, I'll be mostly (if not completely) away from
> >>> >> the computer for the next five days, so unless someone else gets to
> >>> >> it before then I can't really commit to it until I'm around again
> >>> >> either.
> >>> >
> >>> > Thanks for clarifying, and apologize, I didn't have the full context.
> >>> > It's really fine to wait, there is no hurry, I just wanted to make
> >>> > sure it would happen sometimes.
> >>> >
> >>> > Have a great time off and we'll see if someone can help on this task
> >>> > later, but again nothing urgent.
> >>> >
> >>> > Cheers,
> >>> >
> >>> >> --
> >>> >> Jeremy Stanley
> >>> >>
> >>> >> ___
> >>> >> OpenStack-Infra mailing list
> >>> >> OpenStack-Infra@lists.openstack.org
> >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Emilien Macchi
> >>>
> >>>
> >>>
> >>> --
> >>> Emilien Macchi
> >>>
> >>> ___
> >>> OpenStack-Infra mailing list
> >>> OpenStack-Infra@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >>
> >>
> >
> >
> >
> > --
> > Emilien Macchi
>
>
>
> --
> Emilien Macchi
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Request to EOL Puppet OpenStack Mitaka

[Joshua Hesketh]

Hello Emilien,

My apologies for not getting to this sooner. I've processed the list that
Tony put together which included the puppet repos. Please let me know if
I've missed anything.

Cheers,
Josh

On Wed, Jul 5, 2017 at 6:19 AM, Emilien Macchi  wrote:

> On Fri, Jun 23, 2017 at 12:19 AM, Emilien Macchi 
> wrote:
> > On Wed, Jun 21, 2017 at 6:42 PM, Jeremy Stanley 
> wrote:
> >> On 2017-06-21 09:03:47 -0400 (-0400), Emilien Macchi wrote:
> >> [...]
> >>> Can anyone have a look please?
> >>> We would like to EOL Puppet OpenStack Mitaka.
>
> Hey it's me again :-)
> If someone has little time to help me on this process, I would buy
> him/her Canadian beers (some said they're better than US but I don't
> want to get in trouble here) at next summit in Vancouver.
>
> Thanks,
>
> >> It's not forgotten, Infra's just spread thin and some weeks
> >> (especially when lots of people go to conferences) it's about all we
> >> can do to keep the lights on. For larger non-urgent requests like
> >> this to be deprioritized and take more than a week to address is,
> >> unfortunately, not atypical.
> >>
> >> Making matters worse, I'll be mostly (if not completely) away from
> >> the computer for the next five days, so unless someone else gets to
> >> it before then I can't really commit to it until I'm around again
> >> either.
> >
> > Thanks for clarifying, and apologize, I didn't have the full context.
> > It's really fine to wait, there is no hurry, I just wanted to make
> > sure it would happen sometimes.
> >
> > Have a great time off and we'll see if someone can help on this task
> > later, but again nothing urgent.
> >
> > Cheers,
> >
> >> --
> >> Jeremy Stanley
> >>
> >> ___
> >> OpenStack-Infra mailing list
> >> OpenStack-Infra@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >
> >
> >
> > --
> > Emilien Macchi
>
>
>
> --
> Emilien Macchi
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Joshua Hesketh]

Hi all,

Very sorry for the delay on processing this request. I have now EOL'd
stable/mitaka branches for projects listed in [1].

If there are any mistakes it should be possible to restore the branch at
the correct position. Similarly please let me know if there were any
projects that should have been EOL'd but missed out.

Cheers,
Josh

[1] https://gist.githubusercontent.com/tbreeds/c99e62bf8da19
380e4eb130be8783be7/raw/6d02deb40e07516ce8fc529d2ba8c74af11a
5a6b/mitaka_eol_data.txt

On Thu, Jun 29, 2017 at 10:57 PM, Jeremy Stanley  wrote:

> On 2017-06-29 11:28:10 +1000 (+1000), Tony Breeds wrote:
> [...]
> > In the meantime we could look at adding permissions such that the Stable
> > PTL (Well actually I guess eventually it'd be the same bot that does the
> > release tagging) can push tags and abandon changes on all projects.
> >
> > Right now stable-maint-core can do that in a lot of projects but the
> > coverage isn't complete.
>
> Sure, we just need to set it in the global configuration instead of
> on a per-project basis.
>
> > That would allow us to make forward progress and reduce the task for the
> > infra team to deleting the branches.  It does of course introduce a
> > race where I could tag a branch as EOL and then that project merge
> > another change.  Can you think of a way to avoid that?
>
> Not a convenient one anyway... we could probably merge (hundreds of)
> ACL changes preventing approvals on that branch for the projects
> participating in the EOL process, but that's probably worse than
> accepting that there might be a patch or two created, reviewed and
> landed on some project between the EOL tag and branch deletion. The
> additional changes that merge after the tag won't effectively be
> reachable once the branch is gone anyway (you could hunt them down
> in Gerrit, but there's no longer a branch in Git containing them an
> they're not in the history of any tag at that point). It's probably
> neither common nor disruptive enough to be worth our concern.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Joshua Hesketh]

On Fri, Jun 30, 2017 at 12:18 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2017-06-29 18:58:09 +1000 (+1000), Joshua Hesketh wrote:
> > So I apologise if this has already been suggested/discussed (the
> > long threads are difficult to keep up with), but has it been
> > considered to go back to using a stackforge namespace?
> [...]
>
> Back in the bad ol' days when we had a separate namespace for
> unofficial projects, it seemed to me like newcomers were just as
> confused as they are now, perhaps even more so. People like to
> forget, or wax nostalgic, or simply weren't around to see it first
> hand back then; so I agree it's probably worth rehashing the pain
> points as it's been a long time since I can recall anyone
> enumerating them.
>
> Gerrit's design assumes project names (including any prefixed
> namespace) never change. This means project renames in Gerrit are
> painful and disruptive (service outage for everyone, Git remote
> changes for anyone working on that repo, risk of breaking things
> with a SQL update query or directory move, et cetera). There is no
> good automation for transfers between orgs in GH either so handling
> this is a manual process involving lot of clicking around in a Web
> browser. Project renames also touch other systems (our many Git
> servers, StoryBoard) so more places to make mistakes or miss
> something.
>
> As a result, we would want to actively discourage repos moving from
> the stackforge namespace into the openstack namespace (or vice
> versa) which creates an artificial hurdle for projects seeking to
> become official. This causes them to place an urgent pressure on the
> Infra team which makes it harder for us to ease the pain of renames
> by batching them up and processing them less frequently. We
> similarly would no longer be allowed to create repos directly in the
> openstack namespace without prior approval from the TC, which puts
> the brakes on the current flow where teams can create a new repo as
> quickly as the project-config-cores review the change and then work
> on the corresponding governance addition in parallel with doing
> their project development.
>
> In the past the ability to push most of the work of doing renames
> onto the Infra team created a perverse incentive for projects to
> start unofficial so they didn't have to wait on the TC, and then ask
> for a rename once they got approval rather than waiting to start
> work until the TC approved their request. It's hard for the Infra
> team to effectively deter that sort of behavior because the most we
> can do is ask authors of their intentions and then trust that
> they're being up front about a lack of interest in becoming official
> (and that they're unlikely to change their minds about it later).
>
> Unfortunately, hosting unofficial projects grants official teams a
> license to experiment in that space rather than taking
> responsibility up front, and this is detrimental to our community as
> a whole. It also gives new teams an easy excuse to put off applying
> to become official until later since they get most of the
> infrastructure benefits right away regardless. If we could get rid
> of this pervasive temptation to "incubate" ideas out from under the
> shadow of governance then maybe that would make maintaining the rest
> under a different namespace slightly less of a burden, as the need
> to move repos between namespaces would then be far less common or
> urgent.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
Hey Jeremy,

Thanks for that, it's a good refresher. I'm aware of the technical
challenges however (and I think I did a poor job of saying this) I was
suggesting that if we suspend the technical issues for the purpose of this
discussion what does it look like. In other words, lets assume we can
easily move between namespaces (and even git remotes aren't a problem), in
this case is returning to something like stackforge advantageous?

Then, if so, has anybody looked at how difficult it would be to actually to
fix gerrit, automate github (perhaps through a newer API or simulating
those clicks etc), come up with a creative fix to git remotes (redirects,
updating via git review or something) etc.

This possibly isn't helpful as I'm unfortunately not in a position to be
able to volunteer to work on any of the above. Realistically I imagine that
the amount of work is not feasible and that is one of the reasons we moved
away from multiple name spaces. I'm just wondering if

Re: [openstack-dev] [all][tc] How to deal with confusion around "hosted projects"

[Joshua Hesketh]

Howdy,

So I apologise if this has already been suggested/discussed (the long
threads are difficult to keep up with), but has it been considered to go
back to using a stackforge namespace?

It seems to me that the role of stackforge to provide a proving ground or
place for aligned projects/repos was quite clear and well understood
(although perhaps I'm wrong). There were some technical challenges in
moving between namespaces that were less than ideal, but have we A)
investigated what would be required to overcome or at least lessen the
technical challenges, and/or B) weighed them against the alternatives and
current proposals?

Cheers,
Josh

On Thu, Jun 29, 2017 at 6:17 PM, Thierry Carrez 
wrote:

> James E. Blair wrote:
> > Thierry Carrez  writes:
> >
> >> Removing the root cause would be a more radical move: stop offering
> >> hosting to non-OpenStack projects on OpenStack infrastructure
> >> altogether. We originally did that for a reason, though. The benefits of
> >> offering that service are:
> >>
> >> 1- it lets us set up code repositories and testing infrastructure before
> >> a project applies to be an official OpenStack project.
> >>
> >> 2- it lets us host things that are not openstack but which we work on
> >> (like abandoned Python libraries or GPL-licensed things) in a familiar
> >> environment
> >>
> >> 3- it spreads "the openstack way" (Gerrit, Zuul) beyond openstack itself
> >
> > I think this omits what I consider the underlying reason for why we did
> > it:
> >
> > It helps us build a community around OpenStack.
> >
> > Early on we had so many people telling us that we needed to support
> > "ecosystem" projects better.  That was the word they used at the time.
> > Many of us said "hey, you're free to use github" and they told us that
> > wasn't enough.
> >
> > We eventually got the message and invited them in, and it surpassed our
> > expectations and I think surprised even the most optimistic of us.  We
> > ended up in a place where anyone with an OpenStack related idea can try
> > it out and collaborate frictionlessly with everyone else in the
> > OpenStack community on it, and in doing so, become recognized in the
> > community for that.  The ability for someone to build something on top
> > of OpenStack as part of the OpenStack community has been empowering.
> >
> > I confess to being a skeptic and a convert.  I wasn't thrilled about the
> > unbounded additional responsibility when we started this, but now that
> > we're here, I think it's one of the best things about the project and I
> > would hate to cleave our community by ending it.
>
> I think that's a great point, Jim.
>
> I spent a lot of time last week analyzing the "negative space" (things
> that are on our project infrastructure but are not openstack), and there
> are indeed a number of projects which would qualify as "companion
> projects": David's ARA, the swift3 Swift middleware, or Neutron plugins
> for some proprietary hardware that got kicked out of the Neutron
> stadium. There aren't so many of those, but keeping those close to us is
> definitely a good thing.
>
> Ideally we would find a way to continue to host those, without creating
> any doubt as to whether they are an official OpenStack project under TC
> governance. Such options to address the confusion at the edge exist, and
> they were explored in the previous thread (selective GitHub replication,
> aggressive tagging, active removal of obviously-dead things, separate
> branding/domains...). The main issue being, those options all involved a
> lot of work for the infra team, work that is not conceivable with its
> current limited resources. The only reason why I put the nuclear plan B
> on the table is that we can't get the plan A properly done...
>
> --
> Thierry Carrez (ttx)
>
> __
> 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] [all][stable][ptls] Tagging mitaka as EOL

[Joshua Hesketh]

On Wed, Jun 28, 2017 at 6:59 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2017-06-17 01:20:28 +1000 (+1000), Joshua Hesketh wrote:
> [...]
> > I'm happy to help do this if you'd like. Otherwise the script I've
> > used for the last few retirements is here:
> > http://git.openstack.org/cgit/openstack-infra/release-tools/
> tree/eol_branch.sh
>
> That would be really appreciated if you have the available
> bandwidth. If not, I'm going to try to find an opportunity to
> babysit it sometime later this week.
>


Yep, more than happy to. I'll try and get to it this week but if not, next
week at the latest.

Cheers,
Josh



>
> > I believe the intention was to add some hardening around that
> > script and automate it. However I think it was put on hold
> > awaiting a new gerrit.. either that or nobody took it up.
>
> Fingers crossed that we'll be able to switch to Gerrit 2.13 soon and
> resume that much needed development effort.
> --
> Jeremy Stanley
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [OpenStack-Infra] Request to EOL Puppet OpenStack Mitaka

[Joshua Hesketh]

When I've done branch removals in the past I've always created the EOL tag.
The script I have used helps do this so in some ways it's easier to do it
as part of the retirement rather than having teams go through and create
tags themselves.

On Sat, Jun 17, 2017 at 12:27 AM, Emilien Macchi  wrote:

> On Fri, Jun 16, 2017 at 10:17 AM, Jeremy Stanley 
> wrote:
> > On 2017-06-16 09:58:44 -0400 (-0400), Emilien Macchi wrote:
> > [...]
> >> On Wed, Jun 14, 2017 at 8:18 AM, Emilien Macchi 
> wrote:
> > [...]
> >> > puppet-aodh
> >> > puppet-ceilometer
> >> > puppet-cinder
> >> > puppet-designate
> >> > puppet-glance
> >> > puppet-gnocchi
> >> > puppet-heat
> >> > puppet-horizon
> >> > puppet-ironic
> >> > puppet-keystone
> >> > puppet-manila
> >> > puppet-mistral
> >> > puppet-murano
> >> > puppet-neutron
> >> > puppet-nova
> >> > puppet-openstack_extras
> >> > puppet-openstacklib
> >> > puppet-sahara
> >> > puppet-swift
> >> > puppet-tempest
> >> > puppet-trove
> >> > puppet-vswitch
> >> > puppet-zaqar
> > [...]
> >
> > It looks like these are covered by Tony's request to the dev ML:
> >
> >   http://lists.openstack.org/pipermail/openstack-dev/2017-
> June/118473.html
>
> Just in time :-)
>
> >
> > Please confirm you don't need any adjustments there.
>
> Nothing that I'm aware of. IIUC, we need the tag (I can do it myself
> if needed) & branch removal.
>
> Thanks a lot,
>
> > --
> > Jeremy Stanley
> >
> > ___
> > OpenStack-Infra mailing list
> > OpenStack-Infra@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
>
> --
> Emilien Macchi
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

[Joshua Hesketh]

On Sat, Jun 17, 2017 at 12:14 AM, Jeremy Stanley  wrote:

> On 2017-06-16 15:12:36 +1000 (+1000), Tony Breeds wrote:
> [...]
> > It seeems a little odd to be following up so long after I first started
> > this thread  but can someone on infra please process the EOLs as
> > described in [1].
> [...]
>
> I thought in prior discussions it had been determined that the
> Stable Branch team was going to start taking care of abandoning open
> changes and tagging branch tips (and eventually deleting the
> branches once we upgrade to a newer Gerrit release). Looks like some
> of these still have open changes and nothing has been tagged, so you
> want the Infra team to take those tasks back over for this round?
> Did you have any scripts you wanted used for this, or should I just
> wing it for now like I did in the past?
>

I'm happy to help do this if you'd like. Otherwise the script I've used for
the last few retirements is here:
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/eol_branch.sh

I believe the intention was to add some hardening around that script and
automate it. However I think it was put on hold awaiting a new gerrit..
either that or nobody took it up.

Cheers,
Josh



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

Re: [openstack-dev] [all][tc] Moving away from "big tent" terminology

[Joshua Hesketh]

An [official] OpenStack project is also a hosted project by OpenStack
[infra].

I agree that "OpenStack-Hosted projects" is not very distinct from
"OpenStack projects". Furthermore the "hosted" part is not unique to either
category.

I don't have an immediate suggestion for an alternative, but I might give
it some thought.

On Thu, Jun 15, 2017 at 8:13 PM, Shake Chen  wrote:

>
> +1000
> very clearly.
>
> On Thu, Jun 15, 2017 at 6:04 PM, Dmitry Tantsur 
> wrote:
>
>> On 06/15/2017 11:56 AM, Neil Jerram wrote:
>>
>>> Just an immediate reaction: to me "OpenStack-Hosted projects" is not
>>> very distinct from "OpenStack projects".  So with that terminology I think
>>> there will still be confusion (perhaps more).
>>>
>>
>> This was my reaction as well. For people who misunderstood official vs
>> unofficial, this is going to pose an even bigger challenge, I'm afraid.
>>
>>
>>> (Or did I misunderstand your new proposal?)
>>>
>>> Regards - Neil
>>>
>>>
>>> On Thu, Jun 15, 2017 at 10:16 AM Thierry Carrez >> > wrote:
>>>
>>> Hi everyone,
>>>
>>> Back in 2014, OpenStack was facing a problem. Our project structure,
>>> inherited from days where Nova, Swift and friends were the only game
>>> in
>>> town, was not working anymore. The "integrated release" that we
>>> ended up
>>> producing was not really integrated, already too big to be installed
>>> by
>>> everyone, and yet too small to accommodate the growing interest in
>>> other
>>> forms of "open infrastructure". The incubation process (from
>>> stackforge
>>> to incubated, from incubated to integrated) created catch-22s that
>>> prevented projects from gathering enough interest to reach the upper
>>> layers. Something had to give.
>>>
>>> The project structure reform[1] that resulted from those discussions
>>> switched to a simpler model: project teams would be approved based on
>>> how well they fit the OpenStack overall mission and community
>>> principles, rather than based on a degree of maturity. It was
>>> nicknamed
>>> "the big tent" based on a blogpost[2] that Monty wrote -- mostly
>>> explaining that things produced by the OpenStack community should be
>>> considered OpenStack projects.
>>>
>>> So the reform removed the concept of incubated vs. integrated, in
>>> favor
>>> of a single "official" category. Tags[3] were introduced to better
>>> describe the degree of maturity of the various official things.
>>> "Being
>>> part of the big tent" was synonymous to "being an official project"
>>> (but
>>> people kept saying the former).
>>>
>>> At around the same time, mostly for technical reasons around the
>>> difficulty of renaming git repositories, the "stackforge/" git
>>> repository prefix was discontinued (all projects hosted on OpenStack
>>> infrastructure would be created under an "openstack/" git repository
>>> prefix).
>>>
>>> All those events combined, though, sent a mixed message, which we are
>>> still struggling with today. "Big tent" has a flea market
>>> connotation of
>>> "everyone can come in". Combined with the fact that all git
>>> repositories
>>> are under the same prefix, it created a lot of confusion. Some people
>>> even think the big tent is the openstack/ namespace, not the list of
>>> official projects. We tried to stop using the "big tent" meme, but (I
>>> blame Monty), the name is still sticking. I think it's time to more
>>> aggressively get rid of it. We tried using "unofficial" and
>>> "official"
>>> terminology, but that did not stick either.
>>>
>>> I'd like to propose that we introduce a new concept:
>>> "OpenStack-Hosted
>>> projects". There would be "OpenStack projects" on one side, and
>>> "Projects hosted on OpenStack infrastructure" on the other side (all
>>> still under the openstack/ git repo prefix). We'll stop saying
>>> "official
>>> OpenStack project" and "unofficial OpenStack project". The only
>>> "OpenStack projects" will be the official ones. We'll chase down the
>>> last mentions of "big tent" in documentation and remove it from our
>>> vocabulary.
>>>
>>> I think this new wording (replacing what was previously Stackforge,
>>> replacing what was previously called "unofficial OpenStack projects")
>>> will bring some clarity as to what is OpenStack and what is beyond
>>> it.
>>>
>>> Thoughts ?
>>>
>>> [1]
>>> https://governance.openstack.org/tc/resolutions/20141202-pro
>>> ject-structure-reform-spec.html
>>> [2] http://inaugust.com/posts/big-tent.html
>>> [3] https://governance.openstack.org/tc/reference/tags/index.html
>>>
>>> --
>>> Thierry Carrez (ttx)
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for 

Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

[Joshua Hesketh]

On Fri, Jun 2, 2017 at 3:30 AM, Paul Belanger  wrote:

> On Wed, May 24, 2017 at 04:04:20PM -0700, James E. Blair wrote:
> > Hi,
> >
> > As part of Zuul v3, we're adding support for GitHub (and later possibly
> > other systems).  We want these systems to have access to the full power
> > of cross-project-dependencies in the same way as Gerrit.  However, the
> > current syntax for the Depends-On footer is currently the
> > Gerrit-specific change-id.
> >
> > We chose this in an attempt to be future-compatible with some proposed
> > changes to Gerrit itself to support cross-project dependencies.  Since
> > then, Gerrit has gone in a different direction on this subject, so I no
> > longer think we should weigh that very heavily.
> >
> > While Gerrit change ids can be used to identify one or more changes
> > within a Gerrit installation, there is no comparable identifier on
> > GitHub, as pull request numbers are unique only within a project.
> >
> > The natural way to identify a GitHub pull request is with its URL.
> >
> > This can be used to identify Gerrit changes as well, and will likely be
> > well supported by other systems.  Therefore, I propose we support URLs
> > as the content of the Depends-On footers for all systems.  E.g.:
> >
> >   Depends-On: https://review.openstack.org/12345
> >   Depends-On: https://github.com/ansible/ansible/pull/12345
> >
> Hopefully not to off-topic, would it also be possible to support the
> reverse of
> this?  I know we've unofficially used the Needed-By footer for some
> governance
> patches. It has been helpful when looking at git logs to see the other
> direction
> dependency from time to time.
>
> Not a big deal if it is a no, just something that popped into my head when
> reading this topic.
>


So at the moment if we're trying to figure out why something hasn't entered
the gate we can see "oh it depends-on this other things". However if we do
a need-by that becomes a lot less obvious. If we're logging how the
changes/deps are queued/merged (as discussed in this thread) then I don't
see why not. As it is though I'd probably recommend against it.

Cheers,
Josh



>
> > Similarly to the Gerrit change IDs, these identifiers are easily
> > navigable within Gerrit (and Gertty), so that reviewers can traverse the
> > dependency chain easily.
> >
> > One substantial aspect of this change is that it is more specific about
> > projects and branches.  A single Gerrit change ID can refer to more than
> > one branch, and even more than one project.  Zuul interprets this as
> > "this change depends on *all* of the changes that match".  Often times
> > that is convenient, but sometimes it is not.  Frequently users ask "how
> > can I make this depend only on a change to master, not the backport of
> > the change to stable?" and the answer is, "you can't".
> >
> > URLs have the advantage of allowing users to be specific as to which
> > instances of a given change are actually required.  If, indeed, a change
> > depends on more than one, of course a user can still add multiple
> > Depends-On headers, one for each.
> >
> > It is also easy for Zuul connections to determine whether a given URL is
> > referring to a change on that system without actually needing to query
> > it.  A Zuul connected to several code review systems can easy determine
> > which to ask for the change by examining the hostname.
> >
> > URLs do have two disadvantages compared to Gerrit change IDs: they can
> > not be generated ahead of time, and they are not as easily found in
> > offline git history.
> >
> > With Gerrit change IDs, we can write several local changes, and before
> > pushing them to Gerrit, add Depends-On headers since the change id is
> > generated locally.  URLs are not known until the changes are pushed to
> > Gerrit (or GitHub pull requests opened).  So in some cases, editing of
> > an already existing commit message may be required.  However, the most
> > common case of a simple dependency chain can still be easily created by
> > pushing one change up at a time.
> >
> > Change IDs, by virtue of being in the commit message of the dependent as
> > well as depending change, become part of the permanent history of the
> > project, no longer tied to the code review system, once they merge.
> > This is an important thing to consider for long-running projects.  URLs
> > are less suitable for this, since they acquire their context from
> > contemporaneous servers.  However, Gerrit does record the review URL in
> > git notes, so while it's not as convenient, with some additional tooling
> > it should be possible to follow dependency paths with only the git
> > history.
> >
> > Of course, this is not a change we can make instantaneously -- the
> > change IDs have a lot of inertia and developer muscle memory.  And we
> > don't want changes that have been in progress for a while to suddenly be
> > broken with the switch to v3.  So we will need to support both syntaxes
> > for some 

Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

[Joshua Hesketh]

On Tue, May 30, 2017 at 4:55 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2017-05-29 13:34:47 +1000 (+1000), Joshua Hesketh wrote:
> [...]
> > We could extend the 'start message' of zuul to explain what it is
> > about to do. eg: "Testing change XYZ against $branch, with change
> > XYZ applied to $project $branch, with..." etc.
>
> This would be hard (I think for definitions of hard roughly equal to
> impossible) for dependent pipelines since the non-declared
> dependencies which will be tested in the pile can't be guessed in
> advance (some may be kicked out, some may come between declared
> dependencies, et cetera).
>

Right you are. Unless the start message is reposted each time the
dependencies are recalculated this isn't the best place.


>
> > This could alternatively go into a "state" file (of sorts) in the
> > zuul logs/output. ie, summarise what the zuul-cloner did into
> > simple terms that doesn't involve large logs.
>
> I'm assuming you mean zuul-merger unless zuul-cloner is growing to
> replace zuul-merger in v3 or something? Anyway, I agree a general
> logset per changeish might be nice in addition to per-job logs and
> this information might fit well somewhere there (or copied into each
> build result).
>

Right, merger or cloner (since the cloner gets what the merger prepped).

Cheers,
Josh


> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

[Joshua Hesketh]

On Sat, May 27, 2017 at 12:53 AM, James E. Blair <cor...@inaugust.com>
wrote:

> Joshua Hesketh <joshua.hesk...@gmail.com> writes:
>
> > On Fri, May 26, 2017 at 1:09 AM, James E. Blair <cor...@inaugust.com>
> wrote:
> >> So I think that we should start out by simply silently ignoring any
> >> patchset elements in the URL.  We could consider having Zuul leave a
> >> note indicating that the patchset component is not necessary and is
> >> being ignored.
> >>
> >
> > Hmm, I'm not sure if that's the best way to handle it. If somebody clicks
> > the link they'll be shown a particular patchset (whether they are aware
> of
> > not) and it may cause confusion if something else is applied in testing.
> > zuul leaving a message could help clarify this, but perhaps we should
> > honour the patchset in the URL to allow for some very specific testing or
> > re-runs. This also links into what I was saying (in my now forwarded
> > message) about "tested-with" vs "must be merged first". We could test
> with
> > a patchset but that is irrelevant once something has merged (unless we
> add
> > complexity such as detecting if the provided patchset version has merged
> or
> > if it was a different one and therefore the dependency isn't met and
> needs
> > updating).
> >
> > Either way I like the idea of zuul (or something) leave a message to be
> > explicit.
>
> I think when someone uses Depends-On, they invariably mean "this change
> depends on this other change" not "this other patchset".  Referring to a
> previous patchset may have some utility, however, it would be
> counter-intuitive and doesn't help developers in the way that Zuul is
> designed to.
>
> Fundamentally Zuul is about making sure that it's okay to land a change.
> It creates a proposed future state of one or more repositories, and
> verifies that future state is correct.  Depending on a patchset would
> violate this in two ways.
>
> First, if A Depends-On: B and B is updated, there is no feedback to the
> developers whether the new revision of B is correct.  We use Depends-On
> not only to ensure that change A has a way to pass tests, but also that
> B is a correct change that enables the behavior desired in A.
>
> In other words, we're not answering the question "Is it okay to merge B?"
>
> Second, we would be creating a proposed future state that we know can
> not exist.  If A Depends-On: an old patchset of B, and we run that test,
> it would be pointless because we know that old patchset of B is not
> going to merge.  So we're not answering the question "Will A be able to
> merge?"
>
> We merge every change with its target branch before testing in check
> (rather than testing the change as it was written) for the same
> reason -- we test what *will be*, not *what was*.
>
> -Jim
>


Sure, completely agree with everything you're saying. Mostly just thinking
out loud.

I still think we should try and be explicit about what zuul is doing.
Leaving a comment when using a different patchset to what was in the commit
message is one way of doing that.

We could extend the 'start message' of zuul to explain what it is about to
do. eg: "Testing change XYZ against $branch, with change XYZ applied to
$project $branch, with..." etc. This could alternatively go into a "state"
file (of sorts) in the zuul logs/output. ie, summarise what the zuul-cloner
did into simple terms that doesn't involve large logs.

Cheers,
Josh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax

[Joshua Hesketh]

On Fri, May 26, 2017 at 1:09 AM, James E. Blair  wrote:

> Sean Dague  writes:
>
> > On 05/24/2017 07:04 PM, James E. Blair wrote:
> > 
> >> The natural way to identify a GitHub pull request is with its URL.
> >>
> >> This can be used to identify Gerrit changes as well, and will likely be
> >> well supported by other systems.  Therefore, I propose we support URLs
> >> as the content of the Depends-On footers for all systems.  E.g.:
> >>
> >>   Depends-On: https://review.openstack.org/12345
> >>   Depends-On: https://github.com/ansible/ansible/pull/12345
> >>
> >> Similarly to the Gerrit change IDs, these identifiers are easily
> >> navigable within Gerrit (and Gertty), so that reviewers can traverse the
> >> dependency chain easily.
> >
> > Sounds sensible to me. The only thing I ask is that we get a good clock
> > countdown on when it will be removed. Upgrade testing is one of the
> > places where the multi branch magic was really useful, so it will take a
> > little while to get good at it.
>
> Yes!
>
> > For gerrit reviews it should also accept -
> > https://review.openstack.org/#/c/467243/ (as that's what is in people's
> > browser url bar).
>
> Yeah, I was thinking of copying Gertty's URL parsing here which deals
> with all the variants.
>
> This reminds me of something I forgot to mention: we should *not* depend
> on specific patchsets even if the URL specifies it.  Sometimes you end
> up with:
>
>   https://review.openstack.org/#/c/467634/1
>
> as the URL, with the patchset at the end.  I think that still confuses a
> lot of people and they don't notice.  And generally, if someone is
> specifying a dependency, they mean the change in general, and don't want
> to have to go update the depending change's commit message if they fix a
> typo.
>
> So I think that we should start out by simply silently ignoring any
> patchset elements in the URL.  We could consider having Zuul leave a
> note indicating that the patchset component is not necessary and is
> being ignored.
>


Hmm, I'm not sure if that's the best way to handle it. If somebody clicks
the link they'll be shown a particular patchset (whether they are aware of
not) and it may cause confusion if something else is applied in testing.
zuul leaving a message could help clarify this, but perhaps we should
honour the patchset in the URL to allow for some very specific testing or
re-runs. This also links into what I was saying (in my now forwarded
message) about "tested-with" vs "must be merged first". We could test with
a patchset but that is irrelevant once something has merged (unless we add
complexity such as detecting if the provided patchset version has merged or
if it was a different one and therefore the dependency isn't met and needs
updating).

Either way I like the idea of zuul (or something) leave a message to be
explicit.


>
> > And while this change is taking place, it would be nice if there was the
> > ability to have words after the url. I've often wanted:
> >
> > Depends-On: https://review.openstack.org/12345 - nova
> > Depends-On: https://review.openstack.org/12346 - python-neutronclient
> >
> > Just as a quick way to remember, without having to link follow, which of
> > multiple depends on are which projects. I've resorted to putting them on
> > top, but for short things would love to have them on the same line.
>
> That seems reasonable.  In a reply to Jeremy and Tristan, I suggested we
> may want to extend the Depends-On syntax in the future to consume some
> more information after the URL, but I think it should be fine to allow
> arbitrary text now and then reclaim keywords (like "applied to") later
> if necessary.
>
> -Jim
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Fwd: Zuul v3: proposed new Depends-On syntax

[Joshua Hesketh]

I accidentally didn't reply to the list earlier, so forwarding this through
for completeness. I agree with the proposal/discussion in general.

-- Forwarded message --
From: Joshua Hesketh <joshua.hesk...@gmail.com>
Date: Thu, May 25, 2017 at 3:53 PM
Subject: Re: [OpenStack-Infra] Zuul v3: proposed new Depends-On syntax
To: Jeremy Stanley <fu...@yuggoth.org>




On Thu, May 25, 2017 at 10:55 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2017-05-25 00:33:10 + (+), Tristan Cacqueray wrote:
> > On May 24, 2017 11:04 pm, James E. Blair wrote:
> > [...]
> > >How does that sound?
> >
> > Thinking about further connections support, could this also works
> > for a (theorical) mail based patch cross dependency?
>
> I can imagine wanting something like:
>
> Depends-On: https://lkml.org/lkml/diff/2017/5/24/668/1
>
> ...where zuul will git am what it finds there.
>
> > What's the logic to match the Depends-On syntax to a connection
> > driver?
>
> This brings up an additional question: how far can we stretch the
> concept of a connection driver, and does it always need to be
> something we can report back on in some way? Maybe we want to test a
> Gerrit change or GutHub PR which requires a patch from the LKML (as
> above) when rebuilding the kernel for a guest, but we don't ever
> expect to report back to the LKML about anything. Would having a
> generic HTTP(S) driver for things like this make sense?
>


We already have a generic git driver so it'll be theoretically possible to
point at a git ref in the future. We could also look at having a patch/diff
driver.

Depends-On, while used to set up testing scenarios, also adds a restriction
of "only merge after XYZ". We could assume that a dependency on a git ref
has already merged (and it is there to simply instruct the test/build), but
I'm not sure if a "Depends-On diff" makes as much sense. How do we know
when the diff has been applied?

I don't really want to introduce extra complexity, but one option could be
to have "Test-With" (for merging in the test suit) and "Depends-On" (for
blocking until merged) as separate DSL.

My gut feeling is that covering an arbitrary git ref is probably good
enough for now along with the assumption that anything from the git driver
has already merged.

Cheers,
Josh



> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Boston 2017 Summit dinner

[Joshua Hesketh]

Howdy,

Any of those evenings work for me thanks. Slight preference not to clash
with the StackCity though.

Cheers,
Josh

On Fri, Apr 28, 2017 at 10:47 AM, Paul Belanger 
wrote:

> Greetings!
>
> Its that time where we all try to figure out when and where to meet up for
> some
> dinner and drinks in Boston. While I haven't figure out a place to eat
> (suggestion most welcome), maybe we can decide which night to go out.
>
> As a reminder, the summit schedule has 2 events this year that people may
> also
> be attending:
>
>   Mon 8, 6:00pm - 7:30pm - Marketplace Mixer
>   Tue 9, 7:00pm - 10:00pm - StackCity Boston at Fenway Park
>
> Please take a moment to reply, and which day may be better for you.
>
>   Sunday: Yes
>   Monday: Yes
>   Tuesday: No
>   Wednesday: Yes
>   Thursday: No
>
> And, if you have a resturant in mind, please share.
>
> -PB
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [tc][election] Questions for Candidates

[Joshua Hesketh]

On Thu, Apr 13, 2017 at 2:19 AM, Kendall Nelson 
wrote:

> Hello Candidates!
>
> You all have proven yourselves to be crucial parts of the community and I
> just wanted to say good luck to each one of you in the upcoming election!
>
> Also though, I thought it might be good to ask a few more questions. It's
> easy to talk about what you all want to champion on the TC and about the
> ideal breakdown of how you want to spend your time, but it's much harder to
> answer questions that might highlight some of the daily struggles. So!
> Interview time:
>
> -What is one trait you have that makes it difficult to work in groups like
> the TC and how do you counteract it?
>

I think the obvious one is going to be the remoteness and timezones. These
have effects that are being discussed at length in some of the other
threads. However there have been some good suggestions in those threads on
how to mitigate it through utilising other media more effectively.

Another challenge is balancing the needs of the many. I think the community
does a great job at being accommodating to as many individuals, companies
and technologies as they can. However this can often come at the cost of
actually getting things done (perfection is the enemy of progress etc). I
think the TC will need to be pragmatic about its decisions and begin to be
more opinionated in order to be able to be focused and not over burdened.


>
> - What do you see as the biggest roadblock in the upcoming releases for
> the TC?
>

In terms of the releases I think we need to be careful not to bite off more
than we can chew. Recently we've been focusing on making the base layers
more stable, upgrades more seamless etc. and I think these are great. It's
easy to be ambitious with what we want to achieve in a cycle but we also
need to be realistic about our resources as the product matures.



>
> And one lighthearted question:
>
> -What is your favorite thing about OpenStack?
>


The community - it's such a pleasure to work with everybody. Everyone is so
incredibly helpful and always go out of their way as we try to work towards
a common goal.


>
> Thank you for your answers!
>

Thank you for the questions :-)

Cheers,
Josh


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

Re: [openstack-dev] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

[Joshua Hesketh]

+1, yay! :-)

On Thu, Apr 13, 2017 at 2:46 AM, Doug Hellmann 
wrote:

> Excerpts from Monty Taylor's message of 2017-04-12 08:14:31 -0500:
> > Hey all,
> >
> > As I'm sure you all know, pbr is both our most pervasively used
> > dependency and our least well understood. Nobody ever wants to look at
> > the code (sorry, I can write ugly code sometimes - but also wow
> > setuptools) or dig in to figure out what happened when things break.
> >
> > Recently Stephen Finucane (sfinucan) has stepped up to the plate to help
> > sort out issues we've been having. He's shown a lack of fear of the
> > codebase and an understanding of what's going on. He's also following
> > through on patches to projects themselves when needed, which is a huge
> > part of the game. And most importantly he knows when to suggest we _not_
> > do something.
> >
> > It's not a HUGE corpus of work we have to go on - but that's a good
> > thing - pbr shouldn't chance much - but it's in keeping with the other
> > active pbr maintainers:
> >
> > http://stackalytics.com/report/contribution/pbr/90
> >
> > Monty
> >
>
> +1 -- Stephen has been doing good work elsewhere, too.
>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [elections] Available time and top priority

[Joshua Hesketh]

Howdy,

To answer the original question, if elected, I should be able to commit at
least a few hours per day to the TC (if not more). I can also be quite
elastic in this being able to spend more time some weeks than others as the
role dictates.

My timezone is UTC+10 which makes the meetings at 6am. While not ideal I
can attend these meetings. I do, however, agree with the general discussion
about ensuring the meetings are accessible to all and would support an
alternating meeting time to make it easier for others to participate.

If elected to the TC I would like to help focus on strengthening our
engagement with neighbouring communities. To do this we need to solidify
our vision so that we better understand what role we play in the open cloud
world and how we can both leverage other projects and also give them a
platform to build upon. I want to see the core services continue to become
more stable and consistent to allow other applications, not even
necessarily within the OpenStack ecosystem, to build upon them. I am
excited by the draft version of the vision that has been set forward and I
want to do what I can to help us work towards that.

Cheers,
Josh

On Mon, Apr 10, 2017 at 7:16 PM, Thierry Carrez 
wrote:

> Hi everyone,
>
> New in this TC election round, we have a few days between nominations
> and actual voting to ask questions and get to know the candidates a bit
> better. I'd like to kick off this new "campaigning period" with a basic
> question on available time and top priority.
>
> All the candidates are top community members with a lot of
> responsibilities on their shoulders already. My experience tells me that
> it is easy to overestimate the time we can dedicate to Technical
> Committee matters, and how much we can push and get done in six months
> or one year. At the same time, our most efficient way to make progress
> is always when someone "owns" a particular initiative and pushes it
> through the governance process.
>
> So my question is the following: if elected, how much time do you think
> you'll be able to dedicate to Technical Committee affairs (reviewing
> proposed changes and pushing your own) ? If there was ONE thing, one
> initiative, one change you will actively push in the six months between
> this election round and the next, what would it be ?
>
> Thanks in advance for your answers !
>
> --
> Thierry Carrez (ttx)
>
> __
> 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-Infra] Skipping 2017-04-10 Zuul meeting

[Joshua Hesketh]

Hey,

Just checking that you didn't mean the following week (17th) as it's Easter
Monday. That's a public holiday in Australia (although the meeting falls on
the Tuesday here), do we know if we'll have quorum next week?

Cheers,
Josh

On Sat, Apr 8, 2017 at 6:10 AM, James E. Blair  wrote:

> Hi,
>
> We're going to have several absences next Monday, the 10th, so let's
> skip the Zuul meeting that day.
>
> -Jim
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[openstack-dev] [election][tc] Nominating for Technical Committee

[Joshua Hesketh]

Howdy,

My name is Joshua Hesketh and I would like to self nominate for the
Technical
Committee.

I work for Rackspace Australia and have been involved in the OpenStack
community
since the Havana release circa 2013. I have been primarily working on the
Infrastructure (infra) project where I am both a core contributor and root.

Outside of OpenStack, I have experience leading various communities within
the
Oceania region. For six years I served the open source community as
President
and Treasurer of Linux Australia. During this time I helped to grow and
scale
the organisation from overseeing a single conference each year, to over
eight.
Additionally I've directly helped organise and run multiple Linux Australia
Conferences (linux.conf.au), PyCon Australia Conferences, as well as
OpenStack
and cloud/infrastructure miniconfs.

I am a strong proponent and advocate for free and open source software. I am
also a strong believer in the Four Opens that make up OpenStack, and
believe we
lead the way for managing open clouds. I want to do all that I can to help
further this mission.

The Technical Committee has been doing a great job leading the community
and I
don't have a particular platform for radical change. Instead, I would like
to
help continue to strengthen and work on the committee with a focus on the
following:

 - Enabling the community. The TC is here to serve the community and
facilitate
   collaboration.
 - Protecting our values, in particular the Four Opens.
 - Continuing to investigate and evaluate alternative technologies and how
we
   work with them. For example, evaluating and introducing new languages.
 - Promote collaboration with the wider open source community. For example,
   participating with communities such as kubernetes.
 - Easing pain for operators, deployers and users by helping to improve
   consistency across projects through OpenStack-wide goals.

I would be glad to answer any questions during the candidacy period (and any
time for that matter) and if elected I look forward to working in this new
role.

Thank you for your consideration,
Joshua Hesketh
__
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-Infra] Dell Ironic CI broken

[Joshua Hesketh]

Hey,

I've disabled the account. Once it is fixed we can re-enable it.

Thanks,
Josh

On Mon, Mar 27, 2017 at 7:22 PM, Andreas Jaeger  wrote:

>
> Dell Ironic CI is reporting on unrelated changes like
>  https://review.openstack.org/449385 - project-config
> https://review.openstack.org/#/c/450088/ - trove
>
> It reports in both cases:
> "Merge Failed.
> This change or one of its cross-repo dependencies was unable to be
> automatically merged with the current state of its repository. Please
> rebase the change and upload a new patchset."
>
> Please disable our CI immediately - and fix it and test on the
> sandbox-ci repo,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] Zuul v3 - What's Coming: What to expect with the Zuul v3 Rollout

[Joshua Hesketh]

Thanks for the great write-up Monty :-). Last week was great fun and zuulv3
is making excellent process. I'm excited for the switch-over.

Cheers,
Josh

On Wed, Mar 1, 2017 at 10:26 AM, Monty Taylor  wrote:

> Hi everybody!
>
> This content can also be found at
> http://inaugust.com/posts/whats-coming-zuulv3.html - but I've pasted it
> in here directly because I know that some folks don't like clicking links.
>
> tl;dr - At last week's OpenStack PTG, the OpenStack Infra team ran the
> first Zuul v3 job, so it's time to start getting everybody ready for
> what's coming
>
> **Don't Panic!** Awesome changes are coming, but you are NOT on the hook
> for rewriting all of your project's gate jobs or anything crazy like
> that. Now grab a seat by the fire, pour yourself a drink while I spin a
> yarn about days gone by and days yet to come.
>
> First, some background
>
> The OpenStack Infra team has been hard at work for quite a while on a
> new version of Zuul (where by 'quite some time' I mean that Jim Blair
> and I had our first Zuul v3 design whiteboarding session in 2014). As
> you might be able to guess given the amount of time, there are some big
> things coming that will have a real and visible impact on the OpenStack
> community and beyond. Since we have a running Zuul v3 now [1], it seemed
> like the time to start getting folks up to speed on what to expect.
>
> There is other deep-dive information on architecture and rationale if
> you're interested[2], but for now we'll focus on what's relevant for end
> users. We're also going to start sending out a bi-weekly "Status of Zuul
> v3" email to the openstack-dev@lists.openstack.org mailing list ... so
> stay tuned!
>
> **Important Note** This post includes some code snippets - but v3 is
> still a work in progress. We know of at least one breaking change that
> is coming to the config format, so please treat this not as a tutorial,
> but as a conceptual overview. Syntax is subject to change.
>
> The Big Ticket Items
>
> While there are a bunch of changes behind the scenes, there are a
> reasonably tractable number of user-facing differences.
>
> * Self-testing In-Repo Job Config
> * Ansible Job Content
> * First-class Multi-node Jobs
> * Improved Job Reuse
> * Support for non-OpenStack Code and Node Systems
> * and Much, Much More
>
> Self-testing In-Repo Job Config
>
> This is probably the biggest deal. There are a lot of OpenStack Devs
> (around 2k in Ocata) and a lot of repositories (1689) There a lot fewer
> folks on the project-config-core team who are the ones who review all of
> the job config changes (please everyone thank Andreas Jaeger next time
> you see him). That's not awesome.
>
> Self-testing in-repo job config is awesome.
>
> Many systems out there these days have an in-repo job config system.
> Travis CI has had it since day one, and Jenkins has recently added
> support for a Jenkinsfile inside of git repos. With Zuul v3, we'll have
> it too.
>
> Once we roll out v3 to everyone, as a supplement to jobs defined in our
> central config repositories, each project will be able to add a
> zuul.yaml file to their own repo:
>
>
> - job:
> name: my_awesome_job
> nodes:
>   - name: controller
> label: centos-7
>
> - project:
> name: openstack/awesome_project
> check:
>   jobs:
> - my_awesome_job
>
> It's a small file, but there is a lot going on, so let's unpack it.
>
> First we define a job to run. It's named my_awesome_job and it needs one
> node. That node will be named controller and will be based on the
> centos-7 base node in nodepool.
>
> In the next section, we say that we want to run that job in the check
> pipeline, which in OpenStack is defined as the jobs that run when
> patchsets are proposed.
>
> And it's also self-testing!
>
> Everyone knows the fun game of writing a patch to the test jobs, getting
> it approved, then hoping it works once it starts running. With Zuul v3
> in-repo jobs, if there is a change to job definitions in a proposed
> patch, that patch will be tested with those changes applied. And since
> it's Zuul, Depends-On footers are honored as well - so iteration on
> getting a test job right becomes just like iterating on any other patch
> or sequence of patches.
>
> Ansible Job Content
>
> The job my_awesome_job isn't very useful if it doesn't define any
> content. That's done in the repo as well, in playbooks/my_awesome_job.yaml:
>
>
> - hosts: controller
>   tasks:
> - name: Run make tests
>   shell: make distcheck
>
> As previously mentioned, the job content is now defined in Ansible
> rather than using our Jenkins Job Builder tool. This playbook is going
> to run a tasks on a host called controller which you may remember we
> requested in the job definition. On that host, it will run make
> distcheck. Pretty much anything you can do in Ansible, you can do in a
> Zuul job now, and the playbooks should also be re-usable outside of a
> testing 

Re: [OpenStack-Infra] [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Wed, Feb 15, 2017 at 4:20 PM, Tony Breeds 
wrote:

> On Wed, Feb 08, 2017 at 09:55:41AM -0800, Ihar Hrachyshka wrote:
> > Has the liberty-eol cleanup happened? Because I still see
> > stable/liberty branch in openstack/neutron repo, which gets in the way
> > of some logic around proactive backports:
> > https://review.openstack.org/#/c/427936/4/bugs-fixed-since.py@75, and
> > I see backports proposed for the branch that is no longer supported
> > and has broken gate setup.
>
> It seems I setup the second wave and then neglected to ask the infra team
> to process them.
>
> Infra tema (*cough* Josh *cough*) can you remove the branches marke Please
> EOL in
>
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4
> ac/raw/4f781426270cb2030f978f47b1f46dae6f5aecb4/liberty_eol_data.txt
>
>
Hey,

I have processed these retirements. Let me know if there are any more or
any problems etc.

Cheers,
Josh


> Once that's done I can do a final pass for jobs that may break and we can
> drop
> the devstack, devstack-gate and requirements branches.
>
> Tony.
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Wed, Feb 15, 2017 at 4:20 PM, Tony Breeds 
wrote:

> On Wed, Feb 08, 2017 at 09:55:41AM -0800, Ihar Hrachyshka wrote:
> > Has the liberty-eol cleanup happened? Because I still see
> > stable/liberty branch in openstack/neutron repo, which gets in the way
> > of some logic around proactive backports:
> > https://review.openstack.org/#/c/427936/4/bugs-fixed-since.py@75, and
> > I see backports proposed for the branch that is no longer supported
> > and has broken gate setup.
>
> It seems I setup the second wave and then neglected to ask the infra team
> to process them.
>
> Infra tema (*cough* Josh *cough*) can you remove the branches marke Please
> EOL in
>
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4
> ac/raw/4f781426270cb2030f978f47b1f46dae6f5aecb4/liberty_eol_data.txt
>
>
Hey,

I have processed these retirements. Let me know if there are any more or
any problems etc.

Cheers,
Josh


> Once that's done I can do a final pass for jobs that may break and we can
> drop
> the devstack, devstack-gate and requirements branches.
>
> Tony.
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
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-Infra] PTG team dinner?

[Joshua Hesketh]

On Thu, Feb 16, 2017 at 9:58 AM, Clark Boylan  wrote:

> On Tue, Feb 14, 2017, at 03:01 PM, Clark Boylan wrote:
> > With the help of the small restaurant guide on the wiki I have
> > discovered Poor Calvin's. This place looks neat, supposedly fusion of
> > Thai and Southern food and is well reviewed. It is 0.8 miles or ~15
> > minute walk from the Sheraton according to Google so should be walkable
> > for most. Rather than draw out restaurant selection I was thinking I
> > would go ahead and try to make a reservation for however many people are
> > signed up on the etherpad for as close to 7pm as I can manage Monday
> > night. I will wait until tomorrow before doing this in order to provide
> > veto time if this location does not work for someone, in which case
> > please do help suggest an alternative.
> >
> > If I can't get a reservation for us at Poor Calvin's I was looking at
> > Sway as a backup since it also has southern food and seems to be well
> > reviewed despite being hotel restaurant. Again please veto if necessary
> > and suggest alternatives.
> >
> > Lastly I did update the etherpad with links to these restaurants (and a
> > few others) if you need more info.
>
> Alright, with Monty's help we now have a reservation at Poor Calvin's
> for Monday the 20th at 7pm. The reservation is for 14 and under my name,
> Clark Boylan. See you there! (and at the PTG).
>

s... no Hawaiian shirts?



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

Re: [OpenStack-Infra] PTG team dinner?

[Joshua Hesketh]

>
> I'd say reserve for 11 now. You can always adjust it as the etherpad
> changes.
>
>
I'd suggest maybe adding a few extra as we might find people during the day
who want to tag along.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Ask.o.o down

[Joshua Hesketh]

On Tue, Feb 14, 2017 at 7:15 PM, Tom Fifield <t...@openstack.org> wrote:

> On 14/02/17 16:11, Joshua Hesketh wrote:
>
>> Hey Tom,
>>
>> Where is that script being fired from (a quick grep doesn't find it), or
>> is it a tool people are using?
>>
>> If it's a tool we'd need to make sure whoever is using it gets a new
>> version to rule it out.
>>
>
> Indeed.
>
>
> It's fired from a PHP service on www.openstack.org itself, which writes
> to the Member database:
>
> https://github.com/OpenStackweb/openstack-org/blob/master/
> auc-metrics/code/services/ActiveModeratorService.php



Right. I wonder if somebody could check the logs to see if the process
times out. Sadly looking at that code it looks like any output messages
from the script will be discarded.

 - Josh




>
>
> The next step is to update the copy of the script it references:
>
> https://github.com/OpenStackweb/openstack-org/blob/master/
> auc-metrics/lib/uc-recognition/tools/get_active_moderator.py
>
> I am not sure if this is in place using git submodules or manually, but
> will figure it out and get that updated.
>
>
>
>
>  - Josh
>>
>> On Tue, Feb 14, 2017 at 7:07 PM, Tom Fifield <t...@openstack.org
>> <mailto:t...@openstack.org>> wrote:
>>
>> On 14/02/17 16:06, Joshua Hesketh wrote:
>>
>> Hey,
>>
>> I've brought the service back up, but have no new clues as to why.
>>
>>
>> Cheers.
>>
>> Going to try: https://review.openstack.org/#/c/433478/
>> <https://review.openstack.org/#/c/433478/>
>> to see if this script is culprit.
>>
>>
>> - Josh
>>
>> On Tue, Feb 14, 2017 at 6:50 PM, Tom Fifield <t...@openstack.org
>> <mailto:t...@openstack.org>
>> <mailto:t...@openstack.org <mailto:t...@openstack.org>>> wrote:
>>
>> On 10/02/17 22:39, Jeremy Stanley wrote:
>>
>> On 2017-02-10 16:08:51 +0800 (+0800), Tom Fifield wrote:
>> [...]
>>
>> Down again, this time with "Network is unreachable".
>>
>> [...]
>>
>> I'm not finding any obvious errors on the server nor
>> relevant
>> maintenance notices/trouble tickets from the service
>> provider to
>> explain this. I do see conspicuous gaps in network
>> traffic volume
>> and system load from ~06:45 to ~08:10 UTC according to
>> cacti:
>>
>> http://cacti.openstack.org/?tree_id=1_id=156
>> <http://cacti.openstack.org/?tree_id=1_id=156>
>> <http://cacti.openstack.org/?tree_id=1_id=156
>> <http://cacti.openstack.org/?tree_id=1_id=156>>
>>
>> Skipping back through previous days I find some similar
>> gaps
>> starting anywhere from 06:30 to 07:00 and ending between
>> 07:00 and
>> 08:00 but they don't seem to occur every day and I'm not
>> having much
>> luck finding a pattern. It _is_ conspicuously close to
>> when
>> /etc/cron.daily scripts get fired from the crontab so
>> might coincide
>> with log rotation/service restarts? The graphs don't
>> show these gaps
>> correlating with any spikes in CPU, memory or disk
>> activity so it
>> doesn't seem to be resource starvation (at least not for
>> any common
>> resources we're tracking).
>>
>>
>> Indeed. It's down again today during the same timeslot.
>>
>> Another idea for the cron-based theory:
>>
>>
>> https://github.com/openstack/uc-recognition/blob/master/tool
>> s/get_active_moderator.py
>> <https://github.com/openstack/uc-recognition/blob/master/too
>> ls/get_active_moderator.py>
>>
>> <https://github.com/openstack/uc-recognition/blob/master/too
>> ls/get_active_moderator.py
>> <https://github.com/openstack/uc-recognition/blob/master/too
>> ls/get_active_moderator.py>>
>>
>> loops through the list of Ask OpenStack users via the API on
>> a cron
>> running on www.openstack.org <http://www.openstack.org>
>> <http://www.openstack.org>. Not sure
>>  

Re: [OpenStack-Infra] Ask.o.o down

[Joshua Hesketh]

Hey Tom,

Where is that script being fired from (a quick grep doesn't find it), or is
it a tool people are using?

If it's a tool we'd need to make sure whoever is using it gets a new
version to rule it out.

 - Josh

On Tue, Feb 14, 2017 at 7:07 PM, Tom Fifield <t...@openstack.org> wrote:

> On 14/02/17 16:06, Joshua Hesketh wrote:
>
>> Hey,
>>
>> I've brought the service back up, but have no new clues as to why.
>>
>
> Cheers.
>
> Going to try: https://review.openstack.org/#/c/433478/
> to see if this script is culprit.
>
>
> - Josh
>>
>> On Tue, Feb 14, 2017 at 6:50 PM, Tom Fifield <t...@openstack.org
>> <mailto:t...@openstack.org>> wrote:
>>
>> On 10/02/17 22:39, Jeremy Stanley wrote:
>>
>> On 2017-02-10 16:08:51 +0800 (+0800), Tom Fifield wrote:
>> [...]
>>
>> Down again, this time with "Network is unreachable".
>>
>> [...]
>>
>> I'm not finding any obvious errors on the server nor relevant
>> maintenance notices/trouble tickets from the service provider to
>> explain this. I do see conspicuous gaps in network traffic volume
>> and system load from ~06:45 to ~08:10 UTC according to cacti:
>>
>> http://cacti.openstack.org/?tree_id=1_id=156
>> <http://cacti.openstack.org/?tree_id=1_id=156>
>>
>> Skipping back through previous days I find some similar gaps
>> starting anywhere from 06:30 to 07:00 and ending between 07:00 and
>> 08:00 but they don't seem to occur every day and I'm not having
>> much
>> luck finding a pattern. It _is_ conspicuously close to when
>> /etc/cron.daily scripts get fired from the crontab so might
>> coincide
>> with log rotation/service restarts? The graphs don't show these
>> gaps
>> correlating with any spikes in CPU, memory or disk activity so it
>> doesn't seem to be resource starvation (at least not for any
>> common
>> resources we're tracking).
>>
>>
>> Indeed. It's down again today during the same timeslot.
>>
>> Another idea for the cron-based theory:
>>
>> https://github.com/openstack/uc-recognition/blob/master/tool
>> s/get_active_moderator.py
>> <https://github.com/openstack/uc-recognition/blob/master/too
>> ls/get_active_moderator.py>
>>
>> loops through the list of Ask OpenStack users via the API on a cron
>> running on www.openstack.org <http://www.openstack.org>. Not sure
>> when that cron runs, but if it's similar, this could potentially be
>> a high-load generator.
>>
>>
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> <mailto:OpenStack-Infra@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra>
>>
>>
>>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Ask.o.o down

[Joshua Hesketh]

Hey,

I've brought the service back up, but have no new clues as to why.

- Josh

On Tue, Feb 14, 2017 at 6:50 PM, Tom Fifield  wrote:

> On 10/02/17 22:39, Jeremy Stanley wrote:
>
>> On 2017-02-10 16:08:51 +0800 (+0800), Tom Fifield wrote:
>> [...]
>>
>>> Down again, this time with "Network is unreachable".
>>>
>> [...]
>>
>> I'm not finding any obvious errors on the server nor relevant
>> maintenance notices/trouble tickets from the service provider to
>> explain this. I do see conspicuous gaps in network traffic volume
>> and system load from ~06:45 to ~08:10 UTC according to cacti:
>>
>> http://cacti.openstack.org/?tree_id=1_id=156
>>
>> Skipping back through previous days I find some similar gaps
>> starting anywhere from 06:30 to 07:00 and ending between 07:00 and
>> 08:00 but they don't seem to occur every day and I'm not having much
>> luck finding a pattern. It _is_ conspicuously close to when
>> /etc/cron.daily scripts get fired from the crontab so might coincide
>> with log rotation/service restarts? The graphs don't show these gaps
>> correlating with any spikes in CPU, memory or disk activity so it
>> doesn't seem to be resource starvation (at least not for any common
>> resources we're tracking).
>>
>>
> Indeed. It's down again today during the same timeslot.
>
> Another idea for the cron-based theory:
>
> https://github.com/openstack/uc-recognition/blob/master/tool
> s/get_active_moderator.py
>
> loops through the list of Ask OpenStack users via the API on a cron
> running on www.openstack.org. Not sure when that cron runs, but if it's
> similar, this could potentially be a high-load generator.
>
>
>
>
> Regards,
>
>
> Tom
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] PTG team dinner?

[Joshua Hesketh]

I am both interested and there (for the whole week, but any night works for
me at this stage). Catching up with everybody is always a highlight for me
:-). I also might own a Hawaiian shirt somewhere.

On Wed, Feb 8, 2017 at 11:28 AM, Clark Boylan  wrote:

> Hello,
>
> We failed at doing a lunch or dinner together in Barcelona because
> ETOOMANYTHINGS. Wondering if there is interest in attempting to do a
> dinner during the PTG? Would likely have to be Monday night since I
> expect some people will leave late Tuesday.
>
> Not sure how many of us are interested and will be at the PTG, but maybe
> we can try putting something together if we get a rough headcount?
>
> I'm in for what its worth. Also noticed there is a Trader Vic's nearby,
> we could all dress in Hawaiian shirts like fungi :)
>
> Clark
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [openstack-infra] Please add a initial core member to meteos-ui-core.

[Joshua Hesketh]

All done :-)

On Wed, Feb 1, 2017 at 11:53 AM, Hiroyuki Eguchi 
wrote:

> Hello Infra Team.
>
>
>
> I've created new projects named meteos-ui
>
> which UI interface for Machine Learning as a Service.
>
>
>
> Could you please add me (Hiroyuki Eguchi )
>
> as a initial core member of meteos-ui-core ?
>
>
>
> Thanks.
>
>
>
> --
>
> Hiroyuki Eguchi
>
>
>
> __
> 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] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Tue, Dec 20, 2016 at 4:02 PM, Samuel Cassiba  wrote:

> >
> > On Dec 19, 2016, at 14:31, Tony Breeds  wrote:
> >
> > On Mon, Dec 19, 2016 at 09:18:20AM -0800, Samuel Cassiba wrote:
> >
> >> The Chef OpenStack cookbooks team is way late to the party. The
> cookbooks
> >> (openstack/cookbook-openstack-*, openstack/openstack-chef-repo )
> should have
> >> had their liberty branches EOL’d. I have checked and no open reviews
> exist
> >> against liberty.
> >
> > Thanks.
> >
> > While I have your attention what about your older branches.  Is there any
> > mertit keeping the kilo branches in openstack/cookbook-openstack-* or the
> > stable/{grizzly,havana,icehouse,juno} branches in
> openstack/openstack-chef-repo
> >
>
> No, no merit in keeping older branches around. They can be rightfully
> EOL’d as well.
>

Howdy,

I've cleaned up all of these branches for you. The repos that have been
retired haven't been touched. A lot of the repos had eol-$release tags but
the format used for the rest of openstack is typically $release-eol which
is the format I have kept for retiring kilo and liberty against.

Let me know if you have any questions.

Cheers,
Josh


>
> Many thanks!
>
> > Yours Tony.
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack 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][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Mon, Dec 19, 2016 at 11:10 AM, Tony Breeds 
wrote:

> On Fri, Dec 16, 2016 at 05:41:31PM -0500, Emilien Macchi wrote:
> > Hey Tony,
> >
> > Could we also EOL tripleo-incubator and tripleo-image-elements
> > stable/icehouse please?
>
> Yup, No problem.
>

I have retired icehouse in both of those repos.

Cheers,
Josh


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

Re: [openstack-dev] [infra] Any way to disable zuul status page auto-refresh?

[Joshua Hesketh]

You could try saving the status page and modifying the refresh time, or
similarly you could checkout zuul and run the webapp locally[0]. You'd have
to point it at [1] and modify the refresh times here [2]. (The status page
in the zuul tree is different to the one on status.o.o).

Cheers,
Josh

[0] http://git.openstack.org/cgit/openstack-infra/zuul/tree/etc/status
[1] http://zuul.openstack.org/status.json
[2]
http://git.openstack.org/cgit/openstack-infra/zuul/tree/etc/status/public_html/jquery.zuul.js#n627
& 631

On Tue, Dec 20, 2016 at 5:22 AM, Ben Nemec  wrote:

> The subject pretty much covers it.  When there are a lot of jobs on the
> zuul status page, it kind of brings my browser to its knees, which makes it
> hard to navigate the page.  I know you can filter it, but sometimes I want
> to see all of the jobs in a queue so that isn't always an option. If there
> were a way to let me refresh it on demand (or maybe auto-refresh less
> often?) that would be awesome.
>
> -Ben
>
> __
> 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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

On Thu, Dec 15, 2016 at 12:48 AM, Ian Cordasco <sigmaviru...@gmail.com>
wrote:

> -Original Message-
> From: Joshua Hesketh <joshua.hesk...@gmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Date: December 14, 2016 at 06:56:22
> To: OpenStack Development Mailing List <openstack-dev@lists.openstack.org>,
> openstack-infra <openstack-in...@lists.openstack.org>
> Subject:  Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls]
> Tagging liberty as EOL
>
> > The repos listed[0] have had stable/liberty branch removed and replaced
> > with a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
> >
> > Cheers,
> > Josh
> >
> > [0]
> > https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> Glance was late to the party, but it should have had its liberty branches
> EOL'd as well.
>


Tony's comment on https://review.openstack.org/#/c/410536/ implies there
may be some steps to do first. I'll wait on confirmation from Tony before
retiring the branch.

Cheers,
Josh



>
> --
> Ian Cordasco
>
>
> __
> 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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

Hi Sumit,

That's fine. That repo wasn't marked for removal.

Cheers,
Josh

On Thu, Dec 15, 2016 at 3:28 PM, Sumit Naiksatam <sumitnaiksa...@gmail.com>
wrote:

> On Wed, Dec 14, 2016 at 4:54 AM, Joshua Hesketh
> <joshua.hesk...@gmail.com> wrote:
> > The repos listed[0] have had stable/liberty branch removed and replaced
> with
> > a liberty-eol tag. Any open reviews have been abandoned.
> >
> > Please let me know if there are any mistakes or latecomers to the list.
>
> Hi Joshua, Apologies for chiming in late, but we request that the
> openstack/group-based-policy repo’s stable/liberty branch be _not_
> removed/EOL’ed and the currently open patches not be abandoned. We
> have consumers of this branch and we do backport bug fixes. Thanks in
> advance!
>
> ~Sumit.
>
> >
> > Cheers,
> > Josh
> >
> > [0]
> > https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> >
> > On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh <joshua.hesk...@gmail.com
> >
> > wrote:
> >>
> >> Hey Tony and all,
> >>
> >> I'm happy to take care of these retirements. However I probably can't
> get
> >> to it until Tuesday next week. So assuming no other infra root beats me
> to
> >> it I'll look at it then.
> >>
> >> Cheers,
> >> Josh
> >>
> >> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds <t...@bakeyournoodle.com>
> >> wrote:
> >>>
> >>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
> >>>
> >>> > I'll batch the removal of the stable/liberty branches between Nov
> 28th
> >>> > and Dec
> >>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
> >>> > zuul/layout.yaml
> >>> > to remove liberty exclusions and jobs.
> >>>
> >>> This took longer as there are a few repos that are scheduled for EOL
> that
> >>> were a
> >>> little problematic during the kilo cycle.  I've updated the list at [1]
> >>>
> >>> Can the infra team please run eol_branch.sh [2] over the repos listed
> at
> >>> that
> >>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
> >>> later.
> >>>
> >>> eol_branch.sh needs just the repo names what can be generated with
> >>> something like:
> >>>
> >>> URL=https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> >>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
> >>>
> >>> The data format is a balance between human and machine readable.
> >>>
> >>> Yours Tony.
> >>>
> >>> [1]
> >>> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4
> ac#file-liberty_eol_data-txt
> >>> [2]
> >>> http://git.openstack.org/cgit/openstack-infra/release-tools/
> tree/eol_branch.sh
> >>>
> >>> ___
> >>> OpenStack-Infra mailing list
> >>> openstack-in...@lists.openstack.org
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> >>
> >>
> >
> >
> > ___
> > OpenStack-Infra mailing list
> > openstack-in...@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
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-Infra] [openstack-dev] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

The repos listed[0] have had stable/liberty branch removed and replaced
with a liberty-eol tag. Any open reviews have been abandoned.

Please let me know if there are any mistakes or latecomers to the list.

Cheers,
Josh

[0]
https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt

On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh <joshua.hesk...@gmail.com>
wrote:

> Hey Tony and all,
>
> I'm happy to take care of these retirements. However I probably can't get
> to it until Tuesday next week. So assuming no other infra root beats me to
> it I'll look at it then.
>
> Cheers,
> Josh
>
> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds <t...@bakeyournoodle.com>
> wrote:
>
>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>>
>> > I'll batch the removal of the stable/liberty branches between Nov 28th
>> and Dec
>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
>> zuul/layout.yaml
>> > to remove liberty exclusions and jobs.
>>
>> This took longer as there are a few repos that are scheduled for EOL that
>> were a
>> little problematic during the kilo cycle.  I've updated the list at [1]
>>
>> Can the infra team please run eol_branch.sh [2] over the repos listed at
>> that
>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
>> later.
>>
>> eol_branch.sh needs just the repo names what can be generated with
>> something like:
>> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa4
>> 6269456f56649f0a4ac/raw/liberty_eol_data.txt
>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>>
>> The data format is a balance between human and machine readable.
>>
>> Yours Tony.
>>
>> [1] https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0
>> a4ac#file-liberty_eol_data-txt
>> [2] http://git.openstack.org/cgit/openstack-infra/release-tools/
>> tree/eol_branch.sh
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

The repos listed[0] have had stable/liberty branch removed and replaced
with a liberty-eol tag. Any open reviews have been abandoned.

Please let me know if there are any mistakes or latecomers to the list.

Cheers,
Josh

[0]
https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt

On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh <joshua.hesk...@gmail.com>
wrote:

> Hey Tony and all,
>
> I'm happy to take care of these retirements. However I probably can't get
> to it until Tuesday next week. So assuming no other infra root beats me to
> it I'll look at it then.
>
> Cheers,
> Josh
>
> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds <t...@bakeyournoodle.com>
> wrote:
>
>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>>
>> > I'll batch the removal of the stable/liberty branches between Nov 28th
>> and Dec
>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
>> zuul/layout.yaml
>> > to remove liberty exclusions and jobs.
>>
>> This took longer as there are a few repos that are scheduled for EOL that
>> were a
>> little problematic during the kilo cycle.  I've updated the list at [1]
>>
>> Can the infra team please run eol_branch.sh [2] over the repos listed at
>> that
>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
>> later.
>>
>> eol_branch.sh needs just the repo names what can be generated with
>> something like:
>> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa4
>> 6269456f56649f0a4ac/raw/liberty_eol_data.txt
>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>>
>> The data format is a balance between human and machine readable.
>>
>> Yours Tony.
>>
>> [1] https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0
>> a4ac#file-liberty_eol_data-txt
>> [2] http://git.openstack.org/cgit/openstack-infra/release-tools/
>> tree/eol_branch.sh
>>
>> ___
>> OpenStack-Infra mailing list
>> openstack-in...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>
>
__
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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

[Joshua Hesketh]

Hey Tony and all,

I'm happy to take care of these retirements. However I probably can't get
to it until Tuesday next week. So assuming no other infra root beats me to
it I'll look at it then.

Cheers,
Josh

On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds  wrote:

> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>
> > I'll batch the removal of the stable/liberty branches between Nov 28th
> and Dec
> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
> zuul/layout.yaml
> > to remove liberty exclusions and jobs.
>
> This took longer as there are a few repos that are scheduled for EOL that
> were a
> little problematic during the kilo cycle.  I've updated the list at [1]
>
> Can the infra team please run eol_branch.sh [2] over the repos listed at
> that
> URL [1] and flagged with 'Please EOL'.  The others will need to be done
> later.
>
> eol_branch.sh needs just the repo names what can be generated with
> something like:
> URL=https://gist.githubusercontent.com/tbreeds/
> 93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>
> The data format is a balance between human and machine readable.
>
> Yours Tony.
>
> [1] https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4
> ac#file-liberty_eol_data-txt
> [2] http://git.openstack.org/cgit/openstack-infra/release-tools/
> tree/eol_branch.sh
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
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] [OpenStack-Infra] [Infra] Ocata Summit Infra Sessions Recap

[Joshua Hesketh]

Thank you for the write up. Having missed being there in person it is much
appreciated :-)

On Wed, Dec 7, 2016 at 5:56 AM, Jeremy Stanley  wrote:

> I'm Cc'ing this to the openstack-infra ML but setting MFT to direct
> subsequent discussion to the openstack-dev ML so we can hopefully
> avoid further cross-posting as much as possible. If you're replying
> on a particular session topic, please update the Subject so that the
> subthreads are easier to keep straight.
>
> Apologies for the _extreme_ delay in getting this composed and sent
> out!
>
>
> Firehose
> 
>
> https://etherpad.openstack.org/p/ocata-infra-firehose
>
> This was primarily a brainstorming/roadmap session on possible
> future plans for the firehose.openstack.org service. Discussed was
> potential to have Zuul (post-v3) both consume and emit events over
> MQTT, as well as having StoryBoard (should probably support an
> analog of the events handled by lpmqtt at a minimum, probably easy
> to add given it already has an RabbitMQ one) and Nodepool event
> streams. The gerritbot consumer PoC was mentioned, but determined
> that it would be better to shelve that until planning for an
> Errbot-based gerritbot reimplementation is fleshed out.
>
> We talked about how the current logstash MQTT stream implementation,
> while interesting, has significant scaling (especially bandwidth)
> issues with the volume of logging we do in tests while only offering
> limited benefit. We could potentially make use of it in concern with
> a separate logstash for production server and Ansible logs, but it's
> efficacy for our job logs was called into question.
>
> We also spent much of the timeslot talking about possible
> integration with FedMesg (particularly that they're considering
> pluggable backend support which could include an MQTT
> implementation), which yields much opportunity for collaboration
> between our projects.
>
> One other topic which came up was how to do a future HA
> implementation, either by having publishers send to multiple brokers
> and configure consumers to have a primary/fallback behavior or my
> trying to implement a more integrated clustering solution with load
> balancing proxies. We concluded that current use cases don't demand
> anywhere near 100% message delivery and 100% uptime, so we can dig
> deeper when there's an actual use case.
>
>
> Status update and plans for task tracking
> -
>
> https://etherpad.openstack.org/p/ocata-infra-community-task-tracking
>
> As is traditional, we held a fishbowl on our ongoing task tracking
> woes. We started with a brief introduction of stakeholders who
> attended and the groups whose needs they were there to represent.
> After that, some presentation was made of recent StoryBoard
> development progress since Austin (including Gerrit integration,
> private story support for embargoed security issues, improved event
> timelines, better discoverability for boards and worklists, flexible
> task prioritization), as well as the existing backlog of blockers.
>
> We revisited the Infra spec on task tracking
> http://specs.openstack.org/openstack-infra/infra-specs/
> specs/task-tracker.html
> for the benefit of those present, and Kendall Nelson (diablo_rojo)
> agreed to pick up and continue with the excellent stakeholder
> blocking issues outreach/coordination work begun by Anita Kuno
> (anteaya).
>
>
> Next steps for infra-cloud
> --
>
> https://etherpad.openstack.org/p/ocata-infra-infra-cloud
>
> This was sort of a catch-all opportunity to hash out current plans
> and upcoming needs for the infra-cloud. We determined that the
> current heterogeneous hardware in the in-progress "chocolate" region
> should be split into two homogeneous regions named "chocolate" and
> "strawberry" (our "vanilla" region was already homogeneous). We also
> talked about ongoing work to get a quote from OSUOSL for hosting the
> hardware so that we can move it out of HPE data centers, and
> attempting to find funding once we have some figures firmed up.
>
> There were also some sideline discussions on possible monitoring and
> high-availability options for the underlying services.
> Containerization was, as always, brought up but the usual "not a fit
> for this use case" answers abounded. It was further suggested that
> using infra-cloud resources for things like special TripleO tests or
> Docker registry hosting were somehow in scope, but there are other
> solutions to these needs which should not be conflated with the
> purpose of the infra-cloud effort.
>
>
> Interactive infra-cloud debugging
> -
>
> https://etherpad.openstack.org/p/ocata-infra-infra-cloud-debugging
>
> The original intent for this session was to try to gather
> leaders/representatives from the various projects that we're relying
> on in the infra-cloud deployment and step through an interactive
> session debugging the sorts of 

Re: [OpenStack-Infra] [infra]please help to add initial member to networking-zte-core andnetworking-zte-release group

[Joshua Hesketh]

I did this and replied to the os-dev list.

On Mon, Nov 21, 2016 at 7:30 PM, flyflyzhen08 
wrote:

> Hi Infra team:
>
> Please add the following member to networking-zte-core
> and networking-zte-release group.
>
> kyle liu: liu.hui58 at zte.com.cn
>
> Thanks!
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Fw: [Openstack-Infra]please help to add initial member to networking-zte-core and networking-zte-release group

[Joshua Hesketh]

Hi Kyle,

I've added you to those groups.

Cheers,
Josh

On Tue, Nov 29, 2016 at 12:30 PM, flyflyzhen08 
wrote:

> Is anyone able to handle this?
>
> Thanks.
>
> ---Original---
> *From:* "flyflyzhen08 "
> *Date:* 2016/11/21 16:30:03
> *To:* "openstack-infra";
> *Subject:* [infra]please help to add initial member to 
> networking-zte-coreandnetworking-zte-release
> group
>
> Hi Infra team:
>
> Please add the following member to networking-zte-core
> and networking-zte-release group.
>
> kyle liu: liu.hui58 at zte.com.cn
>
> Thanks!
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Group membership request

[Joshua Hesketh]

Hey Christopher,

No problems, I've added you to that group.

Cheers,
Josh

On Thu, Dec 1, 2016 at 11:24 AM, Christopher Aedo  wrote:

> Dear infra, could someone please add me to this group:
> https://review.openstack.org/#/admin/groups/1651,members
>
> This was created as a result of this patch I submitted:
> https://review.openstack.org/398533
>
> Thanks very much!
>
> -Christopher
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Help With CI/CD Setup

[Joshua Hesketh]

Hello Amit,

1. It /should/ be okay to have Jenkins+Gerrit on the one node, but I have
not tried it so I can't be certain. You would have to configure apache or
whatever you're using to point to jenkins/gerrit on separate vhosts, paths,
or ports etc, but otherwise it should be okay. You could attempt to use
containers, but again no idea how that would go.

2. You could mean two things here.
a) You are asking about managing test nodes. In this case you don't need to
install openstack, you just need a way to manage your test nodes.
nodepool[0] can help with this if you have access to a cloud somewhere.
b) You are talking about installing OpenStack to test your driver. In this
case it's a little more specific to what it is that you want to test.
You'll need to come up with a test scenario that exercises your driver with
cinder+manila etc. which might mean figuring out a way to do that. Devstack
plugins can make this easy.

3. If you're talking about 3rd party testing, here is a guide:
http://docs.openstack.org/infra/system-config/third_party.html
Further reading: http://docs.openstack.org/infra/system-config/ and
http://docs.openstack.org/infra/openstackci/

Cheers,
Josh

[0] http://docs.openstack.org/infra/nodepool/

On Tue, Nov 22, 2016 at 4:25 PM, Amit Manel  wrote:

> Hello Infra Team,
>
>
>
> I am presently  working on to setup CI/CD for openstack to test my driver
> related with cinder and manila. I am bit confused about following point,
> appreciate any help on this .
>
>
>
> 1.   Do we need an  OpenStack Node for the CI/CD and is it okay to
> have Jenkins , Gerrit on one node.
>
> 2.   If we may have to install OpenStack, should that be of Devstack
> on Ubuntu  or will  openstack installed with Packstack on RHEL 7.3 will
> work.
>
> 3.   Any  step by step documentation link will be preferable.
>
>
>
>
>
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] About setting up CI

[Joshua Hesketh]

Hey,

Yes, that blog post is likely outdated.

The official documentation is published here:
http://docs.openstack.org/infra/system-config/
It includes a tutorial on running your own CI but admits it may also be out
of date. I haven't checked in detail what parts are missing, but it's
likely closer to what you are after. Nevertheless reading through that and
the system-config and related repos would be a good place to start.

Cheers,
Josh

On Fri, Nov 18, 2016 at 4:06 PM, Wang Shilong  wrote:

> Hello folks,
>
>We are trying to setting up CI testing system for new Lustre cinder
> Drivers.
> I try to do as following URL In centos7:
>
> http://www.joinfu.com/2014/02/setting-up-an-external-
> openstack-testing-system/
> 
>
> But hit the following problem:
>
> [root@vm7-1 ~]# ./install_master.sh
> Using upstream Gerrit user: ddn_openstack
> Using Jenkins SSH key path: /root/data/jenkins_key
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Info: Loading facts
> Error: Could not find template 'openstack_project/puppet.conf.erb' at
> /root/os-ext-testing/puppet/modules/os_ext_testing/manifests/base.pp:132
> on node vm7-1
> Error: Could not find template 'openstack_project/puppet.conf.erb' at
> /root/os-ext-testing/puppet/modules/os_ext_testing/manifests/base.pp:132
> on node vm7-1
>
> I guess this Doc might be out of date, could you please give me some hints
> how
> I can setup latest CI?
>
> Thanks for your suggestion!
> Shilong
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Scheduling a Zuul meeting

[Joshua Hesketh]

Hey,

So selfishly speaking this is early for me (particularly when daylight
savings ends). Would people consider 2200 or 2300?

I suspect though this will make it hard for those in Europe so it's likely
no viable. In this case 2000 is okay.

Cheers,
Josh

On Thu, Nov 3, 2016 at 8:20 AM, Ian Wienand  wrote:

> On 11/03/2016 04:30 AM, James E. Blair wrote:
>
>> Please let me know if the proposed time (Monday, 20:00 UTC) works for
>> you, or if an alternate time would be better.
>>
>
> This should be fine for us antipodeans :) 19:00 is also OK, but starts
> getting pretty early in (our) winter
>
> -i
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [nova] Future of turbo-hipster CI

[Joshua Hesketh]

On Wed, Oct 5, 2016 at 12:39 AM, Dan Smith  wrote:

> > Having said that, I think Dan Smith came across a fairly large
> > production DB dataset recently which he was using for testing some
> > archive changes, maybe Dan will become our new Johannes, but grumpier of
> > course. :)
>
> That's quite an insult to Johannes :)
>
> While working on the db archiving thing recently I was thinking about
> how it would be great to get t-h to run this process on one of its
> large/real datasets. Then I started to wonder when was the last time I
> actually saw it comment.
>
>
So if it's missed something important please let me know and we can look
into it. On the other hand with specific cases like this (as mentioned
earlier) we can test it individually as a special case.


> I feel like these days Nova, by policy, isn't doing any database
> migrations that can really take a long time for a variety of reasons
> (i.e. expand-only schema migrations, no data migrations). That means the
> original thing t-h set out to prevent is not really much of a risk anymore.
>
> I surely think it's valuable, but I understand if the benefit does not
> outweigh the cost at this point.
>


With nova being more careful of big migrations it does seem the effort is
beginning to outweigh the benefit.


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

Re: [openstack-dev] [nova] Future of turbo-hipster CI

[Joshua Hesketh]

On Wed, Oct 5, 2016 at 12:02 AM, Dean Troyer <dtro...@gmail.com> wrote:

> On Mon, Oct 3, 2016 at 11:29 PM, Joshua Hesketh <joshua.hesk...@gmail.com>
> wrote:
>
>> The question now is whether or not to continue running. Is there still
>> value in running turbo-hipster? It uses significant resources and it feels
>> that developers have learned the lessons it was designed to teach.
>>
>
> Is there any value in running turbo-hipster as a periodic job across
> multiple releases?  One common request from operators is to be able to
> upgrade directly from, say, kilo to mitaka or newton.  I know there are
> other factors involved in that (APIs, objects, etc), the question is if
> this is a necessary/useful component of testing that upgrade path?
>

No I don't think there is value. Once a migration is in the code base it's
very difficult to change it in any non-idempotent way. Some deployments run
very close to master and fixing a past migration would mean maintaining
users with diverged databases.



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

Re: [openstack-dev] [nova] Future of turbo-hipster CI

[Joshua Hesketh]

On Tue, Oct 4, 2016 at 11:49 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com>
wrote:

> On 10/3/2016 11:29 PM, Joshua Hesketh wrote:
>
>> Howdy,
>>
>> Quick bit of background. Turbo-hipster is a 3rd party CI system that
>> runs nova's database migrations against real datasets to try and catch
>> real-world problems.
>>
>> When it was initially written the state of migrations in nova would
>> cause a lot of pain for deployers (such as very long downtimes while
>> upgrades were performed or just not working at all). Since then nova has
>> made conscious efforts to minimise this time and are generally aware
>> when implementing a necessary migration may cause large downtimes and
>> attempt to work around it where possible.
>>
>> turbo-hipster used to run against every change in nova. This was to
>> catch changes that may have affected migration performance as a side
>> effect. However for the last few months turbo-hipster has only been
>> running against changes modifying files in nova/db/*. Any changes
>> outside of there that causes pain can likely be reverted.
>>
>> As a note, turbo-hipster is currently not running due
>> to https://review.openstack.org/#/c/374307/ until I have time to update
>> the datasets used.
>>
>> The question now is whether or not to continue running. Is there still
>> value in running turbo-hipster? It uses significant resources and it
>> feels that developers have learned the lessons it was designed to teach.
>>
>> Not running it increases the risk a migration will fail or take a very
>> long time for a real user, but turbo-hipster is far from perfect anyway
>> and only tests a couple of datasets so that risk is still there.
>>
>> Are nova developers still getting value out of turbo-hipster or has it
>> achieved its goal and is it time for it to retire?
>>
>> Thanks,
>> Josh
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> I honestly forgot it existed. We have had some proposed database
> migrations come up which were a bit controversial, e.g.:
>
> https://review.openstack.org/#/c/248780/
>
>

So we if know or expect something to be problematic/controversial it's
something that can be tested manually (as it sounds you have been doing).
It could be possible to find other operators willing to assist too.



> So it would be nice to have something big to test these out while
> considering them. We used to have Johannes for manual test runs on
> migration changes but he's no longer around.
>
> So I guess I'm fine with not having t-h anymore since I didn't even notice
> the absence for the last couple of releases, but I worry a bit about not
> having a large test dataset for manual runs.
>
>
It hasn't been absent for that long. It has only been running on migrations
(ie not every change) for the last few months.



> Having said that, I think Dan Smith came across a fairly large production
> DB dataset recently which he was using for testing some archive changes,
> maybe Dan will become our new Johannes, but grumpier of course. :)
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] Future of turbo-hipster CI

[Joshua Hesketh]

Howdy,

Quick bit of background. Turbo-hipster is a 3rd party CI system that runs
nova's database migrations against real datasets to try and catch
real-world problems.

When it was initially written the state of migrations in nova would cause a
lot of pain for deployers (such as very long downtimes while upgrades were
performed or just not working at all). Since then nova has made conscious
efforts to minimise this time and are generally aware when implementing a
necessary migration may cause large downtimes and attempt to work around it
where possible.

turbo-hipster used to run against every change in nova. This was to catch
changes that may have affected migration performance as a side effect.
However for the last few months turbo-hipster has only been running against
changes modifying files in nova/db/*. Any changes outside of there that
causes pain can likely be reverted.

As a note, turbo-hipster is currently not running due to
https://review.openstack.org/#/c/374307/ until I have time to update the
datasets used.

The question now is whether or not to continue running. Is there still
value in running turbo-hipster? It uses significant resources and it feels
that developers have learned the lessons it was designed to teach.

Not running it increases the risk a migration will fail or take a very long
time for a real user, but turbo-hipster is far from perfect anyway and only
tests a couple of datasets so that risk is still there.

Are nova developers still getting value out of turbo-hipster or has it
achieved its goal and is it time for it to retire?

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

Re: [openstack-dev] [puppet] [infra] Request for old branches removal

[Joshua Hesketh]

Hey Emilien,

Sorry I missed those, I didn't take my script back far enough. I've tidied
up as far back as diablo :-).

I could only see the fix_image_version branch on puppet-tempest, but I've
tidied that up anyway.

Let me know if I'm missed anything else.

Cheers,
Josh

On Tue, Sep 27, 2016 at 1:29 PM, Emilien Macchi <emil...@redhat.com> wrote:

> Hi Josh,
>
> Thanks a lot for your help !
> I've noticed some of them still have stale branches, example:
> https://github.com/openstack/puppet-keystone/branches with essex and
> folsom
> or https://github.com/openstack/puppet-nova/branches with diablo!
> (yeah very old :-))
> also puppet-cinder, puppet-glance, puppet-horizon, puppet-neutron,
> puppet-swift,
> puppet-tempest (remove fix_image_version branch). So at the end we
> only keep stable/liberty and stable/mitaka.
>
> Could we also get rid of them?
>
> Thanks again,
>
> On Tue, Sep 27, 2016 at 8:05 AM, Joshua Hesketh
> <joshua.hesk...@gmail.com> wrote:
> > Hi Emilien,
> >
> > I've removed all of the old branches on the specified repos and created
> tags
> > in their place. Let me know if there are any problems.
> >
> > Cheers,
> > Josh
> >
> > On Mon, Sep 26, 2016 at 3:51 PM, Emilien Macchi <emil...@redhat.com>
> wrote:
> >>
> >> Greatings Infra,
> >>
> >> This is an official request to remove old branches for Puppet OpenStack
> >> modules:
> >>
> >> puppet-ceilometer
> >> puppet-cinder
> >> puppet-glance
> >> puppet-heat
> >> puppet-horizon
> >> puppet-keystone
> >> puppet-neutron
> >> puppet-nova
> >> puppet-openstack_extras
> >> puppet-openstacklib
> >> puppet-swift
> >> puppet-tempest
> >>
> >> Please remove all branches before Kilo (Kilo was already removed).
> >>
> >> Thanks,
> >> --
> >> Emilien Macchi
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [puppet] [infra] Request for old branches removal

[Joshua Hesketh]

Hi Emilien,

I've removed all of the old branches on the specified repos and created
tags in their place. Let me know if there are any problems.

Cheers,
Josh

On Mon, Sep 26, 2016 at 3:51 PM, Emilien Macchi  wrote:

> Greatings Infra,
>
> This is an official request to remove old branches for Puppet OpenStack
> modules:
>
> puppet-ceilometer
> puppet-cinder
> puppet-glance
> puppet-heat
> puppet-horizon
> puppet-keystone
> puppet-neutron
> puppet-nova
> puppet-openstack_extras
> puppet-openstacklib
> puppet-swift
> puppet-tempest
>
> Please remove all branches before Kilo (Kilo was already removed).
>
> Thanks,
> --
> Emilien Macchi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-infra][all] Status update of the InfraCloud

[Joshua Hesketh]

This is awesome stuff. Thanks to all involved and to HPE for the hardware
:-)

On Thu, Sep 1, 2016 at 9:12 PM, Ricardo Carrillo Cruz <
ricardo.carrillo.c...@gmail.com> wrote:

> Hi there
>
> We would like to write an update about the status of the InfraCloud ( if
> you never heard of it, it's essentially a bunch of hardware donated by HPE
> to the project to run an OpenStack cloud for CI testing. More info at
> http://docs.openstack.org/infra/system-config/infra-cloud.html ).
>
> We decided in the last infra mid-cycle at Fort Collins to split logically
> the machines given (roughly 132 servers, with a mix of SL390s, SL230s and
> SE1170s) in two different clouds: vanilla and chocolate, in order to have
> each cloud running the current and previous OpenStack version.
>
> The vanilla region, which is comprised of 48 SL390s nodes, has been
> provisioned with Mitaka and this is how it looks like:
>
> 1 x Bifrost machine to provision the clouds control plane
> 1 x Controller
> 42 x Computes
> 4 x nodes currently being investigated due to faulty HW issues
>
> This vanilla cloud has already been enabled in Nodepool:
>
> https://review.openstack.org/#/c/363942/
>
> So far, it's running quite well per the Logstash job logs collected from
> it.
>
> Next step is to bump the max-servers to 50 servers (
> https://review.openstack.org/#/c/364101/ ) to stress it a little bit more
> to eventually unlock it to its full potential.
> The SL390s report 24 cores, so this region can serve as quite a big
> provider for CI runs.
>
> We are looking forward to hear from you any feedback or problems you may
> encounter.
> We also plan to have a track on the infra mid-cycle in two weeks to plan
> the rollout of the chocolate region and overall improvements.
>
> Regards
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
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-Infra] Request to add group member into the Openstack projects

[Joshua Hesketh]

Hello Vadim,

I've added the fuel-qa-core group into the new fuel-qa-mu-core. From there
other cores/the PTL can add yourself to the group.

Cheers,
Josh

On Thu, Sep 1, 2016 at 4:02 PM, Vadim Rovachev 
wrote:

> Hi openstack-infra team,
>
> Kindly please add vrovac...@mirantis.com and all group fuel-qa-core to
> the following Gerrit ACL group:
>
> https://review.openstack.org/#/admin/groups/1549,members
>
> (ref. https://review.openstack.org/#/c/359704/)
>
> Thanks in advance.
>
> --
> Best regards
>
> Rovachev Vadim,
> QA Engineer
> MOS Maintenance QA Team Lead
> Mirantis Inc
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Development environments for infra's puppet modules

[Joshua Hesketh]

(sorry, mail client failure)

On Tue, Aug 30, 2016 at 4:59 PM, Joshua Hesketh <joshua.hesk...@gmail.com>
wrote:

>
>
> On Fri, Aug 26, 2016 at 1:31 AM, Simon McCartney <si...@mccartney.ie>
> wrote:
>>
>>
>> 
>>
> However, I'm not sure Vagrant provides a good solution for testing puppet
>> modules in isolation (I think it's great for the
>> system-config/project-config scenario, where you want to see how applying
>> the full set of required puppet modules on to an empty VM provides a
>> working system), it's harder to test standing up zuul without also setting
>> up a few other components, so puppet-zuul (for example) may not take
>> advantage of Vagrant directly, but may benefit from beaker[1] or
>> test-kitchen[2] work (I think that conversation has happened before but I
>> wasn't directly involved at the time)
>>
>>
>
 So I think this is the interesting part for vagrant. The infra
bootstrapping will install other components (as mentioned) which is useful
when you want to develop on something intended for OpenStack's infra.
However if we want the puppet modules to be more generic and used outside
of infra's use case, is this sufficient or should we look towards something
more generic (such as vagrant)?

I'm not really sure how this would look as modules may have complicated
inter-dependencies or assumptions about the environment/machine. How do
other puppet developers do their modules upstream?

Cheers,
Josh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Development environments for infra's puppet modules

[Joshua Hesketh]

On Fri, Aug 26, 2016 at 1:31 AM, Simon McCartney  wrote:
>
>
> 
>
However, I'm not sure Vagrant provides a good solution for testing puppet
> modules in isolation (I think it's great for the
> system-config/project-config scenario, where you want to see how applying
> the full set of required puppet modules on to an empty VM provides a
> working system), it's harder to test standing up zuul without also setting
> up a few other components, so puppet-zuul (for example) may not take
> advantage of Vagrant directly, but may benefit from beaker[1] or
> test-kitchen[2] work (I think that conversation has happened before but I
> wasn't directly involved at the time)
>
> [1] https://github.com/puppetlabs/beaker
> [2] https://github.com/neillturner/kitchen-puppet & http://kitchen.ci/
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Development environments for infra's puppet modules

[Joshua Hesketh]

Hey all,

We should look for a way to make developing, debugging and testing our
puppet modules locally easier and more consistent.
Short of bootstrapping an entire clone of openstack-infra, how do
developers currently set up an environment to investigate how a puppet
module behaves? This brings me to my first question:
1) Do we want to find/provide a way to set up a consistent development
environment?
Vagrant could be a useful way of providing a consistent development
environment for those working on infra's puppet modules. This comes up in
light of https://review.openstack.org/#/c/355273 which was split out from a
larger change due to debate over any vagrant precedent. This change was in
turn based upon this documented example of simulating OpenStack Infra
environments for testing:
https://krotscheck.net/2016/06/01/how-to-simulate-an-openstack-infra-slave.html
Currently the only module (that a quick grep found for me) providing a
vagrant file is puppet-storyboard.
2) Is Vagrant a good fit for this? Otherwise should we consider an
ansible-playbook to bootstrap an environment?
3) Where do we store and document such procedures (for example, in the
puppet repos themselves, as a guide somewhere, links to pastebin scripts
etc)
There's probably further discussions here but I don't have enough knowledge
in this area to comment further. The aim though should be to make it easy
to bootstrap a server with the module you're developing on so you can
easily verify and debug your changes.
Thoughts?
Cheers,Josh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Not able to login for https://review.openstack.org

[Joshua Hesketh]

Hi Prabhu,

I've re-activated your account for you. Let me know if you have any
troubles.

Cheers,
Josh

On Tue, Jul 19, 2016 at 11:27 PM, Murthy, Prabhu  wrote:

> Hi ,
>
>
>
> I am not able to login for https://review.openstack.org . Showing error
> [1].
>
> I came to know that my account is deactivated due to personal account used
> for third party CI [2].
>
> I didn’t know that , Sorry for that.
>
>
>
> I agree to use my personal gerrit account for personal committing and
> reviewing only.
>
> Please re-enable it.
>
>
>
> Name : Prabhu Murthy
>
> Company  : prabhu...@hpe.com
>
>
>
> Thanks,
>
> Prabhu.M
>
>
>
>
>
> [1] Not Found
>
> The page you requested was not found, or you do not have permission to
> view this page.
>
>
>
> [2]
> http://comments.gmane.org/gmane.comp.cloud.openstack.infrastructure/3810
>
>
>
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Gerrit group adds for user-committee

[Joshua Hesketh]

I went to do this but it looks like somebody beat me to it. So just FYI
these people are now part of the appropriate groups.

Cheers,
Josh

On Wed, Jul 20, 2016 at 5:51 PM, Tom Fifield  wrote:

> Thanks for the rapid reply,
>
> I submitted the patches, on behalf of the user committee:
>
> https://review.openstack.org/#/c/330403/
> https://review.openstack.org/#/c/330510/
>
> As I'm not on the user committee, I probably shouldn't be on the ACLs,
> hence the request :)
>
>
> Regards,
>
>
> Tom
>
>
> On 20/07/16 14:38, Yolanda Robla Mota wrote:
>
>> Hi Tom. The way it normally works is that the person that created the
>> project, is added as group owner. Then this group owner can add other
>> people.
>> Please can you share the change that created these groups, so we can add
>> the owner there?
>>
>> Best
>> Yolanda
>>
>> - Original Message -
>> From: "Tom Fifield" 
>> To: "openstack-infra" 
>> Sent: Wednesday, July 20, 2016 5:10:08 AM
>> Subject: [OpenStack-Infra] Gerrit group adds for user-committee
>>
>> Hello Infra!
>>
>>
>> Two new gerrit groups need the same list of people added to them:
>>
>> https://review.openstack.org/#/admin/groups/1454,members
>>
>> https://review.openstack.org/#/admin/groups/1453,members
>>
>> They are:
>>
>> shilla.sa...@gmail.com
>> emag...@gmail.com
>> j...@csail.mit.edu
>>
>>
>> Can we make it happen? :)
>>
>>
>>
>>
>> (NB: You can verify these names at
>> https://www.openstack.org/foundation/user-committee/ if needed)
>>
>>
>>
>> Regards,
>>
>>
>> Tom
>>
>>
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [Openstack] [openstack-dev] Naming polls - and some issues

[Joshua Hesketh]

Hello Ian,

My understanding of it is that you need to receive a new link. Monty is
slowly sending those out in batches and he hasn't finished. I expect he'll
email the list once he has finished to confirm so I'd suggest holding off
until then to check.

Cheers,
Josh

On Mon, Jul 18, 2016 at 1:58 PM, Ian Y. Choi  wrote:

> Hello,
>
> Today I tried to vote the naming polls for P and Q releases, however,
> unfortunately I am experiencing some issues.
>
> I used the link for P release in the e-mail titled "Poll: OpenStack P
> Release Naming" on July 11 22:42 UTC.
> When I click my URL, the poll site says:
> "Error / Your voter key is invalid. You should have received a correct URL
> by email."
> , and the poll is not ended yet. However I have not received any other
> correct URLs by e-mail.
>
> For Q release, I followed the link in the e-mail: "Poll: OpenStack Q
> Release Naming" on July 12 02:15 UTC.
> When I go to my vote URL, the site says "Poll already ended".
> But strangely, when I see the poll result (
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_06e681ae091ad657 ),
> all the poll candidates are 'tied'.
>
> So my questions are:
>
> 1) Does anybody have troubles on voting P and Q release naming like me?
>
> 2) Has the Q release naming poll already finished?
> I think it can be finished although the original due date is July 20th.
> However It is so strange that the result I am seeing now is "tied".
>
>
> With many thanks,
>
> /Ian
>
>
> Monty Taylor wrote on 7/18/2016 10:03 AM:
>
>> Any time is a good time.
>>
>> On 07/17/2016 04:54 PM, Michael Still wrote:
>>
>>> So, is now a good time to mention that "Quamby" is the name of a local
>>> prison?
>>>
>>> Michael
>>>
>>>
>>>
>>> On Fri, Jul 15, 2016 at 7:50 PM, Eoghan Glynn >> > wrote:
>>>
>>>
>>>
>>>  > (top posting on purpose)
>>>  >
>>>  > I have re-started the Q poll and am slowly adding all of you fine
>>> folks
>>>  > to it. Let's keep our fingers crossed that it works this time.
>>>  >
>>>  > I also removed Quay. Somehow my brain didn't process the "it
>>> would be
>>>  > like naming the S release "Street"" when reading the original
>>> names.
>>>  > Based on the naming critera, "Circular Quay" would be a great
>>> option for
>>>  > "Circular" - but sadly we already named the C release Cactus. It's
>>>  > possible this choice will make someone unhappy, and if it does,
>>> I'm
>>>  > certainly sorry. On the other hand, there are _so_ many awesome
>>> names
>>>  > possible in this list, I don't think we'll miss it.
>>>
>>>  Excellent, thanks Monty for fixing this ... agreed that the
>>> remaining
>>>  Q* choices are more than enough.
>>>
>>>  Cheers,
>>>  Eoghan
>>>
>>>  > I'll fire out new emails for P once Q is up and going.
>>>  >
>>>  > On 07/15/2016 11:02 AM, Jamie Lennox wrote:
>>>  > > Partially because its name is Circular Quay, so it would be like
>>>  calling
>>>  > > the S release Street for  Street.
>>>  > >
>>>  > > Having said that there are not that many of them and Sydney
>>>  people know
>>>  > > what you mean when you are going to the Quay.
>>>  > >
>>>  > >
>>>  > > On 14 July 2016 at 21:35, Neil Jerram >>  
>>>  > > >> wrote:
>>>  > >
>>>  > > Not sure what the problem would be with 'Quay' or 'Street' -
>>>  they
>>>  > > both sound like good options to me.
>>>  > >
>>>  > >
>>>  > > On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn
>>>  
>>>  > > >>
>>> wrote:
>>>  > >
>>>  > >
>>>  > >
>>>  > > > >> Hey all!
>>>  > > > >>
>>>  > > > >> The poll emails for the P and Q naming have started
>>>  to go
>>>  > > out - and
>>>  > > > >> we're experiencing some difficulties. Not sure at
>>> the
>>>  > > moment what's
>>>  > > > >> going on ... but we'll keep working on the issues
>>>  and get
>>>  > > ballots to
>>>  > > > >> everyone as soon as we can.
>>>  > > > >
>>>  > > > > You'll need to re-send at least some emails,
>>> because the
>>>  > > link I received
>>>  > > > > is wrong - the site just reports
>>>  > > > >
>>>  > > > >   "Your voter key is invalid. You should have
>>> received a
>>>  > > correct URL by
>>>  > > > >   email."
>>>  > > >
>>>  > > > Yup. That would be a key symptom of the problems. One
>>>  of the
>>>  > > others is
>>>  > > > that I just uploaded 3000 of the emails to the Q poll
>>>  and it
>>>  > >

Re: [openstack-dev] [Openstack] Naming polls - and some issues

[Joshua Hesketh]

Hello Ian,

My understanding of it is that you need to receive a new link. Monty is
slowly sending those out in batches and he hasn't finished. I expect he'll
email the list once he has finished to confirm so I'd suggest holding off
until then to check.

Cheers,
Josh

On Mon, Jul 18, 2016 at 1:58 PM, Ian Y. Choi  wrote:

> Hello,
>
> Today I tried to vote the naming polls for P and Q releases, however,
> unfortunately I am experiencing some issues.
>
> I used the link for P release in the e-mail titled "Poll: OpenStack P
> Release Naming" on July 11 22:42 UTC.
> When I click my URL, the poll site says:
> "Error / Your voter key is invalid. You should have received a correct URL
> by email."
> , and the poll is not ended yet. However I have not received any other
> correct URLs by e-mail.
>
> For Q release, I followed the link in the e-mail: "Poll: OpenStack Q
> Release Naming" on July 12 02:15 UTC.
> When I go to my vote URL, the site says "Poll already ended".
> But strangely, when I see the poll result (
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_06e681ae091ad657 ),
> all the poll candidates are 'tied'.
>
> So my questions are:
>
> 1) Does anybody have troubles on voting P and Q release naming like me?
>
> 2) Has the Q release naming poll already finished?
> I think it can be finished although the original due date is July 20th.
> However It is so strange that the result I am seeing now is "tied".
>
>
> With many thanks,
>
> /Ian
>
>
> Monty Taylor wrote on 7/18/2016 10:03 AM:
>
>> Any time is a good time.
>>
>> On 07/17/2016 04:54 PM, Michael Still wrote:
>>
>>> So, is now a good time to mention that "Quamby" is the name of a local
>>> prison?
>>>
>>> Michael
>>>
>>>
>>>
>>> On Fri, Jul 15, 2016 at 7:50 PM, Eoghan Glynn >> > wrote:
>>>
>>>
>>>
>>>  > (top posting on purpose)
>>>  >
>>>  > I have re-started the Q poll and am slowly adding all of you fine
>>> folks
>>>  > to it. Let's keep our fingers crossed that it works this time.
>>>  >
>>>  > I also removed Quay. Somehow my brain didn't process the "it
>>> would be
>>>  > like naming the S release "Street"" when reading the original
>>> names.
>>>  > Based on the naming critera, "Circular Quay" would be a great
>>> option for
>>>  > "Circular" - but sadly we already named the C release Cactus. It's
>>>  > possible this choice will make someone unhappy, and if it does,
>>> I'm
>>>  > certainly sorry. On the other hand, there are _so_ many awesome
>>> names
>>>  > possible in this list, I don't think we'll miss it.
>>>
>>>  Excellent, thanks Monty for fixing this ... agreed that the
>>> remaining
>>>  Q* choices are more than enough.
>>>
>>>  Cheers,
>>>  Eoghan
>>>
>>>  > I'll fire out new emails for P once Q is up and going.
>>>  >
>>>  > On 07/15/2016 11:02 AM, Jamie Lennox wrote:
>>>  > > Partially because its name is Circular Quay, so it would be like
>>>  calling
>>>  > > the S release Street for  Street.
>>>  > >
>>>  > > Having said that there are not that many of them and Sydney
>>>  people know
>>>  > > what you mean when you are going to the Quay.
>>>  > >
>>>  > >
>>>  > > On 14 July 2016 at 21:35, Neil Jerram >>  
>>>  > > >> wrote:
>>>  > >
>>>  > > Not sure what the problem would be with 'Quay' or 'Street' -
>>>  they
>>>  > > both sound like good options to me.
>>>  > >
>>>  > >
>>>  > > On Thu, Jul 14, 2016 at 11:29 AM Eoghan Glynn
>>>  
>>>  > > >>
>>> wrote:
>>>  > >
>>>  > >
>>>  > >
>>>  > > > >> Hey all!
>>>  > > > >>
>>>  > > > >> The poll emails for the P and Q naming have started
>>>  to go
>>>  > > out - and
>>>  > > > >> we're experiencing some difficulties. Not sure at
>>> the
>>>  > > moment what's
>>>  > > > >> going on ... but we'll keep working on the issues
>>>  and get
>>>  > > ballots to
>>>  > > > >> everyone as soon as we can.
>>>  > > > >
>>>  > > > > You'll need to re-send at least some emails,
>>> because the
>>>  > > link I received
>>>  > > > > is wrong - the site just reports
>>>  > > > >
>>>  > > > >   "Your voter key is invalid. You should have
>>> received a
>>>  > > correct URL by
>>>  > > > >   email."
>>>  > > >
>>>  > > > Yup. That would be a key symptom of the problems. One
>>>  of the
>>>  > > others is
>>>  > > > that I just uploaded 3000 of the emails to the Q poll
>>>  and it
>>>  > >

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

Hey Jesse,

Sorry for the delay. I've gone ahead and removed icehouse, juno and kilo
branches creating tags in their places.

Cheers,
Josh

On Wed, Jul 6, 2016 at 3:27 AM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> From: Joshua Hesketh <joshua.hesk...@gmail.com>
>
>
> I assume you want to wait for the tag to merge before removing the branch?
>
> The only tag job I can see for openstack-ansible* projects is the
> releasenotes one. This should be harmless as it just generates the notes
> for mitaka and liberty branches. I'm going to hold off until the final tag
> has merged anyway if you want to confirm this first.
>
>
> Thanks Josh – The final Kilo tag has merged so we’re good to go. We’re
> happy to also go straight ahead with the eol tags for the icehouse and juno
> branches too.
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> 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] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

On Fri, Jul 1, 2016 at 9:26 PM, Jesse Pretorius <
jesse.pretor...@rackspace.co.uk> wrote:

> Hi all,
>
> Now that OpenStack-Ansible has the final Swift kilo-eol tag implemented
> we’ve requested a final tag [1]. Once that merges we are ready to have our
> kilo-eol tag implemented and the ‘kilo’ branch removed.
>

I assume you want to wait for the tag to merge before removing the branch?


>
> Just to make life interesting, we still have leftover ‘juno’ and
> ‘icehouse’ branches and would like to implement eol tags for them too. I
> think we have the appropriate skips in place for the juno branch so there
> should be no funky post-tag jobs kicking off for them, but the icehouse
> branch may end up with some unknown jobs kicking off. If you can help
> identify the changes we need to get implemented into project-config then we
> can be rid of the old cruft.
>

The only tag job I can see for openstack-ansible* projects is the
releasenotes one. This should be harmless as it just generates the notes
for mitaka and liberty branches. I'm going to hold off until the final tag
has merged anyway if you want to confirm this first.

Cheers,
Josh



> Thanks,
>
> Jesse
>
> --
> Rackspace Limited is a company registered in England & Wales (company
> registered number 03897010) whose registered office is at 5 Millington
> Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy
> can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail
> message may contain confidential or privileged information intended for the
> recipient. Any dissemination, distribution or copying of the enclosed
> material is prohibited. If you receive this transmission in error, please
> notify us immediately by e-mail at ab...@rackspace.com and delete the
> original message. Your cooperation is appreciated.
>
> __
> 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] [openstack-infra] [vitrage] branch marking policy

[Joshua Hesketh]

Hey Elisha,

Have you looked at http://docs.openstack.org/infra/manual/drivers.html ?

Cheers,
Josh

On Thu, Jun 30, 2016 at 9:16 PM, Rosensweig, Elisha (Nokia - IL) <
elisha.rosensw...@nokia.com> wrote:

> Hi,
>
> We've prepared a (local) branch with Vitrage that is *Liberty-compatible*,
> and would like to mark (tag?) the branch.
>
> What is the standard way to do this?
>
> Thanks,
>
> Elisha Rosensweig, Ph.D.
> R Director
> CloudBand, Nokia
> T: +972 9793 3159
>
>
> __
> 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-Infra] request to delete obsolete branches in networking-nec

[Joshua Hesketh]

Hey Akihiro,

No trouble. I've deleted the stable branches and added tags for them. I've
also removed the split-backend-logic branch.

Cheers,
Josh

On Mon, Jun 27, 2016 at 3:26 PM, Akihiro Motoki  wrote:

> Hi infra-team,
>
> Could you drop the following branches of openstack/networking-nec?
>
> - stable/juno
> - stable/icehouse
> - split-backend-logic
>
> For the above stable branches, *-eol tags have been added.
> split-backend-logic branch was completely unnecessary.
> It was imported by mistake in the initial setup.
>
> Thanks,
> Akihiro
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

On Sat, Jun 25, 2016 at 10:44 AM, Robert Collins 
wrote:

> Removing the pbr branch should be fine - it was an exceptional thing
> to have that branch in the first place - pbr is consumed by releases
> only, and due to its place in the dependency graph is very very very
> hard to pin or cap.
>

Based off this I have removed the stable/kilo branch from pbr.

Cheers,
Josh



>
> -Rob
>
> On 25 June 2016 at 12:37, Tony Breeds  wrote:
> > On Fri, Jun 24, 2016 at 04:36:03PM -0700, Sumit Naiksatam wrote:
> >> Hi Tony, Thanks for your response, and no worries! We can live with
> >> the kilo-eol tag, no need to try to delete it. And as you suggested,
> >> we can add a second eol tag when we actually EoL this branch.
> >>
> >> As regards reviving the deleted branches, would a bug have to be
> >> created somewhere to track this, or is this already on the radar of
> >> the infra team (thanks in advance if it already is)?
> >
> > No bug needed.  I'll work with the infra team to re-create the branch.
> Just as
> > a level set it wont be this weekend.
> >
> > Yours Tony.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

On Sat, Jun 25, 2016 at 4:20 AM, Sumit Naiksatam <sumitnaiksa...@gmail.com>
wrote:

> Hi, I had earlier requested in this thread that the stable/kilo branch
> for the following repos be not deleted:
>
> > openstack/group-based-policy
> > openstack/group-based-policy-automation
> > openstack/group-based-policy-ui
> > openstack/python-group-based-policy-client
>


Hello,

Very sorry that these were removed. I should have checked this thread
closer.

I have recreated stable/kilo branches for each of those projects.

As Tony mentioned, due to the nature of the tags removing those is slightly
more complicated. We can remove them from the git farm upstream but those
who have already fetched the tags will need to manually remove them
locally. And if you do a subsequent (identical in name) kilo-eol tag only
those who had removed the incorrect version locally will fetch down the new
copy. In other words it'll be very easy for what you have tagged as
kilo-eol upstream to become different to what people may have in their
local copy.

As such, if you ever retire the branch it's probably important to name your
kilo-eol tag differently. If you call it something else there's no harm in
removing the kilo-eol upstream to keep it tidy if you so wish (let me know
if you need help with that).

Cheers,
Josh



>
> and the request was ack’ed by Tony (also in this thread). However, I
> just noticed that these branches have been deleted. Can this deletion
> please be reversed?
>
> Thanks,
> ~Sumit.
>
> On Fri, Jun 24, 2016 at 10:32 AM, Andreas Jaeger <a...@suse.com> wrote:
> > On 06/24/2016 02:09 PM, Joshua Hesketh wrote:
> >>
> >> Hi all,
> >>
> >> I have completed removing stable/kilo branches from the projects listed
> >> [0]*. There are now 'kilo-eol' tags in place at the sha's where the
> >> branches were.
> >>
> >> *There are a couple of exceptions. oslo-incubator was listed but is an
> >> unmaintained project so no further action was required. Tony and I have
> >> also decided to hold off
> >> on openstack-dev/devstack, openstack-dev/grenade, openstack-dev/pbr
> >> and openstack/requirements until we are confident removing the
> >> stable/kilo branch will have no negative effects on the projects who
> >> opt-ed out of being EOL'd.
> >>
> >> In this process we noted a couple of repositories still have branches
> >> from Juno and even earlier. I haven't put together a comprehensive list
> >> of old branches, but rather if your project has an outdated branch that
> >> you would like removed and/or tagged as end-of-life, please let me know.
> >>
> >> For those interested in the script I used or other infra cores looking
> >> to perform this next time, it is up for review in the release-tools
> >> repo: https://review.openstack.org/333875
> >
> >
> > Thanks, Joshua.
> >
> > We're now removing the special handling of kilo branches from
> project-config
> > as well - it looks odd for some projects where kilo is removed from
> > conditions and we still have icehouse or juno. Followup changes are
> welcome.
> >
> > https://review.openstack.org/334008
> > https://review.openstack.org/333910
> > https://review.openstack.org/333977
> >
> > Andreas
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

On Sat, Jun 25, 2016 at 4:20 AM, Sumit Naiksatam <sumitnaiksa...@gmail.com>
wrote:

> Hi, I had earlier requested in this thread that the stable/kilo branch
> for the following repos be not deleted:
>
> > openstack/group-based-policy
> > openstack/group-based-policy-automation
> > openstack/group-based-policy-ui
> > openstack/python-group-based-policy-client
>
> and the request was ack’ed by Tony (also in this thread). However, I
> just noticed that these branches have been deleted. Can this deletion
> please be reversed?
>
> Thanks,
> ~Sumit.
>
> On Fri, Jun 24, 2016 at 10:32 AM, Andreas Jaeger <a...@suse.com> wrote:
> > On 06/24/2016 02:09 PM, Joshua Hesketh wrote:
> >>
> >> Hi all,
> >>
> >> I have completed removing stable/kilo branches from the projects listed
> >> [0]*. There are now 'kilo-eol' tags in place at the sha's where the
> >> branches were.
> >>
> >> *There are a couple of exceptions. oslo-incubator was listed but is an
> >> unmaintained project so no further action was required. Tony and I have
> >> also decided to hold off
> >> on openstack-dev/devstack, openstack-dev/grenade, openstack-dev/pbr
> >> and openstack/requirements until we are confident removing the
> >> stable/kilo branch will have no negative effects on the projects who
> >> opt-ed out of being EOL'd.
> >>
> >> In this process we noted a couple of repositories still have branches
> >> from Juno and even earlier. I haven't put together a comprehensive list
> >> of old branches, but rather if your project has an outdated branch that
> >> you would like removed and/or tagged as end-of-life, please let me know.
> >>
> >> For those interested in the script I used or other infra cores looking
> >> to perform this next time, it is up for review in the release-tools
> >> repo: https://review.openstack.org/333875
> >
> >
> > Thanks, Joshua.
> >
> > We're now removing the special handling of kilo branches from
> project-config
> > as well - it looks odd for some projects where kilo is removed from
> > conditions and we still have icehouse or juno. Followup changes are
> welcome.
> >
> > https://review.openstack.org/334008
> > https://review.openstack.org/333910
> > https://review.openstack.org/333977
> >
> > Andreas
> > --
> >  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
> >   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> >GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> >HRB 21284 (AG Nürnberg)
> > GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

[Joshua Hesketh]

Hi all,

I have completed removing stable/kilo branches from the projects listed
[0]*. There are now 'kilo-eol' tags in place at the sha's where the
branches were.

*There are a couple of exceptions. oslo-incubator was listed but is an
unmaintained project so no further action was required. Tony and I have
also decided to hold off
on openstack-dev/devstack, openstack-dev/grenade, openstack-dev/pbr
and openstack/requirements until we are confident removing the stable/kilo
branch will have no negative effects on the projects who opt-ed out of
being EOL'd.

In this process we noted a couple of repositories still have branches from
Juno and even earlier. I haven't put together a comprehensive list of old
branches, but rather if your project has an outdated branch that you would
like removed and/or tagged as end-of-life, please let me know.

For those interested in the script I used or other infra cores looking to
perform this next time, it is up for review in the release-tools repo:
https://review.openstack.org/333875

Cheers,
Josh

[0] https://gist.github.com/tbreeds/7de812a5d363fab4bd425beae5084c87


On Sat, Jun 11, 2016 at 12:41 AM, Boden Russell  wrote:

> On 6/2/16 4:31 AM, Tony Breeds wrote:
> > Any projects that will be EOL'd will need all open reviews abandoned
> before it
> > can be processed.
>
> openstack/vmware-nsx kilo patches have been abandoned in preparation for
> the EOL.
>
> Thanks
>
> __
> 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-Infra] Infra priorities and spec cleanup

[Joshua Hesketh]

On Wed, Jun 22, 2016 at 6:33 PM, Thierry Carrez 
wrote:

> Jeremy Stanley wrote:
>
>> On 2016-06-21 17:34:07 + (+), Jeremy Stanley wrote:
>>
>>> On 2016-06-21 18:16:49 +0200 (+0200), Thierry Carrez wrote:
>>>
 It hurts a lot when it's down because of so many services being served
 from
 it. We could also separate the published websites (status.o.o,
 governance.o.o, security.o.o, releases.o.o...) which require limited
 resources and grow slowly, from the more resource-hungry storage sites
 (logs.o.o, tarballs.o.o...).

>>>
>>> Agreed, that's actually a pretty trivial change, comparatively
>>> speaking.
>>>
>>
>> Oh, though it bears mention that the most recent extended outage
>> (and by far longest we've experienced in a while) would have been
>> just as bad either way. It had nothing to do with recovering
>> attached volumes/filesystems, but rather was a host outage at the
>> provider entirely outside our sphere of control. That sort of issue
>> can potentially happen with any of our servers/services no matter
>> how much we split them up.
>>
>
> I don't think it would have been just as bad... Even in the unlucky case
> where the VMs end up on the same machine and are all affected, IIUC
> rebuilding some of them would have been much faster if they were split up
> (less data to rsync) ?



I believe only the VM was rsync'd to a new server and the cinder volumes
reattached. What did take a while though was the fsck that ran after it
rebooted. This would have been faster for some services if they were on a
separate VM with smaller disks.

Another gain from separating the services is the surface area affected
should a node go down is smaller. If we're lucky just one service would go
down at a time (for example job logs, but tarballs stays up).

Cheers,
Josh



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

Re: [OpenStack-Infra] Infra priorities and spec cleanup

[Joshua Hesketh]

Good update, thanks fungi.

Just a thought, given the pain we felt yesterday when static.o.o was down,
we should consider if a log solution needs to be a priority. Using afs (or
swift) could allow us to scale static.o.o horizontally.

On Tue, Jun 21, 2016 at 11:22 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2016-06-08 23:08:16 +1000 (+1000), Joshua Hesketh wrote:
> > On Mon, Jun 6, 2016 at 9:21 AM, Jeremy Stanley <fu...@yuggoth.org>
> wrote:
> > [...]
> > > Store Build Logs in Swift
> > [...]
> > > We should remove the original spec from our priority list (since
> > > that's basically already ceased to be an actual priority), and
> > > probably supercede it with the AFS proposal.
> [...]
> > Additionally the urgency of this spec seems to have been reduced (due to
> > limiting the retention on logs). We should perhaps reconsider if it's a
> > priority spec or not after we've decided on a path forward.
>
> That makes sense, though I think we can agree the original spec (and
> accompanying implementation) has ceased to be treated as a priority
> so it's a bit disingenuous to leave it on our priority list.
>
> Anyway, I've pushed a cleanup/update change at
> https://review.openstack.org/331903 which:
>
>   * removes logs-in-swift
>   * replaces maniphest with task-tracker
>   * adds nodepool-zookeeper-workers due to its coupling with zuulv3
>   * updates the Gerrit query string/URL accordingly
>
> I'll put it on the meeting agenda now for formal council vote this
> week. If approved, this leaves us at 6 priority specs, so if we
> consider that we were pretty well saturated at 8 last cycle, we can
> also discuss adding a couple more we expect to be spending
> significant time on over the remainder of this cycle or whether
> sticking with those 6 is perhaps better for focusing our efforts?
> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>

On Tue, Jun 21, 2016 at 11:22 AM, Jeremy Stanley <fu...@yuggoth.org> wrote:

> On 2016-06-08 23:08:16 +1000 (+1000), Joshua Hesketh wrote:
> > On Mon, Jun 6, 2016 at 9:21 AM, Jeremy Stanley <fu...@yuggoth.org>
> wrote:
> > [...]
> > > Store Build Logs in Swift
> > [...]
> > > We should remove the original spec from our priority list (since
> > > that's basically already ceased to be an actual priority), and
> > > probably supercede it with the AFS proposal.
> [...]
> > Additionally the urgency of this spec seems to have been reduced (due to
> > limiting the retention on logs). We should perhaps reconsider if it's a
> > priority spec or not after we've decided on a path forward.
>
> That makes sense, though I think we can agree the original spec (and
> accompanying implementation) has ceased to be treated as a priority
> so it's a bit disingenuous to leave it on our priority list.
>
> Anyway, I've pushed a cleanup/update change at
> https://review.openstack.org/331903 which:
>
>   * removes logs-in-swift
>   * replaces maniphest with task-tracker
>   * adds nodepool-zookeeper-workers due to its coupling with zuulv3
>   * updates the Gerrit query string/URL accordingly
>
> I'll put it on the meeting agenda now for formal council vote this
> week. If approved, this leaves us at 6 priority specs, so if we
> consider that we were pretty well saturated at 8 last cycle, we can
> also discuss adding a couple more we expect to be spending
> significant time on over the remainder of this cycle or whether
> sticking with those 6 is perhaps better for focusing our efforts?
> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Upcoming changes now that Jenkins has retired

[Joshua Hesketh]

Hey Steve,

Yes. The user "jenkins" in gerrit has actually been controlled by zuul for
some years now. This rename is basically to reflect that and includes an
1st party CI comments (so check and gate).

Cheers,
Josh

On Sat, Jun 18, 2016 at 3:26 PM, Steven Dake (stdake) 
wrote:

>
>
> On 6/16/16, 6:13 PM, "James E. Blair"  wrote:
>
> >Now that we have retired Jenkins, we have some upcoming changes:
> >
> >* Console logs are now available via TCP
> >
> >  The status page now has "telnet" protocol links to running jobs.  If
> >  you connect to the host and port specified in that link, you will be
> >  sent the console log for that job up to that point in time and it
> >  will continue to stream over that connection in real time.  If your
> >  browser doesn't understand "telnet://" URLs, just grab the host and
> >  port and type "telnet  " or better yet, "nc 
> >  " into your terminal.  You can also grep through in progress
> >  console logs with "nc   | grep ".
> >
> >* Console logs will soon be available over the WWW
> >
> >  Netcatting to Grep is cool, but sometimes if you're already in a
> >  browser, it may be easier to click on a link and have that just open
> >  up in your existing browser.  Monty has been working on a websocket
> >  interface to the console log stream that we hope to have in place
> >  soon.
> >
> >* Zuul will stop using the name "Jenkins"
> >
> >  There is a new user in Gerrit named "Zuul".  Zuul has been
> >  masquerading as Jenkins for the past few years, but now that we no
> >  longer run any software named "Jenkins" it is the right time to
> >  change the name to Zuul.  If you have any programs, scripts,
> >  dashboards, etc, that look for either the full name "Jenkins" or
> >  username "jenkins" from Gerrit, you should immediately update them
> >  to also use the full name "Zuul" or username "zuul" in order to
> >  prepare for the change.
>
> Jim,
>
> Apologies for the confusion on my end, but does this also apply to the
> gate jenkins user?
>
> Thanks
> -steve
>
> >
> >-Jim
> >
> >___
> >OpenStack-Infra mailing list
> >OpenStack-Infra@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [OpenStack-Infra] Upcoming changes now that Jenkins has retired

[Joshua Hesketh]

Hey Steve,

Yes. The user "jenkins" in gerrit has actually been controlled by zuul for
some years now. This rename is basically to reflect that and includes an
1st party CI comments (so check and gate).

Cheers,
Josh

On Sat, Jun 18, 2016 at 3:26 PM, Steven Dake (stdake) 
wrote:

>
>
> On 6/16/16, 6:13 PM, "James E. Blair"  wrote:
>
> >Now that we have retired Jenkins, we have some upcoming changes:
> >
> >* Console logs are now available via TCP
> >
> >  The status page now has "telnet" protocol links to running jobs.  If
> >  you connect to the host and port specified in that link, you will be
> >  sent the console log for that job up to that point in time and it
> >  will continue to stream over that connection in real time.  If your
> >  browser doesn't understand "telnet://" URLs, just grab the host and
> >  port and type "telnet  " or better yet, "nc 
> >  " into your terminal.  You can also grep through in progress
> >  console logs with "nc   | grep ".
> >
> >* Console logs will soon be available over the WWW
> >
> >  Netcatting to Grep is cool, but sometimes if you're already in a
> >  browser, it may be easier to click on a link and have that just open
> >  up in your existing browser.  Monty has been working on a websocket
> >  interface to the console log stream that we hope to have in place
> >  soon.
> >
> >* Zuul will stop using the name "Jenkins"
> >
> >  There is a new user in Gerrit named "Zuul".  Zuul has been
> >  masquerading as Jenkins for the past few years, but now that we no
> >  longer run any software named "Jenkins" it is the right time to
> >  change the name to Zuul.  If you have any programs, scripts,
> >  dashboards, etc, that look for either the full name "Jenkins" or
> >  username "jenkins" from Gerrit, you should immediately update them
> >  to also use the full name "Zuul" or username "zuul" in order to
> >  prepare for the change.
>
> Jim,
>
> Apologies for the confusion on my end, but does this also apply to the
> gate jenkins user?
>
> Thanks
> -steve
>
> >
> >-Jim
> >
> >___
> >OpenStack-Infra mailing list
> >openstack-in...@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
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-Infra] [openstack-dev] Upcoming changes now that Jenkins has retired

[Joshua Hesketh]

We can update those without any trouble. We just need to also update the
tests that check the usernames. You should be able to make all of the
changes (as per your first patchset) and then find where the tests also
need changing. Happy to help you on the review if you need more guidance.

To clarify though, these are just usernames used in the testing. They can
be anything arbitrarily. And as mentioned by James, it is still possible to
run Jenkins with zuul (in v2.5). So the tests aren't necessarily incorrect.

There are still some places in infra that do still use jenkins though. For
example, when uploading logs or assets zuul ssh's into the log server as
the user 'jenkins'. We could create a new user for zuul to use in these
cases.

On Fri, Jun 17, 2016 at 6:08 PM, Will Zhou  wrote:

> Hi James,
>
> I submitted a fix to openstack-infra/zuul via
> https://review.openstack.org/#/c/330853/. I found that username could not
> be changed from 'jenkins' to 'zuul' like
>
>
> https://github.com/openstack-infra/zuul/blob/master/tests/fixtures/layouts/good_require_approvals.yaml#L11
> review_gerrit:
> - event: comment-added
> require-approval:
> * - username: jenkins*
> older-than: 48h
> - event: comment-added
> require-approval:
> - email: jenk...@example.com
> newer-than: 48h
> It seems that it might be a little early for the fix?
>
> Thanks.
>
> On Fri, Jun 17, 2016 at 9:15 AM James E. Blair 
> wrote:
>
>> Now that we have retired Jenkins, we have some upcoming changes:
>>
>> * Console logs are now available via TCP
>>
>>   The status page now has "telnet" protocol links to running jobs.  If
>>   you connect to the host and port specified in that link, you will be
>>   sent the console log for that job up to that point in time and it
>>   will continue to stream over that connection in real time.  If your
>>   browser doesn't understand "telnet://" URLs, just grab the host and
>>   port and type "telnet  " or better yet, "nc 
>>   " into your terminal.  You can also grep through in progress
>>   console logs with "nc   | grep ".
>>
>> * Console logs will soon be available over the WWW
>>
>>   Netcatting to Grep is cool, but sometimes if you're already in a
>>   browser, it may be easier to click on a link and have that just open
>>   up in your existing browser.  Monty has been working on a websocket
>>   interface to the console log stream that we hope to have in place
>>   soon.
>>
>> * Zuul will stop using the name "Jenkins"
>>
>>   There is a new user in Gerrit named "Zuul".  Zuul has been
>>   masquerading as Jenkins for the past few years, but now that we no
>>   longer run any software named "Jenkins" it is the right time to
>>   change the name to Zuul.  If you have any programs, scripts,
>>   dashboards, etc, that look for either the full name "Jenkins" or
>>   username "jenkins" from Gerrit, you should immediately update them
>>   to also use the full name "Zuul" or username "zuul" in order to
>>   prepare for the change.
>>
>> -Jim
>>
>> __
>> 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-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [OpenStack-Infra] Upcoming changes now that Jenkins has retired

[Joshua Hesketh]

We can update those without any trouble. We just need to also update the
tests that check the usernames. You should be able to make all of the
changes (as per your first patchset) and then find where the tests also
need changing. Happy to help you on the review if you need more guidance.

To clarify though, these are just usernames used in the testing. They can
be anything arbitrarily. And as mentioned by James, it is still possible to
run Jenkins with zuul (in v2.5). So the tests aren't necessarily incorrect.

There are still some places in infra that do still use jenkins though. For
example, when uploading logs or assets zuul ssh's into the log server as
the user 'jenkins'. We could create a new user for zuul to use in these
cases.

On Fri, Jun 17, 2016 at 6:08 PM, Will Zhou  wrote:

> Hi James,
>
> I submitted a fix to openstack-infra/zuul via
> https://review.openstack.org/#/c/330853/. I found that username could not
> be changed from 'jenkins' to 'zuul' like
>
>
> https://github.com/openstack-infra/zuul/blob/master/tests/fixtures/layouts/good_require_approvals.yaml#L11
> review_gerrit:
> - event: comment-added
> require-approval:
> * - username: jenkins*
> older-than: 48h
> - event: comment-added
> require-approval:
> - email: jenk...@example.com
> newer-than: 48h
> It seems that it might be a little early for the fix?
>
> Thanks.
>
> On Fri, Jun 17, 2016 at 9:15 AM James E. Blair 
> wrote:
>
>> Now that we have retired Jenkins, we have some upcoming changes:
>>
>> * Console logs are now available via TCP
>>
>>   The status page now has "telnet" protocol links to running jobs.  If
>>   you connect to the host and port specified in that link, you will be
>>   sent the console log for that job up to that point in time and it
>>   will continue to stream over that connection in real time.  If your
>>   browser doesn't understand "telnet://" URLs, just grab the host and
>>   port and type "telnet  " or better yet, "nc 
>>   " into your terminal.  You can also grep through in progress
>>   console logs with "nc   | grep ".
>>
>> * Console logs will soon be available over the WWW
>>
>>   Netcatting to Grep is cool, but sometimes if you're already in a
>>   browser, it may be easier to click on a link and have that just open
>>   up in your existing browser.  Monty has been working on a websocket
>>   interface to the console log stream that we hope to have in place
>>   soon.
>>
>> * Zuul will stop using the name "Jenkins"
>>
>>   There is a new user in Gerrit named "Zuul".  Zuul has been
>>   masquerading as Jenkins for the past few years, but now that we no
>>   longer run any software named "Jenkins" it is the right time to
>>   change the name to Zuul.  If you have any programs, scripts,
>>   dashboards, etc, that look for either the full name "Jenkins" or
>>   username "jenkins" from Gerrit, you should immediately update them
>>   to also use the full name "Zuul" or username "zuul" in order to
>>   prepare for the change.
>>
>> -Jim
>>
>> __
>> 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-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
__
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-Infra] Infra priorities and spec cleanup

[Joshua Hesketh]

Thanks for all the updates Jeremy :-)

On Mon, Jun 6, 2016 at 9:21 AM, Jeremy Stanley  wrote:

> 
>
> Store Build Logs in Swift
> -
>
>
> http://specs.openstack.org/openstack-infra/infra-specs/specs/logs-in-swift.html
>
> This seems to have taken a break, with our log volume diminishing
> significantly in the past year or so and an alternative AFS-based
> solution proposed:
>
> https://review.openstack.org/269928
>
> We should remove the original spec from our priority list (since
> that's basically already ceased to be an actual priority), and
> probably supercede it with the AFS proposal.
>
>
> 



So I think we need to treat voting on 269928 as a decision to no longer
pursue storing logs in swift or not. In doing so we should consider the
pros and cons of an AFS-based storage vs swift vs lvm (aka what we're doing
now).

For context, here is an update to the swift logs spec that details what is
(known to be) left: https://review.openstack.org/#/c/254718/

To me it feels like AFS is incomplete in terms of solving the original
problems that we set out to solve with swift (such as scaling, redundancy,
durability and low administration overhead). It solves them to an extent
and perhaps that extent is acceptable (more limited damage in an outage or
failure etc).

Swift on the other hand is close but each time we get closer we run into
more problems as we discover it turns out we like posix style filesystems.

I'm not sure which solution is the right answer. It feels a bit like the
storyboard vs manifest discussions we've had where we've tried a few things
and they haven't worked perfectly so now we're all too afraid to get our
fingers burned again.

I don't have particularly strong feelings either way but in order to move
this forward we need to make a concise decision on which way we want to go.

Additionally the urgency of this spec seems to have been reduced (due to
limiting the retention on logs). We should perhaps reconsider if it's a
priority spec or not after we've decided on a path forward.
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] StackViz is now enabled for all devstack-gate jobs

[Joshua Hesketh]

Awesome work to all involved. This is really neat! :-)

On Tue, Jun 7, 2016 at 9:32 AM, Buckley, Tim Jason <
timothy.jas.buck...@hpe.com> wrote:

> Hello all,
>
> I'd like to announce that StackViz will now be running at the end all
> tempest-dsvm jobs and saving visualization output to the log server.
>
> StackViz is a visualization utility for generating interactive
> visualizations of
> jobs in the OpenStack QA pipeline and aims to ease debugging and
> performance
> analysis tasks. Currently it renders an interactive timeline for subunit
> results and dstat data, but we are actively working to visualize more log
> types
> in the future.
>
> StackViz instances are saved as a 'stackviz' directory under 'logs' for
> each job
> run on http://logs.openstack.org/. For an example, see:
>
> http://logs.openstack.org/07/212207/8/check/gate-tempest-dsvm-full/2d30217/logs/stackviz/
>
> For more information StackViz, see the project page at:
> https://github.com/openstack/stackviz
>
> Bugs can also be reported at:
> https://bugs.launchpad.net/stackviz
>
> Feedback is greatly appreciated!
>
> Thanks,
> Tim Buckley
>
>
> __
> 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-Infra] [infra] Jobs failing : "No matching distribution found for "

[Joshua Hesketh]

Thanks for your digging and help with this Ian and Andreas.

I've added an apache rule to redirect -'s to .'s as a quick workaround to
un-wedge the gate https://review.openstack.org/#/c/314898/ (and a few edge
cases https://review.openstack.org/#/c/314956)

If you have a build that has failed due to "No matching distribution found
for " it should be safe to issue a 'recheck' now.

There may be some more edge cases so let us know if you run into any.

We should, as suggested, fix bandersnatch or perhaps pin pi as soon as
possible. Once fixed properly we should undo the workaround so that our
mirror matches pypi.

Cheers,
Josh

On Wed, May 11, 2016 at 2:07 PM, Ian Wienand  wrote:

> So it seems the just released pip 8.1.2 has brought in a new version
> of setuptools with it, which creates canonical names per [1] by
> replacing "." with "-".
>
> The upshot is that pip is now looking for the wrong name on our local
> mirrors.  e.g.
>
> ---
>  $ pip --version
> pip 8.1.2 from /tmp/foo/lib/python2.7/site-packages (python 2.7)
> $ pip --verbose  install --trusted-host mirror.ord.rax.openstack.org -i
> http://mirror.ord.rax.openstack.org/pypi/simple 'oslo.config>=3.9.0'
> Collecting oslo.config>=3.9.0
>   1 location(s) to search for versions of oslo.config:
>   * http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/
>   Getting page
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/
>   Starting new HTTP connection (1): mirror.ord.rax.openstack.org
>   "GET /pypi/simple/oslo-config/ HTTP/1.1" 404 222
>   Could not fetch URL
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/: 404 Client
> Error: Not Found for url:
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/ - skipping
>   Could not find a version that satisfies the requirement
> oslo.config>=3.9.0 (from versions: )
> ---
>
> (note olso-config, not oslo.config).  Compare to
>
> ---
> $ pip --verbose install --trusted-host mirror.ord.rax.openstack.org -i
> http://mirror.ord.rax.openstack.org/pypi/simple 'oslo.config>=3.9.0'
> You are using pip version 6.0.8, however version 8.1.2 is available.
> You should consider upgrading via the 'pip install --upgrade pip' command.
> Collecting oslo.config>=3.9.0
>   Getting page
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo.config/
>   Starting new HTTP connection (1): mirror.ord.rax.openstack.org
>   "GET /pypi/simple/oslo.config/ HTTP/1.1" 200 2491
> ---
>
> I think infra jobs that run on bare-precise are hitting this
> currently, because that image was just built.  Other jobs *might* be
> isolated from this for a bit, until the new pip gets out there on
> images, but "winter is coming", as they say...
>
> There is [2] available to make bandersnatch use the new names.
> However, I wonder if this might have the effect of breaking the
> mirrors for old versions of pip that ask for the "."?
>
> pypi proper does not seem affected, just our mirrors.
>
> I think probably working with bandersnatch to get a fixed version ASAP
> is probably the best way forward, rather than us trying to pin to old
> pip versions.
>
> -i
>
> [1] https://www.python.org/dev/peps/pep-0503/
> [2]
> https://bitbucket.org/pypa/bandersnatch/pull-requests/20/fully-implement-pep-503-normalization/
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [openstack-dev] [OpenStack-Infra] [infra] Jobs failing : "No matching distribution found for "

[Joshua Hesketh]

Thanks for your digging and help with this Ian and Andreas.

I've added an apache rule to redirect -'s to .'s as a quick workaround to
un-wedge the gate https://review.openstack.org/#/c/314898/ (and a few edge
cases https://review.openstack.org/#/c/314956)

If you have a build that has failed due to "No matching distribution found
for " it should be safe to issue a 'recheck' now.

There may be some more edge cases so let us know if you run into any.

We should, as suggested, fix bandersnatch or perhaps pin pi as soon as
possible. Once fixed properly we should undo the workaround so that our
mirror matches pypi.

Cheers,
Josh

On Wed, May 11, 2016 at 2:07 PM, Ian Wienand  wrote:

> So it seems the just released pip 8.1.2 has brought in a new version
> of setuptools with it, which creates canonical names per [1] by
> replacing "." with "-".
>
> The upshot is that pip is now looking for the wrong name on our local
> mirrors.  e.g.
>
> ---
>  $ pip --version
> pip 8.1.2 from /tmp/foo/lib/python2.7/site-packages (python 2.7)
> $ pip --verbose  install --trusted-host mirror.ord.rax.openstack.org -i
> http://mirror.ord.rax.openstack.org/pypi/simple 'oslo.config>=3.9.0'
> Collecting oslo.config>=3.9.0
>   1 location(s) to search for versions of oslo.config:
>   * http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/
>   Getting page
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/
>   Starting new HTTP connection (1): mirror.ord.rax.openstack.org
>   "GET /pypi/simple/oslo-config/ HTTP/1.1" 404 222
>   Could not fetch URL
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/: 404 Client
> Error: Not Found for url:
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo-config/ - skipping
>   Could not find a version that satisfies the requirement
> oslo.config>=3.9.0 (from versions: )
> ---
>
> (note olso-config, not oslo.config).  Compare to
>
> ---
> $ pip --verbose install --trusted-host mirror.ord.rax.openstack.org -i
> http://mirror.ord.rax.openstack.org/pypi/simple 'oslo.config>=3.9.0'
> You are using pip version 6.0.8, however version 8.1.2 is available.
> You should consider upgrading via the 'pip install --upgrade pip' command.
> Collecting oslo.config>=3.9.0
>   Getting page
> http://mirror.ord.rax.openstack.org/pypi/simple/oslo.config/
>   Starting new HTTP connection (1): mirror.ord.rax.openstack.org
>   "GET /pypi/simple/oslo.config/ HTTP/1.1" 200 2491
> ---
>
> I think infra jobs that run on bare-precise are hitting this
> currently, because that image was just built.  Other jobs *might* be
> isolated from this for a bit, until the new pip gets out there on
> images, but "winter is coming", as they say...
>
> There is [2] available to make bandersnatch use the new names.
> However, I wonder if this might have the effect of breaking the
> mirrors for old versions of pip that ask for the "."?
>
> pypi proper does not seem affected, just our mirrors.
>
> I think probably working with bandersnatch to get a fixed version ASAP
> is probably the best way forward, rather than us trying to pin to old
> pip versions.
>
> -i
>
> [1] https://www.python.org/dev/peps/pep-0503/
> [2]
> https://bitbucket.org/pypa/bandersnatch/pull-requests/20/fully-implement-pep-503-normalization/
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
__
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-Infra] An idea to help browse and troubleshoot Ansible Playbook runs

[Joshua Hesketh]

This is really neat, nice work David!

I can see this being useful for zuulv3 or even just infra runs as more of
our tooling moves to ansible :-)

On Wed, May 11, 2016 at 11:24 AM, David Moreau Simard 
wrote:

> Hi openstack-infra,
>
> I've been hacking on an idea since last friday and I was thinking it
> could be of interest for you guys as Ansible users, but also
> considering the next generation of Zuul jobs will be powered by
> Ansible.
>
> The project I'm working on is called ARA [1]. It is very much an alpha
> at this point but it is hopefully fleshed out enough at this point for
> you to see where I am going with this.
> I could go on about what the project looks like but I've actually
> built a sane amount of docs [2] and even put up a video of what the
> interface looks like on YouTube [3].
>
> ARA was born out of necessity because the vast majority of RDO CI [4]
> is driven by Ansible, either through projects like TripleO-Quickstart
> [5] or WeIRDO [6].
>
> We are equipped in a fairly similar way than upstream, we have Jenkins
> console logs that are large enough to crash your browser and logs that
> are collected and made browsable like on logs.o.o.
> In a nutshell, we're running CI jobs that install and test OpenStack
> deployments through various installers: TripleO, Packstack,
> Puppet-OpenStack, and soon: Kolla and Chef-OpenStack.
>
> The sad reality is that the RDO community has limited resources and
> ARA aims at making it easier and faster to see what failed, where and
> why to make everyone more efficient.
> Another sad truth is that I am much more a system administrator than a
> developer and as such I am not exactly awesome in either Python or
> UI/UX frontends.
>
> As such, if you are interested in the project, I would certainly
> welcome not only feedback but contributions if you feel you could use
> this.
>
> Let me know if you have any questions !
>
> [1]: https://github.com/dmsimard/ara
> [2]: http://ara.readthedocs.io/en/latest/
> [3]: https://www.youtube.com/watch?v=K3jTqgm2YuY
> [4]: https://ci.centos.org/view/rdo/view/promotion-pipeline/
> [5]: https://github.com/openstack/tripleo-quickstart
> [6]: https://github.com/redhat-openstack/weirdo
>
> David Moreau Simard
> Senior Software Engineer | Openstack RDO
>
> dmsimard = [irc, github, twitter]
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] UNSTABLE jobs on the periodic-stable pipeline

[Joshua Hesketh]

Hey,

Yolanda is helping repair this. Basically the log filesystem needs
repairing and should be back shortly.

Cheers,
Josh

On Tue, May 3, 2016 at 4:27 PM, Tony Breeds  wrote:

> So the subject says it all really ;P
>
> The last batch of periodic-stable jobs all failed reporting 'UNSTABLE' as
> the result.
>
> The ones I checked had missing log files.
>
> eg
> http://lists.openstack.org/pipermail/openstack-stable-maint/2016-May/004275.html
>
> I reported this on IRC but just in case that gets lost in the scrollback I
> thought I'd also drop it here.
>
> Yours Tony.
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

[OpenStack-Infra] Infra and Friends dinner/social evening

[Joshua Hesketh]

Hi all,

For those at the Austin OpenStack summit who would like to have an infra
and friends dinner/social please join us this evening.

We'll gather at The Loft Bar in the Hilton lobby after the last design
summit session. Once we have quorum (around 6pm) we'll head out to find
some good food.

Anybody is welcome so please come along.

Cheers,
Josh
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] On image building and CI environments

[Joshua Hesketh]

Great write up Ian. Thanks very much :-).

On Wed, Apr 6, 2016 at 8:54 PM, Ian Wienand  wrote:

> Hi all,
>
> I spent a bit of time putting together a high-level view of the many
> changes we've worked on to get our image building & platform support
> to where it is today
>
>  https://www.technovelty.org/openstack/image-building-in-openstack-ci.html
>
> It's a bit long, but I hope it can help introduce interested people to
> the current environment and ongoing work in this area.
>
> Cheers,
>
> -i
>
> (p.s. thanks to the couple of #infra pre-readers for their feedback,
> of course more welcome :)
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra