Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-02-02 Thread Jeremy Stanley 
On 2016-01-30 12:54:50 + (+), Dave Walker wrote:
> Unless anyone else objects, I'd be really happy if you are willing to
> scp a handrolled tarball.

Since there have been no objections, I've generated the tarball and
wheel for ceilometer 2015.1.3 on a representative of the same host
types we use for the CI job which normally does this, and replicated
the steps tox would perform with the exception of downgrading to
pip<8 in the virtualenv first.

> I'm happy to help validate it's pristine-state locally here.

Please do! They're in the usual location at
https://tarballs.openstack.org/ceilometer/ and the checksums for
them are as follows...

md5sum:

a705892697b3ca97eaf4ccc39a013257 
/srv/static/tarballs/ceilometer/ceilometer-2015.1.3-py2-none-any.whl
2f6b10ad557dc524d494e7fa0b140e96 
/srv/static/tarballs/ceilometer/ceilometer-2015.1.3.tar.gz

sha256sum:

a84fd2b18f922be4b2aca7c89baf2153f9656ebe6791a9de37f56283f866645c 
/srv/static/tarballs/ceilometer/ceilometer-2015.1.3-py2-none-any.whl
465f8605639b36bbb86c3198a58ef3282e54546bc587c436db34cb613e1f2404 
/srv/static/tarballs/ceilometer/ceilometer-2015.1.3.tar.gz

-- 
Jeremy Stanley


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

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-02-01 Thread Thierry Carrez 

Jeremy Stanley wrote:

I'm perfectly okay uploading a tarball I or someone else builds for
this, as long as it's acceptable to leadership from stable branch
management, Telemetry and the community at large. Our infrastructure
exists to make things more consistent and convenient, but it's there
to serve us and so we shouldn't be slaves to it.


+1, sounds like the best option at this stage.

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-31 Thread gordon chung 


On 30/01/2016 7:54 AM, Dave Walker wrote:
> On 29 January 2016 at 20:36, Jeremy Stanley  wrote:
>> On 2016-01-29 19:34:01 + (+), gordon chung wrote:
>>> hmm.. that's unfortunate... anything we need to update so this doesn't
>>> happen again? or just a matter of lesson learned, let's keep an eye out
>>> next time?
>> Well, I backported the downloadcache removal to the stable/kilo
>> branch after discovering this issue, and while that's too late to
>> solve it for 2015.1.3 it will at least no longer prevent a 2015.1.4
>> tarball from being built.
>>
>>> i guess the question is can users wait (a month?) for next release? i'm
>>> willing to poll operator list (or any list) to query for demand if
>>> that's easier on your end? if there's very little interest we can defer
>>> -- i do have a few patches lined up for next kilo release window so i
>>> would expect another release.
>> I'm perfectly okay uploading a tarball I or someone else builds for
>> this, as long as it's acceptable to leadership from stable branch
>> management, Telemetry and the community at large. Our infrastructure
>> exists to make things more consistent and convenient, but it's there
>> to serve us and so we shouldn't be slaves to it.
> Unless anyone else objects, I'd be really happy if you are willing to
> scp a handrolled tarball.
>
> I'm happy to help validate it's pristine-state locally here.
>
> Thanks Jeremy!
>
> --
> Kind Regards,
> Dave Walker
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

this is fine with me. please let me know if there is anything i can do 
to help. thanks to both for all the work so far.

cheers,

-- 
gord


__
OpenStack Development Mailing 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][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-30 Thread Dave Walker 
On 29 January 2016 at 19:34, gordon chung  wrote:

>
> hmm.. that's unfortunate... anything we need to update so this doesn't
> happen again? or just a matter of lesson learned, let's keep an eye out
> next time?
>
> i guess the question is can users wait (a month?) for next release? i'm
> willing to poll operator list (or any list) to query for demand if
> that's easier on your end? if there's very little interest we can defer
> -- i do have a few patches lined up for next kilo release window so i
> would expect another release.
>
> cheers,
>

I'd like to think that in the new world order of proposing tags through
gerrit, rather than direct applying this could be avoided.

When Iapplied the tag locally, the current state of the branch did sdist
successfully.. but when jenkins tried to react to the pushed tag it was
non-buildable. This is yet another reason why directly applying tags
should burn.

Thanks

--
Kind Regards,
Dave Walker

__
OpenStack Development Mailing 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][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-30 Thread Dave Walker 
On 29 January 2016 at 20:36, Jeremy Stanley  wrote:
> On 2016-01-29 19:34:01 + (+), gordon chung wrote:
>> hmm.. that's unfortunate... anything we need to update so this doesn't
>> happen again? or just a matter of lesson learned, let's keep an eye out
>> next time?
>
> Well, I backported the downloadcache removal to the stable/kilo
> branch after discovering this issue, and while that's too late to
> solve it for 2015.1.3 it will at least no longer prevent a 2015.1.4
> tarball from being built.
>
>> i guess the question is can users wait (a month?) for next release? i'm
>> willing to poll operator list (or any list) to query for demand if
>> that's easier on your end? if there's very little interest we can defer
>> -- i do have a few patches lined up for next kilo release window so i
>> would expect another release.
>
> I'm perfectly okay uploading a tarball I or someone else builds for
> this, as long as it's acceptable to leadership from stable branch
> management, Telemetry and the community at large. Our infrastructure
> exists to make things more consistent and convenient, but it's there
> to serve us and so we shouldn't be slaves to it.

Unless anyone else objects, I'd be really happy if you are willing to
scp a handrolled tarball.

I'm happy to help validate it's pristine-state locally here.

Thanks Jeremy!

--
Kind Regards,
Dave Walker

__
OpenStack Development Mailing 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][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-29 Thread gordon chung 


On 28/01/2016 3:37 PM, Jeremy Stanley wrote:
> On 2016-01-28 19:40:20 + (+), Dave Walker wrote:
> [...]
>> However, pip 8 was released around the same time as the tarballs were
>> attempted to be generated.  Most of the projects are OK with this, but
>> ceilometer declares pbr!=0.7,<1.0,>=0.6 and then forces an update via
>> tox.
> [...]
>
> More to the point, the latest pbr matching that requirement (0.11.1)
> declares an unversioned dependency on pip in its requirements.txt,
> so ceilometer 2015.1.2's tox.ini is effectively forcing pip to
> upgrade itself to latest (8.x) release which no longer supports a
> command line option the tox.ini is also configured to add
> (--download-cache), making the sdist unbuildable via tox at that
> tagged point in the ceilometer repository.
trying to understand the situation here. isn't this all managed by 
global-reqs? an incompatible pip and pbr were release so now we can't 
build? were we the only project using downloadcache (i don't recall us 
doing anything unique in our tox file)?

i would prefer a release to be made as there was a performance backport 
made. what is the effort required to push tarball generated outside of 
jenkins? any drawbacks? do we have numbers on how often stable releases 
are picked up by users?

cheers,

-- 
gord


__
OpenStack Development Mailing 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][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-29 Thread Jeremy Stanley 
On 2016-01-29 14:14:48 + (+), gordon chung wrote:
> trying to understand the situation here. isn't this all managed by
> global-reqs? an incompatible pip and pbr were release so now we
> can't build? were we the only project using downloadcache (i don't
> recall us doing anything unique in our tox file)?

The tox.ini for Ceilometer stable/kilo was adding a downloadcache
inherited by all its environments which caused tox to add
--download-cache to all pip install invocations. While deprecated in
pip 6 (and removed from the tox.ini during the Liberty cycle), this
worked up until pip 8 dropped that option from its command-line
parser. Due to unfortunate timing, the last commit on stable/liberty
was tested with pip 7 and merged, but the 2015.1.2 tag for that
commit was pushed after pip 8 was released and so tox was no longer
able to work with the tagged commit.

A number of workarounds were tried, but ultimately the explicit
addition of -U (upgrade) to pip calls in tox.ini prevented my
attempts to temporarily pin to earlier versions of pip within the
calling script.

> i would prefer a release to be made as there was a performance
> backport made. what is the effort required to push tarball
> generated outside of jenkins? any drawbacks?
[...]

The steps followed by tox could be emulated manually, with the
addition of forcing a pip 7 install, and the result would then be
copied via scp to tarballs.openstack.org by one of our Infra root
admins. The drawbacks mostly come down to needing to apply some
additional scrutiny to the generated tarball before pronouncing it
viable, and the need to place trust in a manual process slightly
inconsistent with our usual sdist generation mechanisms.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-29 Thread gordon chung 


On 29/01/2016 1:27 PM, Jeremy Stanley wrote:
> On 2016-01-29 14:14:48 + (+), gordon chung wrote:
>> trying to understand the situation here. isn't this all managed by
>> global-reqs? an incompatible pip and pbr were release so now we
>> can't build? were we the only project using downloadcache (i don't
>> recall us doing anything unique in our tox file)?
> The tox.ini for Ceilometer stable/kilo was adding a downloadcache
> inherited by all its environments which caused tox to add
> --download-cache to all pip install invocations. While deprecated in
> pip 6 (and removed from the tox.ini during the Liberty cycle), this
> worked up until pip 8 dropped that option from its command-line
> parser. Due to unfortunate timing, the last commit on stable/liberty
> was tested with pip 7 and merged, but the 2015.1.2 tag for that
> commit was pushed after pip 8 was released and so tox was no longer
> able to work with the tagged commit.
>
> A number of workarounds were tried, but ultimately the explicit
> addition of -U (upgrade) to pip calls in tox.ini prevented my
> attempts to temporarily pin to earlier versions of pip within the
> calling script.
>
>> i would prefer a release to be made as there was a performance
>> backport made. what is the effort required to push tarball
>> generated outside of jenkins? any drawbacks?
> [...]
>
> The steps followed by tox could be emulated manually, with the
> addition of forcing a pip 7 install, and the result would then be
> copied via scp to tarballs.openstack.org by one of our Infra root
> admins. The drawbacks mostly come down to needing to apply some
> additional scrutiny to the generated tarball before pronouncing it
> viable, and the need to place trust in a manual process slightly
> inconsistent with our usual sdist generation mechanisms.

hmm.. that's unfortunate... anything we need to update so this doesn't 
happen again? or just a matter of lesson learned, let's keep an eye out 
next time?

i guess the question is can users wait (a month?) for next release? i'm 
willing to poll operator list (or any list) to query for demand if 
that's easier on your end? if there's very little interest we can defer 
-- i do have a few patches lined up for next kilo release window so i 
would expect another release.

cheers,

-- 
gord


__
OpenStack Development Mailing 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][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-29 Thread Jeremy Stanley 
On 2016-01-29 18:27:18 + (+), Jeremy Stanley wrote:
[...]
> Due to unfortunate timing, the last commit on stable/liberty was
> tested with pip 7 and merged, but the 2015.1.2 tag for that commit
> was pushed after pip 8 was released and so tox was no longer able
> to work with the tagged commit.
[...]

Apologies, just got home from another trip and am even more
addle-brained than usual. This was supposed to say, "...the last
commit on stable/kilo was tested with pip 7 and merged, but the
2015.1.3 tag for that commit..."
-- 
Jeremy Stanley

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

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-29 Thread Jeremy Stanley 
On 2016-01-29 19:34:01 + (+), gordon chung wrote:
> hmm.. that's unfortunate... anything we need to update so this doesn't
> happen again? or just a matter of lesson learned, let's keep an eye out
> next time?

Well, I backported the downloadcache removal to the stable/kilo
branch after discovering this issue, and while that's too late to
solve it for 2015.1.3 it will at least no longer prevent a 2015.1.4
tarball from being built.

> i guess the question is can users wait (a month?) for next release? i'm
> willing to poll operator list (or any list) to query for demand if
> that's easier on your end? if there's very little interest we can defer
> -- i do have a few patches lined up for next kilo release window so i
> would expect another release.

I'm perfectly okay uploading a tarball I or someone else builds for
this, as long as it's acceptable to leadership from stable branch
management, Telemetry and the community at large. Our infrastructure
exists to make things more consistent and convenient, but it's there
to serve us and so we shouldn't be slaves to it.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-28 Thread Jeremy Stanley 
On 2016-01-28 19:40:20 + (+), Dave Walker wrote:
[...]
> However, pip 8 was released around the same time as the tarballs were
> attempted to be generated.  Most of the projects are OK with this, but
> ceilometer declares pbr!=0.7,<1.0,>=0.6 and then forces an update via
> tox.
[...]

More to the point, the latest pbr matching that requirement (0.11.1)
declares an unversioned dependency on pip in its requirements.txt,
so ceilometer 2015.1.2's tox.ini is effectively forcing pip to
upgrade itself to latest (8.x) release which no longer supports a
command line option the tox.ini is also configured to add
(--download-cache), making the sdist unbuildable via tox at that
tagged point in the ceilometer repository.
-- 
Jeremy Stanley

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

[openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

2016-01-28 Thread Dave Walker 
Hi,

As many of you have probably seen, most of the projects targeted for
2015.1.3 release have been tagged and have tarballs ready for release.

However, pip 8 was released around the same time as the tarballs were
attempted to be generated.  Most of the projects are OK with this, but
ceilometer declares pbr!=0.7,<1.0,>=0.6 and then forces an update via
tox.

This has caused a delay across all the projects in announcing the
release.  Jeremy Stanley has been super useful in helping to pin-point
this (and another infra issue).. but now we are stuck.

This leaves us with bit of a pickle, and i'm looking for suggestions
how best we can move forward:

A few ideas are:
- stable/kilo is now fixed, so we could do another patch release which
would succeed (but ugly version numbering)
- rebuuild ceilometer from a separate PyPI mirror which lacks pip>=8 in the pool
- Manually push a tarball generated outside of Jenkins.
- Skip ceilometer for this release.

Any other ideas?

Thanks

--
Kind Regards,
Dave Walker

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