Re: [openstack-dev] [tripleo][ui] Dependency management

[Alan Pevec]

On Mon, Jan 22, 2018 at 9:30 AM, Julie Pichon  wrote:
> On 19 January 2018 at 18:43, Honza Pokorny  wrote:
>> We've recently discovered an issue with the way we handle dependencies for
>> tripleo-ui.  This is an explanation of the problem, and a proposed solution.
>> I'm looking for feedback.
>>
>> Before the upgrade to zuul v3 in TripleO CI, we had two types of jobs for
>> tripleo-ui:
>>
>> * Native npm jobs
>> * Undercloud integration jobs
>>
>> After the upgrade, the integration jobs went away.  Our goal is to add them
>> back.
>>
>> There is a difference in how these two types of jobs handle dependencies.
>> Native npm jobs use the "npm install" command to acquire packages, and
>> undercloud jobs use RPMs.  The tripleo-ui project uses a separate RPM for
>> dependencies called openstack-tripleo-ui-deps.
>>
>> Because of the requirement to use a separate RPM for dependencies, there is 
>> some
>> extra work needed when a new dependency is introduced, or an existing one is
>> upgraded.  Once the patch that introduces the dependency is merged, we have 
>> to
>> increment the version of the -deps package, and rebuild it.  It then shows 
>> up in
>> the yum repos used by the undercloud.
>>
>> To make matters worse, we recently upgraded our infrastructure to nodejs 
>> 8.9.4
>> and npm 5.6.0 (latest stable).  This makes it so we can't write "purist" 
>> patches
>> that simply introduce a new dependency to package.json, and nothing more.  
>> The
>> code that uses the new dependency must be included.  I tend to think that 
>> each
>> commit should work on its own so this can be seen as a plus.
>>
>> This presents a problem: you can't get a patch that introduces a new 
>> dependency
>> merged because it's not included in the RPM needed by the undercloud ci job.
>>
>> So, here is a proposal on how that might work:
>>
>> 1. Submit a patch for review that introduces the dependency, along with code
>>changes to support it and validate its inclusion
>> 2. Native npm jobs will pass
>> 3. Undercloud gate job will fail because the dependency isn't in -deps RPM
>> 4. We ask RDO to review for licensing
>> 5. Once reviewed, new -deps package is built
>> 6. Recheck
>> 7. All jobs pass
>
> Perhaps there should be a step after 3 or 4 to have the patch normally
> reviewed, and wait for it to have two +2s before building the new
> package? Otherwise we may end up with wasted work to get a new package
> ready for dependencies that were eventually dismissed.

Thanks Julie for reminding me of  this thread!

I agree we can only build ui-deps package when the review is about to merge.
I've proposed https://github.com/rdo-common/openstack-tripleo-ui-deps/pull/19
which allows us to build the package with the review and patchset
numbers, before it's merged.
Please review and we can try it on the next deps update!

Cheers,
Alan

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

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

[Alan Pevec]

2017-03-13 15:49 GMT+01:00 Doug Hellmann :
...
> We test this upgrade scenario in the upstream CI, too. The difference
> is that grenade can tell pip "install exactly the version I am
> pointing to in this directory on disk," rather than relying on
> version numbers to notice that an upgrade is needed (or should be
> avoided, as the case may be).
>
> Is it possible to do that with system packages in some way, too, without
> pinning package versions in puppet or tripleo?

That would not test the regular update flow, we'd have to use
workaround for the period before milestone 1
and run explicit yum downgrade with the explicit package list to force
lower version packages to install.
That means real upgrades would not be tested until this kludge is
removed after first milestone is released.
Instead, I'll look at adding automatic bump in RDO Trunk builder
before milestone1 i.e. when it detects master version is lower than
stable branches.

Cheers,
Alan

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

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

[Alan Pevec]

2017-03-09 14:58 GMT+01:00 Jeremy Stanley :
> In the past we addressed this by automatically merging the release
> tag back into master, but we stopped doing that a cycle ago because
> it complicated release note generation.

Also this was including RC >= 2 and final tags so as soon as the first
stable maintenance version was released, master was again lower
version.

Cheers,
Alan

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

Re: [openstack-dev] [TripleO][release][deployment] Packaging problems due to branch/release ordering

[Alan Pevec]

2017-03-09 10:41 GMT+01:00 Alfredo Moralejo Alonso :
> On Wed, Mar 8, 2017 at 12:44 PM, Steven Hardy  wrote:
>> https://bugs.launchpad.net/tripleo/+bug/1669462
>>
>> I'm not clear on the best path forward at this point, but the simplest one
>> suggested so far is to simply tag a new pre-milestone/alpha release for all
>> master branches, which will enable testing upgrades to master.

That would be indeed simplest and cleanest solution but it has been
rejected in the past, IIUC with reasoning that projects are not sure
what will be their next version. IMHO that should not be the case if
the project has decided to have a stable branch and follows semver and
stable branch policy: in that case project will keep X.Y frozen on
stable so master should be bumped to at least X.Y+1 immediately after
branching stable.
For a project using PBR postversioning (almost all by now) this can be
achieved by either pushing the appropriate alpha git tag or by using
PBR Sem-Ver: feature https://docs.openstack.org/developer/pbr/#version
Now, purists would complain that artificial commit right after
branching is not really adding a feature but you could look at it as a
credit because you surely will implement new features in the new
version!
If project is without stable:follows-policy tag and it will keep
adding features on the stable branch, increasing Y part of semver or
if they already decided to bump X major version, Sem-Ver: api-break
can be used.
Example for TripleO projects for opening Ocata:
https://review.openstack.org/#/q/topic:open-ocata+Sem-Ver:

> As reference, puppet team proposed a solution for this issue in
> openstack puppet modules in
> http://lists.openstack.org/pipermail/openstack-dev/2017-March/113494.html
>
> However, as mentioned before this is affecting all projects, not only
> puppet ones.

Solution for OpenStack Puppet modules is to explicitly set pre-version
in metadata.json.
We had used pre-versioning before in regular OpenStack projects by
setting version in setup.cfg but this has been abandoned and instead
we rely on PBR to compute the next version.

>> I know we don't expect to fully support upgrades to pre-milestone releases,
>> but the requirement here is to simply enable testing them.
>>
>> A side-benefit of this regular testing e.g via CI is we'll find upgrade 
>> issues
>> much faster than waiting for one or more milestone releases to happen then
>> doing an upgrade-debug firedrill later in the cycle (which has been bad for
>> project and deployment teams IMO, so it'd be good to figure out this first
>> step to enable earlier testing of upgrades to the development release).
>>
>> Any thoughts on how we can resolve this would be much appreciated, thanks!

I was suggested that upgrade jobs could force install i.e. basically
doing downgrades before milestone1 but that's not testing upgrades!
Versioning is very fundamental for packaging and reflects upstream
version, we cannot fake versions in packaging.
In the spirit of Continuous Everything, versioning should also be
continuous and ensured that master version is always > previous
releases.
Projects doing stable branches could take action individually using
Sem-Ver keyword but better would be to define this as a rule for
having stable branches and enforce it cross projects by the release
procedure.

Cheers,
Alan

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

Re: [openstack-dev] [Tripleo] FFE to add Congress to Triple-o

[Alan Pevec]

Waiting for Alan to give -1/+1 on the RDO side, but it's a +1 for me
on the TripleO side.


+1 from me, I should finish missing PuLP dependency in RDO today
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [release][stable] nominating Alan Pevec (apevec) for stable release core

[Alan Pevec]

> Welcome to the team, Alan!

Thanks all!

Alan

__
OpenStack Development Mailing 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] [rdo-list] [RDO][DLRN] DLRN worker downtime during the weekend

[Alan Pevec]

> We need to run some maintenance operations on the DLRN instance next weekend, 
> starting on Friday 13 @ 19:00 UTC.

I've aborted the purge and restarted Ocata master builder so we can
get reverts built for CI blocker
https://bugs.launchpad.net/nova/+bug/1656276

Cheers,
Alan

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

Re: [openstack-dev] [ironic] [stable] Proposing Jay Faulkner for ironic-stable-maint

[Alan Pevec]

> Well, apparently I don't have access to add you, so we'll have
> to wait for Tony or someone else from the stable team to do that
> thing. :)

Done and welcome Jay!

Cheers,
Alan

__
OpenStack Development Mailing 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][release] Final releases for stable/liberty and liberty-eol

[Alan Pevec]

> 1. Final stable/liberty releases should happen next week, probably by
> Thursday 11/17.

I see only Cinder did it https://review.openstack.org/397282
and Nova is under review https://review.openstack.org/397841

Is that all or other project are not aware Liberty is EOL now?

Cheers,
Alan

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

Re: [openstack-dev] [tripleo] possible backports for stable/newton

[Alan Pevec]

> Since our cherry picks don't seem to be considered equivalents by git
> (probably because of modified commit messages)

I'd like to understand why is that, do you have an example?
It should work when recommendation[*] is followed.

Cheers,
Alan

[*]  
http://docs.openstack.org/project-team-guide/stable-branches.html#change-ids

__
OpenStack Development Mailing 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] [packstack] Proposal to add Alfredo Moralejo as core reviewer

[Alan Pevec]

> I'd like to propose Alfredo Moralejo (amoralej in #Freenode) as a core 
> reviewer for Packstack.

+1
With Alfredo in packstack-core, Spanish-speaking population will gain
relative majority and we should totally rename it to Packistack ;)

Cheers,
Alan

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

[openstack-dev] [release] RDO Newton packages released

[Alan Pevec]

The RDO community is pleased to announce the general availability of
the RDO build for OpenStack Newton for RPM-based distributions -
CentOS Linux 7 and Red Hat Enterprise Linux. RDO is suitable for
building private, public, and hybrid clouds. Newton is the 14th
release from the OpenStack project ( http://openstack.org ), which is
the work of more than 2700 contributors from around the world.
(Source http://stackalytics.com/ )

The RDO community project ( https://www.rdoproject.org/ ) curates,
packages, builds, tests, and maintains a complete OpenStack component
set for RHEL and CentOS Linux and is a member of the CentOS Cloud
Infrastructure SIG (
https://wiki.centos.org/SpecialInterestGroup/Cloud ). The Cloud
Infrastructure SIG focuses on delivering a great user experience for
CentOS Linux users looking to build and maintain their own on-premise,
public or hybrid clouds. At latest count, RDO contains 1157 packages (
https://www.rdoproject.org/documentation/package-list/ ).

All work on RDO, and on the downstream release, Red Hat OpenStack
Platform, is 100% open source, with all code changes going upstream
first.


Getting Started

There are three ways to get started with RDO.

To spin up a proof of concept cloud, quickly, and on limited hardware,
try the  RDO QuickStart ( http://rdoproject.org/Quickstart )  You can
run RDO on a single node to get a feel for how it works.

For a production deployment of RDO, use the TripleO Quickstart (
https://www.rdoproject.org/tripleo/ ) and you'll be running a
production cloud in short order.

Finally, if you want to try out OpenStack, but don't have the time or
hardware to run it yourself, visit  TryStack ( http://trystack.org/ ),
where you can use a free public OpenStack instance, running RDO
packages, to experiment with the OpenStack management interface and
API, launch instances, configure networks, and generally familiarize
yourself with OpenStack


Getting Help

The RDO Project participates in a Q service at ask.openstack.org (
http://ask.openstack.org ), for more developer oriented content we
recommend joining the rdo-list mailing list (
https://www.redhat.com/mailman/listinfo/rdo-list ). Remember to post a
brief introduction about yourself and your RDO story. You can also
find extensive documentation on the RDO docs site (
https://www.rdoproject.org/documentation ).

The #rdo channel on Freenode IRC is also an excellent place to find
help and give help.

We also welcome comments and requests on the CentOS Mailing lists (
https://lists.centos.org/ ) and the CentOS IRC Channels (#centos, and
#centos-devel, on irc.freenode.net), however we have a more focused
audience in the RDO venues.


Getting Involved

To get involved in the OpenStack RPM packaging effort, see the RDO
community pages ( https://www.rdoproject.org/community/ ) and the
CentOS Cloud SIG page (
https://wiki.centos.org/SpecialInterestGroup/Cloud ). See also the RDO
packaging documentation ( https://www.rdoproject.org/packaging/ ).

Join us in #rdo on the Freenode IRC network, and follow us at
@RDOCommunity ( http://twitter.com/rdocommunity ) on Twitter. If you
prefer Facebook, we're there too ( http://facebook.com/rdocommunity ),
and also Google+ ( http://tm3.org/rdogplus ).

And, if you're going to be in Barcelona for the OpenStack Summit (
http://openstack.org/summit/ ) two weeks from now, join us on Tuesday
evening at the Barcelona Princess, 5pm - 8pm, for an evening with the
RDO and Ceph communities. If you can't make it in person, we'll be
streaming it on YouTube ( https://www.youtube.com/watch?v=ji-WqEXZRTY
).


Cheers,
Alan

__
OpenStack Development Mailing 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][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Alan Pevec]

2016-09-22 15:58 GMT+02:00 Matt Riedemann :
> 1. We don't bump minimums just because a new thing comes out in a given
> release, we only bump minimums when something that uses that dependency
> needs a higher minimum version.
>
> 2. Looking at this:
>
> https://github.com/openstack/releases/blob/master/deliverables/liberty/oslo.concurrency.yaml
>
> I read the first release of oslo.concurrency in liberty was 1.9.0, not
> 2.6.0.

I meant first after stable/liberty was branched, without bumping to
that before release we end up with a situation like this, where we
don't have a release vehicle for stable fixes in the libraries.

Cheers,
Alan

__
OpenStack Development Mailing 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][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Alan Pevec]

> We have:
>  * global-requirements.txt:
> origin/stable/liberty : oslo.concurrency>=2.3.0 # Apache-2.0

But wasn't that wrong from the start?
First Liberty release of oslo.concurrency was 2.6.0 why was that not
bumped in g-r ?

Cheers,
Alan

__
OpenStack Development Mailing 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][stable/liberty] Backport impasse: "virt: set address space & CPU time limits when running qemu-img"

[Alan Pevec]

2016-09-20 13:27 GMT+02:00 Kashyap Chamarthy :
>>   (3) Do nothing, leave the bug unfixed in stable/liberty
>
> That was the unspoken third option, thanks for spelling it out. :-)

Yes, let's abandon both reviews.

Cheers,
Alan

__
OpenStack Development Mailing 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.db] [release] opportunistic tests breaking randomly

[Alan Pevec]

> Olso.db 4.13.3 did hit the scene about the time this showed up. So I
> think we need to strongly consider blocking it and revisiting these
> issues post newton.

So that means reverting all stable/newton changes, previous 4.13.x
have been already blocked https://review.openstack.org/365565
How would we proceed, do we need to revert all backport on stable/newton?

Cheers,
Alan

__
OpenStack Development Mailing 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] [packaging-rpm] Javier Peña as additonal core reviewer for packaging-rpm core group

[Alan Pevec]

+1

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

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

[Alan Pevec]

On Thu, Jul 21, 2016 at 12:42 PM, Derek Higgins  wrote:
> Trying to catch up here and summarizing as a top post

ack for the summary

> either of these, based only on which was proposed first i'd go for
> 345070

ack, I've abandoned 345106

> Start a discussion in rdo about how exactly people expect --local and
> --dev to behave and if there is need for a 3rd option to cover the
> tripleo use case, If we find any changes are needed to delorean, make
> them and then remove the hacks from tripleo-ci so we're less likely to
> hit problems in future.

IIRC Javer fixed --local to avoid some edge case we have hit when
running DLRN in production on trunk.rdoproject.org but I forgot
details, he'll chime-in when he's back from PTO.
Explicit --local-source would cover tripleo ci use-case, but let's
first collect all requirements in
https://github.com/openstack-packages/DLRN/issues/22
e.g. tripleo.sh script also has a sed patch to make postinstall step
optional, so let's address all interfaces at the same time.

Cheers,
Alan

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

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

[Alan Pevec]

On Wed, Jul 20, 2016 at 7:49 PM, Sagi Shnaidman  wrote:
> How then it worked before? Can you show me the patch that broke this
> functionality in delorean? It should be about 15 Jul when jobs started to
> fail.

commented in lp

> How then master branch works? It also runs on patched repo and succeeds.

I explained that but looks like we're talking past each other.

> I don't think we can use this workaround, each time this source file will
> change - all our jobs will fail again? It's not even a workaround.
> Please let's stop discussing and let's solve it finally, it blocks our CI
> for stable patches.

Sure, I've assigned https://bugs.launchpad.net/tripleo/+bug/1604039 to
myself and proposed a patch.

Alan

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

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

[Alan Pevec]

> as a quickfix in tripleo.sh you could patch dlrn and set local=True in

correction, patch local=False there while running dlrn command with
--local to keep source checkout as-is

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

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

[Alan Pevec]

>> ^ ... --local here keeps local checkout untouched, so you end up with
>> default rpm-master in distro git checkout.
>> If you remove --local it will reset local checkouts to the branches
>> specified in projects.ini
>>
> Alan,
> I don't want to reset local checkouts and reset branches - I need to build
> with these checkout, it's all CI is for.

DLRN finds matching packaging branch only when you let it reset git checkouts.
For tripleo-ci use-case we would need to add a new option to keep
source repo as-is and reset packaging checkout only, in the meantime
as a quickfix in tripleo.sh you could patch dlrn and set local=True in
[2]

Alan


[1] 
https://github.com/openstack-packages/DLRN/blob/master/dlrn/shell.py#L522-L536

[2] 
https://github.com/openstack-packages/DLRN/blob/master/dlrn/drivers/rdoinfo.py#L83-L84

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

Re: [openstack-dev] [TripleO] Delorean fail blocks CI for stable branches

[Alan Pevec]

> git clone https://git.openstack.org/openstack/tripleo-heat-templates
> cd tripleo-heat-templates/
> git checkout -b stable/mitaka origin/stable/mitaka

^ this is manually switching to the stable source branch

> sed -i -e "s%distro=.*%distro=rpm-mitaka%" projects.ini
> sed -i -e "s%source=.*%source=stable/mitaka%" projects.ini

^ this configures dlrn to the correct combination of distro and source
branches, but ...

> ./venv/bin/dlrn --config-file projects.ini --head-only --package-name
> openstack-tripleo-heat-templates --local

^ ... --local here keeps local checkout untouched, so you end up with
default rpm-master in distro git checkout.
If you remove --local it will reset local checkouts to the branches
specified in projects.ini

Alan

__
OpenStack Development Mailing 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"

[Alan Pevec]

> openstack/packstack  BigTent

Just to clarify, Packstack has not formally applied to BigTent yet, it
has only been automatically migrated from stackforge to openstack
namespace.
But yes, please keep its kilo branch for now until we properly wrap it up.

Cheers,
Alan

__
OpenStack Development Mailing 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] [packstack] Update packstack core list

[Alan Pevec]

>> I would like to step up as PTL if everybody is ok with it.
> 
> Go for it Iván!

+1


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

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Alan Pevec]

> So, if Delorean includes packages built from untagged commits in

Nit clarification: let's call it RDO Trunk repository (Delorean is a
tool, recently renamed https://github.com/openstack-packages/dlrn )

> multiple branches, placed in the same package repository where an
> automated installation tool can't tell stable/mitaka from master,
> that would be bad. Please tell me that's not what happens?

It is not what happens, there are separate repositories for packages
built from master and stable branches but it is still confusing, and
I'm not sure why is such a big deal to just push one empty commit with
Sem-Ver: api-break when we have that nice PBR automagic ?
Previously pre-versioning was used and version had to be bumped
explicitly in setup.cfg when opening master for the new version e.g.
https://review.openstack.org/#q,Ib634eb7acb64ff1d7be49852972295074b11557a,n,z

Another example (not release:managed project but still) where we have
this confusion is gnocchi:
openstack/gnocchi > master $ python ./setup.py --version
2.0.1.dev61
openstack/gnocchi > stable/2.0 $ python ./setup.py --version
2.0.3.dev13

Cheers,
Alan

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

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Alan Pevec]

2016-03-24 2:21 GMT+01:00 Robert Collins :
> Trunk will rapidly exceed mitaka's versions, leading to no confusion too.

That's the case now, RC1 tags are reachable from both branches and
master has more patches, generating higher .devN part. But once RC2
and final tags are pushed, generated version will be higher on
stable/mitaka branch:
>>> from packaging.version import Version, parse
>>> rc2=Version("13.0.0.0rc2")
>>> master=Version("13.0.0.0rc2.dev9")
>>> master > rc2
False
>>> ga=Version("13.0.0")
>>> master > ga
False

Cheers,
Alan

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

Re: [openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Alan Pevec]

> The release team discussed this at the summit and agreed that it didn't 
> really matter. The only folks seeing the auto-generated versions are those 
> doing CD from git, and they should not be mixing different branches of a 
> project in a given environment. So I don't think it is strictly necessary to 
> raise the major version, or give pbr the hint to do so.

ok, I'll send confused RDO trunk users here :)
That means until first Newton milestone tag is pushed, master will
have misleading version. Newton schedule is not defined yet but 1st
milestone is normally 1 month after Summit, and 2 months from now is
rather large window.

Cheers,
Alan

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

[openstack-dev] [release] [pbr] semver on master branches after RC WAS Re: How do I calculate the semantic version prior to a release?

[Alan Pevec]

2016-02-26 19:51 GMT+01:00 Robert Collins :
> On 27 February 2016 at 00:13, Neil Jerram  wrote:
>> I understand the semantic versioning algorithm for calculating a new
>> version.  But what do I run, in a git repository, to do that calculation
>> for me, and output:
>
> pbr does that automatically, generating a pre-release version. The
> regular part of the version is the lowest version number you can use
> that will match the semver rules.

So to help PBR, all projects should be inserting commit with Sem-Ver:
api-break after stable/mitaka was cut, without that we have the same
major version on both branches e.g. nova:

$ git checkout master
$ python ./setup.py --version
13.0.0.0rc2.dev48

$ git checkout stable/mitaka
$ python ./setup.py --version
13.0.0.0rc2.dev10

After pushing empty commit to the master with the message like:
Newton bump major version

Sem-Ver: api-break
Change-Id: I8a2270d5a0f45342fe418b3018f31e6ef054fe9e

$ python ./setup.py --version
14.0.0.dev49

Any reason not to do that? Other option is to push alpha tag to
master, but that would be weird IMHO.


Cheers,
Alan

__
OpenStack Development Mailing 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 do I calculate the semantic version prior to a release?

[Alan Pevec]

2016-02-29 9:32 GMT+01:00 Thomas Bechtold :
>> >>   python setup.py rpm_version
>> >
>> > The output for i.e. for Manila is here "1...b3.dev138"

And in Tempest rpm_version outputs 4.0.0.dev22 while setup.py
--version says 10.0.1.dev79 ?!

>> > Which is not really correct. The version is "2.0.0.0b3.dev138" .
>> > rpm supports the tilde ("~") for pre versions. Converting a PEP440
>> > compatible version to a rpm version can be done with code like:

Fedora does not use ~ for pre-versions[1] instead Release: starting
with 0 is used for pre-releases [2]

>> Does it? Thats great. It didn't as far as anyone here knew when we
>> wrote the spec -
>> http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/juno/pbr-semver.rst
>> - or we'd have avoiding a tonne of complexity.

I did mention Fedora pre-release versioning in that spec review
https://review.openstack.org/#/c/96608/10/specs/juno/pbr-semver.rst@235

>> I see from http://www.rpm.org/ticket/56 that it only came in in RPM 4.10 - 
>> is RPM
>> 4.10 available on all the RPM platforms we support? Including I guess
>> old RHEL's and stuff?
>
> Good question. For SUSE, SLE12 has rpm 4.11 which is fine. No idea about RHEL.

EL7 has rpm 4.11 too but ~ is not used, it follows above Fedora
guidelines for pre-releases.


Cheers,
Alan

[1] https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag
[2] 
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages

__
OpenStack Development Mailing 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] [packstack] Update packstack core list

[Alan Pevec]

2016-03-16 11:23 GMT+01:00 Lukas Bezdicka <lbezd...@redhat.com>:
>> ...
>> - Martin Mágr
>> - Iván Chavero
>> - Javier Peña
>> - Alan Pevec
>>
>> I have a doubt about Lukas, he's contributed an awful lot to
>> Packstack, just not over the last 90 days. Lukas, will you be
>> contributing in the future? If so, I'd include him in the proposal as
>> well.
>
> Thanks, yeah I do plan to contribute just haven't had time lately for
> packstack.

I'm also adding David Simard who recently contributed integration tests.

Since there hasn't been -1 votes for a week, I went ahead and
implemented group membership changes in gerrit.
Thanks to the past core members, we will welcome you back on the next

One more topic to discuss is if we need PTL election? I'm not sure we
need formal election yet and de-facto PTL has been Martin Magr, so if
there aren't other proposal let's just name Martin our overlord?

Cheers,
Alan

__
OpenStack Development Mailing 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] [stable] Stable* wiki updates

[Alan Pevec]

Hi stable-maints,

FYI I've updated https://wiki.openstack.org/wiki/StableBranch and
https://wiki.openstack.org/wiki/StableBranchRelease now that all
policy and team information has ben included in the Project Team
Guide. Please review in case I missed something!

Cheers,
Alan

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

Re: [openstack-dev] [ironic] [stable] Suggestion to remove stable/liberty and stable branches support from ironic-python-agent

[Alan Pevec]

> The tricky bit is that RDO does not include patches in our packages
> built from trunk (trunk.rdoproject.org), and for liberty we first check
> if stable/liberty exists, then fallback to master if it does not. So the
> presence of stable/liberty that is not actually the recommended way to
> build IPA for liberty is a bit not ideal for us.

Trunk builder will first use branch specified per project per release,
and we can now override that easily in rdoinfo.

> All of that said, I totally understand not wanting to delete a branch.
> Especially since I think I am the one who Dmitry is referring to asking
> for it. (Though I think what I wanted was releases which is subtly
> different)

that goes under "for historical reasons" :)

> I think there are some hacks I could make in our trunk builder if I at
> least have a ML post like this as justification. I am not 100% sure that
> is possible though.

No hacks needed and I've referenced this ML post:
https://github.com/redhat-openstack/rdoinfo/pull/158
Please let me know if that's what you wanted, to avoid further confusion :)

Cheers,
Alan

__
OpenStack Development Mailing 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-announce] [release][stable][horizon] horizon release 8.0.1 (liberty)

[Alan Pevec]

> With package available at:
>
> https://pypi.python.org/pypi/horizon

AFAICT non-client/non-oslo stable point releases are NOT uploaded to
pypi, are they?
e.g. last horizon on pypi is version 2012.2
Should we start uploading them to pypi or change the email template
for services projects?

Cheers,
Alan

__
OpenStack Development Mailing 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] kilo 2015.1.3 freeze exception request for cve fixes

[Alan Pevec]

2016-01-15 11:08 GMT+01:00 Dave Walker :
> On 15 January 2016 at 10:01, Thierry Carrez  wrote:
>> Ihar Hrachyshka wrote:
>>>
>>> +1. CVE fixes obviously should be granted an exception.
>>
>>
>> +1
>>
>
> Agreed, I have already +2'd on Gerrit.  Can another core please do the same?

Done and workflow started.

Cheers,
Alan

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

Re: [openstack-dev] [ironic] RFC: stop using launchpad milestones and blueprints

[Alan Pevec]

>>> I wonder how to avoid giving impression that development has stopped on
>>> 4.2.0. E.g. Launchpad would show 4.2.0 as the last released tarball, as
>>> we no longer push tarballs to launchpad.

.0 is clear indication that's GA tarball, but to make it clear you can
update Launchpad series summary
https://launchpad.net/ironic/liberty/+edit
to include the link to
http://docs.openstack.org/releases/releases/liberty.html#liberty-ironic

>> If, over time, we see a lot of folks actually confused about the
>> move we can figure out a way to migrate the old data elsewhere so
>> it can be deleted. But that's not going to happen this cycle, so
>> please leave it intact for now.
> Understood, thanks for explanation. So I withdraw suggestion #2.

Count me confused, when I saw Ironic 4.2.2 announcement and then 4.2.1
as latest in Launchpad.
I propose to remove https://launchpad.net/ironic/+milestone/4.2.1 - it
has no release notes and only one minor bug, so that's not much
information loss and cuts this confusing corner case.
For historical purposes, tarball is still available at
http://tarballs.openstack.org/ironic/ironic-4.2.1.tar.gz. This should
be the only non-reno Liberty release, for other projects it would be
super nice if release team could bulk add link
http://docs.openstack.org/releases/releases/liberty.html#liberty-$PROJECT
in all Liberty series summaries in Launchpad.

Cheers,
Alan

__
OpenStack Development Mailing 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] [Magnum] Liberty RPMs for RDO

[Alan Pevec]

Hi Mathieu,

2015-11-30 10:54 GMT+01:00 Mathieu Velten :
> Hi,
>
> Let me first introduce myself : I am currently working at CERN to help
> evaluate and deploy Magnum.
>
> In this regard Ricardo recently sends an email regarding Puppet
> modules, this one is about RPMs of Magnum for CentOS with RDO.

Nice, looking forward to review it!

> You can find here a repository containing the source and binary RPMs
> for magnum and python-magnumclient.
> http://linuxsoft.cern.ch/internal/repos/magnum7-testing/

This one is 403 ?

> The version 1.0.0.0b2.dev4 is the Magnum Liberty release and the
> 1.1.0.0-5 version is the Mitaka M1 release using Liberty dependencies
> (one client commit regarding keystone auth and one server commit
> regarding oslo.config have been reverted).
>
> Let me know how I can contribute the spec files to somewhere more
> suitable.

Let's discuss this on rdo-list (CCed)

Cheers,
Alan

__
OpenStack Development Mailing 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] Post-release bump after 2014.2.4?

[Alan Pevec]

> I've confirmed that the juno side of kilo grenade is not blowing up [1], but
> I'm not sure why it's not blowing up. Trying to figure that out.

It would blow up if something were merged after 2014.2.4 tag which
won't happen before version in setup.cfg is either bumped or removed
so we're safe :)

Cheers,
Alan

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

Re: [openstack-dev] [release][stable][keystone] keystonemiddleware release 1.5.3 (kilo)

[Alan Pevec]

> keystonemiddleware 1.5.3: Middleware for OpenStack Identity

periodic-ceilometer-python27-kilo started failing after this release
First bad: 
http://logs.openstack.org/periodic-stable/periodic-ceilometer-python27-kilo/40c5453/testr_results.html.gz
test_acl_scenarios failing with 401 Unauthorized

__
OpenStack Development Mailing 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] Post-release bump after 2014.2.4?

[Alan Pevec]

> But to illustrate better the issue I'm seeing:
> http://tarballs.openstack.org/cinder/cinder-stable-juno.tar.gz contains
> a directory cinder-2014.2.4.dev24, which is kind of wrong. That's the
> bit that I'd like to see fixed.

That version was correct at the time tarball was generated, if it were
regenerated now that tag was pushed, it would be cinder-2014.2.4
You could either ask infra to regenerate those tarballs or generate
tarballs yourself (python ./setup.py sdist in git checkout) instead of
relying on tarballs.o.o.

Cheers,
Alan

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

Re: [openstack-dev] [release][stable] OpenStack 2014.2.4 (juno)

[Alan Pevec]

2015-11-20 3:22 GMT+01:00 Davanum Srinivas :
> fyi https://review.openstack.org/#/c/247677/

That's not the right answer to Rochelle's plea :)
It was actually already answered by Matt, with a suggestion that
_Kilo_ grenade job could simply checkout 2014.2.4 tag instead of
stable/juno and for that we don't need to keep branches around.

Cheers,
Alan

__
OpenStack Development Mailing 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][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Alan Pevec]

> So we were brainstorming this with Rocky the other night. Would this be 
> possible to do by following:
> 1) we still tag juno EOL in few days time
> 2) we do not remove the stable/juno branch

Why not?

> 3) we run periodic grenade jobs for kilo

>From a quick look, grenade should work with a juno-eol tag instead of
stable/juno, it's just a git reference.
"Zombie" Juno->Kilo grenade job would need to set BASE_DEVSTACK_BRANCH=juno-eol
and for devstack all $PROJECT_BRANCH=juno-eol (or 2014.2.4 should be
the same commit).
Maybe I'm missing some corner case in devstack where stable/* is
assumed but if so that should be fixed anyway.
Leaving branch around is a bad message, it implies there support for
it, while there is not.

Cheers,
Alan

__
OpenStack Development Mailing 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] [stable] Call for testing: 2014.2.4 candidate tarballs

[Alan Pevec]

Hi all,

we are scheduled to publish 2014.2.4, last Juno point release,
on Thursday November 19th for Ceilometer, Cinder, Glance, Heat,
Horizon, Keystone, Neutron, Nova, Sahara and Trove.
Draft release notes are available at
https://wiki.openstack.org/wiki/ReleaseNotes/2014.2.4

We'd appreciate anyone who could test the candidate 2014.2.4 tarballs:

  http://tarballs.openstack.org/ceilometer/ceilometer-stable-juno.tar.gz
  http://tarballs.openstack.org/cinder/cinder-stable-juno.tar.gz
  http://tarballs.openstack.org/glance/glance-stable-juno.tar.gz
  http://tarballs.openstack.org/heat/heat-stable-juno.tar.gz
  http://tarballs.openstack.org/horizon/horizon-stable-juno.tar.gz
  http://tarballs.openstack.org/keystone/keystone-stable-juno.tar.gz
  http://tarballs.openstack.org/neutron/neutron-stable-juno.tar.gz
  http://tarballs.openstack.org/nova/nova-stable-juno.tar.gz
  http://tarballs.openstack.org/sahara/sahara-stable-juno.tar.gz
  http://tarballs.openstack.org/trove/trove-stable-juno.tar.gz


Thanks,
Alan

__
OpenStack Development Mailing 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] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Alan Pevec]

> Speaking of your "hacky" patch: yes and no. It makes the gate passing,
> it doesn't change the code itself. For most people, this will work fine.
>
> The right way to do it, would be to create a juno branch for doa and
> cap requirements there.
>
> How to do this? Is there a procedure to request a branch?

Let's not go there, I've approved "hacky" one.

Cheers,
Alan

__
OpenStack Development Mailing 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] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Alan Pevec]

> This is a call to stable-maint teams for Nova, Keystone, Glance,
> Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review
> open stable/juno changes[2] and approve/abandon them as appropriate.

CCing CPLs listed in
https://wiki.openstack.org/wiki/CrossProjectLiaisons#Stable_Branch

I got only ACK from Erno for Glance, anyone other project ready?


> [2] 
> https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z

AFAICT there are at least two blockers for 2014.2.4:
- horizon - django_openstack_auth issue Tony mentions in
https://review.openstack.org/172826
- nova - gate-grenade-dsvm-ironic-sideways failures e.g. in
https://review.openstack.org/227800


Cheers,
Alan

__
OpenStack Development Mailing 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] [stable] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Alan Pevec]

Hi,

while we continue discussion about the future of stable branches in
general and stable/juno in particular, I'd like to execute the current
plan which was[1]

2014.2.4 (eol) early November, 2015. release manager: apevec

Iff there's enough folks interested (I'm not) in keep Juno alive
longer, they could resurrect it but until concrete plan is done let's
be honest and stick to the agreed plan.

This is a call to stable-maint teams for Nova, Keystone, Glance,
Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to review
open stable/juno changes[2] and approve/abandon them as appropriate.
Proposed timeline is:
* Thursday Nov 12 stable/juno freeze[3]
* Thursday Nov 19 release 2014.2.1

Cheers,
Alan

[1] 
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Fjuno_releases_.2812_months.29

[2] 
https://review.openstack.org/#/q/status:open+AND+branch:stable/juno+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n,z

[3] documented  in
https://wiki.openstack.org/wiki/StableBranch#Stable_release_managers
TODO add in new location
http://docs.openstack.org/project-team-guide/stable-branches.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

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

[Alan Pevec]

>> The Stable Branch Policy, lets not put it in any repo.
>> Doing that would give indication that we expect changes into it and I'd 
>> prefer that policy mostly staying stable as well.

What indication did it give when it was in wiki? :)

> It actually already is in a repo:
> http://git.openstack.org/cgit/openstack/project-team-guide/tree/doc/source/stable-branches.rst

https://wiki.openstack.org/wiki/StableBranch should be replaced with
the link to it to avoid confusion.
There were changes since it was moved to the repo:
https://wiki.openstack.org/w/index.php?title=StableBranch=history
Which team approves the changes in the project-team-guide, can it be per file?

Regarding stable team spin-off, I think it's worth discussing further
to define exact scope, then see show of hands before formally setting
the team up as I'm afraid we don't have the critical mass yet.
I'm personally tied up with other obligations next few months so
cannot actively help or lead this initial effort.

Cheers,
Alan

__
OpenStack Development Mailing 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][release] 2015.1.2

[Alan Pevec]

2015-10-14 10:59 GMT+02:00 Thierry Carrez :
> Sean Dague wrote:
>> I think that whoever sets the tag should also push those fixes. We had
>> some kilo content bogging down the gate today because of this kind of
>> failure. Better to time this as close as possible with the tag setting.
>
> Right. The ideal process is to push the version bump and cut the tag
> from the commit just before that. That is how it's done on the main
> release when we start cutting the release branch at RC1.

I've now documented this step in StableReleaseBranch wiki:
https://wiki.openstack.org/w/index.php?title=StableBranchRelease=92628=92626

Cheers,
Alan

__
OpenStack Development Mailing 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] Do all OpenStack daemons support sd_notify?

[Alan Pevec]

Thanks for responding, does this make it longest by time duration
thread ever? :)

2015-10-15 22:44 GMT+02:00 Thomas Goirand <z...@debian.org>:
> On 12/16/2014 11:59 AM, Alan Pevec wrote:
...
>> Current implementation in oslo service sends notification only just
>> before entering the wait loop, because at that point all
>> initialization should be done and service ready to serve. Does anyone
>> have a suggestion for the better place where to notify service
>> readiness?
> What you describe above looks like a defect in the implementation. Of
> course, waiting for more than 90s should be considered as failed, and I
> wouldn't want in any case to have this timeout increased. Failed
> attempts to connect to Rabbit shouldn't, IMO, be the cause for not
> sending the notify signal.

But if service requires message bus for normal operations, it is not
ready to server requests, is it?

Cheers,
Alan

__
OpenStack Development Mailing 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][release] 2015.1.2

[Alan Pevec]

> For Horizon, it would make sense to move this a week back. We discovered
> a few issues in Liberty, which are present in current kilo, too. I'd
> love to cherry-pick a few of them to kilo.

What are LP bug#s ? Are you saying that fixes are still work in
progress on master and not ready for backporting yet?

> Unfortunately, it takes a bit, until Kilo (or in general: stable)
> reviews are being done.

One suggestion how to speed up reviews of such patch series:
put them all under the same topic for an easy gerrit URL, then ping on
#openstack-stable.
Stable backport reviews are supposed to be done primarily by
per-project stable-maint teams but stable-maint-core could also help.

Cheers,
Alan

__
OpenStack Development Mailing 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] Patches coming for .coveragerc

[Alan Pevec]

2015-09-21 16:12 GMT+02:00 Monty Taylor :
> We're running a script right now to submit a change to every project with
> this change. The topic will be coverage-v4

stable/kilo has uncapped coverage>=3.6 do we patch-spam it or cap coverage?
stable/juno has coverage>=3.6,<=3.7.1

Cheers,
Alan

__
OpenStack Development Mailing 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] [stable] 2015.1.2 readiness check WAS : gate-trove-functional-dsvm-mysql needs some stable branch love

[Alan Pevec]

>> [1] https://bugs.launchpad.net/trove-integration/+bug/1479358
>> [2] https://review.openstack.org/#/c/207193/

This fix has been merged and bug closed but Trove on stable/kilo is
not green yet, summary from
https://etherpad.openstack.org/p/stable-tracker
* Trove
 * various proboscis.case.MethodTest errors
 * Mock issues too, some fixed (but not all) at
https://review.openstack.org/202015 MERGED but
periodic-trove-python27-kilo is still failing:
  * 
http://logs.openstack.org/periodic-stable/periodic-trove-python27-kilo/3a6b8c7/console.html

In https://wiki.openstack.org/wiki/StableBranchRelease#Rinse.2C_Repeat
we have planned 2015.1.2  mid-September, 2015
are we ready to freeze stable/kilo now?

Cheers,
Alan

__
OpenStack Development Mailing 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] [requirements] attention requirements-cores, please look out for constraints updates

[Alan Pevec]

> I'd like to add in a lower-constraints.txt set of pins and actually
> start reporting on whether our lower bounds *work*.

Do you have a spec in progress for lower-constraints.txt?
It should help catch issues like https://review.openstack.org/221267
There are also lots of entries in global-requirements without minimum
version set while they should:
http://git.openstack.org/cgit/openstack/requirements/tree/README.rst#n226

Cheers,
Alan

__
OpenStack Development Mailing 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] [depfreeze] [keystone] Set minimum version for passlib

[Alan Pevec]

Hi all,

according to https://wiki.openstack.org/wiki/DepFreeze I'm requesting
depfreeze exception for
https://review.openstack.org/221267
This is just a sync with reality, copying Javier's description:

(Keystone) commit a7235fc0511c643a8441efd3d21fc334535066e2 [1] uses
passlib.utils.MAX_PASSWORD_SIZE, which was only introduced to
passlib in version 1.6

Cheers,
Alan

[1] https://review.openstack.org/217449

__
OpenStack Development Mailing 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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Alan Pevec]

 The only alternative seems to be to have on-demand stable-branch
 tagging. The main drawbacks of that option are that consumers of the
 stable branch are unnecessarily limited to specific tagged commits, and
 depend on various project teams to remember to push them.

As Doug suggested,  stable releases would be triggered by submitting a
patch to the releases
repository, so maybe we could be auto-generating release proposals
periodically (monthly, weekly?) as a reminder to the team if there
hasn't been a release in that period?
Also OSSA merge could trigger an async release proposal too.

Cheers,
Alan

__
OpenStack Development Mailing 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] [swift] swift memory usage in centos7 devstack jobs

[Alan Pevec]

 2) Should this also be sent to centos-devel folks so that they don't
 upgrade/update the pyopenssl in their distro repos until the issue
 is resolved ?


 I think let's give the upstream issues a little while to play-out,
 then we decide our next steps around use of the library based on that
 information.

pyOpenSSL was bumped to 0.14 https://review.openstack.org/197986
does it work now on EL7 ?

Cheers,
Alan

__
OpenStack Development Mailing 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] [pbr] [stable] [infra] How to generate .Z version increments on stable/liberty commits

[Alan Pevec]

To give you an idea, if we enabled that for Kilo we'd be at Nova 
11.0.80
(kilo) and Nova 10.0.218 (juno).
   I am not a fan of doing this second option at all. We would be polluting
   the ref space of our repos with redundant information making the output
   of `git tag` unusable to humans. If this was not redundant info and a
   tag of 11.0.80 provided more information than a generated version of
   11.0.0.dev80 / 11.0.80 I think we could live with that, but it does not.

It actual does: auto-tagged commit means it passed our CI hence
project stands behind it.
PBR-generated Z-version could be just local change which has never
seen any CI yet.

 Using pbr to generate versions avoids that problem, but introduces the
 challenge of not being able to necessarily figure out which commit
 corresponds to a given version number from the outside. Say I want to
 check out version 11.0.80 for some reason (maybe .81 has a bug I don't
 want to deploy). How do I do that without a tag?

That also, PBR-generated version is not universally reproducible.

So what about making auto-tagging on stable branches optional for projects:
by default if project has a stable branch(es) they will get
auto-tagging but project could also opt-out and push X.Y.Z tags
themselves, via the same release process like Oslo and clients.


Cheers,
Alan

__
OpenStack Development Mailing 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/kilo (and master grenade) will be blocked until version bumps on kilo are merged

[Alan Pevec]

 Agreed, after 2015.1.2 version bumps are merged, I'll propose version=
 line removals on stable branches so this situation doesn't happen
 again.

 Err, no.

 Post-versioning means all projects use semantic rather than date-based
 version numbers, which happens starting with *liberty*. Remaining kilo
 and juno stable releases will still need to use pre-versioning.

Actually, post/pre doesn't make a difference on stable branches.
I tried locally on keystone stable/kilo and generated versions stay the same.

* current pre-version setup i.e. version = 2015.1.2 in setup.cfg
** commit 070b51603879f0f70f85f72e9e82126d1bb398ba Bump stable/kilo
next version to 2015.1.2
2015.1.2.dev1
** review 205130 rebased on top of 070b516 Bump...
2015.1.2.dev2

* post-version i.e. version = line removed from setup.cfg on top of
070b516 Bump...
commit fb9582acc739d7719da0f1cc5f29b9e24097e025
Author: Alan Pevec alan.pe...@redhat.com
Date:   Thu Jul 30 12:07:27 2015 +0200

Switch to post-versioning

Change-Id: Ie4758058672bdeff86147f796d53f602a65228f1

diff --git a/setup.cfg b/setup.cfg
index e8d84e3..da0edb9 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,6 +1,5 @@
 [metadata]
 name = keystone
-version = 2015.1.2
 summary = OpenStack Identity
 description-file =
 README.rst

2015.1.2.dev2

** review 205130 rebased on top of Switch to post-versioning
2015.1.2.dev3

And when I tag that commit locally:
$ git tag 2015.1.2
$ python ./setup.py --version
2015.1.2

Then one backport on top of that:
2015.1.3.dev1

So all is good and safe to remove version = lines from setup.cfg on
stable branches.

Cheers,
Alan

__
OpenStack Development Mailing 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/kilo (and master grenade) will be blocked until version bumps on kilo are merged

[Alan Pevec]

 The way we did it in the past was to push the setup.cfg version=2015.1.2
 bump BEFORE we tag, then once that is merged, tag the previous commit in
 history as 2015.1.1. That way you avoid the lockstep (and ensure no
 intermediary badly-versioned tarball can be produced).

 Any reason why that wouldn't work anymore ?

It should've worked but we didn't update the current stable release
procedure which I was following.
We have documented pushing tags in step
https://wiki.openstack.org/wiki/StableBranchRelease#Tag
and pushing version bumps only later, after Close bugs and Upload The Release:
https://wiki.openstack.org/wiki/StableBranchRelease#Rinse.2C_Repeat

Let's update this procedure since we still have few Kilo and Juno
point releases to be done.


Cheers,
Alan

__
OpenStack Development Mailing 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] [horizon] [stable] Freeze exception

[Alan Pevec]

 I would like to request for a freeze exception for the this bug:
 https://bugs.launchpad.net/horizon/+bug/1474618

 This is the patch:
 https://review.openstack.org/#/c/206184/

Too late for 2015.1.1, tags (except neutron) have been pushed but
certainly fine to merge to stable/kilo.

Cheers,
Alan

__
OpenStack Development Mailing 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/kilo (and master grenade) will be blocked until version bumps on kilo are merged

[Alan Pevec]

 I think pushing them up earlier would indeed make it easier for folk.

Indeed, but it's too late now.

 But its not as good as using post-versioniing :)

Agreed, after 2015.1.2 version bumps are merged, I'll propose version=
line removals on stable branches so this situation doesn't happen
again.


Cheers,
Alan

__
OpenStack Development Mailing 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]{kilo][glance] freeze exceptions

[Alan Pevec]

 We have been waiting python-cinderclient stable/kilo release for couple of
 weeks to be able to merge glance_store stable/kilo backports. Namigly:

 https://review.openstack.org/#/q/status:open+project:openstack/glance_store+branch:stable/kilo,n,z

 As Alan blocked them all, I’d like to ask everyone hold your horses with the
 2015.1.1 release until cinder gets their client released so we can fix the
 glance store for the release.

This was actually freeze script misfire, it matched glance substring.
glance_store was not part of point releases, same as clients and Oslo
libs are not, so I'll remove my -2s

BTW, what is the estimate for the cinderclient stable/kilo release?

Cheers,
Alan

__
OpenStack Development Mailing 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] [stable][kilo] Call for testing: 2015.1.1 candidate tarballs

[Alan Pevec]

Hi all,

We are scheduled to publish 2015.1.1 Kilo point releases,
on Thursday July 16th for Ceilometer, Cinder, Glance, Heat, Horizon,
Ironic, Keystone, Neutron, Nova, Sahara and Trove.

We'd appreciate anyone who could test the candidate 2015.1.1 tarballs, which
include all changes aside from any pending freeze exceptions:

  http://tarballs.openstack.org/ceilometer/ceilometer-stable-kilo.tar.gz
  http://tarballs.openstack.org/cinder/cinder-stable-kilo.tar.gz
  http://tarballs.openstack.org/glance/glance-stable-kilo.tar.gz
  http://tarballs.openstack.org/heat/heat-stable-kilo.tar.gz
  http://tarballs.openstack.org/horizon/horizon-stable-kilo.tar.gz
  http://tarballs.openstack.org/ironic/ironic-stable-kilo.tar.gz
  http://tarballs.openstack.org/keystone/keystone-stable-kilo.tar.gz
  http://tarballs.openstack.org/neutron/neutron-stable-kilo.tar.gz
  http://tarballs.openstack.org/nova/nova-stable-kilo.tar.gz
  http://tarballs.openstack.org/sahara/sahara-stable-kilo.tar.gz
  http://tarballs.openstack.org/trove/trove-stable-kilo.tar.gz

Thanks,
Alan

__
OpenStack Development Mailing 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] issues with beaker/centos7 job

[Alan Pevec]

2015-07-02 5:00 GMT+02:00 Ian Wienand iwien...@redhat.com:
 So I looked into this with Gilles, and that error is a red-herring
 (it's just saying the rdo repos don't create the presto/deltarpm
 stuff);

yep

 the real issue is when python-requests fails to install [1] a
 bit later due to [2] (mentioned in comments of [3]).

[2] is unrelated EL6 issue, job is running on EL7 + RDO Kilo repo

 So this is really a upstream packaging issue and not an issue with the
 nodepool images.

I could not reproduce on a clean centos7, so I'd like to grab nodepool
image to have a closer look:
https://bugs.launchpad.net/puppet-openstack/+bug/1470685/comments/1

Cheers,
Alan

__
OpenStack Development Mailing 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] issues with beaker/centos7 job

[Alan Pevec]

 I could not reproduce on a clean centos7, so I'd like to grab nodepool
 image to have a closer look

After having a closer look, I see that image has requests 2.7
installed from pypi which overwrites python-requests RPM installation
and wreaks havoc when trying to upgrade RPM.
I'm not sure why and where is pypi used during the image build but it
should not be installed system-wide on RPM system. If really needed,
install it in venv.

Cheers,
Alan

__
OpenStack Development Mailing 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] [stable] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

[Alan Pevec]

Hi all,

We are scheduled to publish 2014.1.5, last Icehouse point release,
on Thurs June 18th for Ceilometer, Cinder, Glance, Heat, Horizon,
Keystone, Neutron, Nova and Trove.

The list of issues fixed can be seen here:

  https://launchpad.net/ceilometer/+milestone/2014.1.5
  https://launchpad.net/cinder/+milestone/2014.1.5
  https://launchpad.net/glance/+milestone/2014.1.5
  https://launchpad.net/heat/+milestone/2014.1.5
  https://launchpad.net/horizon/+milestone/2014.1.5
  https://launchpad.net/keystone/+milestone/2014.1.5
  https://launchpad.net/neutron/+milestone/2014.1.5
  https://launchpad.net/nova/+milestone/2014.1.5
  https://launchpad.net/trove/+milestone/2014.1.5

We'd appreciate anyone who could test the candidate 2014.1.5 tarballs:

  http://tarballs.openstack.org/ceilometer/ceilometer-stable-icehouse.tar.gz
  http://tarballs.openstack.org/cinder/cinder-stable-icehouse.tar.gz
  http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz
  http://tarballs.openstack.org/heat/heat-stable-icehouse.tar.gz
  http://tarballs.openstack.org/horizon/horizon-stable-icehouse.tar.gz
  http://tarballs.openstack.org/keystone/keystone-stable-icehouse.tar.gz
  http://tarballs.openstack.org/neutron/neutron-stable-icehouse.tar.gz
  http://tarballs.openstack.org/nova/nova-stable-icehouse.tar.gz
  http://tarballs.openstack.org/trove/trove-stable-icehouse.tar.gz

Thanks,
Alan

__
OpenStack Development Mailing 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] Call for testing: 2014.1.5 (last Icehouse point release) candidate tarballs

[Alan Pevec]

   http://tarballs.openstack.org/glance/heat-stable-icehouse.tar.gz

copy-paste fail, this should be:

http://tarballs.openstack.org/glance/glance-stable-icehouse.tar.gz

__
OpenStack Development Mailing 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] Targeting icehouse-eol?

[Alan Pevec]

 let's release this last one (codename: Farewell ?) point release. I
 can do this next week after we finish pending reviews.

Remaining stable/icehouse reviews[1] have -2 or -1 except
https://review.openstack.org/176019 which I've asked
neutron-stable-maint to review.
Matt, anything else before we can tag 2014.1.5 and icehouse-eol ?

Cheers,
Alan

[1]
https://review.openstack.org/#/q/status:open+AND+branch:stable/icehouse+AND+%28project:openstack/nova+OR+project:openstack/keystone+OR+project:openstack/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+OR+project:openstack/horizon+OR+project:openstack/heat+OR+project:openstack/ceilometer+OR+project:openstack/trove%29,n,z

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

 The only issue is having a correct version number. Swift could well
 iterate after 20151, for example doing 20151.1 then 20151.2, etc.

Swift never had coordinated YEAR.N versions,
https://wiki.openstack.org/wiki/Swift/version_map
and they never released a version from their stable/* branches.
e.g. 2.2.1 and 2.2.2 are in Launchpad Series kilo
https://launchpad.net/swift/kilo
and were created from master branch, not stable/juno as one would expect.
I heard Swift team call them Juno version released during Kilo cycle
which confused me a lot but if you take into account that Swift master
is stable and always backward compatible, it does make sense.
In short, Swift is different enough so best not to force them into
coordinated point releases which is what we did.
And when you think of it more, Swift model should be the goal for all
OpenStack project: stable master, always backward compatbile, no
upgrade issues = no need for stable/* branches :)

 So we could do what you're asking (option B) for Kilo stable releases,
 but I think it's not really a viable option for stable/liberty onward.

 I fail to understand how version numbers are related to doing
 synchronized point releases. Sure, we have a problem with the version
 numbers, but we can still do a point release of all the server projects
 at once.

I don't see what value does the same tag across certain set of projects bring?
Taking it to the extreme, why don't you put the same version across
all packages in a distro?
Reality is that each openstack is independent and compatibility among
them is ensured by CI not by using the coordinated version tags.

 FYI, after a CVE, I have uploaded cinder with this version number:
 2015.1.0+2015.06.06.git24.493b6c7f12-1

And with modified[*] plan D it would be 2015.1.25

 IMO, it looks ugly, and not comprehensive to Debian users. If I really
 have to go this way, I will, but I would have  not to.

You don't, if you'd support planD :)

 Though there's now zero guidance at what should be the speed of
 releasing server packages to our users.

Why there should be any guidance from upstream? Let your users tell
you and with planD you can update whenever requested fix is merged on
stable!

 So I totally get that we should still have reference points to be able
 to tell this is fixed in openstack/nova stable/liberty starting with
 12.1.134post34 (or whatever we settle with). I totally get that any of
 those should ship with relevant release notes. But that's about all I
 think we need ?

 That's not a little thing that you're pointing at: having reference
 points is very important. But yeah, it may be the only thing... Like
 we will only loose track of what is fixed in which version. :(

On the contrary, with planD you'd have reference points and lots of them :)
And release notes would be generated from commit messages - this
requires better commit messages on stable branches but that's always
good. Here's how it would look like for current Cinder stable/kilo:
CHANGES
===

2015.1.25
-

* Disallow backing files when uploading volumes to image

2015.1.24
-

* Dispose DB connections between backend proc starts

2015.1.23
-

* Allow provisioning to reach max oversubscription
...

Cheers,
Alan


[*] modified plan D: automatically sign and push git tag after each
commit on stable branch. We get both, tags and tarballs in one go.

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

2015-06-06 19:08 GMT+02:00 Ian Cordasco ian.corda...@rackspace.com:
 Not exactly. PBR/OpenStack follow SemVer and 2015.1.0.38 isn't valid
 SemVer (http://semver.org/)

Right, so semver compatible versioning on stable/kilo would be 2015.1.N
but PBR doesn't support that.

 If we want to be pedantic about the version numbers generated by PBR (at the 
 gate, in tox, etc.), it should be next version number.devN

That's what PBR does now, even for projects without version in
setup.cfg, it assumes MAJOR.MINOR.PATCH++ from the last tag on the
branch.

Cheers,
Alan

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

 and *Plan D* would be to start doing automatic per-project
 micro-versions on each commit: e.g. 2015.1.N where N is increased on
 each commit.

 How do you gpg sign these tags? I hope the solution isn't to store a key
 in infra without a passphrase.

Plan D doesn't include git tags, 2015.1.N would be generated by PBR
automatically.

 FYI, I don't use tarballs (just git), and generate my own orig.tar.xz
 out of a signed git tag, so I am not affected by this.

We could generate it too but upstream SourceURL is preferred[1] so it
can be easily verified.
BTW there's an issue re. verification that
https://tarballs.openstack.org/ is using cert for
security.openstack.org but should be easily fixed by infra.


Cheers,
Alan

[1] https://fedoraproject.org/wiki/Packaging:SourceURL

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

 How do you check if project X in version n works with project Y in
 version m, using this non-scheduled point release free for all model?

That was an illusion of point releases, as Thierry said there wasn't
significantly more testing and I don't remember any testing reports
during stable freeze periods.
All we had was upstream CI testing, but that's what we get for every commit.

 Why every 2 weeks? Why every month?

Sure, no problem, every distro can update whenever it works for them,
what is important for me is that we have a common reference points.
With plan D that would be automatically generated maj.min.N where N is
the number of commits since maj.min tag which doesn't depend on
anyone's manually pushing git tag.

 Not synchronizing brings a bunch of problems. The only problem raised by
 synchronous point releases is we don't have enough resources, which I
 fail to understand, given how cheap it is to tag a release. If the
 release managers don't have enough time to do so, it is my view that
 it's ok to give this power to individual projects. But that's orthogonal
 to having synchronous point releases.

Tag is indeed cheap, this is more about reflecting reality and not
keeping this synchronized illusion alive.
BTW point release process is more[1] than just pushing signed git tag,
the most time consuming work is cats herding (i.e. pushing for reviews
before the freeze) and Launchpad pruning.
The former was hopeless and will be even more with big-tent and the
latter we should avoid by automatically generated changelog.

Cheers,
Alan

[1] https://wiki.openstack.org/wiki/StableBranchRelease

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

 If the downsteam consumer has their own extra patches ontop of the
 stable branch, then it seems D is even less useful than A.

It is not - downstream (speaking for RDO) I would keep Version:
2015.1.N where N is stable patch# so that we have a common reference
point with other distros.
Our patches, if any, then come on top this, so it's clear which
patches are added by distro.

Cheers,
Alan

__
OpenStack Development Mailing 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] Targeting icehouse-eol?

[Alan Pevec]

 The only open question I have is if we need to do an Icehouse point release
 prior to the tag and dropping the branch, but I don't think that's happened
 in the past with branch end of life - the eol tag basically serves as the
 placeholder to the last 'release'.

 I don't think we need to do a point release, there will be the icehouse-eol
 tag which will mark the same thing. But, even if we later decide to add a
 point release to mark the same thing it is trivial to push another tag for
 the same sha1.

 I CC-ed the stable branch release managers for their opinion on it. We
 definitely announced a 2014.1.5 last icehouse release, so I think we
 should probably do one. Ideally we would have time to coordinate it in
 the coming week so that both plans are compatible.

Based on previoius 15 months plan, 2014.1.5 was targeting July 2015,
so releasing it next week would be close enough:
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Ficehouse_releases

I'm not sure if release machinery would work after removing the branch
so let's release this last one (codename: Farewell ?) point release. I
can do this next week after we finish pending reviews.

Cheers,
Alan

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

 You will get different checksums with tar and/or gzip, you can check the
 extracted files and they should be the same.

Yes, content is the same, it's just difference in timestamps of
folders and generated files (ChangeLog, egg-info etc).

 I would like to see signed commits in the 'official' repos (at
 git.openstack.org), if only because relying on sha alone doesn't seem
 enough for some.

Yeah, maybe RPM and I are just too old and should drop reproducibility
requirement :)
It might be nitpicking to expect exact same bits but it seems that
only missing part is an option to tell sdist to set specific timestamp
on generated files and folders.


Cheers,
Alan

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

 One issue is how would we provide source tarballs, statically hosting
 tarballs for each and every micro version is not realistic, also those
 wouldn't be signed.

 Sorry, but why isn't it realistic, and why wouldn't they be signed?

I thought storage requirements to generate tarball for each commit for
each project is unrealistic but infra could tell.
Re. signing - I was judging from current stable release procedure[*]
where tarballs are manually signed by the release manager before
upload to Launchpad.


Cheers,
Alan

[*] https://wiki.openstack.org/wiki/StableBranchRelease#Upload_The_Release

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

 *Plan C* would be to just let projects tag stable point releases from
 time to time. That would solve all the original stated problems. And
 that would solve objections 2 and 3, which I think are the most valid ones.

and *Plan D* would be to start doing automatic per-project
micro-versions on each commit: e.g. 2015.1.N where N is increased on
each commit. There's just TBD item how to provide source tarballs for
this.
This would solve 3. reference points for OSSAs and relnotes.
Solution for 2. could be to add doc/source/release-notes.rst for each
project wishing to maintain it, docs are already published for each
branch e.g. http://docs.openstack.org/developer/keystone/kilo/

Cheers,
Alan

__
OpenStack Development Mailing 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] No longer doing stable point releases

[Alan Pevec]

2015-05-29 18:30 GMT+02:00 Jeremy Stanley fu...@yuggoth.org:
 On 2015-05-29 16:30:12 +0100 (+0100), Dave Walker wrote:
 This is generally my opinion as-well, I always hoped that *every*
 commit would be considered a release rather than an arbitrary
 tagged date.
 [...]

 If we switch away from lockstep major/minor release versioning
 anyway (again separate discussion underway but seems a distinct
 possibility) then I think the confusion over why stable point
 releases are mismatched becomes less of an issue. At that point we
 may want to reconsider and actually tag each of them with a
 sequential micro (patch in semver terminology) version bump. Could
 help in communication around security fixes in particular.

Yes, if dropping stable point releases, sub-version schema is still
needed for clear communication in OSSAs and proposed continuous
releases notes.
One issue is how would we provide source tarballs, statically hosting
tarballs for each and every micro version is not realistic, also those
wouldn't be signed.
RPM packages traditionally expect pristine upstream tarballs which can
be verified and generating them from git is not reproducible e.g.
right now in nova stable/kilo branch:
python ./setup.py sdist
mv dist/nova-2015.1.1.dev20.tar.gz dist/nova-2015.1.1.dev20.tar.gz-TAKE1
python ./setup.py sdist
diff dist/nova-2015.1.1.dev20.tar.gz-TAKE1 dist/nova-2015.1.1.dev20.tar.gz
Binary files dist/nova-2015.1.1.dev20.tar.gz-TAKE1 and
dist/nova-2015.1.1.dev20.tar.gz differ

Before dropping point releases, I would like to have:
* idempotent sdist on the same SHA
* dynamic tarball generation service like github archive
* switch to micro-version i.e. current nova stable/kilo would be 2015.1.20


Cheers,
Alan

__
OpenStack Development Mailing 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] ERROR: openstackclient.shell Exception raised: python-keystoneclient 1.4.0

[Alan Pevec]

 This is a problem of dependency resolution rather than an issue of 
 keystoneclient specifically. You can see that glanceclient has a cap on 
 keystoneclient that the installed version doesn't meet.

python-keystoneclient=1.1.0,1.4.0 is requirement on
python-glanceclient stable/kilo branch,
while python-keystoneclient 1.4.0 is master. Are you using stable/kilo
or master devstack?
Problem is that openstackclient stable/kilo is missing requirements
caps so if installed earlier it will pull latest published on pypi
which is out of bounds for Kilo. https://review.openstack.org/174341
should fix that


Cheers,
Alan

__
OpenStack Development Mailing 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] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Alan Pevec]

 I'm working on removing mox in favor of mox3 to reduce a bit our dependency.

Then mox3 should be imported to openstack namespace as suggested by
Chuck in Dec 2013.
Looks like last known source repository is
https://github.com/emonty/pymox with last commit from Aug 2013 or did
it move somewhere else?


Cheers,
Alan

__
OpenStack Development Mailing 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] [swift] swift memory usage in centos7 devstack jobs

[Alan Pevec]

 I'll spend a bit more time on this -- I haven't determined if it's
 centos or swift specific yet -- but in the mean-time, beware of
 recent pyOpenSSL

But how come that same recent pyOpenSSL doesn't consume more memory on Ubuntu?


Alan

__
OpenStack Development Mailing 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] mox3 WAS Re: [nova] Do we have some guidelines for mock, stub, mox when writing unit test?

[Alan Pevec]

blast from the past...

2013-12-04 19:17 GMT+01:00 Chuck Short chuck.sh...@canonical.com:
 On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov ndipa...@redhat.com wrote:
...
 1) Figure out what is the deal with mox3 and decide if owning it will
 really be less trouble than porting nova. To be hones - I was unable to
 even find the code repo for it, only [3]. If anyone has more info -
 please weigh in. We'll also need volunteers


 Monty and I did this last cycle, its apart of the openstack project,
 although its not available in gerrit. Which should be fixed so we can start
 getting bug fixes in for it.

Looks like this was not done, last pypi upload was mox3-0.7.0.tar.gz
on 2013-08-15 by owner openstackci but I don't see it in
https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/projects.yaml
?

There was a bug reported about py34 incompatibility which was worked
around in one specific project, but oslotest has a dependency on mox3
so I moved it to oslotest
https://bugs.launchpad.net/oslotest/+bug/1403214

What's the status of migration to mock, can mox and mox3 be dropped
from global-requirements ?


Cheers,
Alan

__
OpenStack Development Mailing 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] [stable] Icehouse 2014.1.4 freeze exceptions

[Alan Pevec]

Hi,

next Icehouse stable point release 2014.1.4 has been slipping last few
weeks due to various gate issues, see Recently closed section in
https://etherpad.openstack.org/p/stable-tracker for details.
Branch looks good enough now to push the release tomorrow (Thursdays
are traditional release days) and I've put freeze -2s on the open
reviews.
I'm sorry about the short freeze period but branch was effectively
frozen last two weeks due to gate issues and further delay doesn't
make sense.
Attached is the output from the stable_freeze script for thawing after
tags are pushed.

At the same time I'd like to propose following freeze exceptions for
the review by stable-maint-core:

* https://review.openstack.org/144714 - Eventlet green threads not
released back to pool
  Justification: while not OSSA fix, it does have SecurityImpact tag

* https://review.openstack.org/163035 - [OSSA 2015-005] Websocket
Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259)
  Justification: pending merge on master and juno


Cheers,
Alan


stable_freeze.txt-2014.1.4
Description: Binary data
__
OpenStack Development Mailing 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] Testtools 1.7.0 may error if you installed it before reading this email

[Alan Pevec]

 So, we can work around this in devstack, but it seems like there is a
 more fundamental bug here that setup project isn't following dependencies.

Dep chain was: testtools (from
zake=0.1-tooz=0.12,=0.3-ceilometer==2014.2.3.dev2)
Unneeded _runtime_ dependency on testtools was removed in
https://github.com/yahoo/Zake/commit/215620ca51c3c883279ba62ccc860a274219ecc1

 Is this just another 'pip is drunk' issue in it not actually satisfying
 requirements?

Seems that pip is drunk by design, clarkb explained that pip only
updates deps if you pass the --upgrade flag.


Cheers,
Alan

__
OpenStack Development Mailing 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] Testtools 1.7.0 may error if you installed it before reading this email

[Alan Pevec]

 The wheel has been removed from PyPI and anyone installing testtools
 1.7.0 now will install from source which works fine.

On stable/icehouse devstack fails[*] with
pkg_resources.VersionConflict: (unittest2 0.5.1
(/usr/lib/python2.7/dist-packages),
Requirement.parse('unittest2=1.0.0'))
when installing testtools 1.7.0

unittest2 is not capped in stable/icehouse requirements, why is it not
upgraded by pip?


Cheers,
Alan


[*] e.g. 
http://logs.openstack.org/14/144714/3/check/check-tempest-dsvm-neutron/4d195b5/logs/devstacklog.txt.gz

__
OpenStack Development Mailing 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] [neutron] New version of python-neutronclient release: 2.3.11

[Alan Pevec]

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

 Do you know where it ends ? We could set up Depends lines on those
 requirements stable/* reviews and line them up so that they are ready to
 merge when openstackclient is fixed in devstack.

Alternative workaround is https://review.openstack.org/157654 which is
blocked on swift-dsvm-functional issue fixed by
https://review.openstack.org/157670 which is blocked on neutronclient
i.e. we got a cyclic dep here which will require ninja merge to
resolve.

I suggest to start with ninja merging 157670 which looks the most innocent.

Once we get icehouse working again we can look at backporting venv
patch series to devstack icehouse.


Cheers,
Alan

__
OpenStack Development Mailing 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] [neutron] New version of python-neutronclient release: 2.3.11

[Alan Pevec]

 (I believe the version cap for icehouse 2.4 is expected to a policy like 
 this).

Yes, that assumed Semantic Versioning (semver.org) which 2.3.11 broke.


Cheers,
Alan

__
OpenStack Development Mailing 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] Lets keep our community open, lets fight for it

[Alan Pevec]

 I think there's a place for
 private conversation (eg. discussing a security issue that corresponds
 to a CVE...

 CVE's are a special exception and I'd even argue on the need of
 private conversations there.

Discussing CVEs in private came up few times but I'm not sure IRC is
secure enough for that.
IMHO discussion about embargoed issues must  be kept in private
Launchpad bugs but I'd like to hear from VMT team.


Cheers,
Alan

__
OpenStack Development Mailing 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] juno is fubar in the gate

[Alan Pevec]

  Tracking etherpad:
  https://etherpad.openstack.org/p/wedged-stable-gate-feb-2015

BTW there is a tracking etherpad updated by
https://wiki.openstack.org/wiki/StableBranch#Stable_branch_champions
https://etherpad.openstack.org/p/stable-tracker
linked in https://wiki.openstack.org/wiki/StableBranch#Gate_Status and
announced on this list
http://lists.openstack.org/pipermail/openstack-dev/2015-January/05.html

From crossed items in Recently closed section you can see that
branch champions have been busy.

 You are missing the fact that a bunch of us (Matt Treinish, myself and
 others) are frustrated by the fact that we end up fixing stable branches
 whenever they break because we touch tempest, grenade and other projects
 that require working stable branches. But we do not want to be working on
 stable branches ourselves.  I begrudgingly stepped up to work on pinning all
 requirements on stable branches, to reduce the number of times stable
 branches break and ruin my day. But my plan to cap dependencies has been
 delayed several times by stable branches breaking again and again, along
 with unwinding undesired behaviors in our testing harnesses.

 Most recently, stable/juno grenade broke on February 4th (due to the release
 of tempest-lib 0.2.0). This caused bug

So that's a change in tooling, not stable branch itself. Idea when 15
months for Icehouse was discussed was that branchless Tempest would
make it easier, but now it turns out that's making both tooling and
stable branch unhappy.

 What I expect to happen when issues like this arise is interested parties
 work together to fix things and be proactive and make stable testing more
 robust. Instead we currently have people who have no desire to work on
 stable branches maintaining them.

At least parts of stable team have been pro-active (see above
etherpad) but I guess we have a communication issue here: has
anyonetried to contact stable branch champions (juno=Adam,
icehouse=Ihar) and what exactly do you expect stable team to do?
AFAICT these are all changes in tooling where stable-maint is not core
(devstack, tempest)...

BTW Icehouse 2014.1.4 was planned[*] for Feb 19 with freeze starting
on Feb 12, I'll delay it for now until we sort the current situation
out.


Cheers,
Alan


[*] 
https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.2Ficehouse_releases

__
OpenStack Development Mailing 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] django-openstack-auth and stable/icehouse

[Alan Pevec]

 Dependencies in requirements.txt do not seem to be used in
 stable/icehouse gate jobs, recent pip freeze in stable/icehouse
 shows: ... oslo.config==1.6.0 # git sha 99e530e
 django-openstack-auth==1.1.9 # git sha 2079383

 It's because of this:

 2015-01-27 19:33:44.152 | Collecting oslo.config=1.4.0 (from
 python-keystoneclient=0.11.1-python-openstackclient=1.0.1)

 After that installs 1.6.0, consequent pip runs assume that 1.6.0 is
 always better than 1.4.0 and disregards version cap, hence does not
 downgrade the library.

 Should we finally cap versions for clients so that they don't fetch
 new library versions?

Clients are capped in stable/icehouse requirements but devstack in
gate seems to be installing them from git master (note # git sha)


Cheers,
Alan

__
OpenStack Development Mailing 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] django-openstack-auth and stable/icehouse

[Alan Pevec]

 Bumping minimal oslo.config version due to the issue in
 django-openstack-auth seems like a wrong way to do it.

Dependencies in requirements.txt do not seem to be used in
stable/icehouse gate jobs, recent pip freeze in stable/icehouse shows:
...
 oslo.config==1.6.0 # git sha 99e530e
 django-openstack-auth==1.1.9 # git sha 2079383


Cheers,
Alan

__
OpenStack Development Mailing 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] Requirements.txt and optional requirements

[Alan Pevec]

 - Remove this requirement, no optional entries in requirements.txt, a
 'deployer' has to know what dependencies the components he wants to use have

Keystone is documenting its optional dependencies in test-requirements.txt
look for # Optional ... comments in
http://git.openstack.org/cgit/openstack/keystone/tree/test-requirements.txt


Cheers,
Alan

__
OpenStack Development Mailing 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] [barbican] python-barbicanclient 3.0.2 released

[Alan Pevec]

2015-01-29 19:31 GMT+01:00 Joe Gordon joe.gord...@gmail.com:
 That means clients need overlapping dependencies with the stable branches.
 I don't think this is a reasonable requirement, and am not sure what we gain 
 from it.

Capping all Oslo and clients on stable/juno was reverted[1] due to
issue with upgrades when you don't have overlap between master and
previous release, has that been resolved?


Cheers,
Alan

[1] https://review.openstack.org/138546

__
OpenStack Development Mailing 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] [stable] Stable check of openstack/nova failed - EnvironmentError: mysql_config not found

[Alan Pevec]

 - periodic-nova-docs-icehouse 
 http://logs.openstack.org/periodic-stableperiodic-nova-docs-icehouse/a3d88ed/ 
 : FAILURE in 1m 15s

Same symptom as https://bugs.launchpad.net/openstack-ci/+bug/1336161
which is marked as Fix released, could infra team check if all images
are alright?
This showed up in 3 periodic icehouse jobs over weekend, all on
bare-precise-hpcloud-b2 nodes, I've listed them in
https://etherpad.openstack.org/p/stable-tracker


Cheers,
Alan

__
OpenStack Development Mailing 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] Proposal to add Flavio Percoco to stable-maint-core

[Alan Pevec]

+2 Flavio knows stable branch policies very well and will be a good
addition to the cross-projects stable team.

Cheers,
Alan

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

Re: [openstack-dev] Do all OpenStack daemons support sd_notify?

[Alan Pevec]

2014-12-15 17:00 GMT+01:00 Clint Byrum cl...@fewbar.com:
 Excerpts from Ihar Hrachyshka's message of 2014-12-15 07:21:04 -0800:
 I guess Type=notify is supposed to be used with daemons that use
 Service class from oslo-incubator that provides systemd notification
 mechanism, or call to systemd.notify_once() otherwise.
...
 BTW now that more distributions are interested in shipping unit files
 for services, should we upstream them and ship the same thing in all
 interested distributions?

 Since we can expect the five currently implemented OS's in TripleO to all
 have systemd by default soon (Debian, Fedora, openSUSE, RHEL, Ubuntu),
 it would make a lot of sense for us to make the systemd unit files that
 TripleO generates set Type=notify wherever possible. So hopefully we can
 actually make such a guarantee upstream sometime in the not-so-distant
 future, especially since our CI will run two of the more distinct forks,
 Ubuntu and Fedora.

There's one issue with Type=notify that Dan Prince discovered and
where Type=simple works better for his use-case:
if service startup takes more than DefaultTimeoutStartSec (90s by
default) and systemd does not get notification from the service, it
will consider it failed and try to restart it if Restart is defined in
the service unit file.
I tried to fix that by disabling timeout (example in Nova package
https://review.gerrithub.io/13054 ) but then systemctl start blocks
until notification is received.
Copying Dan's review comment: This still isn't quite right. It is
better in that the systemctl doesn't think the service fails... rather
it just seems to hang indefinately on 'systemctl start
openstack-nova-compute', as in I never get my terminal back.
My test case is:
1) Stop Nova compute. 2) Stop RabbitMQ. 3) Try to start Nova compute
via systemctl.
Could the RabbitMQ retry loop be preventing the notification?


Current implementation in oslo service sends notification only just
before entering the wait loop, because at that point all
initialization should be done and service ready to serve. Does anyone
have a suggestion for the better place where to notify service
readiness?
Or should just Dan's test-case step 3) be modified as:
3) Start Nova compute via systemctl start ...   (i.e. in the background) ?


Cheers,
Alan

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

[openstack-dev] [stable] Re: Stable check of openstack/cinder failed

[Alan Pevec]

2014-12-06 7:14 GMT+01:00 A mailing list for the OpenStack Stable
Branch test reports. openstack-stable-ma...@lists.openstack.org:
 Build failed.

 - periodic-cinder-python26-icehouse 
 http://logs.openstack.org/periodic-stable/periodic-cinder-python26-icehouse/d19db38
  : FAILURE in 6m 50s
 - periodic-cinder-python27-icehouse 
 http://logs.openstack.org/periodic-stable/periodic-cinder-python27-icehouse/eeb5864
  : FAILURE in 5m 48s

Fixed by https://review.openstack.org/139791 - please review/approve.

Cheers,
Alan

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

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

[Alan Pevec]

2014-12-03 22:10 GMT+01:00 Ben Nemec openst...@nemebean.com:
 On 12/03/2014 02:45 PM, Sean Dague wrote:
 So this -
 https://github.com/openstack/oslo.messaging/commit/bcb3b23b8f6e7d01e38fdc031982558711bb7586
 was clearly a violation of our 1 cycle for deprecation of config options.

 I think that should be reverted, an oops release put out to fix it, and
 then deprecate for 1.6.

 +1.  That was definitely a no-no.

Filed as https://bugs.launchpad.net/oslo.messaging/+bug/1399085
Since this is blocking stable/juno I've pushed partial revert of
Revert Cap Oslo and client library versions
 https://review.openstack.org/138963
as a quickfix before the 2014.2.1 release today.
We'll of course need to revisit that, once oslo.messaging is fixed.

Cheers,
Alan

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

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

[Alan Pevec]

 I'd like to request another exception for Neutron to avoid introducing
 regression in hostname validation for DNS nameservers:
 https://review.openstack.org/#/c/139061/

Nice solution for this regression, I think it's worthy last-minute exception.
Should VMT also send this officially to the vendors as a followup to
OSSA 2014-039 ?

Cheers,
Alan

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

Re: [openstack-dev] [stable] Exception proposals for 2014.2.1

[Alan Pevec]

2014-12-04 23:00 GMT+01:00 Jay S. Bryant jsbry...@electronicjungle.net:
 Finally was able to get the master version through the gate and
 cherry-picked it here:
 https://review.openstack.org/#/c/139194/

 That one has made it through the check.  So, if it isn't too late, it could
 use a +2/+A.

Looks good and is exception worthy, approved.

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

Re: [openstack-dev] [oslo] oslo.messaging config option deprecation

[Alan Pevec]

 Filed as https://bugs.launchpad.net/oslo.messaging/+bug/1399085
 Since this is blocking stable/juno I've pushed partial revert of
 Revert Cap Oslo and client library versions
  https://review.openstack.org/138963
 as a quickfix before the 2014.2.1 release today.
 We'll of course need to revisit that, once oslo.messaging is fixed.

oslo.messaging 1.5.1 was released so we've revisited this on
#openstack-stable and instead of this quickfix pushed
https://review.openstack.org/#q,I6107b996d5da808c3222696a9549ee06c22f80b9,n,z
and 
https://review.openstack.org/#q,I47138da02c58073b03e3fb40537cc6f0b6a94a3c,n,z

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