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-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-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-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-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-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

[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-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-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-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-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-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-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-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-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-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-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-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-dev] Acknowledging Jim Blair's work on the TC

[Joshua Hesketh]

Absolutely, +1!

Thanks very much for all you do Jim.

On Sat, Apr 2, 2016 at 6:06 AM, Anita Kuno  wrote:

> Jim is an incumbent on the TC this election and he didn't run. I'm
> posting this to express my thanks to Jim for his work and dedication on
> the TC.
>
> Jim, I think your commitment to open source, spanning many years before
> OpenStack, and your dedication to governance process, are qualities I
> admire very much and I'm grateful you were able to voice your opinions
> on the TC from October 2013 until now.
>
> Thank you for taking your turn and thank you as well for allowing others
> a chance to take theirs.
>
> Thank you, Jim,
> Anita.
>
> __
> 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] Devstack jobs failing

[Joshua Hesketh]

Hi all,

Just a heads up that devstack jobs are failing in the gate. I'm currently
investigating but unfortunately haven't found anything yet and don't have
much time this evening.

Hopefully somebody smarter than I will look at it shortly.

Cheers,
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] [docs] [api] Why WADL when you can Swagger

[Joshua Hesketh]

Hey Anne,

Thanks for all your work. This sounds really exciting.

The explanation in this email was largely what I was missing during my
earlier reviews of the spec. I'll take another look at the spec shortly but
it might be helpful to have some of this rationale added.

Cheers,
Josh

On Sat, Feb 13, 2016 at 12:43 PM, michael mccune  wrote:

> On 02/12/2016 04:45 PM, Anne Gentle wrote:
> 
>
>> What's new?
>> 
>> This week, with every build of the api-site, we are now running
>> fairy-slipper to migrate from WADL to Swagger for API reference
>> information. Those migrated Swagger files are then copied to
>> developer.openstack.org/draft/swagger
>> .
>>
>> We know that not all files migrate smoothly. We'd love to get teams
>> looking at these migrated files. Thank you to those of you already
>> submitting fixes!
>>
>> In addition, the infra team is reviewing a spec now so that we can serve
>> API reference information from the developer.openstack.org
>>  site:
>> https://review.openstack.org/#/c/276484/
>>
>>
> Anne, this is a great update!
>
> love to see the progress on swagger integration.
>
>
> 
>
>> Last but not least, if you want to learn more about Swagger in the
>> upstream contributors track at the Summit, vote for this session:
>>
>> https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7723
>>
>
> sweet, +1
>
> regards,
> mike
>
>
>
> __
> 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] [doc] DocImpact vs. reno

[Joshua Hesketh]

Hey all,

So I just caught up on this thread and the corresponding scrollback in IRC.

First of all, sorry if this came as a surprise to anybody. As Andreas
pointed out this was highlighted in a number of docs email to this list,
but I understand why they might have been overlooked.

The resource usage was indeed a concern I had in mind in implementing the
DocImpact check. That is why I worked on further improvements to zuul to
only need to run the test on jobs that actually use the DocImpact flag[0].
The job does, however, run in under 2min. So the total burden of boot time
+ 2min isn't overly high. I do completely agree with all the concerns and
that it's not ideal though.

More than happy to have the job reverted or turned off while we discuss
this further. From the discussion in IRC it sounds like there'll be a
little bit of holding off until the new year (and people return from
holidays) but overall there seems to be a desire to use reno to replace
parts of this perhaps making the new job redundant.

Cheers,
Josh

[0]
https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z

On Sat, Dec 19, 2015 at 8:52 AM, Sean Dague  wrote:

> On 12/18/2015 02:31 PM, Andreas Jaeger wrote:
> > On 12/18/2015 07:45 PM, Sean Dague wrote:
> >> On 12/18/2015 01:34 PM, Andreas Jaeger wrote:
> >>> On 12/18/2015 07:03 PM, Sean Dague wrote:
>  Recently noticed that a new job ended up on all nova changes that was
>  theoertically processing commit messages for DocImpact. It appears
>  to be
>  part of this spec -
> 
> http://specs.openstack.org/openstack/docs-specs/specs/mitaka/review-docimpact.html
> 
> 
> >>>
> >>> Lana talked with John Garbutt about this and announced this also in
> >>> several 'What's up' newsletters like
> >>>
> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081522.html
> >>>
> >>>
> >>>
>  First, a heads up would be good. Nova burns a lot of nodes (i.e. has a
>  lot of patch volume), so this just decreased everyone's CI capacity
>  noticably.
> >>>
> >>> I understand this reasoning and Joshua worked on a superior solution,
> >>> see
> >>>
> https://review.openstack.org/#/q/status:open+project:openstack-infra/zuul+branch:master+topic:skip-commit,n,z
> >>>
> >>>
> >>>
> 
>  Secondly, this all seems like the wrong direction. We've got reno now,
>  which is extremely useful for documenting significant changes in the
>  code base that need to be reflected up. We've dropped UpgradeImpact
> for
>  an upgrade comment in reno, which is *so* much better.
> 
>  It seems like using reno instead of commit message tags would be much
>  better for everyone here.
> >>>
> >>> The goal of DocImpact is to notify the Documentation team about changes
> >>> - currently done via bugs in launchpad so that manuals can be easily
> >>> updated. How would this tracking work with docimpact?
> >>
> >> Because the current concern seems to be that naked DocImpact tag leaves
> >> people guessing what is important. And I understand that. There is a
> >> whole job now to just check that DocImpact containts a reason after it.
> >>
> >> We now have a very detailed system in reno to describe changes that will
> >> impact people using the code. It lets you do that with the commit and
> >> provide an arbitrarily large amount of content in it describing what and
> >> why you think that's important to reflect up.
> >>
> >> I think it effectively deprecates all *Impact flags. Now we have a place
> >> for that payload.
> >
> >
> > We - Sean, Anne Gentle, and Jeremy Stanley - just discussed this on
> > #openstack-infra, let me summarize my understanding:
> >
> > Some flags are used for checking before a merge the changes, especially
> > SecurityImpact and APIImpact. These are used for reviewing the changes.
> > This would be nice for DocImpact as well. SecurityImpact creates emails
> > for merged changes, DocImpact creates bugs for merged changes.
> >
> > When the docimpact spec was written, reno was not in use - and later
> > nobody brought it up as alternative idea.
> >
> > The idea going forward is instead of checking the commit message, is to
> > add a special section using reno that explains the changes that are
> > needed. A post-job would run and create bugs or sends out emails like
> > today whenever a new entry gets added. But this would be triggered by
> > special sections in the release-notes and not in the commit message. We
> > also expect/hope that release notes get a good review and thus the
> > quality of these notifications would be improved.
> >
> > Let's look on how exactly we can do this next year,
>
> Definitely.
>
> One other thing. Not running tests on commit messages has been the norm
> for a while. We used to have commit message checks in hacking, but they
> are things that you can't run locally (easily). So people push a
> critical fix, and run local, everything 

Re: [openstack-dev] Mitaka Infra Sprint

[Joshua Hesketh]

Hey,

Sorry about the formatting on my last email. Clearly my copy+paste skills
are lacking. Let me try again in case anybody was confused:


Hi all,

As discussed during the infra-meeting on Tuesday[0], the infra team will be
holding a mid-cycle sprint to focus on infra-cloud[1].

The sprint is an opportunity to get in a room and really work through as
much code and reviews as we can related to infra-cloud while having each
other near by to discuss blockers, technical challenges and enjoy company.

Information + RSVP:
https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint

Dates:
Mon. February 22nd at 9:00am to Thursday. February 25th

Location:
HPE Fort Collins Colorado Office

Who:
Anybody is welcome. Please put your name on the wiki page if you are
interested in attending.

If you have any questions please don't hesitate to ask.

Cheers,
Josh + Infra team

[0]
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-08-19.00.html
[1]
https://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html




On Thu, Dec 10, 2015 at 6:30 PM, Spencer Krum <n...@spencerkrum.com> wrote:

> Thanks josh
>
> --
>   Spencer Krum
>   n...@spencerkrum.com
>
>
>
> On Wed, Dec 9, 2015, at 09:17 PM, Joshua Hesketh wrote:
>
> Hi all,
> As discussed during the infra-meeting on Tuesday[0], the infra team will
> be holding a mid-cycle sprint to focus on infra-cloud[1].
> The sprint is an opportunity to get in a room and really work through as
> much code and reviews as we can related to infra-cloud while having each
> other near by to discuss blockers, technical challenges and enjoy company.
> Information + RSVP:
> https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint
> Dates:Mon. February 22nd at 9:00am to Thursday. February 25th
> Location:HPE Fort Collins Colorado Office
> Who:Anybody is welcome. Please put your name on the wiki page if you are
> interested in attending.
> If you have any questions please don't hesitate to ask.
> Cheers,Josh + Infra team
> [0]
> http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-08-19.00.html[1]
> https://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html
>
> *__*
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Mitaka Infra Sprint

[Joshua Hesketh]

Hi all,
As discussed during the infra-meeting on Tuesday[0], the infra team will be
holding a mid-cycle sprint to focus on infra-cloud[1].
The sprint is an opportunity to get in a room and really work through as
much code and reviews as we can related to infra-cloud while having each
other near by to discuss blockers, technical challenges and enjoy company.
Information + RSVP:https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint
Dates:Mon. February 22nd at 9:00am to Thursday. February 25th
Location:HPE Fort Collins Colorado Office
Who:Anybody is welcome. Please put your name on the wiki page if you are
interested in attending.
If you have any questions please don't hesitate to ask.
Cheers,Josh + Infra team
[0]
http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-12-08-19.00.html[1]
https://specs.openstack.org/openstack-infra/infra-specs/specs/infra-cloud.html
__
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] Open Cloud Symposium Call for Proposals – LCA2016

[Joshua Hesketh]

We are pleased to announce that the call for proposals to the Open Cloud
Symposium for linux.conf.au 2016 is now open! The symposium – a one day
mini-conference dedicated to all things cloud – will be held on Monday
01 February 2016 in Geelong, Victoria as part of linux.conf.au 2016.

Presentation subjects are warmly invited from a wide range of topics
related to cloud. This includes practically any layer of the typical
*aaS stack, containers, software defined networking/infrastructure and
other emerging technology. Talks targeted at any relevant audiences are
encouraged, such as:
 - System administration and operation of clouds,
 - Development of clouds and developer talks,
 - Cloud application development and users of cloud components.

The symposium is agnostic of the cloud software presented – so long as
it is open source. The organisers are looking to get a wide variety of
technologies represented and welcome proposals from as many cloud
flavours as possible.

If you have something interesting to talk about, please head on over to
http://goo.gl/forms/IH8surT5Zs to lodge your submission.

Dates:
 - CFP open: 02/12/2015
 - CFP close: 29/12/2015
 - Conference starts: 01/02/2016

Help dispersing this CFP to other mailing lists or individuals that you
think would be well suited to presenting would be greatly appreciated.

Presenters at the Open Cloud Symposium need to be delegates of
linux.conf.au; so make sure you’ve registered at
http://linux.conf.au/register/info. Even if you’re not presenting, you
should consider attending this fantastic conference (and mini-conferences).

Any questions or queries can be directed to j...@nitrotech.org

Cheers,
The Open Cloud Symposium organisers.
http://sites.rcbops.com/opencloud_symposium/

== About Open Cloud Symposium ==

The Open Cloud Symposium will be held on Monday 01 February 2016 in
Geelong, Victoria as part of linux.conf.au 2016.

The Open Cloud Symposium is a one day mini-conference dedicated to all
things cloud held as part of the main linux.conf.au conference. A ticket
for linux.conf.au is required to attend the event.

== About linux.conf.au ==

Linux Conference Australia, officially ‘linux.conf.au’ and
affectionately known as ‘LCA’, started life as the the Congress of
Australian Linux Users in 1999. Since 2001, the conference has been held
around different cities and towns in both Australia and New Zealand,
attracting both Linux professionals and passionate hobbyists.

linux.conf.au is an informal, grass-roots event, where the hallway track
is just as valuable as the formal conference schedule. The conference
has spawned a close knit and tightly connected community in Australia
and overseas.
__
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] IRC Bot issues

[Joshua Hesketh]

Hi all,

Freenode are currently experiencing a severe DDoS attack that are having an
effect on our bots. As such the meetbot, irc logging and gerrit watcher are
interminably available.

We expect the bots to resume their normal function once Freenode has
recovered. For now, meetings may have to be postponed or minuted by hand.

Cheers,
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] [OpenStack-Infra] [infra] PTL non-candidacy

[Joshua Hesketh]

On Fri, Sep 11, 2015 at 6:56 AM, Jeremy Stanley  wrote:

> On 2015-09-10 13:27:53 -0700 (-0700), James E. Blair wrote:
> [...]
> > I do not plan to run for PTL in the next cycle.
> [...]
>
> Thanks for the awesome job you did as PTL these last cycles. I hope
> you enjoy a much-deserved break from the post, and I'm looking
> forward to the new Zuul! ;)
>

Indeed! Your efforts on infra have been both tireless and amazing. Thanks
for all you do for open source!

Cheers,
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] [all] PTL/TC candidate workflow proposal for next elections

[Joshua Hesketh]

I'm struggling to think of a way this might help enable discussions between
nominees and voters about their platforms. Since the tooling will send out
the nomination announcements the only real noise that is reduced is the
nomination confirmed type emails.

While I think this sounds really neat, I'm not convinced that it'll
actually reduce noise on the mailing list if that was the goal. I realise
the primary goal is to help the election officials, but perhaps we can
achieve both of these by a separate mailing list for both nomination
announcements and also platform discussions? This could be a first step and
then once we have the tooling to confirm a nominees validity we could
automate that first announcement email still.

Just a thought anyway.

Cheers,
Josh

On Sat, Aug 22, 2015 at 5:44 AM, Anita Kuno ante...@anteaya.info wrote:

 On 08/21/2015 03:37 PM, Jeremy Stanley wrote:
  On 2015-08-21 14:32:50 -0400 (-0400), Anita Kuno wrote:
  Personally I would recommend that the election officials have
  verification permissions on the proposed repo and the automation
  step is skipped to begin with as a way of expediting the repo
  creation. Getting the workflow in place in enough time that
  potential candidates can familiarize themselves with the change,
  is of primary importance I feel. Automation can happen after the
  workflow is in place.
 
  Agreed, I'm just curious what our options actually are for
  automating the confirmation research currently performed. It's
  certainly not a prerequisite for using the new repo/workflow in a
  manually-driven capacity in the meantime.
 

 Fair enough. I don't want to answer the question myself as I feel it's
 best for the response to come from current election officials.

 Thanks Jeremy,
 Anita.

 __
 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] Gerrit under high load

[Joshua Hesketh]

Hi all,

Gerrit (review.openstack.org) has been restarted and the systems are back
up and functioning.

We have an idea of the cause of the problem and will investigate more
permanent fixes.

Cheers,
Josh

On Mon, Aug 17, 2015 at 5:06 PM, Joshua Hesketh joshua.hesk...@gmail.com
wrote:

 Hi all,

 Gerrit is currently under very high load and may be unresponsive. We are
 looking into the issue and will keep you updated here.

 Cheers,
 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

[openstack-dev] Gerrit under high load

[Joshua Hesketh]

Hi all,

Gerrit is currently under very high load and may be unresponsive. We are
looking into the issue and will keep you updated here.

Cheers,
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] How to use the log server in CI ?

[Joshua Hesketh]

Hi Tang,

For OpenStack's set up, os-loganalyze sits at /htmlify/ and is used to add
markup and filter log lines when viewing in a browser.

For your own set up you don't need to use this and could simply serve
anything straight off your disk. It should be safe to remove the apache
matching rules in order to do so.

Hope that helps.

Cheers,
Josh

On Thu, Aug 6, 2015 at 6:50 PM, Tang Chen tangc...@cn.fujitsu.com wrote:

 Hi Abhishek,

 After I setup a log server, if the request ends in .txt.gz, console.html
 or console.html.gz rewrite the url to prepend /htmlify/ .
 But actually the log file is on my local machine.

 Is this done by os-loganalyze ?  Is this included in install_log_server.sh
 ? (I don't think so.)
 Could I disable it and access my log file locally ?

 I found this URL for reference.

 http://josh.people.rcbops.com/2014/10/openstack-infrastructure-swift-logs-and-performance/

 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-dev] [OpenStack-Infra] [all][infra] CI System is broken

[Joshua Hesketh]

On Fri, Jul 31, 2015 at 10:29 PM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2015-07-31 14:49:52 +0800 (+0800), Gareth wrote:
  Could this issue be fixed today?

 I believe it is, now that we've restarted with
 https://review.openstack.org/207675 applied.

  Btw, is it possible to design a special mode for gate/zuul? If ops
  switch to that mode, all new gerrit event can't trigger any
  jenkins job.

 I must not be understanding what you're describing, since it sounds
 exactly like Zuul's existing graceful shutdown behavior and also
 because I have no idea how that would help this situation at all.


I think the suggestion might be to not add anything new to a queue when
zuul is in a particular mode. In other words to give zuul a chance to catch
up.

However this is difficult because zuul will eventually have to run for
those changes at some point, so it may as well queue them immediately and
get to them when it can.

Cheers,
Josh


 --
 Jeremy Stanley

 ___
 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] [all] CI Infrastructure down

[Joshua Hesketh]

Hi all,

The gate is slowly recovering and working through the backlog of changes.

It should now be safe to do 'recheck's on jobs that received NOT_REGISTERED
errors.

Cheers,
Josh

On Wed, Jul 22, 2015 at 11:08 PM, Andreas Jaeger a...@suse.com wrote:

 This morning we hit some problems with our CI infrastructure, the infra
 team is still investigating and trying to fix it.

 You can upload changes and comment on them but many jobs will fail with
 NOT_REGISTERED.

 Do not recheck these until the infrastructure is fixed again.

 Also, there's no sense in approving changes currently, they might be hit
 by the same NOT_REGISTERED jobs or fail in the post jobs.

 So, happy coding, reviewing - and local testing for now,

 Andreas
 --
  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, 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

Re: [openstack-dev] [nova][qa] turbo-hipster seems to be out to lunch

[Joshua Hesketh]

Everything is up and running again FYI. Let me know if you spot any further
problems.

Cheers,
Josh

On Tue, Jul 14, 2015 at 12:21 AM, Matt Riedemann mrie...@linux.vnet.ibm.com
 wrote:



 On 7/12/2015 1:50 AM, Joshua Hesketh wrote:

 Hey,

 Yes, sorry, I only discovered this yesterday. I should have updated the
 wiki page sooner but I've placed some details there now:

 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z

 Basically the removal of migrate-flavor-data from master broke
 turbo-hipster and a few of the patches to make it work just missed the
 cut-off for kilo. As such they are backported here:

 https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z

 Turbo-hipster is now disabled, blocked on getting those in so any help
 reviewing would be appreciated.

 Thanks,
 Josh


 On Sat, Jul 11, 2015 at 9:09 AM, Matt Riedemann
 mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote:

 There are a lot of failures on nova changes since yesterday and
 rechecks today don't seem to be coming back (after rechecking
 several hours ago).

 Known issues?

 --

 Thanks,

 Matt Riedemann



 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://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


 Thanks for the summary.  I'll work on getting these in today which
 includes getting the g-r sync and requirements jobs working again on
 stable/kilo.  The fix for that is in the gate now and then we'll get the
 proper stuff working in nova stable/kilo to get your cherry picks in.


 --

 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

Re: [openstack-dev] [nova][qa] turbo-hipster seems to be out to lunch

[Joshua Hesketh]

Hey,

Yes, sorry, I only discovered this yesterday. I should have updated the
wiki page sooner but I've placed some details there now:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z

Basically the removal of migrate-flavor-data from master broke
turbo-hipster and a few of the patches to make it work just missed the
cut-off for kilo. As such they are backported here:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z

Turbo-hipster is now disabled, blocked on getting those in so any help
reviewing would be appreciated.

Thanks,
Josh


On Sat, Jul 11, 2015 at 9:09 AM, Matt Riedemann mrie...@linux.vnet.ibm.com
wrote:

 There are a lot of failures on nova changes since yesterday and rechecks
 today don't seem to be coming back (after rechecking several hours ago).

 Known issues?

 --

 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] OpenStack miniconf at PyCon AU Ticket giveaway

[Joshua Hesketh]

Hi all,

The OpenStack miniconf at  PyCon Australia is rapidly approaching (31st
July) but it's not too late to register!

You can find all of the details on http://2015.pycon-au.org/, including
the OpenStack miniconf programme
http://2015.pycon-au.org/programme/schedule/friday.

We're also excited to be able to give away 2 full access (professional)
tickets, courtesy of the OpenStack foundation! If you would like to
attend the miniconf, but it would be a hardship for you to do so, please
send an email to myself (j...@nitrotech.org) and Robert Collins
(robe...@robertcollins.net) stating why you'd like to attend and we'll
consider you for receiving a ticket.

Cheers,
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] [OpenStack-Infra] Nominating Joshua Hesketh for infra-root

[Joshua Hesketh]

Thanks all. I promise to not break things too much!

Cheers,
Josh

On Fri, Jun 12, 2015 at 2:54 AM, James E. Blair cor...@inaugust.com wrote:
 The Infrastructure program has a unique three-tier team structure:
 contributors (that's all of us!), core members (people with +2 ability
 on infra projects in Gerrit) and root members (people with
 administrative access).  Read all about it here:

   http://docs.openstack.org/infra/system-config/project.html#teams

 Joshua has been a valuable member of infra-core for some time, having a
 high degree of familiarity with Zuul and related systems and an
 increasing interest in other operational aspects of the project
 infrastructure.  His eagerness to contribute is presently tempered by
 most of the infra-root team sleeping[1] during large parts of his day.
 I look forward to Joshua being able to approve changes with confidence.

 Joshua, if you are interested, please propose your SSH key to
 system-config, and thanks again for all of your work!

 -Jim
 [1] contrary to widely-held belief, this does happen

 ___
 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] PyCon-AU Openstack miniconf CFP open

[Joshua Hesketh]

Hi all,

Just a reminder that this closes in *1 weeks time*. We're hoping to put 
together a great selection of OpenStack talks from developers, users and 
operators. If you're interested in presenting at the miniconf, please 
submit to the main call for proposals where we'll be picking content from.


https://2015.pycon-au.org/cfp

See you in Brisbane!

Cheers,
Josh

Rackspace Australia

On 4/21/15 9:36 AM, Robert Collins wrote:

Hi everybody - I'd like to call attention to the PyCon-AU OpenStack miniconf.

http://2015.pycon-au.org/cfp

Pycon-au is an excellent conference, and the OpenStack miniconf is now
in its third year - we're really getting into the swing of things.

Please submit a paper to the main conference CFP - we'll be pulling
from the that to select talks.

Brisbane is a beautiful city, the venue is great - and so is the weather.

If you've any questions about whether to submit or not, please ping me
or Joshua Hesketh - we're organising the miniconf together and can
provide guidance.

Cheers,
Rob




__
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] Required data migrations in Kilo, need Turbo Hipster tests updated

[Joshua Hesketh]

On 4/23/15 11:41 PM, Dan Smith wrote:

That change works on the dataset. However I was referring to the
db/object api (which I have no real knowledge of) that it should be able
to get_by_uuid unmigrated instances and in my case I got the traceback
given in that paste. It's possible I'm just using the API incorrectly.

You should be able to pull migrated or unmigrated instances, yes. The
tests for the flavor stuff do this (successfully) at length. The
traceback you have seems like a half-migrated instance, where there is a
non-null flavor column on the instance_extra record, which shouldn't be
possible. The line numbers also don't match master, so I'm not sure
exactly what you're running.

If you can track down where in your dataset that is hitting and maybe
figure out what is going on, we can surely address it, but the current
tests cover all the cases I can think of at the moment.

Any chance you're tripping over something that was a casualty of
previous failures here?
I suspect I did manage to create an instance in between the two states 
when trying to set up my tests. Your fix works fine now, thanks.





Oh yes, we want that restriction, but a way around it for instances that
may be stuck or just testing purposes could be useful.

Yeah, as long as we're clear about the potential for problems if they
run --force on a moving target...


Yep. If this could get reviewed+merged that'd be great. I need this for 
turbo-hipster to sanely step through the migrate part.


Cheers,
Josh



--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] Required data migrations in Kilo, need Turbo Hipster tests updated

[Joshua Hesketh]

On 4/22/15 1:20 AM, Dan Smith wrote:

The migrate_flavor_data command didn't actually work on the CLI (unless
I'm missing something or did something odd). See
https://review.openstack.org/#/c/175890/ where I fix the requirement of
max_number. This likely means that operators have not bothered to do or
test the migrate_flavor_data yet which could be a concern.

Yep, I saw and +2d, thanks. I think it's pretty early in kilo testing
and since you don't *have* to do this for kilo, it's not really been an
issue yet.


Sure, but for people doing continuous deployment, they clearly haven't 
ran the migrate_flavor_data (or if they have, they haven't filed any 
bugs about it not working[0]).


I also found what I believe to be a bug with the flavor migration code. 
I started working on a fix by my limited knowledge of nova's objects has 
hindered me. Any thoughts on the legitimacy of the bug would be helpful 
though: https://bugs.launchpad.net/nova/+bug/1447132 . Basically for 
some of the datasets that turbo-hipster uses there are no entries in the 
new instance_extra table stopping any flavor migration from actually 
running. Then in your change (174480) you check the metadata table 
instead of the extras table causing the migration to fail even though 
migrate_flavor_data thinks there is nothing to do.


I think it's worth noting that your change (174480) will require 
operators (particularly continuous deployers) to run migrate_flavor_data 
and given the difficulties I've found I'm not sure it's ready to be ran. 
If we encounter bugs against real datasets with migrate_flavor_data then 
deployers will be unable to upgrade until migrate_flavor_data is fixed. 
This may make things awkward if a deployer updates their codebase and 
can't run the migrations. Clearly they'll have to roll-back the changes. 
This is the scenario turbo-hipster is meant to catch - migrations that 
don't work on real datasets.


If migrate_flavor_data is broken a backport into Kilo will be needed so 
that if Liberty requires all the flavor migrations to be finished they 
can indeed be ran before upgrading to Liberty. This may give reason not 
to block on having the flavors migrated until the M-release but I 
realise that has other undersiable consequences (ie high code maintenance).


Cheers,
Josh

[0] I found another one even: https://review.openstack.org/#/c/176172/




That said, I'm surprised migrate_flavor_data isn't just done as a
migration. I'm guessing there is a reason it's a separate tool and that
it has been discussed before, but if we are going to have a migration
enforcing the data to be migrated, then wouldn't it be sensible enough
to just do it at that point?

The point of this is that it's *not* done as a migration. Doing this
transition as a DB migration would require hours of downtime for large
deployments while rolling over this migration. Instead, the code in kilo
can handle the data being in either place, and converts it on update.
The nova-manage command allows background conversion (hence the
max-number limit for throttling) to take place while the system is running.

Thanks for fixing up nova-manage and for making T-H aware!

--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] Required data migrations in Kilo, need Turbo Hipster tests updated

[Joshua Hesketh]

On 4/23/15 1:31 AM, Dan Smith wrote:

Sure, but for people doing continuous deployment, they clearly haven't
ran the migrate_flavor_data (or if they have, they haven't filed any
bugs about it not working[0]).

Hence the usefulness of T-H here, right? The point of the migration
check is to make sure that people _do_ run it before the leave kilo.
Right now, they have nothing other than the big note in the release
notes about doing it. Evidence seems to show that they're not seeing it,
which is exactly why we need the check :)


I also found what I believe to be a bug with the flavor migration code.
I started working on a fix by my limited knowledge of nova's objects has
hindered me. Any thoughts on the legitimacy of the bug would be helpful
though: https://bugs.launchpad.net/nova/+bug/1447132 . Basically for
some of the datasets that turbo-hipster uses there are no entries in the
new instance_extra table stopping any flavor migration from actually
running. Then in your change (174480) you check the metadata table
instead of the extras table causing the migration to fail even though
migrate_flavor_data thinks there is nothing to do.

I don't think this has anything to do with the objects, it's probably
just a result of my lack of sqlalchemy-fu. Sounds like you weren't close
to a fix, so I'll try to cook something up.
Yeah it was my sqlalchemy-fu letting me down too. However I mentioned 
the objects because I was down a rabbit hole trying to figure out all of 
the code surrounding loading flavours from either system-metadata or extras.


If I selected all the instance_type_id's from the system-metadata table 
and used those uuid's to load the object with something like:

instance = objects.Instance.get_by_uuid(
context, instance_uuid,
expected_attrs=['system_metadata', 'flavor'])

The tests would fail at that point when trying to read in the flavor as 
json. http://paste.openstack.org/show/205158/


Basically without digging further it seems like I should be able to load 
an instance by uuid regardless of the state of my flavor(s). Since this 
fails it seems like there is something wrong with the flavor handling on 
the objects.




So, a question here: These data sets were captured at some point in
time, right? Does that mean that they were from say Icehouse era and
have had nothing done to them since? Meaning, are there data sets that
actually had juno or kilo running on them? This instance_extra thing
would be the case for any instance that hasn't been touched in a long
time, so it's legit. However, as we move to more online migration of
data, I do wonder if taking an ancient dataset, doing schema migrations
forward to current and then expecting it to work is really reflective of
reality.

Can you shed some light on what is really going on?


As mikal has followed up, that's correct. We have intended to refresh 
our datasets and will try and get some more recent ones, but testing the 
old ones has also proven useful.


Another interesting thing is that migrate_flavor_data avoids migrating 
instances that are in the middle of an operation. The snapshot of 
databases we have include instances in this state. Since turbo-hipster 
is just testing against a snapshot in time there is no way for those 
instances to leave their working state and hence migrate_flavor_data can 
never finish (every run will leave instances undone). This therefore 
blocks the migrations from ever finishing.


I don't think this is a real world problem though, so once we get this 
migration closer to merging we might have to force the instances to be 
migrated in our datasets. In fact, that could be a useful feature so I 
wrote it here: https://review.openstack.org/#/c/176574/


Cheers,
Josh




I think it's worth noting that your change (174480) will require
operators (particularly continuous deployers) to run migrate_flavor_data
and given the difficulties I've found I'm not sure it's ready to be ran.

Right, that's the point.


If we encounter bugs against real datasets with migrate_flavor_data then
deployers will be unable to upgrade until migrate_flavor_data is fixed.
This may make things awkward if a deployer updates their codebase and
can't run the migrations. Clearly they'll have to roll-back the changes.
This is the scenario turbo-hipster is meant to catch - migrations that
don't work on real datasets.

Right, that's why we're holding until we make sure that it works.


If migrate_flavor_data is broken a backport into Kilo will be needed so
that if Liberty requires all the flavor migrations to be finished they
can indeed be ran before upgrading to Liberty. This may give reason not
to block on having the flavors migrated until the M-release but I
realise that has other undersiable consequences (ie high code maintenance).

Backports to fix this are fine IMHO, and just like any other bug found
in actual running of things. It's too bad that none of our continuous
deployment people seem to have found 

Re: [openstack-dev] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

[Joshua Hesketh]

On 4/23/15 1:16 PM, Dan Smith wrote:

If I selected all the instance_type_id's from the system-metadata table
and used those uuid's to load the object with something like:
 instance = objects.Instance.get_by_uuid(
 context, instance_uuid,
 expected_attrs=['system_metadata', 'flavor'])

The tests would fail at that point when trying to read in the flavor as
json. http://paste.openstack.org/show/205158/

Basically without digging further it seems like I should be able to load
an instance by uuid regardless of the state of my flavor(s). Since this
fails it seems like there is something wrong with the flavor handling on
the objects.

You should. The above is a reasonable result to get without the fix to
ensure that we create instance_extra records for instances missing it.

Do you still see the above with

   https://review.openstack.org/#/c/176387/

applied?


That change works on the dataset. However I was referring to the 
db/object api (which I have no real knowledge of) that it should be able 
to get_by_uuid unmigrated instances and in my case I got the traceback 
given in that paste. It's possible I'm just using the API incorrectly.





Another interesting thing is that migrate_flavor_data avoids migrating
instances that are in the middle of an operation. The snapshot of
databases we have include instances in this state. Since turbo-hipster
is just testing against a snapshot in time there is no way for those
instances to leave their working state and hence migrate_flavor_data can
never finish (every run will leave instances undone). This therefore
blocks the migrations from ever finishing.

Ah, yeah, that's interesting, but I think it's a restriction we have to
make for sanity.


Oh yes, we want that restriction, but a way around it for instances that 
may be stuck or just testing purposes could be useful.


Cheers,
Josh



--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] Dropping DB Downgrades, need Turbo Hipster tests updated

[Joshua Hesketh]

Hey,

turbo-hipster is no longer testing downgrades as per the TC decision. 
The CI bot now passes on that change.


Cheers,
Josh

Rackspace Australia

On 4/20/15 10:16 PM, Sean Dague wrote:

Awesome, thanks Josh.

On 04/20/2015 07:14 AM, Joshua Hesketh wrote:

Hi Sean,

Thanks for your work on this. I'll take a closer look tomorrow and remove the 
downgrade testing from turbo-hipster in line with the TC decision.

Cheers,
Josh

From: Sean Dague s...@dague.net
Sent: Monday, 20 April 2015 8:38 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster 
tests updated

This proposed patch to drop the db downgrades in Nova master is making
Turbo Hipster face plant - https://review.openstack.org/#/c/175010/

It appears that turbo hipster is walking all the way up, then walking
back down through migrations, which clearly, is no longer a thing.

It would be nice to merge this patch sooner rather than later, so would
be great if Turbo hipster could function on migrations without
downgrades RSN.

 -Sean

--
Sean Dague
http://dague.net

__
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


Rackspace Hosting Australia PTY LTD a company registered in the state of 
Victoria, Australia (company registered number ACN 153 275 524) whose 
registered office is at Level 1, 37 Pitt Street, Sydney, NSW 2000, Australia. 
Rackspace Hosting Australia PTY LTD privacy policy can be viewed at 
www.rackspace.com.au/company/legal-privacy-statement.php - 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] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

[Joshua Hesketh]

Hey,

So I can add support to turbo-hipster to apply migrate_flavor_data when 
it hits your migration (in fact I started to do this). This means the 
tests will pass on your change and continue to once it merges. I'll 
update the datasets after the next release but it'll probably be to a 
version before migrate_flavor_data is required so we'll actually still 
be able to test that functionality against real datasets.


The migrate_flavor_data command didn't actually work on the CLI (unless 
I'm missing something or did something odd). See 
https://review.openstack.org/#/c/175890/ where I fix the requirement of 
max_number. This likely means that operators have not bothered to do or 
test the migrate_flavor_data yet which could be a concern.


That said, I'm surprised migrate_flavor_data isn't just done as a 
migration. I'm guessing there is a reason it's a separate tool and that 
it has been discussed before, but if we are going to have a migration 
enforcing the data to be migrated, then wouldn't it be sensible enough 
to just do it at that point?


If I were to have a guess at that reason I would say it is that you can 
do this command live without taking nova api offline whereas migrations 
are generally done as downtime and this could be a long migration.


Cheers,
Josh

Rackspace Australia

On 4/21/15 4:52 PM, Michael Still wrote:

Hey, turbo hipster already knows how to upgrade major releases, so
adding this should be possible.

That said, I've been travelling all day so haven't had a chance to
look at this. If Josh doesn't beat me to it, I will take a look when I
get to my hotel tonight.

(We should also note that we can just merge a thing without turbo
hipster passing if we understand the reason for the test failure.
Sure, that breaks the rest of the turbo hipster runs, but we're not
100% blocked here.)

Michael

On Tue, Apr 21, 2015 at 12:09 AM, Dan Smith d...@danplanet.com wrote:

This proposed patch requiring a data migration in Nova master is making
Turbo Hipster face plant - https://review.openstack.org/#/c/174480/

This is because we will require Kilo deployers to fully migrate their
flavor data from system_metadata to instance_extra before they upgrade
to the next release. They (and turbo hipster) will need to do this first:

https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L963

I'm not sure how you want to handle this, either by converting your data
sets, or only converting the ones that master runs.

It would be nice to merge this patch as soon as grenade is ready to do
so, as it's blocking all other db migrations in master.

Thanks!

--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] Dropping DB Downgrades, need Turbo Hipster tests updated

[Joshua Hesketh]

Hi Sean,

Thanks for your work on this. I'll take a closer look tomorrow and remove the 
downgrade testing from turbo-hipster in line with the TC decision.

Cheers,
Josh

From: Sean Dague s...@dague.net
Sent: Monday, 20 April 2015 8:38 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster 
tests updated

This proposed patch to drop the db downgrades in Nova master is making
Turbo Hipster face plant - https://review.openstack.org/#/c/175010/

It appears that turbo hipster is walking all the way up, then walking
back down through migrations, which clearly, is no longer a thing.

It would be nice to merge this patch sooner rather than later, so would
be great if Turbo hipster could function on migrations without
downgrades RSN.

-Sean

--
Sean Dague
http://dague.net

__
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


Rackspace Hosting Australia PTY LTD a company registered in the state of 
Victoria, Australia (company registered number ACN 153 275 524) whose 
registered office is at Level 1, 37 Pitt Street, Sydney, NSW 2000, Australia. 
Rackspace Hosting Australia PTY LTD privacy policy can be viewed at 
www.rackspace.com.au/company/legal-privacy-statement.php - 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

Re: [openstack-dev] [OpenStack-Infra] [third-party]Time for Additional Meeting for third-party

[Joshua Hesketh]

Hey,

0700 - 1000 UTC would work for me most weeks fwiw.

Cheers,
Josh

Rackspace Australia

On 12/3/14 11:17 AM, He, Yongli wrote:

anteaya,

UTC 7:00 AM to UTC9:00, or UTC11:30 to UTC13:00 is ideal time for china.

if there is no time slot there, just pick up any time between UTC 7:00 AM to 
UCT 13:00. ( UTC9:00 to UTC 11:30 is on road to home and dinner.)

Yongi He
-Original Message-
From: Anita Kuno [mailto:ante...@anteaya.info]
Sent: Tuesday, December 02, 2014 4:07 AM
To: openstack Development Mailing List; openstack-in...@lists.openstack.org
Subject: [openstack-dev] [third-party]Time for Additional Meeting for 
third-party

One of the actions from the Kilo Third-Party CI summit session was to start up 
an additional meeting for CI operators to participate from non-North American 
time zones.

Please reply to this email with times/days that would work for you. The current 
third party meeting is on Mondays at 1800 utc which works well since Infra 
meetings are on Tuesdays. If we could find a time that works for Europe and 
APAC that is also on Monday that would be ideal.

Josh Hesketh has said he will try to be available for these meetings, he is in 
Australia.

Let's get a sense of what days and timeframes work for those interested and 
then we can narrow it down and pick a channel.

Thanks everyone,
Anita.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
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-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Turbo hipster problems

[Joshua Hesketh]

Hi Gary,

Sorry we had a mis-hap over the weekend. The Database CI should be back 
up and running now. Let me know if you see any more problems.


Cheers,
Josh

Rackspace Australia

On 10/18/14 1:55 AM, Gary Kotton wrote:

Hi,
Anyone aware why Turbo his peter is failing with:

real-db-upgrade_nova_percona_user_002:th-percona http://localhost 
Exception: [Errno 2] No such file or directory: 
'/var/lib/turbo-hipster/datasets_user_002' in 0s


Thanks
Gary


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


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

Re: [openstack-dev] [infra] Nominating Anita Kuno for project-config-core

[Joshua Hesketh]

Absolutely. +1.

Rackspace Australia

On 9/27/14 1:34 AM, James E. Blair wrote:

I'm pleased to nominate Anito Kuno to the project-config core team.

The project-config repo is a constituent of the Infrastructure Program
and has a core team structured to be a superset of infra-core with
additional reviewers who specialize in the area.

Anita has been reviewing new projects in the config repo for some time
and I have been treating her approval as required for a while.  She has
an excellent grasp of the requirements and process for creating new
projects and is very helpful to the people proposing them (who are often
creating their first commit to any OpenStack repository).

She also did most of the work in actually creating the project-config
repo from the config repo.

Please respond with support or concerns and if the consensus is in
favor, we will add her next week.

Thanks,

Jim

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



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

Re: [openstack-dev] [infra] Nominating Andreas Jaeger for project-config-core

[Joshua Hesketh]

Agreed :-). +1

Rackspace Australia

On 9/27/14 1:35 AM, James E. Blair wrote:

I'm pleased to nominate Andreas Jaeger to the project-config core team.

The project-config repo is a constituent of the Infrastructure Program
and has a core team structured to be a superset of infra-core with
additional reviewers who specialize in the area.

Andreas has been doing an incredible amount of work simplifying the
Jenkins and Zuul configuration for some time.  He's also been making it
more complicated where it needs to be -- making the documentation jobs
in particular a model of efficient re-use that is far easier to
understand than what he replaced.  In short, he's an expert in Jenkins
and Zuul configuration and both his patches and reviews are immensely
helpful.

Please respond with support or concerns and if the consensus is in
favor, we will add him next week.

Thanks,

Jim

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



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

Re: [openstack-dev] [infra] Nominating Sean Dague for project-config-core

[Joshua Hesketh]

Awesome. +1.

Rackspace Australia

On 9/27/14 1:35 AM, James E. Blair wrote:

I'm pleased to nominate Sean Dague to the project-config core team.

The project-config repo is a constituent of the Infrastructure Program
and has a core team structured to be a superset of infra-core with
additional reviewers who specialize in the area.

For some time, Sean has been the person we consult to make sure that
changes to the CI system are testing what we think we should be testing
(and just as importantly, not testing what we think we should not be
testing).  His knowledge of devstack, devstack-gate, tempest, and nova
is immensely helpful in making sense of what we're actually trying to
accomplish.

Please respond with support or concerns and if the consensus is in
favor, we will add him next week.

Thanks,

Jim

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



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

Re: [openstack-dev] Oslo final releases ready

[Joshua Hesketh]

Howdy,

I did some digging and it appears because the proposal bot failed and
skipped out updating keystone-specs:
http://logs.openstack.org/c2/c2372ca3ef6c3ced31934429aecf830daafe583a/post/propose-requirements-updates/e9bbc05/console.html#_2014-09-18_22_56_42_181
(the exit comes from here:
http://git.openstack.org/cgit/openstack/requirements/tree/update.py#n171)

Basically the problem is that keystone-specs have change
requirements.txt where it possibly shouldn't have. I'm not sure what
the policy is here but I'm guessing the keystone-specs repository
shouldn't be in the global requirements project list. There is no need
for deployers to have requirements that are needed for specs.

I've proposed a change to remove the keystone-specs repository from
projects.txt. If that merges the post jobs for the requirements
project will be re-ran and and proposals for the missed projects
should come through then.
https://review.openstack.org/#/c/122619/

As a side note, we should probably have failed post-jobs reported to
the somewhere. I've also put up a proposal for this:
https://review.openstack.org/#/c/122620/

Cheers,
Josh

On Fri, Sep 19, 2014 at 4:02 PM, Michael Still mi...@stillhq.com wrote:
 I would like to do a python-novaclient release, but this requirements
 commit hasn't yet turned into a requirements proposal for novaclient
 (that I can find). Can someone poke that for me?

 Michael

 On Fri, Sep 19, 2014 at 12:04 AM, Doug Hellmann d...@doughellmann.com wrote:
 All of the final releases for the Oslo libraries for the Juno cycle are 
 available on PyPI. I’m working on a couple of patches to the global 
 requirements list to update the baseline in the applications. In all cases, 
 the final release is a second tag on a previously released version.

 - oslo.config - 1.4.0 (same as 1.4.0.0a5)
 - oslo.db - 1.0.0 (same as 0.5.0)
 - oslo.i18n - 1.0.0 (same as 0.4.0)
 - oslo.messaging - 1.4.0 (same as 1.4.0.0a5)
 - oslo.rootwrap - 1.3.0 (same as 1.3.0.0a3)
 - oslo.serialization - 1.0.0 (same as 0.3.0)
 - oslosphinx - 2.2.0 (same as 2.2.0.0a3)
 - oslotest - 1.1.0 (same as 1.1.0.0a2)
 - oslo.utils - 1.0.0 (same as 0.3.0)
 - cliff - 1.7.0 (previously tagged, so not a new release)
 - stevedore - 1.0.0 (same as 1.0.0.0a2)

 Congratulations and *Thank You* to the Oslo team for doing an amazing job 
 with graduations this cycle!

 Doug


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



 --
 Rackspace Australia

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

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

Re: [openstack-dev] [Nova] [feature freeze exception] Move to oslo.db

[Joshua Hesketh]

Hey,

Yep, I became aware of these this afternoon. The negative votes are due 
to a bad nodepool image. I've rebuilt them and am working on clearing 
the backlog. Sorry for the issues.


Cheers,
Josh

Rackspace Australia

On 9/4/14 4:30 PM, Michael Still wrote:

I'm good with this one too, so that makes three if Joe is ok with this.

@Josh -- can you please take a look at the TH failures?

Thanks,
Michael

On Wed, Sep 3, 2014 at 8:10 PM, Matt Riedemann
mrie...@linux.vnet.ibm.com wrote:


On 9/3/2014 5:08 PM, Andrey Kurilin wrote:

Hi All!

I'd like to ask for a feature freeze exception for porting nova to use
oslo.db.

This change not only removes 3k LOC, but fixes 4 bugs(see commit message
for more details) and provides relevant, stable common db code.

Main maintainers of oslo.db(Roman Podoliaka and Victor Sergeyev) are OK
with this.

Joe Gordon and Matt Riedemann are already signing up, so we need one
more vote from Core developer.

By the way a lot of core projects are using already oslo.db for a
while:  keystone, cinder, glance, ceilometer, ironic, heat, neutron and
sahara. So migration to oslo.db won’t produce any unexpected issues.

Patch is here: https://review.openstack.org/#/c/101901/

--
Best regards,
Andrey Kurilin.


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


Just re-iterating my agreement to sponsor this.  I'm waiting for the latest
patch set to pass Jenkins and for Roman to review after his comments from
the previous patch set and -1.  Otherwise I think this is nearly ready to
go.

The turbo-hipster failures on the change appear to be infra issues in t-h
rather than problems with the code.

--

Thanks,

Matt Riedemann


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






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

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

[Joshua Hesketh]

On 9/3/14 10:43 AM, Jeremy Stanley wrote:

On 2014-09-03 11:51:13 +1200 (+1200), Robert Collins wrote:

I thought there was now a thung where zuul can use a different account
per pipeline?

That was the most likely solution we discussed at the summit, but I
don't believe we've implemented it yet (or if we have then it isn't
yet being used for any existing pipelines).
It's currently in review[0], although I think from discussions with 
other zuul devs we're likely to refactor large parts of how we connect 
to systems and hence this may be delayed. If it's something that's 
needed soon(erish) we could probably do this step before the refactoring.


Cheers,
Josh

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

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

Re: [openstack-dev] [Infra][Neutron] How to verify link to logs for disabled third-party CI

[Joshua Hesketh]

On 9/3/14 12:11 PM, Gary Duan wrote:

Hi,

Our CI system is disabled due to a running bug and wrong log link. I 
have manually verified the system with sandbox and two Neutron testing 
patches. However, with CI disabled, I am not able to see its review 
comment on any patch.


Is there a way that I can see what the comment will look like when CI 
is disabled?


Hi Gary,

If you are using zuul you can use the smtp reporter[0] to email you a 
report in the format as it will appear in gerrit. Otherwise you'll need 
to look at what you'll be posting via ssh (if communicating directly 
with the gerrit api).


Cheers,
Josh

[0] http://ci.openstack.org/zuul/reporters.html#smtp



Thanks,
Gary


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


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

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

[Joshua Hesketh]

I've moved it back up the review chain for you :-)

Rackspace Australia

On 9/3/14 6:34 PM, Robert Collins wrote:

We would benefit a great deal from having this sooner.

On 3 September 2014 20:11, Joshua Hesketh joshua.hesk...@rackspace.com wrote:

On 9/3/14 10:43 AM, Jeremy Stanley wrote:

On 2014-09-03 11:51:13 +1200 (+1200), Robert Collins wrote:

I thought there was now a thung where zuul can use a different account
per pipeline?

That was the most likely solution we discussed at the summit, but I
don't believe we've implemented it yet (or if we have then it isn't
yet being used for any existing pipelines).

It's currently in review[0], although I think from discussions with other
zuul devs we're likely to refactor large parts of how we connect to systems
and hence this may be delayed. If it's something that's needed soon(erish)
we could probably do this step before the refactoring.

Cheers,
Josh

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


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






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

Re: [openstack-dev] Retrigger turbo-hipster

[Joshua Hesketh]

Hi John,

Sorry for the slow reply*. We ran into some trouble with our CI system 
after an upgrade to nova's requirements broke our system.


Everything is back up and running now and we've caught up on missed jobs 
(including your recheck). My apologies for the hassle. Let me know if 
you have any further problems.


Cheers,
Josh

* we had replied to your email to rcbau, let me know if you didn't 
receive that in-case there is something wrong with our emails


Rackspace Australia

On 8/9/14 2:10 PM, Anita Kuno wrote:

On 08/08/2014 02:53 PM, jswar...@linux.vnet.ibm.com wrote:

I'm unable to retrigger the turbo-hipster verification job on a change
(recheck migrations comment retriggers Jenkins but not turbo-hipster)
and I sent an e-mail to rc...@rcbops.com two days ago and still have not
received a reply.  Has anyone else run into this problem and found a way
to resolve it?

Thanks,

John


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

Hi John:

I've included Josh on this email and also added the openstack-infra
mailing list (where the majority of third-party ci questions get posted).

Since it is the weekend in Australia it might be a day or so before we
get a response but I am confident we will get one.

Thanks John,
Anita.

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



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

Re: [openstack-dev] [nova][qa] turbo-hipster seems very unhappy

[Joshua Hesketh]

Hey Matt,

You're absolutely right. We've been having trouble since a change to nova 
requirements was merged. We release we're a long way behind and are working on 
getting things back to normal as soon as possible. My apologies for the 
inconvenience.

Cheers,
Josh

From: Matt Riedemann [mrie...@linux.vnet.ibm.com]
Sent: Wednesday, July 30, 2014 8:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][qa] turbo-hipster seems very unhappy

I've seen t-h failing on many patches today, most that aren't touching
the database migrations, but it's primarily catching my attention
because of the failure on this change:

https://review.openstack.org/#/c/109660/

It looks like a pretty simple issue of the decorator package not being
in whatever pypi mirror that t-h is using.

--

Thanks,

Matt Riedemann


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

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

[openstack-dev] PyCon AU OpenStack Miniconf – Schedule now available!

[Joshua Hesketh]

Hello all,

The miniconf organisers are pleased to announce their first draft of a
schedule for the PyCon Australia OpenStack miniconf:

http://sites.rcbops.com/openstack_miniconf/2014/07/openstack-miniconf-programme-for-pycon-au/

The OpenStack miniconf is a one day conference held on Friday the 1st of
August 2014 in Brisbane before PyCon Australia. The day is dedicated to
talks and discussions related to the OpenStack  project.

The next OpenStack miniconf in the Asia-Pacific region will be held on
the 1st of August 2014 in Brisbane before PyCon AU.

Cheers,
Josh


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

Re: [openstack-dev] [Nova] Turbo hipster

[Joshua Hesketh]

Hi Gary,

Thanks for the notification. Our nodepool had built a corrupt image 
which was returning false positives. I have fixed this up and rerun 
tests on changes that had negative votes where Jenkins passed. If you 
notice any changes that seem like a false negative please issue a 
recheck migrations. If it fails a second time please let us know at 
rc...@rcbops.com.


FYI, you can see our testing progress at http://zuul.rcbops.com

Cheers,
Josh

Rackspace Australia

On 6/29/14 5:48 PM, Gary Kotton wrote:

Hi,
This appears to be broken over the last 24 hours.
Thanks
Gary


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


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

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

[Joshua Hesketh]

On 6/28/14 10:40 AM, James E. Blair wrote:

An alternate approach would be to have third-party CI systems register
jobs with OpenStack's Zuul rather than using their own account.  This
would mean only a single report of all jobs (upstream and 3rd-party)
per-patchset.  It significantly reduces clutter and makes results more
accessible -- but even with one system we've never actually wanted to
have Jenkins results in comments, so I think one of the other options
would be preferred.  Nonetheless, this is possible with a little bit of
work.


I agree this isn't the preferred solution, but I disagree with the 
little bit of work. This would require CI systems registering with 
gearman which would mean security issues. The biggest problem with this 
though is that zuul would be stuck waiting from results from 3rd parties 
which often have very slow return times.


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

Re: [openstack-dev] PyCon AU OpenStack Miniconf – Call for proposals now open!

[Joshua Hesketh]

Hello everybody,

Just a quick reminder that the call for proposals closes at the end of 
Friday for the openstack miniconf in Brisbane, Australia


http://openstack.pycon-au.org

Cheers,
Josh

On 5/27/14 5:33 PM, Joshua Hesketh wrote:

The OpenStack miniconf organisers for PyCon AU are pleased to announce
their call for proposals is now open!

The OpenStack miniconf is a one day conference held on Friday the 1st of
August 2014 in Brisbane before PyCon Australia. The day is dedicated to
talks related to the OpenStack project and we welcome proposals of all
kinds, from all kinds of speakers - first-time through to
super-experienced. The miniconf is a community conference and we are
eager to hear from anyone in the community.

Presentation subjects may range from reports on OpenStack; technical,
community, infrastructure or code talks/discussions; academic or
commercial applications; or even tutorials and case studies. If a
presentation is interesting and useful to the OpenStack community, it
will be considered for inclusion. We also welcome talks that have been
given previously in different events - e.g. talks from the OpenStack
Summit in Atlanta will be considered for inclusion.

The deadline for proposals is the 20th of June. If you submitted
OpenStack related talks to the main programme we encourage you to
re-submit to the miniconf.

If you have friends or colleagues who have something valuable to
contribute, twist their arms to tell us about it! Please also forward
this Call for Proposals to anyone that you feel may be interested.

To send in your submissions please visit http://openstack.pycon-au.org
See you in Brisbane in August!





--
Rackspace Australia

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

Re: [openstack-dev] [nova][qa] Do all turbo-hipster jobs fail in stable/havana?

[Joshua Hesketh]

On 6/18/14 12:52 AM, Matt Riedemann wrote:



On 6/16/2014 11:58 PM, Joshua Hesketh wrote:

Hi there,

Very sorry for the mishap. I manually enqueued our zuul to run tests on
changes that turbo-hipster had recently missed and did not pay attention
to the branch they were for.

Turbo-Hipster doesn't run tests on stable or non-master branches so it
should have never attempted to. Because I enqueued the changes manually
it accidentally attempted to run them and didn't know how to handle it
correctly.

I have removed the negative votes. Please let me know if I have missed
any.

Sorry again for the trouble.

Cheers,
Josh

On 6/17/14 11:44 AM, wu jiang wrote:

Hi all,

Is turbo-hipster OK for stable/havana?

I found all turbo-hipster jobs after 06/09 failed in stable/havana [1].
And the 'recheck migrations' command didn't trigger the re-examination
of turbo-hipster, but Jenkins recheck work..

Thanks.

WingWJ

---

[1]
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/havana,n,z



[2] https://review.openstack.org/#/c/67613/
[3] https://review.openstack.org/#/c/72521/
[4] https://review.openstack.org/#/c/98874/


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






Yeah I have some on stable/icehouse with -1 votes from t-h:

https://review.openstack.org/#/c/99215/
https://review.openstack.org/#/c/97811/



Thanks, I've cleaned those up as well as some other stable/icehouse 
changes that shouldn't have been voted on.


Sorry again for the mistake!

Cheers,
Josh

--
Rackspace Australia

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

Re: [openstack-dev] [nova][qa] Do all turbo-hipster jobs fail in stable/havana?

[Joshua Hesketh]

Hi there,

Very sorry for the mishap. I manually enqueued our zuul to run tests on 
changes that turbo-hipster had recently missed and did not pay attention 
to the branch they were for.


Turbo-Hipster doesn't run tests on stable or non-master branches so it 
should have never attempted to. Because I enqueued the changes manually 
it accidentally attempted to run them and didn't know how to handle it 
correctly.


I have removed the negative votes. Please let me know if I have missed any.

Sorry again for the trouble.

Cheers,
Josh

On 6/17/14 11:44 AM, wu jiang wrote:

Hi all,

Is turbo-hipster OK for stable/havana?

I found all turbo-hipster jobs after 06/09 failed in stable/havana [1].
And the 'recheck migrations' command didn't trigger the re-examination
of turbo-hipster, but Jenkins recheck work..

Thanks.

WingWJ

---

[1]
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/havana,n,z

[2] https://review.openstack.org/#/c/67613/
[3] https://review.openstack.org/#/c/72521/
[4] https://review.openstack.org/#/c/98874/


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




--
Rackspace Australia

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

Re: [openstack-dev] [Nova] [Ironic] [Infra] Making Ironic vote as a third-party Nova driver

[Joshua Hesketh]

Howdy,

Here is my first pass at allowing different voters for different pipelines.
https://review.openstack.org/#/c/97391/2

Cheers,
Josh

Rackspace Australia

On 5/30/14 3:30 AM, Devananda van der Veen wrote:
On Wed, May 28, 2014 at 10:54 PM, Joshua Hesketh 
joshua.hesk...@rackspace.com mailto:joshua.hesk...@rackspace.com 
wrote:


On 5/29/14 8:52 AM, James E. Blair wrote:

Devananda van der Veen devananda@gmail.com
mailto:devananda@gmail.com writes:

Hi all!

This is a follow-up to several summit discussions on
how-do-we-deprecate-baremetal, a summary of the plan
forward, a call to
raise awareness of the project's status, and hopefully
gain some interest
from folks on nova-core to help with spec and code reviews.

The nova.virt.ironic driver lives in Ironic's git tree
today [1]. We're
cleaning it up and submitting it to Nova again this cycle.
I've posted
specs [2] outlining the design and planned upgrade
process. Earlier today,
we enabled voting in Ironic's check and gate queues for the
tempest-dsvm-virtual-ironic job. This runs a tempest
scenario test [3]
against devstack, exercising Nova with the Ironic driver
to PXE boot a
virtual machine. It has been running for a few months on
Ironic, and has
been stable for more than a month. However, because Ironic
is not
integrated, we also can't vote in check/gate queues on
integrated projects
(like Nova). We can - and do - report the test result in a
non-voting way,
though that's easy to miss, since it looks like every
other non-voting test.

At the summit [4], it was suggested that we make this job
report as though
it were a third-party CI test for a Nova driver. This
would be removed at
the time that Ironic graduates and the job is allowed to
vote in the gate.
Until that time, I'm happy to have the nova.virt.ironic
driver reporting as
a third-party driver (even though it's not) simply to help
raise awareness
(third-party CI jobs are watched more closely than
non-voting jobs) and
decrease the likelihood that Nova developers will
inadvertently break
Ironic's gate.

Given that there's a concrete plan forward, why am I
sending this email to
all three teams? A few reasons:
- document the plan that we discussed
- many people from infra and nova were not present during
the discussion
and may not be aware of the details
- I may have gotten something wrong (it was a long week)
- and mostly because I don't technically know how to make
an upstream job
report as though it's a third-party job, and am hoping
someone wants to
volunteer to help figure that out

I think it's a reasonable plan.  To elaborate a bit, I think we
identified three categories of jobs that we run:

a) jobs that are voting
b) jobs that are non-voting because they are advisory
c) jobs that are non-voting for policy reasons but we feel fairly
strongly about

There's a pretty subtle distinction between b and c.  Ideally,
there
shouldn't be any.  We've tried to minimize the number of
non-voting jobs
to make sure that people don't ignore them.  Nonetheless, it
seems that
a large enough number of people still do that non-voting jobs are
considered ineffective in Nova.  I think it's worth noting the
potential
danger of de-emphasizing the actual results.  It may make other
non-voting jobs even less effective than they already are.

The intent is to make the jobs described by (c) into voting
jobs, but in
a way that they can still be overridden if need be.  The aim
is to help
new (eg, incubated) projects join the integrated gate in a way
that lets
them prove they are sufficiently mature to do so without
impacting the
currently integrated projects.  I believe we're currently
thinking that
point is after their integration approval.  If we are
comfortable with
incubated projects being able to block the integrated gate
earlier, we
could simply make the non-voting jobs voting instead.

Back to the proposal at hand.  I think we should call the
kinds of jobs
described in (c) as non-binding.

The best way to do that is to register a second

Re: [openstack-dev] [Nova] [Ironic] [Infra] Making Ironic vote as a third-party Nova driver

[Joshua Hesketh]

On 5/29/14 8:52 AM, James E. Blair wrote:

Devananda van der Veen devananda@gmail.com writes:


Hi all!

This is a follow-up to several summit discussions on
how-do-we-deprecate-baremetal, a summary of the plan forward, a call to
raise awareness of the project's status, and hopefully gain some interest
from folks on nova-core to help with spec and code reviews.

The nova.virt.ironic driver lives in Ironic's git tree today [1]. We're
cleaning it up and submitting it to Nova again this cycle. I've posted
specs [2] outlining the design and planned upgrade process. Earlier today,
we enabled voting in Ironic's check and gate queues for the
tempest-dsvm-virtual-ironic job. This runs a tempest scenario test [3]
against devstack, exercising Nova with the Ironic driver to PXE boot a
virtual machine. It has been running for a few months on Ironic, and has
been stable for more than a month. However, because Ironic is not
integrated, we also can't vote in check/gate queues on integrated projects
(like Nova). We can - and do - report the test result in a non-voting way,
though that's easy to miss, since it looks like every other non-voting test.

At the summit [4], it was suggested that we make this job report as though
it were a third-party CI test for a Nova driver. This would be removed at
the time that Ironic graduates and the job is allowed to vote in the gate.
Until that time, I'm happy to have the nova.virt.ironic driver reporting as
a third-party driver (even though it's not) simply to help raise awareness
(third-party CI jobs are watched more closely than non-voting jobs) and
decrease the likelihood that Nova developers will inadvertently break
Ironic's gate.

Given that there's a concrete plan forward, why am I sending this email to
all three teams? A few reasons:
- document the plan that we discussed
- many people from infra and nova were not present during the discussion
and may not be aware of the details
- I may have gotten something wrong (it was a long week)
- and mostly because I don't technically know how to make an upstream job
report as though it's a third-party job, and am hoping someone wants to
volunteer to help figure that out

I think it's a reasonable plan.  To elaborate a bit, I think we
identified three categories of jobs that we run:

a) jobs that are voting
b) jobs that are non-voting because they are advisory
c) jobs that are non-voting for policy reasons but we feel fairly
strongly about

There's a pretty subtle distinction between b and c.  Ideally, there
shouldn't be any.  We've tried to minimize the number of non-voting jobs
to make sure that people don't ignore them.  Nonetheless, it seems that
a large enough number of people still do that non-voting jobs are
considered ineffective in Nova.  I think it's worth noting the potential
danger of de-emphasizing the actual results.  It may make other
non-voting jobs even less effective than they already are.

The intent is to make the jobs described by (c) into voting jobs, but in
a way that they can still be overridden if need be.  The aim is to help
new (eg, incubated) projects join the integrated gate in a way that lets
them prove they are sufficiently mature to do so without impacting the
currently integrated projects.  I believe we're currently thinking that
point is after their integration approval.  If we are comfortable with
incubated projects being able to block the integrated gate earlier, we
could simply make the non-voting jobs voting instead.

Back to the proposal at hand.  I think we should call the kinds of jobs
described in (c) as non-binding.

The best way to do that is to register a second user with Gerrit for
Zuul to use, and have it report non-binding jobs with a +/- 1 vote in
the check queue that is separate from the normal Jenkins vote.  In
order to do that, we will have to modify Zuul to be able to support a
second user, and associate that user with a pipeline.  Then configure a
new non-binding pipeline to use that user and run the desired jobs.

Note that a similar problem of curation may occur with the non-binding
jobs.  If we run jobs for the incubated projects Foo and Bar, they will
share a vote in Gerrit, and Nova developers will have to examine the
results of -1 votes; if Bar consistently fails tests, it may need to be
made non-voting or removed to avoid obscuring Foo's results.

I expect the Zuul modification to take an experienced Zuul developer
about 2-3 days to write, or an inexperienced one about a week.  If no
one else has started it by then, I will probably have some time around
the middle of the cycle to hack on it.  In the mean time, we may want to
make sure that the number of non-voting jobs is at a minimum (and
further reduce them if possible), and emphasize to reviewers the
importance of checking posted results.


I like this plan. I can make a start on implementing this :-)

Cheers,
Josh



-Jim

___
OpenStack-dev mailing list

Re: [openstack-dev] [infra] Nominating Joshua Hesketh for infra-core

[Joshua Hesketh]

Thanks Jim and guys. Very excited by this new responsibility :-)

Cheers,
Josh

From: James E. Blair [jebl...@openstack.org]
Sent: Friday, May 30, 2014 3:05 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [infra] Nominating Joshua Hesketh for infra-core

jebl...@openstack.org (James E. Blair) writes:

 The Infrastructure program has a unique three-tier team structure:
 contributors (that's all of us!), core members (people with +2 ability
 on infra projects in Gerrit) and root members (people with
 administrative access).  Read all about it here:

   http://ci.openstack.org/project.html#team

 Joshua Hesketh has been reviewing a truly impressive number of infra
 patches for quite some time now.  He has an excellent grasp of how the
 CI system functions, no doubt in part because he runs a copy of it and
 has been doing significant work on evolving it to continue to scale.
 His reviews of python projects are excellent and particularly useful,
 but he also has a grasp of how the whole system fits together, which is
 a key thing for a member of infra-core.

 Please respond with any comments or concerns.

 Thanks, Joshua, for all your work!

Joshua is now in infra-core.  Congratulations!

-Jim

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

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

[openstack-dev] PyCon AU OpenStack Miniconf – Call for proposals now open!

[Joshua Hesketh]

The OpenStack miniconf organisers for PyCon AU are pleased to announce
their call for proposals is now open!

The OpenStack miniconf is a one day conference held on Friday the 1st of
August 2014 in Brisbane before PyCon Australia. The day is dedicated to
talks related to the OpenStack project and we welcome proposals of all
kinds, from all kinds of speakers - first-time through to
super-experienced. The miniconf is a community conference and we are
eager to hear from anyone in the community.

Presentation subjects may range from reports on OpenStack; technical,
community, infrastructure or code talks/discussions; academic or
commercial applications; or even tutorials and case studies. If a
presentation is interesting and useful to the OpenStack community, it
will be considered for inclusion. We also welcome talks that have been
given previously in different events - e.g. talks from the OpenStack
Summit in Atlanta will be considered for inclusion.

The deadline for proposals is the 20th of June. If you submitted
OpenStack related talks to the main programme we encourage you to
re-submit to the miniconf.

If you have friends or colleagues who have something valuable to
contribute, twist their arms to tell us about it! Please also forward
this Call for Proposals to anyone that you feel may be interested.

To send in your submissions please visit http://openstack.pycon-au.org
See you in Brisbane in August!


--
Rackspace Australia


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

Re: [openstack-dev] [infra] Nominating Sergey Lukjanov for infra-root

[Joshua Hesketh]

+1 :-)

From: James E. Blair [jebl...@openstack.org]
Sent: Thursday, May 22, 2014 7:42 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [infra] Nominating Sergey Lukjanov for infra-root

The Infrastructure program has a unique three-tier team structure:
contributors (that's all of us!), core members (people with +2 ability
on infra projects in Gerrit) and root members (people with
administrative access).  Read all about it here:

  http://ci.openstack.org/project.html#team

Sergey has been an extremely valuable member of infra-core for some time
now, providing reviews on a wide range of infrastructure projects which
indicate a growing familiarity with the large number of complex systems
that make up the project infrastructure.  In particular, Sergey has
expertise in systems related to the configuration of Jenkins jobs, Zuul,
and Nodepool which is invaluable in diagnosing and fixing operational
problems as part of infra-root.

Please respond with any comments or concerns.

Thanks again Sergey for all your work!

-Jim

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

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

[openstack-dev] [nova] Turbo-Hipster bad votes

[Joshua Hesketh]

Hi all,

Unfortunately turbo-hipster has been leaving bad votes on nova db migrations. 
I've disabled voting and we're looking into the problem.

Sorry for the inconvenience. If you have any questions please feel free to ask.

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

[openstack-dev] PyCon Australia Call For Proposals

[Joshua Hesketh]

Hi There,

Just a friendly note that PyCon Australia's call for proposals closes 
tomorrow.


PyCon Australia 2014 will be held in Brisbane 1st-5th of August. 
OpenStack content is welcome in the main programme.


For full details and to submit, see http://2014.pycon-au.org/cfp

Cheers,
Josh

--
Rackspace Australia


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

Re: [openstack-dev] [Infra] How to solve the cgit repository browser line number misalignment in Chrome

[Joshua Hesketh]

Hey,

I suspect you're looking for this : 
http://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/git/openstack.css

Hope that helps!

Cheers,
Josh

From: Doug Hellmann [doug.hellm...@dreamhost.com]
Sent: Thursday, April 10, 2014 12:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Infra] How to solve the cgit repository browser 
line number misalignment in Chrome

I don't, but someone on the infra team (#openstack-infra) should be
able to tell you where the theme is maintained.

Doug

On Tue, Apr 8, 2014 at 7:26 PM, Zhongyue Luo zhongyue@intel.com wrote:
 Do you happen to know where the repo for cgit is? I'll submit a patch adding
 font and font size.

 On Apr 8, 2014 10:24 PM, Doug Hellmann doug.hellm...@dreamhost.com
 wrote:

 Maybe those changes should be added to our cgit stylesheet?

 Doug

 On Mon, Apr 7, 2014 at 9:23 PM, Zhongyue Luo zhongyue@intel.com
 wrote:
  Hi,
 
  I know I'm not the only person who had this problem so here's two simple
  steps to get the lines and line numbers aligned.
 
  1. Install the stylebot extension
 
 
  https://chrome.google.com/extensions/detail/oiaejidbmkiecgbjeifoejpgmdaleoha
 
  2. Click on the download icon to install the custom style for
  git.openstack.org
 
  http://stylebot.me/styles/5369
 
  Thanks!
 
  --
  Intel SSG/STO/DCST/CBE
  880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
  China
  +862161166500
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 

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


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


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

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

Re: [openstack-dev] [tempest] who builds other part of test environment

[Joshua Hesketh]

Hi Gareth,

Tempest shouldn't touch the test that you are looking at. The Jenkins 
job should execute using the tox.ini in the rally repository so that 
part should be the same as your local environment. This is the relevant 
part loaded onto the Jenkin's slaves: 
https://github.com/openstack-infra/config/blob/master/modules/jenkins/files/slave_scripts/run-pep8.sh.


What is the specific difference you were concerned with?

Cheers,
Josh

Rackspace Australia

On 3/6/14 1:33 PM, Gareth wrote:

Hi

Here a test result: 
http://logs.openstack.org/25/78325/3/check/gate-rally-pep8/323b39c/console.html 
and its result is different from in my local environment. So I want to 
check some details of official test environment, for example 
/home/jenkins/workspace/gate-rally-pep8/tox.ini.


I guess it is in tempest repo but it isn't. I didn't find any test 
tox.ini file in tempest repo. So it should be hosted in another repo. 
Which is that one?


thanks

--
Gareth

/Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball/
/OpenStack contributor, kun_huang@freenode/
/My promise: if you find any spelling or grammar mistakes in my email 
from Mar 1 2013, notify me /

/and I'll donate $1 or ?1 to an open organization you specify./


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


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