Re: [openstack-dev] [all] We're combining the lists!

2018-11-10 Thread Robert Collins
On Sat, 10 Nov 2018 at 23:03, Thierry Carrez  wrote:
>
> Robert Collins wrote:
> > There don't seem to be any topics defined for -discuss yet, I hope
> > there will be, as I'm certainly not in a position of enough bandwidth
> > to handle everything *stack related.
> >
> > I'd suggest one for each previously list, at minimum.
>
> As we are ultimately planning to move lists to mailman3 (which decided
> to drop the "topics" concept altogether), I don't think we planned to
> add serverside mailman topics to the new list.

Ah, fair enough, I'll unsubscribe from the new list then; If folk need
me, you know where to find me.

-Rob

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


Re: [openstack-dev] [all] We're combining the lists!

2018-11-09 Thread Robert Collins
On Sat, 10 Nov 2018 at 07:15, Jeremy Stanley  wrote:
>
> REMINDER: The openstack, openstack-dev, openstack-sigs and
> openstack-operators mailing lists (to which this is being sent) will
> be replaced by a new openstack-disc...@lists.openstack.org mailing
> list. The new list is open for subscriptions[0] now, but is not yet
> accepting posts until Monday November 19 and it's strongly
> recommended to subscribe before that date so as not to miss any
> messages posted there. The old lists will be configured to no longer
> accept posts starting on Monday December 3, but in the interim posts
> to the old lists will also get copied to the new list so it's safe
> to unsubscribe from them any time after the 19th and not miss any
> messages. See my previous notice[1] for details.
>
> For those wondering, we have 207 subscribers so far on
> openstack-discuss with a little over a week to go before it will be
> put into use (and less than a month before the old lists are closed
> down for good).

There don't seem to be any topics defined for -discuss yet, I hope
there will be, as I'm certainly not in a position of enough bandwidth
to handle everything *stack related.

I'd suggest one for each previously list, at minimum.

-Rob

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


Re: [openstack-dev] [all][requirements] a plan to stop syncing requirements into projects

2018-03-25 Thread Robert Collins
On 26 March 2018 at 09:08, Doug Hellmann  wrote:
> Excerpts from Doug Hellmann's message of 2018-03-25 16:04:11 -0400:
>> A few of the jobs failed because the dependencies were wrong. In a few
>> cases I was able to figure out what was wrong, but I can use some help
>> from project teams more familiar with the code bases to debug the
>> remaining failures.
>
> If you need to raise the lower bounds in a requirements file, please
> update that file as well as lower-constraints.txt in the patch. You may
> need to add a Depends-On for https://review.openstack.org/555402 in
> order to have a version specifier that is different from the value in
> the global requirements list.

Nice stuff; I'm so glad to see this evolution happening.

-Rob

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


Re: [openstack-dev] [oslo.db] [all] please DO NOT IMPORT from oslo_db.tests.* ! projects doing this need to revert ASAP

2018-02-20 Thread Robert Collins
On 20 February 2018 at 04:39, Andrey Kurilin  wrote:
> Can someone explain me the reason for including "tests" module into
> packages?

Namespacing the tests makes the test ids unique which is very helpful
for aggregating test data as we do. Including that in the tar.gz that
is uploaded to PyPI is pretty standard - a) its how you can verify
that what you downloaded works in your context (and no, going to git
is not a good answer there because that means you now need the entire
ecosystem of tools to build man pages etc etc etc). and b) its
providing the full source of the thing we're releasing. Thats you
know, how F/LOSS works.

It should be possible, if we care to, to exclude the tests from wheels
made from those distributions, which would make the footprint for
binary usage smaller - I have no strong opinion on whether thats wise
or not, but I will say I can't see a use case for needing the tests in
that scenario.

Similarly whether those tests should be included in Linux distribution
packages or not is a debate I don't care to enter - but again I don't
see a use case: binary distributions are presumed to be integration
tested by the distributor, not the consumers.

I don't think importing code from another packages 'tests' module is
wrong or right - python is very much a consenting-adults language -
but I do think that in OpenStack with the sheer number of people
involved we should set very clear guidance; and I'd suggest that
saying its not supported is a good default: if folk want to offer a
contract where something can be imported they can always put it in a
different package.

In summary:
 - moving 'tests' to the root is a poor idea, please don't do it - we
had this debate back in 2011 or so and nothing has changed that I can
see.
 - we can, and perhaps should, exclude $package.tests from wheels to
save bandwidth (but *not* from .tar.gz).
 - linux distributions should IMO follow what we put in wheels.

-Rob

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


Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

2017-02-02 Thread Robert Collins
On 3 Feb. 2017 16:14, "Robert Collins" <robe...@robertcollins.net> wrote:

This may help. http://jam-bazaar.blogspot.co.nz/2009/11/memory-
debugging-with-meliae.html

-rob


Oh, and if i recall correctly run snake run supports both heapy and meliae.

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


Re: [openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

2017-02-02 Thread Robert Collins
This may help.
http://jam-bazaar.blogspot.co.nz/2009/11/memory-debugging-with-meliae.html

-rob

On 3 Feb. 2017 10:39, "Armando M."  wrote:

>
>
> On 2 February 2017 at 13:36, Ihar Hrachyshka  wrote:
>
>> On Thu, Feb 2, 2017 at 7:44 AM, Matthew Treinish 
>> wrote:
>> > Yeah, I'm curious about this too, there seems to be a big jump in
>> Newton for
>> > most of the project. It might not a be a single common cause between
>> them, but
>> > I'd be curious to know what's going on there.
>>
>> Both Matt from Nova as well as me and Armando suspect
>> oslo.versionedobjects. Pattern of memory consumption raise somewhat
>> correlates with the level of adoption for the library, at least in
>> Neutron. That being said, we don't have any numbers, so at this point
>> it's just pointing fingers into Oslo direction. :) Armando is going to
>> collect actual memory profile.
>>
>
> I'll do my best, but I can't guarantee I can come up with something in
> time for RC.
>
>
>>
>> Ihar
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

2016-11-10 Thread Robert Collins
On 10 Nov 2016 9:29 PM, "Tony Breeds" <t...@bakeyournoodle.com> wrote:
>
> On Thu, Nov 10, 2016 at 08:48:16PM +1300, Robert Collins wrote:
>
> > We generate multiline constraints whenever versions are different
> > between python 2 and 3 for the same package. That was happening when I
> > wrote the tool in the first place - it was one of the reasons I wrote
> > edit-constraints, to avoid writing silly-awkward sed. (A multiline
> > constraint when sedd'd will error with 'requirement already supplied'
> > or whatever the pip error string is.
>
> Okay.  It's unlikley that we'll hit that case but not impossible.

Currently happening to dnspython3 right now :)

> > > I think the way forward is to get openstack_requirements on pypi so
we can just
> > > pip install openstack_requirements.
> > >
> > > That'd make the script simple and still retain the
cross-platform'ness needed.
> >
> > Yes. And/or do the long mooted refactoring to separate out the scripts
> > from the current constraints and requirements.
>
> Yup, that'll be part of it but a lower priority that the actual
publication.

+1

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


Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

2016-11-09 Thread Robert Collins
On 10 November 2016 at 11:00, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Thu, Nov 10, 2016 at 06:17:44AM +1300, Robert Collins wrote:
>> Sed doesn't exist on windows, whereas a python script can. Sed doesn't
>> handle multiple line constraints.
>
> I don't think that right now we care/handle multiline constraints but the
> windows think is important and not something I considered.

We generate multiline constraints whenever versions are different
between python 2 and 3 for the same package. That was happening when I
wrote the tool in the first place - it was one of the reasons I wrote
edit-constraints, to avoid writing silly-awkward sed. (A multiline
constraint when sedd'd will error with 'requirement already supplied'
or whatever the pip error string is.

> I think the way forward is to get openstack_requirements on pypi so we can 
> just
> pip install openstack_requirements.
>
> That'd make the script simple and still retain the cross-platform'ness needed.

Yes. And/or do the long mooted refactoring to separate out the scripts
from the current constraints and requirements.

-Rob

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


Re: [openstack-dev] [all][infra][requirements] Odd cases in requirements?

2016-11-09 Thread Robert Collins
Sed doesn't exist on windows, whereas a python script can. Sed doesn't
handle multiple line constraints.

Rob

On 10 Nov 2016 12:00 AM, "Ihar Hrachyshka"  wrote:

>
> > On 8 Nov 2016, at 04:07, Tony Breeds  wrote:
> >
> > On Sat, Sep 03, 2016 at 07:33:42PM +0200, Andreas Jaeger wrote:
> >> Reviewing all the constraints work, I see that repositories have created
> >> some workaround around requirements install for one of these two legimit
> >> reasons - most often using tools/tox_install.sh from tox.ini for it:
> >>
> >> 1) The repository is a dependency of another one and uses constraints,
> >> so edit upper-constraints file and allow git install.
> >>
> >> Example:
> >> http://git.openstack.org/cgit/openstack/ironic-lib/tree/
> tools/tox_install.sh
> >
> > We had a very brief discussion about this in Barcelona.  The idea being
> to
> > create an "incubator" style script in openstack/requirements that can be
> the
> > canonical source and easily copied out to repos that need it.  I'm not
> > proposing auto syncing but it would be pretty easy to script.
> >
> > We need "all projects"[1] to support constraints real soon now.  It
> seems like
> > the majority of projects that currently do not use constraints are
> because
> > they're also listed in constraints.
> >
> > I started looking at this today using [2] as the base in the
> oslo.messaging
> > repo  The good thing about this is it doesn't "just work"  I hit the
> following
> > problem:
> > ---
> > cmdargs: ['/home/stack/projects/openstack/openstack/oslo.
> messaging/tools/tox_install.sh', 'https://git.openstack.org/
> cgit/openstack/requirements/plain/upper-constraints.txt',
> '/home/stack/projects/openstack/openstack/oslo.messaging/.tox/dist/oslo.
> messaging-5.12.1.dev10.zip']
> > 
> > Processing ./.tox/dist/oslo.messaging-5.12.1.dev10.zip
> > Could not satisfy constraints for 'oslo.messaging': installation from
> path or url cannot be constrained to a version
> > ---
> >
> > This is because we use 'edit-constraints' to change
> "oslo.messaging===5.12.0" to
> > "-e file:///home/stack/projects/openstack/openstack/oslo.
> messaging#egg=oslo.messaging"[3]
> >
> > Which doesn't match because we're installing from an sdist.
> >
> > For development installs like this what we really want is a way to say
> > constrain all my requirements but allow this library to be unconstrained
> don't
> > we?  That seems to me what we're saying in [3].  When I'm working
> locally I do
> > something like:
> >
> > ---
> > pip install -c https://git.openstack.org/cgit/openstack/requirements/
> plain/upper-constraints.txt \
> >-r requirements.txt -r test-requirements.txt
> > pip install .
> > ---
> >
> > This is all leading me to think that we should just remove the
> constraint on
> > $library which can be done with something like:
> > --- [4]
> > #!/usr/bin/env bash
> >
> > # Client constraint file contains this client version pin that is in
> conflict
> > # with installing the client from source. We should remove the version
> pin in
> > # the constraints file before applying it for from-source installation.
> > BRANCH_NAME=XXX
> > CLIENT_NAME=XXX
> >
> > set -e
> >
> > CONSTRAINTS_FILE=$1
> > shift
> >
> > localfile="${VIRTUAL_ENV}/upper-constraints.txt"
> > if [[ $CONSTRAINTS_FILE != http* ]]; then
> >CONSTRAINTS_FILE=file://$CONSTRAINTS_FILE
> > fi
> >
> > curl $CONSTRAINTS_FILE -k -o $localfile
> > sed -i~ -e "/^${CLIENT_NAME}===/d" $localfile
> >
> > pip install -U -c$localfile $*
> > ---
> >
> > Using openstack_requirements is the "right" thing to do and we could
> still use
> > edit-constraints $localfile -- $CLIENT_NAME ""
> > do delete the entry but it seems like wasted work to me
>
> I believe sed is the way to go. There is not much we get from
> edit-constraints at this point, and it untangles the script from
> zuul-cloner that would be needed to fetch requirements repo.
>
> It seems like the way to go. Wanna propose a patch for a repo
> (oslo.messaging) to iterate on it in gerrit?
>
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [requirements][all] What does the future look like?

2016-10-25 Thread Robert Collins
I'm not in Barcelona, but am interested : please do try to capture
some prose around the resulting design for us there-in-spirit folk.

-Rob

On 26 October 2016 at 01:50, Tony Breeds  wrote:
> Hi All,
> I'd like to highlight a requirements session:
>
> https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16986/requirements-what-does-the-future-look-like
>
> The point of this session is to understand the pain points that several
> projects have with requirements management, discussion a proposed solution and
> get stakeholder buy-in/feedback.
>
> Please attend if you have strong opinions on this.
>
> The main topics will be "Divergent Requirements", which is allowing projects 
> to
> define *and test* the lower bounds that they support while still maintaining
> co-iinstallability
>
> With a follow-on topic brought up in [1]
>  * How to allow libraries to pip install . *and* use constraint[2]
>  * How to work with plugins / dependencies on upstream ie Horizon or 
> Neutron[3]
>
> Yours Tony.
>
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-September/102872.html
> [2] 
> http://git.openstack.org/cgit/openstack/ironic-lib/tree/tools/tox_install.sh
> [3] 
> http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/tools/tox_install.sh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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


Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

2016-09-01 Thread Robert Collins
On 31 August 2016 at 01:57, Clint Byrum  wrote:
>
>
> It's simple, these are the holy SQL schema commandments:
>
> Don't delete columns, ignore them.
> Don't change columns, create new ones.
> When you create a column, give it a default that makes sense.

I'm sure you're aware of this but I think its worth clarifying for non
DBAish folk: non-NULL values can change a DDL statements execution
time from O(1) to O(N) depending on the DB in use. E.g. for Postgres
DDL requires an exclusive table lock, and adding a column with any
non-NULL value (including constants) requires calculating a new value
for every row, vs just updating the metadata - see
https://www.postgresql.org/docs/9.5/static/sql-altertable.html
"""
When a column is added with ADD COLUMN, all existing rows in the table
are initialized with the column's default value (NULL if no DEFAULT
clause is specified). If there is no DEFAULT clause, this is merely a
metadata change and does not require any immediate update of the
table's data; the added NULL values are supplied on readout, instead.
"""

> Do not add new foreign key constraints.

What's the reason for this - if it's to avoid exclusive locks, I'd
note that the other rules above don't avoid exclusive locks - again,
DB specific, and for better or worse we are now testing on multiple DB
engines via 3rd party testing.

https://dev.launchpad.net/Database/LivePatching has some info from our
experience doing online and very fast offline patches in Launchpad.

-Rob

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


Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

2016-08-12 Thread Robert Collins
On 12 August 2016 at 12:09, Clay Gerrard  wrote:
>
>
> On Fri, Aug 12, 2016 at 11:52 AM, Andreas Jaeger  wrote:
>>
>> On 08/12/2016 08:37 PM, Clay Gerrard wrote:
>> >
>> > ... but ... it doesn't have a --install option?  Do you know if that is
>> > strictly out-of-scope or roadmap or ... ?
>>
>>
>> Right now we don't need it - we take the output and pipe that to yum/apt
>> etc...
>>
>> See
>>
>> http://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/scripts/install-distro-packages.sh
>>
>
> the -b option is great - thanks for the pointer!
>
>   -b, --brief   List only missing packages one per line.
>
> It should have been more obvious to me that it meant "you should totally use
> this as input into your package manager"!
>
> But, to be clear, when you say "we don't need it" - you *mean" - "yeah, we
> totally need it and added it as bash in a different project"?  ;)
>
> but also *not* strictly out-of-scope?  Or not sure?  Or patches welcome and
> we'll see!?  Or .. we can *both* continue to use our existing tools to solve
> this problem in the same way we always have?  :P

When I designed it it seemed more important to get a clear list than
to be able to drive package managers - it just limited the degree of
integration needed; that said I see no reason it can't be added if
folk find it useful - as long as we still keep the clean query UI :)

-Rob

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


Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

2016-08-12 Thread Robert Collins
Fantastic news Andreas!

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


Re: [openstack-dev] [Cinder] [stable] [all] Changing stable policy for drivers

2016-08-11 Thread Robert Collins
On 11 Aug 2016 3:13 PM, "Ben Swartzlander"  wrote:
>
> ...
>
> I still don't agree with this stance. Code doesn't just magically stop
working. Code breaks when things change which aren't version controlled
properly or when you have undeclared dependencies.

Well this is why the constraints work was and is being done. It's not
100%rolled out as far as I know though, and stable branch support feels all
the gaps.
__
OpenStack Development Mailing 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] Status of the OpenStack port to Python 3

2016-06-26 Thread Robert Collins
On 27 June 2016 at 13:20, Jens Rosenboom  wrote:
> 2016-06-22 9:18 GMT+02:00 Victor Stinner :
>> Hi,
>>
>> Current status: only 3 projects are not ported yet to Python 3:
>>
>> * nova (76% done)
>> * trove (42%)
>> * swift (0%)
>>
>>https://wiki.openstack.org/wiki/Python3
>
> How should differences between python3.4 and python3.5 be handled?

Like most minor version differences - write code that handles them.
The test in https://bugs.launchpad.net/neutron/+bug/1559191is overly
literal, since it depends on the string of the error from Python,
which is not a stable interface

-Rob

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


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

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

-Rob

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

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


Re: [openstack-dev] [requirements][all] VOTE to expand the Requirements Team

2016-06-17 Thread Robert Collins
Sure. +1

On 17 June 2016 at 02:44, Davanum Srinivas  wrote:
> Folks,
>
> At Austin the Release Management team reached a consensus to spin off
> with some new volunteers to take care of the requirements process and
> repository [1]. The following folks showed up and worked with me on
> getting familiar with the issues/problems/tasks (see [1] and [2]) and
> help with the day to day work.
>
> Matthew Thode (prometheanfire)
> Dirk Mueller (dirk)
> Swapnil Kulkarni (coolsvap)
> Tony Breeds (tonyb)
> Thomas Bechtold (tbechtold)
>
> So, please cast your VOTE to grant them +2/core rights on the
> requirements repository and keep up the good work w.r.t speeding up
> reviews, making sure new requirements don't break etc.
>
> Also, please note that Thierry has been happy enough with our work to
> step down from core responsibilities :) Many thanks Thierry for
> helping with this effort and guidance. I'll make all the add/remove to
> the requirements-core team when this VOTE passes.
>
> Thanks,
> Dims
>
> [1] https://etherpad.openstack.org/p/newton-relmgt-plan
> [2] https://etherpad.openstack.org/p/requirements-tasks
> [3] https://etherpad.openstack.org/p/requirements-cruft
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


Re: [openstack-dev] [all][tc] Require a level playing field for OpenStack projects

2016-06-15 Thread Robert Collins
This might come across a little trolly/devils advocate, but I mulled
on it for a few days, and I think I need to send it, so... fingers
crossed you can extract some value from my questions.

On 15 June 2016 at 01:57, Thierry Carrez  wrote:
> Hi everyone,
>
> I just proposed a new requirement for OpenStack "official" projects, which I
> think is worth discussing beyond the governance review:
>
> https://review.openstack.org/#/c/329448/
>
> From an upstream perspective, I see us as being in the business of providing
> open collaboration playing fields in order to build projects to reach the
> OpenStack Mission. We collectively provide resources (infra, horizontal
> teams, events...) in order to enable that open collaboration.
>
> An important characteristic of these open collaboration grounds is that they
> need to be a level playing field, where no specific organization is being
> given an unfair advantage.

Would it change your meaning if I added 'by OpenStack community /
infrastructure' there? If not, then it seems to me that e.g.
Rackspace, Dreamhost, and the other organisations that have deployed
scaled clouds have a pretty big advantage. If it does change your
meaning, then what really do you mean?

>  I expect the teams that we bless as "official" project teams to operate in 
> that fair manner. Otherwise we end up blessing
> what is essentially a trojan horse for a given organization, open-washing
> their project in the process. Such a project can totally exist as an
> unofficial project (and even be developed on OpenStack infrastructure) but I
> don't think it should be given free space in our Design Summits or benefit
> from "OpenStack community" branding.

We already have a mechanism - the undiverse tag - for calling out
projects that don't have diversity in their core. That seems to
overlap a lot here?

> So if, in a given project team, developers from one specific organization
> benefit from access to specific knowledge or hardware (think 3rd-party
> testing blackboxes that decide if a patch goes in, or access to proprietary
> hardware or software that the open source code primarily interfaces with),
> then this project team should probably be rejected under the "open
> community" rule. Projects with a lot of drivers (like Cinder) provide an
> interesting grey area, but as long as all drivers are in and there is a
> fully functional (and popular) open source implementation, I think no
> specific organization would be considered as unfairly benefiting compared to
> others.

So I read this paragraph as Its ok if many organisations have unfair
advantages, but its not ok if there is only one organisation with an
unfair advantage?

Consider a project with one open implementation and one organisation
funded proprietary driver. This would be a problem. But I don't
understand why it would be.

I *think* what you're trying to say is that 'if there is no open
implementation then there is a problem', but that seems self evident
(and the CDN orchestration question doesn't apply here, because the
/implementation/ was to be entirely open, and *noone* involved had any
more advantage - the folk proposing the team did not work for the CDN,
so everyone was on equal, if terrible, footing).

> A few months ago we had the discussion about what "no open core" means in
> 2016, in the context of the Poppy team candidacy. With our reading at the
> time we ended up rejecting Poppy partly because it was interfacing with
> proprietary technologies. However, I think what we originally wanted to
> ensure with this rule was that no specific organization would use the
> OpenStack open source code as crippled bait to sell their specific
> proprietary add-on.

I'm a huge +1 on not setting up such an open-core strategy in
OpenStack, but I'm really having trouble mapping the proposed ruleset
to the goal.

> I think taking the view that OpenStack projects need to be open, level
> collaboration playing fields encapsulates that nicely. In the Poppy case,
> nobody in the Poppy team has an unfair advantage over others, so we should
> not reject them purely on the grounds that this interfaces with
> non-open-source solutions (leaving only the infrastructure/testing
> requirement to solve). On the other hand, a Neutron plugin targeting a
> specific piece of networking hardware would likely give an unfair advantage
> to developers of the hardware's manufacturer (having access to that gear for
> testing and being able to see and make changes to its proprietary source
> code) -- that project should probably live as an unofficial OpenStack
> project.
>
> Comments, thoughts ?

I worry that this sets up a pathological situation where vendors are
encouraged *not* to engage, because they would be perceived to have an
unfair advantage...

I think the heart of the problem is a confounding effect: you're
measuring 'ability to develop on project X', not 'ability to compete
with proprietary backend Y'.

The existing diversity 

Re: [openstack-dev] [tc][pbr][packaging][all] Definition of Data Files (config) in setup.cfg

2016-06-11 Thread Robert Collins
On 12 June 2016 at 11:31, Thomas Goirand <z...@debian.org> wrote:
> On 06/11/2016 05:02 AM, Robert Collins wrote:
...
> Then keystone.conf ends up installed in /usr/etc/keystone when setup.py
> install is used. With this configuration, it would be installed
> correctly within a venv.

Except that noone uses 'setup.py install' - *except* for rpm and dpkg
packagers. Everyone else uses pip, and pip won't pass new options.
Worse, pip creates wheels and then installs the wheels, and until PEP
491 [1] is finalised and implemented, wheels won't change their
behaviour.

> If instead we have:
> [files]
> data_files =
> /etc/keystone/keystone.conf = etc/keystone.conf.sample
>
> [ notice the leading / for the destination... ]
>
> Then keystone.conf gets installed on the root of the filesystem instead
> of properly be installed within the venv. Though it's installed properly
> for distributions in /etc/keystone.
>
> To address this problem, Julien Danjou attempted to add a --sysconfdir
> option in PBR. Though it was rejected by Robert, who wrote in the code
> review that it should be addressed within setuptools or disutils.

Not should. Must be. A local change to pbr won't solve the problem,
except for the very narrow case of package creators (who already have
excellent tools - its a single one-line file to fix it on Debian, and
I presume roughly the same on RPM distributions). It certainly won't
solve it for virtual envs.

> If I got the above facts wrong, feel free to let everyone know. Now, my
> reply to Robert...
> === End of context ===
>
> Robert,
>
> I do not agree that we *must* wait until politics are discussed and a

I'm going to quote what I said back in February - 4 months ago: "Ok,
so here's where I got to:

- wheel doesn't support or understand /etc per se
- setuptools and distutils disagree on the meaning of data files paths
- wheel takes the distutils value today
- pep 491, which seems moribund, is an attempt to explicitly support
sysconf dir's like /etc, and thats what is needed in general.

I think the way forward to get this available as a sensible,
supportable feature is to discuss it on the distutils-sig list, and
that community can help figure out a design, including the backwards
compat implications."

I don't -2 lightly, and I did considerable research into this patch
before leaving the -2 in place.

With regards to politics and consensus in the upstream packaging
community - well, it would move faster if folk who are distro folk and
thus want to see the mess sorted were collaborating there: its been 4
months since Julien's original patch and no discussion has taken
place, nor has anyone volunteered in that community to do the work.
Its not super hard, and I'd be happy to guide anyone interested in
reviving PEP 491 (or drafting an alternative). What I'm not interested
in doing is adding an ineffective hack to pbr which we'll have to
maintain for an extended period, which isn't actually in pbr's domain
(pbr exists to prevent duplication amongst OpenStack projects and
provide solid and sane policy, not to replace wheel and setuptools).
I'm sorry if that sounds like a hard line, but we had an ongoing
series of bugs in pbr - the gift that keeps on giving - from the
previous attempts to work around defects upstream of pbr rather than
fixing those defects directly, which is a much better strategy : less
cost, less technical debt, benefits the entire community, gets better
outcomes.

-Rob

[1]: https://www.python.org/dev/peps/pep-0491/

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


Re: [openstack-dev] [tc][pbr][packaging][all] Definition of Data Files (config) in setup.cfg

2016-06-10 Thread Robert Collins
The underlying problem is as you say that distutils and setuptools and
wheel are all different, and until there is a PEP addressing this
*and* implemented in both wheel and setuptools, we won't get
consistent behaviour. I'm pretty sure Daniel Hoth is interested in
making this happen - there have been threads about it on distutils-sig
inside the last year, but we (me/sachi/steven) hadn't gotten onto it
as a thing to help with. I suggest chatting to Daniel as a first point
of call to see where his effort is at and what help is needed.

Note that we *need* the wheel and setuptools behaviour to be
consistent, or we will have differences between distro package
building, devstack, and ansible uses.. amongst others.

-Rob

On 11 June 2016 at 13:50, Morgan Fainberg  wrote:
> There has been a bit of back[1] and forth[2][3][4][5] between at least one
> packaging group and a few folks who are trying to define data files (config)
> in the setup.cfg to aid/ease installation within virtual environments.
>
> From what I can tell, there has been an issue with setuptools that makes
> this a particularly sticky situation and difficult to address in PBR via an
> option like --sysconfdir due to a disagreement between setuptools and
> disttools disagreeing upon the meaning of "data-files".  [6]
>
> Before this turns into a nightmare of add-patches/revert/add/revert and
> making things highly inconsistent within OpenStack, I'd like to get feedback
> from the packaging teams on where this impacts them. I know that a number of
> folks carry effectively this patch internally to make working with VENVs
> easier.
>
> We should absolutely address this in setuptools/distutils/etc but a clear
> direction forward so that the projects under OpenStack remain consistent for
> users, developers, and packagers would be good at this point.
>
> I know that keystone has had a lot of work done to ensure we can work in
> most "general" environments, but installing the data-files within a VENV is
> much more simple than a bunch of special casing to "find" the config files.
>
> In short, I think OpenStack needs to define (even if it's a short period of
> time) what we consider "data-files", we can always revisit this when/if we
> have a clear path forward via PBR, setuptools, disttools, etc.
>
> [1] https://review.openstack.org/#/c/322086/
> [2] https://review.openstack.org/#/c/326152/
> [3] http://git.openstack.org/cgit/openstack/neutron/tree/setup.cfg#n24
> [4] http://git.openstack.org/cgit/openstack/gnocchi/tree/setup.cfg#n87
> [5] http://git.openstack.org/cgit/openstack/aodh/tree/setup.cfg#n30
> [6] https://review.openstack.org/#/c/274077/
>
> Cheers,
> --Morgan
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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


Re: [openstack-dev] [tc] supporting Go

2016-05-19 Thread Robert Collins
On 19 May 2016 at 22:40, Dmitry Tantsur  wrote:
>
>> You are correct that my position is subjective, but it is based on my
>> experiences trying to operate and deploy OpenStack in addition to
>> writing code. The draw of Go, in my experience, has been easily
>> deploying a single binary I've been able to build and test consistently.
>> The target system has doesn't require Go installed at all and it works
>> on old distros. And it has been much faster.
>
>
> .. this is something distributions would never do or encourage. Ask zigo for
> reasons :)

Distros are having a hard time at the moment :) - much of their
/obvious/ value is no longer sought: for instance compile time is
cheap enough that folk are rebuilding distros just to check that the
binaries are actually from the same sources!

Further, the historical squashing of all dependencies into one version
becomes increasing fragile as dependency chains get larger: the
probability of a bug preventing a library being updated (best case -
caught by CI) or breaking something without warning (typical case,
little-to-no-CI of transitive reverse deps) goes up, not down. This is
one of the major reasons folks doing operations often bypass distro
packages (or roll their own isolated set with known-good
dependencies).

The idea of trusted-collections-of-packages made a lot more sense
before this explosion of software we have now, much of which is high
quality, and moving much much faster than distro release
cycles.Canonical/Ubuntu has at least partly got its head around this
with their focus for the last while on a vibrant app store ecosystem -
one where shipping a single binary with vendored, static dependencies
is actually viable.

So yeah, some distros are getting there, bit by bit :)

-Rob

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


Re: [openstack-dev] [fixtures] Re: [Neutron][Stable][Liberty][CLI] Gate broken

2016-05-18 Thread Robert Collins
On 18 May 2016 at 19:55, Ihar Hrachyshka  wrote:
>
>> On 18 May 2016, at 05:31, Darek Smigiel  wrote:
>>
>> Hello Stable Maint Team,
>> It seems that python-neutronclient gate for Liberty is broken[1][2] by 
>> update for keystoneclient. OpenStack proposal bot already sent update to 
>> requirements [3], but it needs to be merged.
>> If you have enough power, please unblock gate.
>>
>> Thanks,
>> Darek
>>
>> [1] https://review.openstack.org/#/c/296580/
>> [2] https://review.openstack.org/#/c/296576/
>> [3] https://review.openstack.org/#/c/258336/
>
> Right.
>
> I actually looked at the requirements update yesterday, and the problem is 
> that it also fails in gate due to fixtures 2.0.0 being used in client gate, 
> and apparently misbehaving for python3:

FWIW there is actually a fairly deep bug in MonkeyPatch that we'd
simply been fortunate to not hit, though folk had been unknowningly
working around edge cases for some time. We applied what looked like a
shallow fix leading to 2.0.0, but investigating the fallout from that
got us to understand the actual depth of the rabbit hole and Andrew
and I have been collaborating on a comprehensive, fix it forever patch
set since.

-Rob

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


Re: [openstack-dev] [all][requirements] Refresher on how to use global requirements process

2016-05-18 Thread Robert Collins
On 19 May 2016 at 01:40, Ihar Hrachyshka  wrote:
> Great write-up. Do you plan to capture it e.g. in project guide?

It's already fully documented in the requirements repo README; if
there is no link to that from the project-guide, we should add one,
but I would not duplicate the content.

-Rob

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


Re: [openstack-dev] [requirements][all] First Requirements Team Meeting

2016-05-17 Thread Robert Collins
On 17 May 2016 at 23:47, Davanum Srinivas  wrote:
> Team,
>
> Let's meet in #openstack-meeting-cp channel at 12:00 UTC on May 18th:
> http://www.timeanddate.com/worldclock/meetingdetails.html?year=2016=5=18=12=0=0=43=240=195=166=83=281=141
>
> We can decide if we need a better time/day for regular meetings.
>
> MUST read before the meeting :
> https://etherpad.openstack.org/p/requirements-tasks :)

FWIW I can't make that (its midnight here), but if you need anything
from me, drop me a mail :)

-Rob

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


Re: [openstack-dev] [tc] [all] [glance] Answers to some questions about Glance

2016-05-17 Thread Robert Collins
On 18 May 2016 at 00:54, Brian Rosmaita  wrote:

>> Couple of examples:
>> 1. switching from "is_public=true" to "visibility=public"
>
>
> This was a major version change in the Images API.  The 'is_public' boolean
> is in the original Images v1 API, 'visibility' was introduced with the
> Images v2 API in the Folsom release.  You just need an awareness of which
> version of the API you're talking to.

So I realise this is ancient history, but this is really a good
example of why Monty has been pushing on 'never break our APIs': API
breaks hurt users, major versions or not. Keeping the old attribute as
an alias to the new one would have avoided the user pain for a very
small amount of code.

We are by definition an API - doesn't matter that its HTTP vs Python -
when we break compatibility, there's a very long tail of folk that
will have to spend time updating their code; 'Microversions' are a
good answer to this, as long as we never raise the minimum version we
support. glibc does a very similar thing with versioned symbols - and
they support things approximately indefinitely.

-Rob

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


Re: [openstack-dev] [TripleO] [diskimage-builder] LVM in diskimage-builder

2016-05-17 Thread Robert Collins
On 18 May 2016 at 07:32, Andre Florath  wrote:
> Hi All!
>
> AFAIK the diskimage-builder started as a testing tool, but it looks
> that it evolves more and more into a general propose tool for creating
> docker and VM disk images.

We started as a fast, production, targeted image builder suitable for
cloud images - the other existing tools were either overly hard to
customise for different use cases, or too slow.

>   Problem: I have no idea how to boot from a pure LVM image.

Install grub2 in the boot block, it can deal with some layout metadata.

-Rob

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


Re: [openstack-dev] [tc] supporting Go

2016-05-12 Thread Robert Collins
On 13 May 2016 at 00:01, Thierry Carrez <thie...@openstack.org> wrote:
> Robert Collins wrote:
>>
>> [...]
>> So, given that that is the model - why is language part of it? Yes,
>> there are minimum overheads to having a given language in CI [...]
>
>
> By "minimum" do you mean that they are someone else's problem ?

No. I mean that there is an irreducible cost: there is some minimum
and we need to account for that. (as in fact the end of that paragraph
which you snipped, said).

> There are economics at play here. Adding a language simplifies the work of
> some and make more work for others. Obviously "some" see mostly benefits and
> "others" see mostly drawbacks. You're just creating an externality[1].

I'm not sure that allowing arbitrary languages would constitute an
externality, properly structured - which is what I was trying to get
at with my mail.

> So rather than shifting workloads to someone else or pretending there is no
> problem, let's take the time to calmly measure the cost, see what resources
> we have lined up to address that cost, and make a decision from there.

I proposed neither of those things (shifting, or pretence). Rebutting
those positions is not rebutting my argument.

 I agree with taking the time to assess things carefully, but in this
discussion noone had taken a general 'pro' stance, so I decided, as an
exercise, to write one up.

However, assessing 'what we have to address that cost' is missing the
actual point: we don't need to cover the cost /once/, we need to make
how-its-covered, and who-covers-it be structured such that folk
wanting to use $LANGUAGE provide the [human] resources needed to cover
the incurred costs. An answer which says 'we can just afford to pay
for go, but thats it', is an answer that has failed to actually tackle
the underlying problem.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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


Re: [openstack-dev] [tc] supporting Go

2016-05-11 Thread Robert Collins
I'm going to try arguing the pro case.

The big tent has us bringing any *team* that want to work the way we
do: in the open, collaboratively, in concert with other teams, into
OpenStacks community.

Why are we using implementation language as a gate here?

I assert that most deployers don't fundamentally care about language
of the thing they are deploying; they care about cost of operations,
which is influenced by a number of facets around the language
ecosystem: packaging, building, maturity, VM
behaviour-and-tuning-needs, as well as service specific issues such as
sharding, upgrades, support (from vendors/community), training (their
staff - free reference material, as well as courses) etc. Every
discussion we had with operators about adding new dependencies was
primarily focused on the operational aspects, not 'is it written in
C/$LANGUAGE'. Right now our stock dependency stack has C (Linux, libc,
libssl, Python itself etc, Erlang (rabbitmq), java (zookeeper).

End users emphatically do not care about the language API servers were
written in. They want stability, performance, features, not 'Written
in $LANGUAGE'.

As a community, we decided long ago to silo our code: Nova and Swift
could have been in one tree, with multiple different artifacts - think
of all the cross-code-base-friction we would not have had if we'd done
that! The cultural consequence though is that bringing up new things
is much less disruptive: add a new tree, get it configured in CI, move
on. We're a team-centric structure for governance, and the costs of
doing cross-team code-level initiatives are already prohibitive: we
have already delegated all those efforts to the teams that own the
repositories: requirements syncing, translations syncing, lint fixups,
security audits... Having folk routinely move cross project is
something we seem to be trying to optimise for, but we're not actually
achieving.

So, given that that is the model - why is language part of it? Yes,
there are minimum overheads to having a given language in CI - we need
to be able to do robust reliable builds [or accept periodic downtime
when the internet is not cooperating], and that sets a lower fixed
cost, varying per language. Right now we support Python, Java,
Javascript, Ruby in CI (as I understand it - infra focused folk please
jump in here :)).

A Big Tent approach would be this:
 - Document the required support for a new language - not just CI
 - Any team that wants to use $LANGUAGE just needs to ensure that that
support is present.
 - Make sure that any cross-service interactions are well defined in a
language neutral fashion. This is just good engineering basically:
define a contract, use it.

Here is a straw man list of requirements:
 - Reliable builds: the ability to build and test without talking to
the internet at all.
 - Packagable: the ability to take a source tree for a project, do
some arbitrary transform and end up with a folder structure that can
be placed on another machine, with any needed dependencies, and work.
[Note, this isn't the same as 'packagable in a way that makes Red Hat
and Canonical and Suse **happy**, but thats something we can be sure
that those orgs are working on with language providers already ]
 - FL/OSS
 - Compatible with ASL v2 source code. [e.g. any compiler doesn't
taint its output]
 - Can talk oslo.messaging's message format

That list is actually short, and those needs are quite tameable. So
lets do it - lets open up the tent still further, stop picking winners
and instead let the market sort it out.

-Rob

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


Re: [openstack-dev] [tc] supporting Go

2016-05-11 Thread Robert Collins
On 12 May 2016 at 02:35, Brant Knudson <b...@acm.org> wrote:
>
> I'd be worried about bringing in a language that doesn't integrate well with
> Python, since I'd expect the normal route would be to take advantage of as
> much of the existing code as we have and only replace those parts that need
> replacing. From these web pages it looks like Go integrates with Python:
> https://blog.filippo.io/building-python-modules-with-go-1-5/ and
> https://github.com/go-python/gopy (I haven't tried these myself).

It looks like that works by forking off of a go runtime and chatting
via locks. Using an RPC model (similar to privsep) would probably be
more flexible and easier, with at most a small speed cost. Worth
trying a few things to get experience?

-Rob



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-05-10 Thread Robert Collins
On 11 May 2016 at 08:27, Jeremy Stanley <fu...@yuggoth.org> wrote:

>
> Anyway, to the original point, yes Launchpad is full of compromised
> or perhaps freshly created accounts under the control of spammers.

Ubuntu SSO is **not** Launchpad. Launchpad is just another consumer of
Ubuntu SSO, and it has the 'feature' of forwarding through to Ubuntu
SSO - so we're actually seeing Ubuntu SSO spam accounts :(.

Why does this matter? If folk want to solve this at source - make
making new accounts harder - you need to look at the correct code
base, which is https://launchpad.net/canonical-identity-provider

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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


Re: [openstack-dev] [tc] supporting Go

2016-05-10 Thread Robert Collins
On 11 May 2016 at 06:10, Hayes, Graham <graham.ha...@hpe.com> wrote:
> On 10/05/2016 01:01, Gregory Haynes wrote:

> The way this component works makes it quite difficult to make any major
> improvement.
>
> MiniDNS (the component) takes data and sends a zone transfer every time
> a recordset gets updated. That is a full (AXFR) zone transfer, so every
> record in the zone gets sent to each of the DNS servers that end users
> can hit.
>
> This can be quite a large number - ns[1-6].example.com. may well be
> tens or hundreds of servers behind anycast IPs and load balancers.
>
> In many cases, internal zones (or even external zones) can be quite
> large - I have seen zones that are 200-300Mb. If a zone is high traffic

I presume you mean MB ?

> (like say cloud.example.com. where a record is added / removed for
> each boot / destroy, or the reverse DNS zones for a cloud), there can
> be a lot of data sent out from this component.
>
> We are a small development team, and after looking at our options, and
> judging the amount of developer hours we had available, a different
> language was the route we decided on. I was going to go implement a few
> POCs and see what was most suitable.

Out of interest, what was the problem you had/have with Python here?
Sending a few GB of data at wire speeds on a TCP link is pretty
shallow for Python, though not having had my hands on a 40gpbs NIC I
can't personally say whether its still the case there.

I guess my fundamental question is: is this a domain problem, or a
Python problem? If the problem is 'we need to send 300MB to 100
servers in < 5 seconds', which is 30GB of traffic - you're going to
need a 240GB/5s == 48Gbps NIC, or you're going to need distributed
workers to shard that workload across machines.

If the problem is 'designate's memory use is blowing way up when we
try to do this' - that might be a very straightforward fix (use
memoryviews and zero-copy IO).

I guess what I'm wondering is whether there is a low hanging fix, and
as an observer I have absolutely no insight into the problem you've
been having - I'd like to know more... is there a bug report perhaps?

My *fear* is that the underlying problem has nothing to do with Python
and can rear its head in any language - and that perhaps the idioms
being used in Designate (or OpenStack as a whole) are driving whatever
specific problem you've got?

I know that our current programming model is missing a lot of the
easily-correct improvements that have been created in the last few
decades (because our basic abstraction is the thread) - how much does
that factor in, do you think?

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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


Re: [openstack-dev] [tc] supporting Go

2016-05-09 Thread Robert Collins
On 10 May 2016 at 06:58, Hayes, Graham <graham.ha...@hpe.com> wrote:
>  From a deck about "the rise and fall of Bind 10" [0] -
>
>"Python is awesome, but too damn slow for DNS"

That slide deck doesn't provide any analysis on *what* that means -
latency? requests per second?
Dollars-per-millions-requests-per-second?

https://github.com/bundy-dns/bundy/blob/master/src/lib/python/bundy/server_common/bundy_server.py
<- they wrote their server around select(), which has been pretty much
deprecated for high performance - whether scale or latency (except
with very small connection counts) servers for decades...

tl;dr: I don't trust their ability to make the statement that Python
is too slow, because their code is failing a basic sniff test in this
space.

A UDP only DNS server could get away with select (in fact, it might
possibly be optimal), but something handling TCP will rapidly run into
terrible scaling problems - quadratic overheads - with select.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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


Re: [openstack-dev] [tc] supporting Go

2016-05-09 Thread Robert Collins
On 10 May 2016 at 10:54, John Dickinson <m...@not.mn> wrote:
> On 9 May 2016, at 13:16, Gregory Haynes wrote:
>>
>> This is a bit of an aside but I am sure others are wondering the same
>> thing - Is there some info (specs/etherpad/ML thread/etc) that has more
>> details on the bottleneck you're running in to? Given that the only
>> clients of your service are the public facing DNS servers I am now even
>> more surprised that you're hitting a python-inherent bottleneck.
>
> In Swift's case, the summary is that it's hard[0] to write a network
> service in Python that shuffles data between the network and a block
> device (hard drive) and effectively utilizes all of the hardware
> available. So far, we've done very well by fork()'ing child processes,
...
> Initial results from a golang reimplementation of the object server in
> Python are very positive[1]. We're not proposing to rewrite Swift
> entirely in Golang. Specifically, we're looking at improving object
> replication time in Swift. This service must discover what data is on
> a drive, talk to other servers in the cluster about what they have,
> and coordinate any data sync process that's needed.
>
> [0] Hard, not impossible. Of course, given enough time, we can do
>  anything in a Turing-complete language, right? But we're not talking
>  about possible, we're talking about efficient tools for the job at
>  hand.
...

I'm glad you're finding you can get good results in (presumably)
clean, understandable code.

Given go's historically poor perfornance with multiple cores
(https://golang.org/doc/faq#Why_GOMAXPROCS) I'm going to presume the
major advantage is in the CSP programming model - something that
Twisted does very well: and frustratingly we've had numerous
discussions from folk in the Twisted world who see the pain we have
and want to help, but as a community we've consistently stayed with
eventlet, which has a threaded programming model - and threaded models
are poorly suited for the case here.

All of which to say, I disagree quite strongly that its hard to drive
a server's hardware at full capacity using Python. Using Python like
*we have been* - yes, certainly.

Thats not a reason to avoid golang - but if minimising the number of
languages in play is a thing we want to do, we should make sure we're
actually using the best facilities of our existing languages first!

On the Designate side, PyPy got a 40% performance improvement over
CPython for a benchmark of Twisted's DNS component 6 years ago - and
Twisted and PyPy have both moved forward a great deal since then
http://morepypy.blogspot.co.nz/2010/03/hello.html

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Team blogs

2016-05-09 Thread Robert Collins
IIRC mediawiki provides RSS of changes... maybe just using the wiki
more would be a good start, and have zero infra costs?

-Rob

On 10 May 2016 at 10:37, Joshua Harlow <harlo...@fastmail.com> wrote:
> After seeing the amount of summit recaps and the scattered nature of these
> (some on the ML, some on etherpads, some on personal blogs); I am starting
> to wonder if we should again bring up the question of having infra (and I
> guess the foundation?) support/provide a place for team blogs...
>
> I've heard its been discussed before but nothing much ever came of that (not
> enough people?) and I'm wondering if we can restart this kind of effort so
> that teams can show-case what is happening in there project, project summit
> recaps, newer or advertise less used features/functionality and so-on.
> Having such hosted team blogs also makes it easier to have a history of
> information (personal blogs can be deleted...) and I think can be quite
> useful for collaboration/information sharing.
>
> Thoughts?
>
> -Josh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Bootstrapping new team for Requirements.

2016-05-09 Thread Robert Collins
I've replied on the etherpad.

-Rob

On 8 May 2016 at 03:02, Davanum Srinivas <dava...@gmail.com> wrote:
> Dirk, Haïkel, Igor, Alan, Tony, Ghe,
>
> Please see brain dump here - 
> https://etherpad.openstack.org/p/requirements-tasks
>
> Looking at time overlap, it seems that most of you are in one time
> range and Tony and I are outliers
> http://www.timeanddate.com/worldclock/meetingtime.html?iso=20160506=43=240=195=166=83=281=141)
>
> So one choice for time is 7:00 AM or 8:00 AM my time which will be
> 9:00/10:00 PM for Tony. Are there other options that anyone sees?
> Please let me know which days work as well.
>
> dhellmann, sdague, markmcclain, ttx, lifeless,
> Since you are on the current requirements-core gerrit group, Can you
> please review the etherpad and add your thoughts/ideas/pointers to
> transfer knowledge to the new folks?
>
> To be clear, we are not yet adding new folks to the gerrit group, At
> the moment, i am just getting everyone familiar and productive with
> what we do now and see who is still around doing stuff in a couple of
> months :)
>
> Anyone else want to help, Jump in please!
>
> Thanks,
> Dims
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [kolla] Gate precheck job failed due to minimum kernel version on ubuntu 14.04

2016-05-07 Thread Robert Collins
That won't get you running the new kernel; for that you need to change
the image itself.

-Rob

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


[openstack-dev] [oslo] Backwards compatibility policy

2016-04-29 Thread Robert Collins
Yesterday, in 
https://etherpad.openstack.org/p/newton-oslo-backwards-compat-testing
we actually reached consensus - well, 7/10 for and noone against -
doing 1 cycle backwards compatibility in Oslo.

That means that after we release a thing, code using it must not break
(due to an Oslo change) until a release from the cycle *after* the
next cycle..

Concretely, add a thing at the start of L, we can break code using
that exact API etc at the start of N. We could try to be clever and
say 'Release of L, can break at the start of N', but 'release of L' is
now much fuzzier than it used to be - particularly with independent
releases of some things. So I'd rather have a really simple easy to
define and grep for rule than try to optimise the window. Happy if
someone else can come up with a way to optimise it.

This is obviously not binding on any non-oslo projects: os-brick,
python-neutronclient etc etc: though I believe folks in such projects
are generally cautious as well.

The key thing here is that we already have to do backwards compat to
move folk off of a poor API onto a new one: all this policy says is
that the grace period needs to cross release boundaries.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] backwards compatibility followup

2016-04-26 Thread Robert Collins
On 26 April 2016 at 18:41, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>> On Apr 26, 2016, at 6:32 PM, Perry, Sean <sean.pe...@hpe.com> wrote:
>>
>> What if we update the docs and tell people to put any services on a shared 
>> system into independent virtualenvs?
>>
>> If a box only runs neutron or whatever all is well. The issue happens when 
>> you mix and match services on a single host. Which is exactly what 
>> virtualenv was intended to fix.
>
> Except that a fair portion of respondents to the OpenStack User Survey talk 
> about using packages provided by the distribution of Linux they happen to be 
> on. Those cannot be installed into virtual environments.

Right. The specific situation is 'same python environment' - so distro
packages all land in the same python environment. You can make
packages of virtualenvs and other such things - and folk wanting to be
able to do same-node-no-container-distro-package in-place upgrade
solutions would be looking at such things if we decide we don't want
to support/enable this.

Some distros were in the room, and e.g. I believe it was Dan that said
RH don't support - in their packaging - mixed versions: upgrade nova,
and neutron would be upgraded too in the given example. So its
possible that while some folk aspire to it, many other folk are either
accepting downtime, or running their control plane on isolated
operating system instances (whether physical, VM or containers is
irrelevant).

At the party tonight I ran into Brian Demers and a colleague whose
name I have forgotten :( - but they have a backwards compat use case
we hadn't touched on in the session: running their Neutron plugin
against both stable and master of Neutron.

This is a classic colocation situation. There are a few possible scenarios:
 - run stable branches of the plugin and backport everything
- tricky if new oslo features are needed, but the existing pattern.
- also tricky for users, since there would be lots of releases of
both stable and master
 - run master against stable neutron using stable neutron oslo
 - means they can't use any new oslo features, and they would
depend on oslo not breaking any API's they use in master - so depends
on oslo API compat
 - or they have to provide backports within their tree and monkey
patch them into place, of new/changed things from oslo
 - run master against stable neutron using master oslo
- means neutron would have to work with master oslo - so the same
compat story, just from the other side


(Clearly there are also Neutron API driver things to discuss, but this
is in the context of the libraries thread :)).

I wonder how many other folk are trying to attempt such a thing -
anyone care to raise their metaphorical hand?

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] backwards compatibility followup

2016-04-26 Thread Robert Collins
Thanks everyone for coming to the backwards compat for clients and
libraries session.

Here are the things I think we agreed on:
 - clients need to talk to all versions of openstack clouds
 - oslo libraries already do need to do backwards compat - josh,
myself, dims, doug are all striving for that in reviews
 - some fraction of our deploys - somewhere between 1% and 50% - are
trying to do in-place upgrades where e.g. nova is upgraded and then
later neutron, which runs into neutron having to work with the new
libraries the nova upgrade dragged in.

Here is the choice I think we're still struggling with:
 - should we support in-place upgrades? If we do, we need at least 1,
possibly more, versions of compatibility such that e.g. mitaka Nova
can run with newton olso+clientlibs
 - or should we explicitly state that we don't support in-place
upgrades - that deployment methods must be architected to avoid ever
encountering the situation where a client or one of N services is
going to be upgraded on a single python environment: all clients and
services must be upgraded together, or none.

If we decide to support in-place upgrades, we can figure out how to
test that effectively; its a linear growth with the number of stable
releases we choose to support.

If we decide not to support them, we have no further requirement to
have any cross-over compat between OpenStack releases - while we will
still have to be backwards compatible on individual changes (so that
we can get them rolled out and used), we can do our garbage collection
much more rapidly - even same-cycle.


https://etherpad.openstack.org/p/newton-backwards-compat-libs

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Distributed Database

2016-04-24 Thread Robert Collins
ed to have adopting a distributed database be a net
benefit. Everyone may have different concerns here - but if we union
them together we can see if there is a feasible thing.

For instance, the things I think are essential for a distributed
database based datastore:
 - good single-machine developer story. Must not need a physical
cluster to hack on OpenStack
 - deal gracefully with single node/rack/site failures (when deployed
appropriately) - allow limiting failure domain impact
 - straightforward programming model: wrong uses should be obvious to reviewers
 - low latency performance with big datasets: e.g. nova list as an
admin should be able to get the Nth page as rapidly as the 2nd or 3rd.
 - code to deliver that should be (approximately) no worse than the current code

I realise this isn't easy to judge from a small prototype - so I'd be
proposing that once we've got rough consensus on a set of essential
things, we constitute a new team to put together a sizable POC (or
POCs - one per DB for a few DBs...) - an 80% thing - so folk can
actually assess how it look/feel at both a code and ops perspective.

Then, if the result *has met* those essential things, we should
actually have the ability to do a gap analysis and talk about how a
project to move to such a thing would look like.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-04-20 Thread Robert Collins
On 18 April 2016 at 03:13, Doug Hellmann <d...@doughellmann.com> wrote:
> I am organizing a summit session for the cross-project track to
> (re)consider how we manage our list of global dependencies [1].
> Some of the changes I propose would have a big impact, and so I
> want to ensure everyone doing packaging work for distros is available
> for the discussion. Please review the etherpad [2] and pass the
> information along to colleagues who might be interested.


Thanks for kicking this off Doug. Its a great topic - as the thread shows :).

I have a few thoughts - and I fully intend to be at the session as
well. I don't know if I'm pro or con the specific proposal today - and
I definitely need to understand the details of the issue a bit better,
my focus has been on various testing and packaging things for a bit -
I've neglected my requirements reviews except when prompted - sorry.

I think that federated constraints/requirements raise some risks with
multi-project gating jobs. This is separate to the co-installability
requirement and instead due to the ability to end up with a multi-tree
wedge. If something happens atomically that breaks two projects
constraints at the same time, two distinct git changes are required to
fix that. AIUI this happens maybe 1/8 weeks? In a centralised model we
can fix that atomically within the normal CI workflow. With a
federated approach, we will have to get infra intervention. Similarly,
if there is a needle-threading situation that can end up with multiple
projects broken at the same time, and they consume each other (or both
are present in devstack jobs for the other) we can wedge. I'm thinking
e.g. changes to Nova and Neutron go through, independently but the
combination turns out to be API incompatible on the callbacks between
services or some such. Perhaps too niche to worry about?

Co-installability has very significant impact on the backwards compat
discussion: its a major driver of the need I perceive for library
backwards compatibility (outside of client library compat with older
clouds) and I for one think we could make a bunch of stuff simpler
with a reduced co-installability story.
https://review.openstack.org/#/c/226157/ and
https://etherpad.openstack.org/p/newton-backwards-compat-libs

I'm super worried about the impact on legacy distributions though - I
don't think they're ready for it, and I don't think we're important
enough to act as a sane forcing function: but perhaps we can find some
compromise that works for everyone - or at least get distros to commit
to moving ahead in their view of the world :).

I don't think we can ditch co-installability per se though, even in a
totally containerised world: we still have the need to make each leaf
artifact in the dependency tree co-installable with all its
dependencies. That is, we can't get to a situation where
oslo.messaging and oslo.db are not co-installable, even though they
don't depend on each other, because Nova depends on both and we want
to be able to actually install Nova.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-04-20 Thread Robert Collins
On 20 April 2016 at 05:44, Clint Byrum <cl...@fewbar.com> wrote:
> Excerpts from Michał Jastrzębski's message of 2016-04-18 10:29:20 -0700:
>> What I meant is if you have liberty Nova and liberty Cinder, and you
>> want to upgrade Nova to Mitaka, you also upgrade Oslo to Mitaka and
>> Cinder which was liberty either needs to be upgraded or is broken,
>> therefore during upgrade you need to do cinder and nova at the same
>> time. DB can be snapshotted for rollbacks.
>>
>
> If we're breaking backward compatibility even across one release, that
> is a bug.  You should be able to run Liberty components with Mitaka
> Libraries. Unfortunately, the testing matrix for all of the combinations
> is huge and nobody is suggesting we try to solve that equation.

Sadly no: we don't make that guarantee today. I think we should, but
there isn't consensus - at least amongst the folk that have been
debating the backwards compat for libraries spec - that it is actually
*desirable*. Please, come to the session and help build consensus in
Austin :).

> However, to the point of distros: partial upgrades is not the model distro
> packages work under. They upgrade what they can, whether they're a rolling
> release, or 7 year cycle LTS's. When the operator says "give me the new
> release", the packages that can be upgraded, will be upgraded. And if
> Mitaka Nova is depending on something outside the upper constraints in
> another package on the system, the distro will just hold Nova back.

And presumably all of OpenStack.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-04-20 Thread Robert Collins
On 20 April 2016 at 04:47, Clark Boylan <cboy...@sapwetik.org> wrote:
> On Tue, Apr 19, 2016, at 08:14 AM, Doug Hellmann wrote:
>> Excerpts from Jeremy Stanley's message of 2016-04-19 15:00:24 +:
>> > On 2016-04-19 09:10:11 -0400 (-0400), Doug Hellmann wrote:
>> > [...]
>> > > We have the global list and the upper constraints list, and both
>> > > are intended to be used to signal to packaging folks what we think
>> > > ought to be used. I'm glad that signaling is working, and maybe
>> > > that means you're right that we don't need to sync the list
>> > > absolutely, just as a set of "compatible" ranges.
>> > [...]
>> >
>> > When we were firming up the constraints idea in Vancouver, if my
>> > memory is correct (which it quite often is not these days), part of
>> > the long tail Robert suggested was that once constraints usage in
>> > the CI is widespread we could consider resolving it from individual
>> > requirements lists in participating projects, drop the version
>> > specifiers from the global requirements list entirely and stop
>> > trying to actively synchronize requirement version ranges in
>> > individual projects. I don't recall any objection from those of us
>> > around the table, though it was a small ad-hoc group and we
>> > certainly didn't dig too deeply into the potential caveats that
>> > might imply.
>>
>> I have no memory of that part of the conversation, but I'll take your
>> word for it.
>>
>> If I understand your description correctly, that may be another
>> alternative. Most of the reviews I've been doing are related to the
>> constraints, though, so I'm not really sure it lowers the amount of work
>> I'm seeing.
>
> This was one of my concerns with constraints when we put them in place.
> Previously we would open requirements and things would break
> periodically and we would address them. With constraints every single
> requirements update whether centralized or decentralized needs to be
> reviewed. It does add quite a bit of overhead.
>
> The argument at the time was that the time saved by not having the gate
> explode every few weeks would offset the cost of micromanaging every
> constraint update.

I also argued at the time that we should aim for entirely automated
check-and-update. This has stalled on not figuring out how to run e.g.
Neutron unit tests against requirements changes - our coverage is just
too low at the moment to proceed further down the automation path.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][requirements][packaging][summit] input needed on summit discussion about global requirements

2016-04-20 Thread Robert Collins
On 20 April 2016 at 03:00, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2016-04-19 09:10:11 -0400 (-0400), Doug Hellmann wrote:
> [...]
>> We have the global list and the upper constraints list, and both
>> are intended to be used to signal to packaging folks what we think
>> ought to be used. I'm glad that signaling is working, and maybe
>> that means you're right that we don't need to sync the list
>> absolutely, just as a set of "compatible" ranges.
> [...]
>
> When we were firming up the constraints idea in Vancouver, if my
> memory is correct (which it quite often is not these days), part of
> the long tail Robert suggested was that once constraints usage in
> the CI is widespread we could consider resolving it from individual
> requirements lists in participating projects, drop the version
> specifiers from the global requirements list entirely and stop
> trying to actively synchronize requirement version ranges in
> individual projects. I don't recall any objection from those of us
> around the table, though it was a small ad-hoc group and we
> certainly didn't dig too deeply into the potential caveats that
> might imply.

I think I suggested that we could remove the *versions* from
global-requirements. Constraints being in a single place is a
necessary tool unless (we have atomic-multi-branch commits via zuul ||
we never depend on two projects agreeing on compatible versions of
libraries in the CI jobs that run for any given project).

Constraints being in a single place (not necessarily a single file)
allows to fix multi-project wedging issues with a single git commit.
Atomic multi-branch commits in zuul would allow us to fix
multi-project wedging issues if constraints are federated out to
multiple trees.
Never needing any two projects to agree on compatible versions in CI
would allow us to change things without triggering a wedge...
possibly. *detailed* thought needed here - because consider for
instance the impact of a removed release on PyPI.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][elections] Results of the TC Election

2016-04-07 Thread Robert Collins
Congrats everyone!

-Rob

On 8 April 2016 at 12:03, Tony Breeds <t...@bakeyournoodle.com> wrote:
> Please join me in congratulating the 7 newly elected members of the TC.
>
> <<<<<< REMOVE UNEEDED >>>>>
> * Davanum Srinivas (dims)
> * Flavio Percoco (flaper87)
> * John Garbutt (johnthetubaguy)
> * Matthew Treinish (mtreinish)
> * Mike Perez (thingee)
> * Morgan Fainberg (morgan)/(notmorgan)
> * Thierry Carrez (ttx)
>
> Full results: 
> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a
>
> Thank you to all candidates who stood for election, having a good group of
> candidates helps engage the community in our democratic process.
>
> Thank you to all who voted and who encouraged others to vote. We need to 
> ensure
> your voice is heard.
>
> Thank you for another great round.
>
> Here's to Newton!
>
> Yours Tony.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [infra] The same SRIOV / NFV CI failures missed a regression, why?

2016-03-30 Thread Robert Collins
On 26 March 2016 at 09:08, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2016-03-25 15:20:00 -0400 (-0400), Jay Pipes wrote:
> [...]
>> 3) The upstream Infrastructure team works with the hired system
>> administrators to create a single CI system that can spawn
>> functional test jobs on the lab hardware and report results back
>> to upstream Gerrit
> [...]
>
> This bit is something the TripleO team has struggled to accomplish
> over the past several years (running a custom OpenStack deployment
> tied directly into our CI), so at a minimum we'd want to know how
> the proposed implementation would succeed in ways that they've so
> far found a significant challenge even with a larger sysadmin team
> than you estimate being required.

I think what Jay is getting at is to have the *exact same approach*
third-party CI for NFV and PCI have been using - so whatever
$behind-the-abstraction setup they are using, but community accessible
and visible, unlike the current behind-corprorate-firewall setups.

I'm not saying this is better or worse, but it is different to the
tripleo approach of providing a Nova API endpoint for zuul.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [TC] TC Non-candidancy

2016-03-30 Thread Robert Collins
Hi everyone - I'm not submitting my hat for the ring this cycle - I
think its important we both share the work, and bring more folk up
into the position of having-been-on-the-TC. I promise to still hold
strong opinions weakly, and to discuss those in TC meetings :).

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-03-24 Thread Robert Collins
On 25 March 2016 at 10:30, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2016-03-24 16:21:30 -0500 (-0500), Ian Cordasco wrote:
>> Also this only affects libraries and not the server projects.
>> Besides, hasn't this community always asserted that no one
>> installs from PyPI anyway (inspite of evidence of projects
>> allowing just that based on user feedback)?
>
> The libraries are tagging in master AFAIK. The
> {name}-merge-release-tags jobs are run in the release pipeline for
> all projects using the openstack-server-release-jobs template in
> Zuul because those are the projects that needed it since they were
> the only ones traditionally tagging final releases on off-master
> branches:
>
> http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul/layout.yaml

I'm not worried about servers; they don't publish to pypi. Libraries
and clients however, are branching and being released from branches.
Do we merge release tags to master for them? If so, thats probably
perfect (though I haven't worked through it all in my head - public
holiday here so only paying partial attention).

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][all][ptl][stable] requirements updates in stable/mitaka libraries

2016-03-24 Thread Robert Collins
I think this is reasonable to do; we may need to follow up on this
depending on the result of the other thread about version
mgmt-after-a-branch.

-Rob

On 25 March 2016 at 04:05, Doug Hellmann <d...@doughellmann.com> wrote:
> We have branched the openstack/requirements repository as the first
> step to unfreezing requirements changes in master. Creating the
> branch triggered the requirements update bot to propose changes to
> repositories with stable/mitaka branches that were out of sync
> relative to the point where we branched. Most of those repositories
> are for libraries, but there are one or two server projects in the
> list as well.
>
> These updates are mostly changes we made to the requirements list
> after it was frozen in order to address issues such as bad versions
> of libraries, needed patch updates, etc. Some may also reflect
> requirements updates that were not merged into the repositories
> before their stable branches were created. We want to have the
> stable branch requirements updates cleaned up to avoid the limbo
> state we were in with liberty for so long, where no one was confident
> of merging requirements changes in the stable branch.
>
> We need project teams to review and land the patches, then prepare
> release requests for the affected projects as soon as possible.
> Please look through the list of patches [1] and give them a careful
> but speedy review, then submit a change to openstack/releases for
> the new release using a minimum-version level update (increment the
> Y from X.Y.Z and reset Z to 0) reflecting the change in requirements.
>
> Thanks,
> Doug
>
> [1] 
> https://review.openstack.org/#/q/is:open+branch:stable/mitaka+topic:openstack/requirements
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-03-24 Thread Robert Collins
On 25 March 2016 at 08:23, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>

> Right I'm not convinced it's more than the ~15 or 20 of us that work on OSA 
> and care about upgrading and catching regressions early.

However, Doug and I just uncovered a concern on IRC: having PyPI be
ahead of master for more than very short periods seems like a poor
idea.

When we tag a final release on a branch, without master being higher
than that final release, folk running things installed from master,
will now be 'upgradable' to whats on PyPI, even though thats older
from a human perspective.

So, I think we do need some aggressive means to bump master up past
the versions reserved for a stable branch, at the stable branches
creation.

-Rob



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-03-24 Thread Robert Collins
On 25 March 2016 at 07:25, Chris Dent <cdent...@anticdent.org> wrote:
> On Thu, 24 Mar 2016, Doug Hellmann wrote:
>
> [good explanation snipped]
>
> Thanks for the detailed explanation.
>
> As with so many of these bits of automation they come with a variety
> of compromises. After a while it starts to seem like maintaining
> those compromises becomes as important as solving the original goal.
>
>>> [1] The fact that I can't look in the code for __version__ gives me
>>> rage face.
>>
>>
>> Having a __version__ inside the package actually has no bearing on
>> what version the packaging system thinks is associated with the
>> dist. The name is just a convention some projects have used. Rather
>> than hard-coding a value, it's better to use pkg_resources to ask
>> for the version of the current package.
>
>
> Yeah, I know. I guess I have become accustomed to __version__ as the
> canonical source of version authority (used by tooling) because...hrmmm
> what's the best way to put this...it's clear, it's just _there_.

There's a stock recipe for pbr using projects that lets you have a
https://www.python.org/dev/peps/pep-0396/ compliant __version__ (even
though that PEP is deferred :)) which will use either pkg_resources
metadata, or pep 345 metadata,  or git history, depending on whats
available. Thats entirely suitable for querying via automation (import
the module, consult mod.__version__). Or you can alternatively query
the standard (https://www.python.org/dev/peps/pep-0345/ ) metadata
generated from python setup.py egg_info, if you prefer.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-03-24 Thread Robert Collins
On 25 March 2016 at 01:11, Alan Pevec <ape...@gmail.com> wrote:
> 2016-03-24 2:21 GMT+01:00 Robert Collins <robe...@robertcollins.net>:
>> 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

Those versions are not the versions that pbr will generate.

mitaka gets backports and local requirements changes only, so it will
get less commits than master.

Say mitaka gets 10 commits, and master 50.

mitaka  13.0.1.dev10
master 13.0.1.dev50

As soon as someone pushes a commit that adds a feature (sem-ver:
feature), master will bump to 13.1.0.devN

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-03-23 Thread Robert Collins
On 24 March 2016 at 13:23, Dean Troyer <dtro...@gmail.com> wrote:
> On Wed, Mar 23, 2016 at 3:03 PM, Doug Hellmann <d...@doughellmann.com>
> wrote:
>>
>> Are you packaging unreleased things in RDO? Because those are the only
>> things that will have similar version numbers. We ensure that whatever
>> is actually tagged have good, non-overlapping, versions.
>
>
> The packages on https://trunk.rdoproject.org/ are built from master and have
> version numbers in the future derived from the pbr default 'next' version.
> So yes, there are packages distributed in the wild with version numbers that
> have not been tagged.

Thats ok, because thats an opt-in thing there - its not existing in
the same namespace as the mitaka builds for rdo, is it?

Trunk will rapidly exceed mitaka's versions, leading to no confusion too.

-Rob



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-03-23 Thread Robert Collins
On 24 March 2016 at 10:36, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>

> The project will build wheels first. The wheels generated tend to look 
> something like 13.0.0.0rc2.dev10 when they're built because of pbr.
>
> If someone is doing CD with the openstack-ansible project and they deploy 
> mitaka once it has a final tag, then they decide to upgrade to run master, 
> they could run into problems upgrading. That said, I think my team is the 
> only team doing this. (Or at least, none of the other active members of the 
> IRC channel talk about doing this.) So it might not be anything more than a 
> "nice to have" especially since no one else from the project has chimed in.

So when we discussed this in Tokyo, we had the view that folk *either*
run master -> master, or they run release->release, or rarely
release->alpha-or-beta.

We didn't think it made sense that folk would start with a stable use
case and evolve that into an unstable one, *particularly* early in the
unstable cycle.

So - if there's one team doing it, I think its keep-both-pieces time.

If its going to be more common than that, we can do the legwork to
make tags early on every time. But I don't think we've got supporting
evidence that its more than you so far :).

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] How do we move forward with xstatic releases?

2016-03-09 Thread Robert Collins
On 10 Mar 2016 2:58 AM, "Radomir Dopieralski" 
wrote:
>
> On 03/09/2016 04:43 PM, Serg Melikyan wrote:
>>>
>>> This is exactly my first thought. The plugins *must* depend on Horizon,
>>> and they have to use the same versions of XStatic packages anyways,
>
> >> so why specify the dependencies twice?
>>
>>
>> Plugins may require different xstatic library, which is not even used
>> by Horizon. Issue raised by Richard exists for plugins too, not only
>> for Horizon itself.
>
>
> How would such an xstatic library conflict with what is in Horizon then,
> though?

Say there are two xstatic libraries, a and b. B depends on a. Horizon
depends only on a. Plugin-foo depends on b. Horizon updates to a version of
a that the version of b consumed by plugin-foo is not compatible with.

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


Re: [openstack-dev] {openstack-dev][tc] Leadership training proposal/info

2016-03-08 Thread Robert Collins
On 9 March 2016 at 09:51, Colette Alexander <colettealexan...@gmail.com> wrote:
>
>
> On Tue, Mar 8, 2016 at 12:27 PM, Matt Riedemann <mrie...@linux.vnet.ibm.com>
> wrote:
>>>
>>>
>>
>> So is this for only current TC members? What about people that aren't on
>> the TC?
>>
>> I asked in this in today's TC meeting but figured I'd ask here where it's
>> more global.
>
>
> Because of limited space in the class, and because of the very early stages
> of figuring out what, exactly, leadership training or support might look
> like in OpenStack, we're focusing on current and future-elected (in April)
> TC members as attendees. If there is any extra space in the class available,
> I'll be sure to announce that here on the ML as soon as we know, and would
> *love* to open space up to the rest of the community, even in these early
> stages. Anyone who's interested in learning more or giving feedback should
> also feel free to ping me on IRC (I'm gothicmindfood) or email - I'm happy
> to answer any and all questions about this.


IMO whatever works for the folk wishing to go is sensible. As I
blogged at the beginning of this cycle, I'm convinced that this is a
useful opportunity for OpenStack as a whole, as well as for the
individuals that attend - I'm very glad you've been pushing
coordination of this forward. Thank you.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] How do we move forward with xstatic releases?

2016-03-08 Thread Robert Collins
On 9 March 2016 at 14:23, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2016-03-09 13:57:45 +1300 (+1300), Robert Collins wrote:
>> On 9 March 2016 at 13:07, Jeremy Stanley <fu...@yuggoth.org> wrote:
>> > On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
>> > [...]
>> >> SOLUTION 6 - make zuul capable of performing atomic cross-repository
>> >> commits.
>> >
>> > This seems unlikely to happen, as it's very much counter to Zuul's
>> > designed-in reliance on serializing changes to test before merging
>> > them.
>>
>> I'd like to explore this more, but a mailing list thread probably
>> isn't terribly efficient - I don't even know where to start to figure
>> out any differing assumptions, whether whats being propose is
>> conceptually desirable and-or how to represent that in zuul. But we've
>> spent nearly three days of bug smash here in sydney trying to get some
>> sort of design for going forward, and so far this is the only one that
>> hasn't bad pretty big negative external side effects such as 'break
>> every other user of xstatic when horizon updates'. :(.
>>
>> So -> IRC and/or/perhaps voice?
>
> ML thread will probably work for some initial exploration, but with
> James leading the Zuul v3 design and implementation he's in the best
> position to say whether it's going to be sane to support having
> changes in multiple repos which must test and merge together rather
> than being able to merge one before the other. Previously we've seen
> the idea of atomic merges coordinated across multiple repositories
> to be a sign of poor software design, and as such have actively
> discouraged the notion (it did come up briefly during the original
> cross-repo dependencies design, and was pretty quickly rejected as
> unsanitary).
>
> Anyway, I'll give him a heads up on this since he likely doesn't
> follow Horizon-specific discussions very closely.

Thanks. The driving factor here is that supporting both versions of
many of these static things - both JS, and the html that interacts
with it - is very tricky. E.g. having two copies of all templates
tricky.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] How do we move forward with xstatic releases?

2016-03-08 Thread Robert Collins
On 9 March 2016 at 13:07, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2016-03-08 17:25:41 +1100 (+1100), Richard Jones wrote:
> [...]
>> SOLUTION 6 - make zuul capable of performing atomic cross-repository
>> commits.
>
> This seems unlikely to happen, as it's very much counter to Zuul's
> designed-in reliance on serializing changes to test before merging
> them.

I'd like to explore this more, but a mailing list thread probably
isn't terribly efficient - I don't even know where to start to figure
out any differing assumptions, whether whats being propose is
conceptually desirable and-or how to represent that in zuul. But we've
spent nearly three days of bug smash here in sydney trying to get some
sort of design for going forward, and so far this is the only one that
hasn't bad pretty big negative external side effects such as 'break
every other user of xstatic when horizon updates'. :(.

So -> IRC and/or/perhaps voice?

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] audience for release notes

2016-03-01 Thread Robert Collins
There is a fixture in pbr's test suite to create keys with out entropy use,
should be easy to adapt for user by Reno's tests.
On 1 Mar 2016 6:52 AM, "Thomas Goirand"  wrote:

> On 02/29/2016 10:31 PM, Doug Hellmann wrote:
> >>> Give this a try and see if it works any better:
> >>> https://review.openstack.org/285812
> >>
> >> Oh, thanks so much! I'll try and give feedback on review.d.o. Is the
> >> issue around the (missed) use of --debug-quick-random?
> >>
> >> Why do we need Reno unit tests to generate so many GPG keys btw, why not
> >> just one or 2?
> >
> > As you've noticed, reno scans the history of a git repository to find
> > release notes. It doesn't actually read any of the files from the work
> > tree. So for tests, we need to create a little git repo and then tag
> > commits to look like releases. We do that for a bunch of scenarios, and
> > each test case generates a GPG key to use for signing the tags.
>
> The patch works super well, and I uploaded a new version of the Debian
> package with unit tests at build time.
>
> However, the combined output of gnupg and testr is a bit ugly. Wouldn't
> it be nicer to just generate a single GPG key, reused by multiple tests,
> using a unit test fixture?
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] How do I calculate the semantic version prior to a release?

2016-02-26 Thread Robert Collins
On 27 February 2016 at 01:34, Thomas Bechtold <tbecht...@suse.com> wrote:
> On Fri, Feb 26, 2016 at 06:52:03AM -0500, Doug Hellmann wrote:
>> Excerpts from Neil Jerram's message of 2016-02-26 11:27:05 +:
>> > On 26/02/16 11:16, Neil Jerram wrote:
> [snipped]
>> > v = version.VersionInfo('networking-calico').semantic_version()
>> > print v.release_string()
>> > print v.brief_string()
>> > print v.debian_string()
>> > print v.rpm_string()
>>
>> Those do work. I found that there's also an rpm_version command
>> available like this:
>>
>>   python setup.py rpm_version
>
> The output for i.e. for Manila is here "1...b3.dev138"
>
> 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:

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

-Rob



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-02-26 Thread Robert Collins
On 27 February 2016 at 00:52, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Neil Jerram's message of 2016-02-26 11:27:05 +:
>> On 26/02/16 11:16, 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:
>> >
>> > - the new semantic version that would be used if I asked for a formal
>> > release to PyPI
>> >
>> > - the corresponding Debian version
>> >
>> > - the corresponding RPM version.
>> >
>> > Thanks,
>> > Neil
>>
>> The following seems to work, but is it the best way?
>>
>> from pbr import version
>>
>> v = version.VersionInfo('networking-calico').semantic_version()
>> print v.release_string()
>> print v.brief_string()
>> print v.debian_string()
>> print v.rpm_string()
>
> Those do work. I found that there's also an rpm_version command
> available like this:
>
>   python setup.py rpm_version
>
> I don't see a similar command for getting the deb version.
>
> I threw together https://review.openstack.org/#/c/285250/ with some
> additions to pbr's "info" command to expose these formats.

I'll review in detail on gerrit, but we probably want an option to get
a *released* versions of debian and rpm versions too - not just the
current version - thats basically
v= SemanticVersion(orig_v.brief_string())
v.debian_string()
v.rpm_string()

-Rob




-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-02-26 Thread Robert Collins
On 27 February 2016 at 00:24, Jeremy Stanley <fu...@yuggoth.org> wrote:
> On 2016-02-26 11:13:52 + (+), 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:
>>
>> - the new semantic version that would be used if I asked for a formal
>> release to PyPI
> [...]
>
> To my knowledge, we have no automation to do this for you. Deciding
> what the next version number of a project should be based on any
> backward incompatibility, new features and so on, is a human-made
> determination. Someone identifies these factors a bit subjectively
> based on the published guidelines and history/release notes and then
> pushes a tag with a new version number based on that determination.

We certainly do -
http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/juno/pbr-semver.rst
was the spec for it. All it relies on is the use of git tags for
release, + the sem-ver pseudo-header to provoke major and minor
version bumps.

> If you're using PBR in an unreleased repository state, it can
> auto-calculate a temporary "dev" version based on the lowest
> possible next version number which sorts after the most recent tag,
> but that's really only a reflection of what the next version should
> be _if_ all the changes since the last tag are trivial bug fixes.

No - its much more than that. See
http://docs.openstack.org/developer/pbr/#version

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

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

2016-02-26 Thread Robert Collins
On 27 February 2016 at 00:13, Neil Jerram <neil.jer...@metaswitch.com> 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.

> - the new semantic version that would be used if I asked for a formal
> release to PyPI

We were/are going to add a command to tag for you, but just querying
it would be good too.

> - the corresponding Debian version

I don't think we expose that yet (but we should).

> - the corresponding RPM version.

As already mentioned, the rpm_version command exposes this.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][glance][barbican][kite][requirements] pycrypto vs pycryptodome

2016-02-16 Thread Robert Collins
I suggest:
 - pin anything that moves
 - start being strict ourselves to prepare for moving
 - work with paramiko to help them move

Sadly Python doesn't have either-or dependencies as yet, so we're
going to be in the position of having to override pip for some time
during the migration process.

-Rob

On 15 February 2016 at 11:16, Davanum Srinivas <dava...@gmail.com> wrote:
> Hi,
>
> Short Story:
> pycryptodome if installed inadvertently will break several projects:
> Example : https://review.openstack.org/#/c/279926/
>
> Long Story:
> There's a new kid in town pycryptodome:
> https://github.com/Legrandin/pycryptodome
>
> Because pycrypto itself has not been maintained for a while:
> https://github.com/dlitz/pycrypto
>
> So folks like pysaml2 and paramiko are trying to switch over:
> https://github.com/rohe/pysaml2/commit/0e4f5fa48b1965b269f69bd383bbfbde6b41ac63
> https://github.com/paramiko/paramiko/issues/637
>
> In fact pysaml2===4.0.3 has already switched over. So the requirements
> bot/script has been trying to alert us to this new dependency, you can
> see Nova fail.
> https://review.openstack.org/#/c/279926/
>
> Why does it fail? For example, the new library is strict about getting
> bytes for keys and has dropped some parameters in methods. for
> example:
> https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/PublicKey/RSA.py#L405
> https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA.py#L499
>
> Another problem, if pycrypto gets installed last then things will
> work, if it pycryptodome gets installed last, things will fail. So we
> definitely cannot allow both in our global-requirements and
> upper-constraints. We can always try to pin stuff, but things will
> fail as there are a lot of jobs that do not honor upper-constraints.
> And things will fail in the field for Mitaka.
>
> Action:
> So what can we do? One possibility is to pin requirements and hope for
> the best. Another is to tolerate the install of either pycrypto or
> pycryptodome and test both combinations so we don't have to fight this
> battle.
>
> Example for Nova : https://review.openstack.org/#/c/279909/
> Example for Glance : https://review.openstack.org/#/c/280008/
> Example for Barbican : https://review.openstack.org/#/c/280014/
>
> What do you think?
>
> Thanks,
> Dims
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][requirements] Why do we use pip install -U as our install_command

2016-02-15 Thread Robert Collins
On 11 February 2016 at 16:09, Clark Boylan <cboy...@sapwetik.org> wrote:
> The reason that I remember off the top of my head is because we spent
> far too much time telling people to run `tox -r` when their code failed
> during Jenkins testing but ran just fine locally. It removes a
> significant amount of debugging overhead to have everyone using a
> relatively consistent set of packages whenever they rerun tests.

So for liberty and up, we have constraints which avoid this - every
run will be precisely specified once a project has adopted the tox
rules. For kilo, if the only reason for -U was to deal with bad lower
requirements / missing exclusions for bad releases (which is what I
infer from what you recall) then I think we're better off without -U
in kilo, because so much of our requirements in kilo are not capped,
we're going to face growing breakage as external projects do change
things.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Mock and the stdlib

2016-02-10 Thread Robert Collins
We've just had a mass gate breakage due to
https://review.openstack.org/#/c/268945/ go through, so I thought I'd
try to get ahead of anyone trying this again.

unittest.mock in the stdlib is not static, it evolves over time. We're
currently writing to - and depending on - the unittest.mock version
approximately == that in python 3.5. Until we have that as our minimum
python version - no 2.7 - we can't just use 'unittest.mock'.

'mock', the original code that became unittest.mock, is still
maintained. Its a rolling backport of the features that land in
Python's stdlib, which lets us use newer features on older pythons. So
- until the hypothetical date where our minimum Python version is
newer than the oldest capability we need from unittest.mock, we're
going to be using 'mock', not 'unittest.mock'.

-> noone should be importing 'unittest.mock', and 'mock' is the
dependency, not conditional on any given version of Python.

I'm sorry I didn't spot 268945 going through, or I would have -2'd it :(.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [oslo] Sachi King for oslo core

2016-01-24 Thread Robert Collins
Hey, so I'd like to propose Sachi - one of my HPE colleages who has
been helping out with pbr for a while now, for oslo core. pbr is
pretty quiet as you know, so its a bit hard to assess her work based
on reviews done - but I think her error rate will be
approximately the same as mine - pbr is such a minefield that everyone
will make mistakes, but she is thoughtful and has been burnt enough by
the minefield that she's developing quite the paranoia about
interactions in the wild. \o/

I'd actually like to propose her for oslo core, not just pbr: though she
doesn't have a big track record there outside of pbr, I don't see much
point in restricting her to just pbr - she's very
diligent and I'm sure if we offered it she'd do more for oslo code
review than I've managed to. I have asked her if she's interested, and
if she could commit to doing some reviews in oslo outside of pbr
itself - which she has said she is and can.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Stabilization cycles: Elaborating on the idea to move it forward

2016-01-21 Thread Robert Collins
On 21 January 2016 at 07:38, Ian Cordasco <ian.corda...@rackspace.com> wrote:
>
> I think this is a solid proposal but I'm not sure what (if anything) the TC 
> needs to do about this. This is something most non-corporate open source 
> projects do (and even some corporate open source projects). It's the natural 
> life-cycle of any software project (that we ship a bunch of things and then 
> focus on stability). Granted, I haven't seen much of a focus on it in 
> OpenStack but that's a different story.
>
> That said, I'd like to see a different release cadence for cycles that are 
> "stabilization cycles". We, as a community, are not using minor version 
> numbers. During a stabilization cycle, I would like to see master be released 
> around the 3 milestones as X.1.0, X.2.0, X.3.0. If we work that way, then 
> we'll be able to avoid having to backport a lot of work to the X.0 series and 
> while we could support X.0 series with specific backports, it would avoid 
> stressing our already small stable teams. My release strategy, however, may 
> cause more stress for downstream packages though. It'll cause them to have to 
> decide what and when to package and to be far more aware of each project's 
> current development cycle. I'm not sure that's positive.

So the reason this was on my todo this cycle - and I'm so glad Flavio
has picked it up (point 9 of
https://rbtcollins.wordpress.com/2015/11/02/openstack-mitaka-debrief/)
- was that during the Tokyo summit, in multiple sessions, folk were
saying that they wanted space from features, to consolidate already
added things, and to cleanup accrued debt, and that without TC
support, they couldn't sell it back to their companies.

Essentially, if the TC provides some leadership here: maybe as little as:
 - its ok to do it [we think it will benefit our users]
 - sets some basic expectations

And then individual projects decide to do it (whether thats a PTL
call, a vote, core consensus, whatever) - then developers have a
platform to say to their organisation that the focus is X, don't
expect features to land - and that they are *expected* to help with
the cycle.

Without some framework, we're leaving those developers out in the cold
trying to explain what-and-why-and-how all by themselves.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][[Infra] Gate failure

2016-01-19 Thread Robert Collins
I suspect we'll see fallout in unit tests too, once new images are built.

On 20 January 2016 at 14:47, Davanum Srinivas <dava...@gmail.com> wrote:
> https://review.openstack.org/#/c/269954/ is the plan of action.
> @mtreinish is driving it. Plan is to request infra to promote it once
> it passes check. This is not a neutron only break. it breaks all dsvm
> jobs.
>
> -- Dims
>
> On Tue, Jan 19, 2016 at 8:28 PM, Armando M. <arma...@gmail.com> wrote:
>> Hi neutrinos,
>>
>> New week, new gate failure. This time this might be infra related [1]. This
>> one fails with [2]. If you know what's going on, spread the word!
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/269937/
>> [2]
>> http://logs.openstack.org/37/269937/1/check/gate-tempest-dsvm-neutron-full/a91b641/logs/devstacklog.txt.gz#_2016-01-20_01_12_41_571
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] re-introducing twisted to global-requirements

2016-01-13 Thread Robert Collins
On 8 January 2016 at 08:09, Jim Rollenhagen <j...@jimrollenhagen.com> wrote:
> Hi all,
>
> A change to global-requirements[1] introduces mimic, which is an http
> server that can mock various APIs, including nova and ironic, including
> control of error codes and timeouts. The ironic team plans to use this
> for testing python-ironicclient without standing up a full ironic
> environment.

Whee that was a bit of a thread. Sorry for kicking this off on IRC and
not chiming in until now.

As I read it the following points were made:
  - this is a new an different testing thing
  - which has the same interface skew issues as regular mocks
  - and devs may need to hack twisted to fix issues with it in future
  - but it is being used to target local devs, not gate jobs [today]

Interface skew can be handled a couple of ways. I'm a big fan of a
technique (that I *think* came out of Google) of having a test fake
layer which is substitutable by real things, so you can always run it
in 'slow mode' to make sure things still work with real components.
It's my understanding that with the way mimic is used, this can be
done: run the same tests with real e.g. devstack brought up
components. I think that that is good insurance, particularly if this
is being done periodically rather than
when-someone-remembers-or-has-an-issue.

Another way to mitigate interface skew is to have the publisher of an
interface also publish a fast test fake for folk to use. I am also a
fan of doing that, but as we haven't done so yet, I think its ok to go
with what we have. If we couldn't run the same things with a real
implementation, I would be more worried - because mocks of moving
interfaces are fragile (e.g. mocking out oslo.config is fragile vs
mocking out os.unlink).

Personally, I'm fine hacking on Twisted code - I quite like it
(particularly good Twisted code :)) - and since folk seem ok with that
aspect, great - thank you for raising the discussion here.

I look forward to hearing how it goes for Ironic.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Further closing the holes that let gate breakage happen

2016-01-13 Thread Robert Collins
On 14 January 2016 at 08:24, Carl Baldwin <c...@ecbaldwin.net> wrote:
> Hi,
>
> I was looking at the most recent gate breakage in Neutron [1], fixed
> by [2].  This gate breakage was held off for some time by the
> upper-constraints.txt file.   This is great progress and I applaud it.
> I'll continue to cheer on this effort.
>
> Now to the next problem.   If my assessment of this gate failure is
> correct, the update to the upper-constraints file [3] was merged
> without running all of the tests across all of the projects that would
> be broken by bringing in this new constraint.  So, we still get
> breakage and it is still (IMO) too often.
>
> As I see it, there are a couple of options.
>
> 1) We run all tests under the upper-constraints control on all updates
> to the upper constraints file like [2].  This would probably mean each
> update has a very long list of tests and we would require that they
> all be fixed before the upper constraint update can be merged.  This
> seems like a difficult thing to coordinate all at once.

We don't need to run 100% of tests to have good coverage - breakage
mitigation is probabalistic, and I think always will be - its the
combination of far too many interacting variables to be otherwise.

We tried to add some unit test jobs to cross check constraints, but we
need some infrastructure work to permit specifying that a unit test
job for a change to requirements checkout the code for e.g. nova and
run nova's tests. Jeremy has more info on that :).

> 2) We handle upper-constraints much like we do the global requirements
> updates.  We have the master and a bot that proposes updates to it out
> to the individual projects.  This would create a situation where
> projects are out of sync with the master but I think if we froze the
> master early enough, we could have time to reconcile before release.

Part of the fundamental design of constraints is that its a single
point of control - so we can fix it with a single commit.

> 3) We continue to allow changes in the upper constraints to break
> individual projects.
>
> Are there options that I missed?  What is your opinion?  In my
> opinion, gate breakage happens a bit too often and the effect on the
> community is widespread.  I'd like to contain it even a little bit
> more.
>
> Carl
>
> [1] https://bugs.launchpad.net/neutron/+bug/1533638
> [2] https://review.openstack.org/#/c/266885/
> [3] https://review.openstack.org/#/c/266042/
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Horizon kilo gate fails due to testrepository dependency

2016-01-04 Thread Robert Collins
On 5 January 2016 at 11:59, Robert Collins <robe...@robertcollins.net> wrote:
> This is odd indeed. pbr is not meant to have a dep on testrepository,
> and you can see in
> https://git.openstack.org/cgit/openstack-dev/pbr/tree/pbr/testr_command.py#n150
> that we only access it if it is installed and we use latest pbr
> everywhere because otherwise we can't deal with ecosystem changes to
> e.g. setuptools or pip.
>
> http://logs.openstack.org/96/262296/2/check/gate-tempest-dsvm-full/e47e5c6/logs/devstacklog.txt.gz#_2015-12-30_09_53_14_200
> shows that the latest pbr (1.8.1 which would work) is being
> downgraded. Thats when the problem is introduced. However, kilo has
> that special thing where pbr is capped because a lot of dependencies
> error due to version disagreements (not API breaks - pbr is
> compatible!), so this is expected :(.
>
> I'm not sure what has caused testrepository to not be installed in
> this scenario, but thats what I'd be looking at.
>

Further to that, I suspect setuptools may have changed -
https://pypi.python.org/pypi/setuptools - 19.2 was released
suspiciously close to the point errors were reported (25th dec).

Looking now..

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][nova][all] timeutils deprecation removals will break Nova

2015-12-21 Thread Robert Collins
On 21 December 2015 at 04:57, Davanum Srinivas <dava...@gmail.com> wrote:
> Nova folks,
>
> We have this review in oslo.utils:
> https://review.openstack.org/#/c/252898/
>
> There were failed effort in the past to cleanup in Nova:
> https://review.openstack.org/#/c/164753/
> https://review.openstack.org/#/c/197601/
>
> What do we do? Suggestions please.

We don't remove it yet. Not till liberty-eol at the earliest, or if we
don't get users migrated early enough, mitaka-eol.

We would benefit from an automated thing in place to tell projects
like Nova that they are using deprecated things during CI (without
bloating deployer logs) -  whether a keystone API, an oslo config
option or function, or $whatever. We would also benefit from a thing
to rollup such information from consuming projects back to the
deprecating project, so we can tell whether we're ready to cleanup old
things.

I think in general that there needs to be a balance around effort on
migrations: if oslo deprecates something - anything - we're creating
work for consumers of oslo. Its unfair for us to do that unilaterally.
Conversely, if projects don't migrate away from poor APIs onto newer
better ones, they create long term maintenance work for oslo: so we
all need to work together to coordinate such things.

https://review.openstack.org/#/c/226157/12 is part of this - it is an
effort to bring consistency in expectations and process/patterns here.

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [gate] any project using olso.db test_migrations is currently blocked

2015-12-17 Thread Robert Collins
On 18 December 2015 at 16:58, Mike Bayer <mba...@redhat.com> wrote:
>
>

>> Or do you still consider SQLA / Alembic as just a 3rd party lib for
>> OpenStack? Wouldn't it be nice to have it maintained directly in
>> OpenStack infra? Your thoughts?
>
> Alembic / SQLAlchemy are completely outside of Openstack and are
> intrinsic to thousands of non-Openstack environments and userbases.  I
> wonder why don't we ask the same question of other Openstack
> dependencies, like numpy, lxml, boto, requests, rabbitMQ, and everything
> else.

Whats happening organically is that many contributing orgs also
contribute to projects like libvirt, sqlaclhemy and so on - so there's
some 'common funding source' pattern happening - but IMO its entirely
appropriate to consider these projects as independent. Because.. they
are :).

> As far as it being *gated*, that is already the plan within Openstack
> itself via the upper-constraints system discussed in this thread, which
> I mistakenly thought was already in use across the board.  That is, new
> release of library X hits pypi, some series of CI only involved with
> testing new releases of libs above that of upper-constraints runs tests
> on it to see if it breaks current openstack applications, and if so, the
> constraints file stays unchanged and the bulk of gate jobs remain
> unaffected.

Yah, we're rolling that out more broadly at the moment. cookiecutter
has been updated, there's a review setting -constraints as the
expected pattern in the infra manual now.

-Rob


-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] tox 2.3.0 broke tempest jobs

2015-12-13 Thread Robert Collins
On 13 December 2015 at 03:20, Yuriy Taraday <yorik@gmail.com> wrote:
> Tempest jobs in all our projects seem to become broken after tox 2.3.0
> release yesterday. It's a regression in tox itself:
> https://bitbucket.org/hpk42/tox/issues/294
>
> I suggest us to add tox to upper-constraints to avoid this breakage for now
> and in the future: https://review.openstack.org/256947
>
> Note that we install tox in gate with no regard to global-requirements, so
> only upper-constraints can save us from tox releases.

Ah, friday releases. Gotta love them... on my saturday :(.

So - tl;dr AIUI:

 - the principle behind gating changes to tooling applies to tox as well
 - existing implementation of jobs in the gate precludes applying
upper-constraints systematically as a way to gate these changes
 - the breakage we experienced was due to already known-bad system images

Assuming that thats correct, my suggestion would be that we either
make tox pip installed during jobs (across the board), so that we can
in fact control it with upper-constraints, or we work on functional
tests of new images before they go-live

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] stable/liberty branch needed for oslo-incubator

2015-12-13 Thread Robert Collins
On 14 December 2015 at 15:28, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote:
>
>
> I don't have a pressing need to backport something right now, but as long as
> there was code in oslo-incubator that *could* be synced to other projects
> which wasn't in libraries, then that code could have bugs and code require
> backports to stable/liberty oslo-incubator for syncing to projects that use
> it.

I thought the thing to do was backport the application of the change
from the projects master?

-Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [all] last-call backwards compat for libraries and clients spec

2015-12-09 Thread Robert Collins
https://review.openstack.org/#/c/226157/ is very close to consensus
now, at least as I read it. Please do weigh in this week, as I expect
the cross project meeting next week to be the last discussion of it
before it goes to the TC.

Cheers,
Rob

-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][glance][all] Removing deprecated functions from oslo_utils.timeutils

2015-12-09 Thread Robert Collins
On 10 December 2015 at 18:19, Davanum Srinivas  wrote:
> So clearly the deprecation process is not working as no one looks at
> the log messages and fix their own projects. Sigh!

I think we need some way to ensure that a deprecation has been done:
perhaps a job that we can run on each oslo project which fails if
deprecated things are in use; we can have that on non-voting, and then
use it to detect the release in which we can start the removal clock
for a deprecated thing.

-Rob

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


Re: [openstack-dev] [oslo][glance][all] Removing deprecated functions from oslo_utils.timeutils

2015-12-09 Thread Robert Collins
I'm not suggesting we increase Oslo responsibilities, but that we need a
non fire drill way to signal that the work hasn't been done.
On 10 Dec 2015 6:42 PM, "Davanum Srinivas" <dava...@gmail.com> wrote:

> Rob,
>
> This is a shared responsibility. I am stating that projects using oslo
> are failing to take up their share of things to be done. No, we should
> not increase more responsibility on Oslo team.
>
> -- Dims
>
> On Thu, Dec 10, 2015 at 8:25 AM, Robert Collins
> <robe...@robertcollins.net> wrote:
> > On 10 December 2015 at 18:19, Davanum Srinivas <dava...@gmail.com>
> wrote:
> >> So clearly the deprecation process is not working as no one looks at
> >> the log messages and fix their own projects. Sigh!
> >
> > I think we need some way to ensure that a deprecation has been done:
> > perhaps a job that we can run on each oslo project which fails if
> > deprecated things are in use; we can have that on non-voting, and then
> > use it to detect the release in which we can start the removal clock
> > for a deprecated thing.
> >
> > -Rob
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [release] preparing your mitaka-1 milestone tag

2015-12-03 Thread Robert Collins
On 28 November 2015 at 03:32, Doug Hellmann <d...@doughellmann.com> wrote:
> Next week (Dec 1-3) is the Mitaka 1 milestone deadline. Release
> liaisons for all managed projects using the cycle-with-milestones
> release model will need to propose tags for their repositories by
> Thursday. Tag requests submitted after Dec 3 will be rejected.
...
> 3. Prepare a patch to the project repository removing the version
>line from setup.cfg.
>
>Set the patch to depend on the release patch from step 1, and
>use the topic "remove-version-from-setup".

There is a gotchya here that may confuse people. The patch in step 3,
if prepared concurrently with the tag, will show versions regressing,
but in the gate it will do the right thing!

The issue is merely that if the local git revision doesn't reach the
tag, then as far pbr is concerned (and git describe), the new tag
doesn't exist, and so its like step 2 was skipped. So - to avoid
confusing anyone, make sure you base the patch for step 3 on top of
the revision being tagged in step 2.



-- 
Robert Collins <rbtcoll...@hpe.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][all] The lock files saga (and where we can go from here)

2015-11-30 Thread Robert Collins
On 1 December 2015 at 08:37, Ben Nemec  wrote:
> On 11/30/2015 12:42 PM, Joshua Harlow wrote:
>> Hi all,
>>
>> I just wanted to bring up an issue, possible solution and get feedback
>> on it from folks because it seems to be an on-going problem that shows
>> up not when an application is initially deployed but as on-going
>> operation and running of that application proceeds (ie after running for
>> a period of time).
>>
>> The jist of the problem is the following:
>>
>> A <> has a need to ensure that no
>> application on the same machine can manipulate a given resource on that
>> same machine, so it uses the lock file pattern (acquire a *local* lock
>> file for that resource, manipulate that resource, release that lock
>> file) to do actions on that resource in a safe manner (note this does
>> not ensure safety outside of that machine, lock files are *not*
>> distributed locks).
>>
>> The api that we expose from oslo is typically accessed via the following:
>>
>>oslo_concurrency.lockutils.synchronized(name, lock_file_prefix=None,
>> external=False, lock_path=None, semaphores=None, delay=0.01)
>>
>> or via its underlying library (that I extracted from oslo.concurrency
>> and have improved to add more usefulness) @
>> http://fasteners.readthedocs.org/
>>
>> The issue though for <> is that each of
>> these projects now typically has a large amount of lock files that exist
>> or have existed and no easy way to determine when those lock files can
>> be deleted (afaik no? periodic task exists in said projects to clean up
>> lock files, or to delete them when they are no longer in use...) so what
>> happens is bugs like https://bugs.launchpad.net/cinder/+bug/1432387
>> appear and there is no a simple solution to clean lock files up (since
>> oslo.concurrency is really not the right layer to know when a lock can
>> or can not be deleted, only the application knows that...)
>>
>> So then we get a few creative solutions like the following:
>>
>> - https://review.openstack.org/#/c/241663/
>> - https://review.openstack.org/#/c/239678/
>> - (and others?)
>>
>> So I wanted to ask the question, how are people involved in <> favorite openstack project>> cleaning up these files (are they at all?)
>>
>> Another idea that I have been proposing also is to use offset locks.
>>
>> This would allow for not creating X lock files, but create a *single*
>> lock file per project and use offsets into it as the way to lock. For
>> example nova could/would create a 1MB (or larger/smaller) *empty* file
>> for locks, that would allow for 1,048,576 locks to be used at the same
>> time, which honestly should be way more than enough, and then there
>> would not need to be any lock cleanup at all... Is there any reason this
>> wasn't initially done back way when this lock file code was created?
>> (https://github.com/harlowja/fasteners/pull/10 adds this functionality
>> to the underlying library if people want to look it over)
>
> I think the main reason was that even with a million locks available,
> you'd have to find a way to hash the lock names to offsets in the file,
> and a million isn't a very large collision space for that.  Having two
> differently named locks that hashed to the same offset would lead to
> incredibly confusing bugs.
>
> We could switch to requiring the projects to provide the offsets instead
> of hashing a string value, but that's just pushing the collision problem
> off onto every project that uses us.
>
> So that's the problem as I understand it, but where does that leave us
> for solutions?  First, there's
> https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/lockutils.py#L151
> which allows consumers to delete lock files when they're done with them.
>  Of course, in that case the onus is on the caller to make sure the lock
> couldn't possibly be in use anymore.
>
> Second, is this actually a problem?  Modern filesystems have absurdly
> large limits on the number of files in a directory, so it's highly
> unlikely we would ever exhaust that, and we're creating all zero byte
> files so there shouldn't be a significant space impact either.  In the
> past I believe our recommendation has been to simply create a cleanup
> job that runs on boot, before any of the OpenStack services start, that
> deletes all of the lock files.  At that point you know it's safe to
> delete them, and it prevents your lock file directory from growing forever.

Not that high - ext3 (still the default for nova ephemeral
partitions!) has a limit of 64k in one directory.

That said, I don't disagree - my thinkis is that we should advise
putting such files on a tmpfs.

-Rob

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


Re: [openstack-dev] More and more circular build dependencies: what can we do to stop this?

2015-11-26 Thread Robert Collins
On 27 November 2015 at 03:50, Thomas Goirand <z...@debian.org> wrote:
> Hi,
>
> As a package maintainer, I'm seeing more and more circular
> build-dependency. The latest of them is between oslotest and oslo.config
> in Mitaka.
>
> There's been some added between unittest2, linecache2 and traceback2
> too, which are now really broadly used.
>
> The only way I can work around this type of issue is to temporarily
> disable the unit tests (or allow them to fail), build both packages, and
> revert the unit tests tweaks. That's both annoying and frustrating to do.
>
> What can we do so that it doesn't constantly happen again and again?
> It's a huge pain for downstream package maintainers and distros.
>
> Cheers,
>
> Thomas Goirand (zigo)

Firstly, as Thierry says, we're not well equipped to stop things
happening without tests, its the nature of a multi-thousand developer
structure.

Secondly, the cases you site are not circular build dependencies: they
are circular test dependencies, which are not the same thing.

I realise that the Debian and RPM tooling around this has historically
been weak, but its improving -
https://wiki.debian.org/DebianBootstrap#Circular_dependencies.2Fstaged_builds
- covers the current state of the art, and should, AIUI, entirely
address your needs: you do one build that is just a pure build with no
tests-during-build-time, then when the build phase of everything is
covered, a second stage 'normal' build that includes tests.

-Rob


-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [hyper-v] oslo.privsep vs Windows

2015-11-25 Thread Robert Collins
On 26 November 2015 at 15:54, Alessandro Pilotti
<apilo...@cloudbasesolutions.com> wrote:
> Basic Python development does not really differ too much on Windows compared
> to Linux.
>
> Let’s start with the Python environment. I’d recommend to install a 2.7
> (x86) one and a 3.4 (x64) one:
>
> https://www.python.org/ftp/python/2.7.10/python-2.7.10.msi
> https://www.python.org/ftp/python/3.4.3/python-3.4.3.amd64.msi
>
> Download also git for Windows: https://git-scm.com/download/win
> Git works in the same way, so nothing particular to add. Just take care of
> the line endings. I usually keep them all in LF, avoiding CRLF, others let
> git do the conversion.
>
> When done, open a PowerShell or command prompt and set your PATH and
> PYTHONPATH e.g.:
>
> $ENV:PATH += ";C:\Python27;C:\Python27\Scripts"
> $ENV:PYTHONPATH = "."
>
> From here is pretty standard Python, e.g.:
>
> pip install “blah>=1.0.0"
> pip install –r requirements.txt
>
> python yourmodule.py
>
> For running tests you can use for example nose since tox / testr don’t
> really work:
>
> pip install mock
> pip install nose
> nosetests .

i haven't seen any bug reports on testrepository vis-a-vis windows;
please do file them, otherwise I'll presume it works.

-Rob

-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [pbr][oslo] volunteer needed to increase pbr test coverage of sphinx

2015-11-25 Thread Robert Collins
Hi, so pbr has some glue that revolves around running sphinx, and it
got messy and broken with Sphinx 1.3.

Its been broken in a subtle way since then - warnerrors has no effect,
and previous attempts to get it working have broken things in a hard
visible way.

Doug has a patch up - https://review.openstack.org/#/c/229951/1 to fix
things, which may even be right on both sphinx < 1.3 and >=1.3 ... -
but without enough test coverage to know, we're basically guessing,
and since pbr is at the bottom of the ecosystem stack, guessing is a
high-risk activity there.

What we'd like is if someone could backfill the crucial test coverage:
we need to expand the coverage added in
https://review.openstack.org/#/c/189884/2/pbr/tests/test_core.py to
test a 2x2x2 matrix:

One dimension is the sphinx version - < 1.3 and >=1.3

The next dimension is the warnerrors flag - on or off

and the last dimension is whether the project has warnings or not.

pbr's test suite has a virtualenv fixture that makes putting together
arbitrary package combinations pretty straight forward, and I'd be
delighted to mentor someone who picks this up.

The current status quo means we have bitrot happening in docs jobs
across all of openstack, and its accruing project wide tech debt at an
unpleasant rate :(.

-Rob

-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Thoughts on python-future?

2015-11-25 Thread Robert Collins
On 26 November 2015 at 10:08, Eric Kao <ekcs.openst...@gmail.com> wrote:
> I think the main benefit of python-future is that the library helps us
> write straight Python 3 code instead of special bridged code.
>
> For example, instead of writing six.iteritems(dict0), one could write
> simply dict0.items() and expect Python 3 behavior across Python 2 & 3.

But - one shouldn't be writing six.iteritems(dict0) *anyway* except in
really specific circumstances. We had a mega thread on that a few
months back - tl;dr at our scale - even at our aspirational scale - it
rarely if ever matters.

Its that that makes me actually skeptical - the overheads of 2+3
single tree compat are really really low already, generally.

-Rob



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Thoughts on python-future?

2015-11-24 Thread Robert Collins
Which bit in particular do you like? Some of the stuff - like
past.translation - is likely to be deeply fragile, other bits are
fine, but not really any different to six.

On 25 November 2015 at 15:33, Eric Kao <ekcs.openst...@gmail.com> wrote:
> Hi all,
>
> I’ve been using the python-future library for Python 3 porting and want to
> see what people think of it. http://python-future.org/overview.html#features
>
> The end result is standard Python3 code made compatible with Python2 through
> library imports. The great thing is that Python 3 execution is mostly
> independent of the library, so once Python 2 support is dropped, the use of
> the library can be dropped too.
>
> Anyone know why it’s not used in OpenStack perhaps alongside six? Thanks!
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] process change for closing bugs when patches merge

2015-11-24 Thread Robert Collins
On 25 November 2015 at 05:26, Thierry Carrez <thie...@openstack.org> wrote:
...
> So it would be a shame to restrict task tracking possibilities to two
> projects per bug just to preserve accurate change tracking in Launchpad,
> while the plan is to focus Launchpad usage solely on task tracking :)

I don't think it would be a shame, I think it would work better :).
The vast majority of multi-project bugs I see in LP are not
multi-project bugs (defined as one conversation, many work items), but
rather conceptually similar things (many conversations started from
one seed).

Anyhow, thats a different discusion :)

-Rob

-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] process change for closing bugs when patches merge

2015-11-24 Thread Robert Collins
On 24 November 2015 at 10:58, Doug Hellmann <d...@doughellmann.com> wrote:
> As part of completing the release automation work and deprecating our
> use of Launchpad for release content tracking, we also want make some
> changes to the way patches associated with bugs are handled.
>
> Right now, when a patch with Closes-Bug in the commit message merges,
> the bug status is updated to "Fix Committed" to indicate that the change
> is in git, but not a formal release, and we rely on the release tools to
> update the bug status to "Fix Released" when the release is  made. This
> is one of the most error prone areas of the release process, due to
> Launchpad service timeouts and other similar issues. The fact that we
> cannot reliably automate this step is the main reason we want to stop
> using Launchpad's release content tracking capabilities in the first
> place.

FWIW the reason for timeouts on these bugs is very well known - we use
multi-project bugs, and there is a known performance problem in that
area of the LP code; its considered an attractive nuisance by the LP
team - federation is a superior model with more user control over
notifications and so fort.

So, if folk do want bugs to sit in fix-committed, we can address the
timeouts really very easily: one (or two tops) projects per bug. We
should do that anyway because adding a comment to a bug is also able
to timeout, so our code is still going to suffer the same fragility
and need the same robustness if we're trying to guarantee that the
comment is added.

-Rob



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Should we make qpid/proton optional dependencies? (please say yes)

2015-11-23 Thread Robert Collins
On 23 November 2015 at 22:33, Victor Stinner <vstin...@redhat.com> wrote:
> Hi,
>
> Would it be possible to use the "extra dependencies" thing in setup.cfg?
> Robert Collins started a similar change for Oslo DB for make DB drivers
> optional:
> https://review.openstack.org/#/c/184328/
>
> Sadly, this change was not merged yet.
>
> @Robert: any progress on this change?
>
> It would allow to ask for "Oslo Messaging with Qpid support" in service
> dependencies, without knowning the exact required Python packages for Qpid.

The yaks go deep; we (me, Nakato, StevenK, dims) have been working
through the issues in getting this live.

Most recently (yesterday!) we got a bugfix into pip to let you have
the same thing turn up in both requirements.txt (install_requires) and
a second dependency such as an extras reference - without that, the
idiom we wanted to use won't work if any dep turns up unconditionally
and optionally - thats in pip 8.0 which isn't released yet.

We also have a requirements syncing bug which dims has a patch in
progress for, needed to sync properly with extras references.

I *think* that once both those things happen (pip 8 is released, the
sync bug is landed) that the extras stuff will be unblocked and we can
walk it forward.

-Rob



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

2015-11-23 Thread Robert Collins
On 24 November 2015 at 20:06, Angus Lees <g...@inodes.org> wrote:
> Ah, I could have been clearer.  A workaround for (2) in the original post:
> If you're starting from an older pip version it can be hard to bootstrap the
> right order of new things to correctly survive the new "; predicate"
> requirements.txt syntax.

Oh. So yes and no. That won't help with a number of failures,
specifically conflicts with pbr in setup_requires which will happen at
sdist time if the setuptools and or pbr *outside* the venv are too
old.

https://rbtcollins.wordpress.com/2015/07/12/bootstrapping-developer-environments-for-openstack/

is my recipe for avoiding issues - and doesn't require mucking about
with system packages, nor changing tox.ini.

It has one known defect - I need to update it for the
python3-as-default changes that are rippling through various distros
at the moment, since they change the packages that one needs to not
use - but putting stuff in a user-install and not touching the system
packages is still superior and doesn't require any purging etc.

-Rob



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [oslo] Please stop removing usedevelop from tox.ini (at least for now)

2015-11-22 Thread Robert Collins
Workaround for what?

-Rob

On 23 November 2015 at 19:39, Angus Lees <g...@inodes.org> wrote:
> The workaround I found is to set this in tox.ini:
>
> install_command =
>  sh -c 'pip install -U "pip>=6" && pip install -U "$@"' pip {opts}
> {packages}
>
> It's pretty ugly, but works fine and was unfortunately the only way I could
> find to update a dependency before parsing requirements.txt.
>
>  - Gus
>
> On Tue, 17 Nov 2015 at 06:25 Doug Hellmann <d...@doughellmann.com> wrote:
>>
>> Excerpts from gord chung's message of 2015-11-16 12:04:27 -0500:
>> >
>> > On 16/11/2015 11:13 AM, Doug Hellmann wrote:
>> > >   does anyone want to sign up to remove that last
>> > > namespace package?
>> > already in action: https://review.openstack.org/#/c/243255/
>> >
>>
>> Thanks, Gordon!
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] [trove] trove unit tests failing on stable/kilo

2015-11-18 Thread Robert Collins
On 18 November 2015 at 16:27, Matt Riedemann <mrie...@linux.vnet.ibm.com> wrote:
>
>
> On 11/17/2015 9:22 PM, Matt Riedemann wrote:
>>
>> I noticed this failing today:
>>
>>
>> http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_061
>>
>>
>> Looks like https://review.openstack.org/#/c/218701/ and maybe the
>> dependent python-troveclient change would need to be backported to
>> stable/kilo (neither are clean backports), or we can just skip the test
>> on stable/kilo if there is a good reason why it won't work.
>>
>
> I also see that the unit test job on stable/kilo is pulling in trunk
> python-troveclient:
>
> http://logs.openstack.org/81/206681/3/check/gate-trove-python27/45d645d/console.html#_2015-11-17_17_07_28_393
>
> Even though we have troveclient capped at 1.1.0 in kilo g-r:
>
> https://github.com/openstack/requirements/blob/stable/kilo/global-requirements.txt#L136
>
> So how is that happening?
>
> Oh, because of this:
>
> https://github.com/openstack/trove/blob/stable/kilo/test-requirements.txt#L17
>
> And that's terriblewhy are we doing that?

I know you know this, but yeah - don't do that :).

FWIW constraints *will* override that but liberty and above.

-Rob


-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][all] Oslo libraries dropping python 2.6 compatability

2015-11-16 Thread Robert Collins
Yes, major version bump. As long as we don't have to change any consumers,
we have no backwards compatibility concerns because we deprecated 2.6 in
Juno. However i suspect we will have to change consumers specifically we
still had 2.6 jobs in liberty
On 17 Nov 2015 3:23 AM, "Davanum Srinivas"  wrote:

> Gordon,
>
> When we stop the py26 jobs, the next version we release should have
> major bumps by semver definition. liberty does not have version caps
> unfortunately, but i'll let Doug and others chime in on that.
>
> yes, i know major bumps are hard
>
> thanks,
> dims
>
> On Mon, Nov 16, 2015 at 9:07 AM, gord chung  wrote:
> > do we require a major versioning bump for this? i'm wondering how
> 'breaking'
> > this is in real life if all the services have dropped py2.6 already.
> maybe
> > this just requires an upper-cap in appropriate stable branches?
> >
> > to be devils advocate, one (arguably terrible) reason for not doing a
> major
> > bump is that a lot of libs just did one for the Mitaka cycle.
> >
> > On 11/11/2015 2:14 PM, Davanum Srinivas wrote:
> >>
> >> Folks,
> >>
> >> Any concerns? please chime in:
> >> https://review.openstack.org/244275
> >>
> >> Thanks
> >> -- Dims
> >>
> >
> > --
> > 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo][testing-cabal] Help needed getting oslo.versionedobjects to install in tox venv

2015-11-16 Thread Robert Collins
On 17 November 2015 at 16:25, Jay Pipes <jaypi...@gmail.com> wrote:
> On 11/15/2015 08:10 PM, Robert Collins wrote:
...
>
> Thanks, Robert, but unfortunately that didn't work. I still get the same
> problem:
>
> Downloading/unpacking .[fixtures]
>   Could not find any downloads that satisfy the requirement .[fixtures]
>
> Is ".[fixtures]" really the correct name of the requirement?

It means 'the fixtures extra of the project found in the current
working directory.

You can check setup.cfg if the project is a pbr using one, to see the
defined extras.

> Here is proof that I'm running the right versions of pip and virtualenv
> (installed from scratch with sudo -H python get-pip.py and sudo -H pip
> install virtualenv after clearing the system packages for both)
>
> http://paste.openstack.org/show/479076/
>
> Any other ideas? This is getting quite frustrating :(

Can you attach/pastebin your log files?

/home/jaypipes/repos/oslo.versionedobjects/.tox/py34/log/py34-1.log and

/home/jaypipes/repos/oslo.versionedobjects/.tox/py34/log/py34-0.log ?

also

. .tox/py34/bin/activate
pip list

Thanks!
-Rob





-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][neutron] upper constraints for stable/liberty

2015-11-15 Thread Robert Collins
On 14 November 2015 at 02:53, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
> Hi Sachi and all,
>
> I was recently looking into how stable/liberty branches are set for neutron
> in terms of requirements caps, and I realized that we don’t have neither
> version caps nor upper constraints applied to unit test jobs in
> stable/liberty gate. We have -constraints targets defined in tox.ini, but
> they are not running in gate.
>
> I believe this situation leaves us open to breakages by any random library
> releases out there. Am I right? If so, I would like to close the breakage
> vector for projects I care (all neutron stadium).
>
> I suggest we do the following:
>
> - unless there is some specific reason for that, stop running unconstrained
> jobs in neutron/master;

Sachi King is working up a bit of data mining to confirm that the
constraints jobs are only failing when unconstrained jobs fail - then
we're going to propose the change to project-config to switch around
which vote.

> - enable voting for constraints jobs in neutron/liberty; once proved to work
> fine, stop running unconstrained jobs in neutron/liberty;

I expect the same query can answer this as well.

> - for neutron-*aas, introduce constraints targets in tox.ini, enable jobs in
> gate; make them vote there/remove old jobs;
> - after that, backport constraints targets to stable/liberty; make them vote
> there/remove old jobs.

We're going to advocate widespread adoption once the neutron master
ones are voting

> Does the plan make sense?

Totally :) As non-Neutron-contributors we've just been conservative in
our recommendations; if Neutron wants to move a little faster by
taking on a little risk, thats *totally cool* IMO.

-Rob

-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][testing-cabal] Help needed getting oslo.versionedobjects to install in tox venv

2015-11-15 Thread Robert Collins
On 16 November 2015 at 15:29, Jay Pipes <jaypi...@gmail.com> wrote:
> Hi all,
>
> Really getting frustrated with a particular problem. I'm trying to build
> oslo.versionedobjects locally (this problem occurs on both my lappie and my
> desktop, running Ubuntu 15.04 and 15.10 respectively.
>
> When running tox -epy34, I'm getting an error about not being able to
> install a dependency called ".[fixtures]":
>
> http://paste.openstack.org/show/478933/
>
> Matt Riedemann thought that it had something to do with me using an old
> version of setuptools, but I've upgraded both my site packages setuptools
> and the one in the tox virtualenv to the latest 18.5 setuptools (see proof
> in paste above) and still getting the same problem.
>
> Any help would be appreciated!

It probably means you're installing with an old pip. The most common
way that happens is using distribution versions of virtualenv, because
of how pip gets installed in tox virtualenvs:

virtualenv makes the environment
virtualenv takes a cached wheel from the environment *that virtualenv
ran from* and unpacks it into the tox environment.

tl;dr: sudo apt-get remove python-pip python-virtualenv; install pip
using get-pip.py; sudo -H pip install virtualenv

More info here:
https://rbtcollins.wordpress.com/2015/07/12/bootstrapping-developer-environments-for-openstack/

-Rob

-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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][stackalytics] possibly breaking bug closing statistics?

2015-11-11 Thread Robert Collins
On 12 November 2015 at 03:17, Ilya Shakhat <ishak...@mirantis.com> wrote:
> 2015-11-11 16:38 GMT+03:00 Thierry Carrez <thie...@openstack.org>:
>>
>>
>> date_fix_committed is probably not set if we directly switch the bug to
>> "Fix released", and that is what we plan to do now with Launchpad bugs.
>>
>> We might therefore need a backward-compatible patch to Stackalytics so
>> that it uses (date_fix_committed or date_fix_released) instead.
>
>
> Good point, Thierry.
>
> I have one bug that was transferred from New directly into Fix Released
> state
> (https://bugs.launchpad.net/stackalytics/+bug/1479791). Launchpad sets all
> intermediate
> states, including date_fix_committed:
> "date_fix_committed": "2015-08-03T08:37:49.270140+00:00",
> "date_fix_released": "2015-08-03T08:37:49.270140+00:00",
>
> Not sure if it's documented behavior or not, so the patch to Stackalytics
> would probably
> be preferred.

Released implies committed: being defensive here won't hurt but is IMO
entirely unneeded.

-Rob



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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-operators] [stable][all] Keeping Juno "alive" for longer.

2015-11-09 Thread Robert Collins
On 10 November 2015 at 08:22, matt <m...@nycresistor.com> wrote:
> tons from what i've seen.  there are a LOT of havana and even earlier stuff
> out there.  essex is still out there in the wild.

>From the Mitaka keynotes we know there are substantial sized public
clouds still in production running Diablo...

-Rob



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Outcome of distributed lock manager discussion @ the summit

2015-11-09 Thread Robert Collins
On 10 November 2015 at 19:24, Kevin Carter <kevin.car...@rackspace.com> wrote:
> Hello all,
>
> The rational behind using a solution like zookeeper makes sense however in 
> reviewing the thread I found myself asking if there was a better way to 
> address the problem without the addition of a Java based solution as the 
> default. While it has been covered that the current implementation would be a 
> reference and that "other" driver support in Tooz would allow for any backend 
> a deployer may want, the work being proposed within devstack [0] would become 
> the default development case thus making it the de-facto standard and I think 
> we could do better in terms of supporting developers and delivering 
> capability.
>
> My thoughts on using Redis+Redislock instead of Java+Zookeeper as the default 
> option:
> * Tooz already support redislock
> * Redis has an established cluster system known for general ease of use and 
> reliability on distributed systems.

I believe Clint already linked to
https://aphyr.com/posts/309-knossos-redis-and-linearizability or
similar - but 'known for general ease of use and reliability' is uhm,
a bold claim. Its worth comparing that (and the other redis writeups)
to this one: https://aphyr.com/posts/291-call-me-maybe-zookeeper. "Use
zookeeper, its mature".

> * Several OpenStack projects already support Redis as a backend option or 
> have extended capabilities using a Redis.
> * Redis can be implemented in RHEL, SUSE, and DEB based systems with ease.
> * Redis is Opensource software licensed under the "three clause BSD license" 
> and would not have any of the same questionable license implications as found 
> when dealing with anything Java.

The openjdk is present on the same linux distributions, and has been
used in both open source and proprietary programs for decades. *what*
license implications are you speaking of?

> * The inclusion of Redis would work on a single node allowing developers to 
> continue work using VMs running on Laptops with 4GB or ram but would also 
> scale to support the multi-controller use case with ease. This would also 
> give developers the ability to work on a systems that will actually resemble 
> production.

I believe you can do this with zookeeper - both single process, or
three processes on one machine to emulate a cluster - very easily.
Quoting http://qnalist.com/questions/29943/java-heap-size-for-zookeeper
- "It's more dependent on your workload than anything. If you're
storing on order of hundreds of small znodes then 1gb is going to [be]
more then fine." Obviously we should test this and confirm it, but
developer efficiency is a key part of any decision, and AFAIK there is
absolutely nothing in the way as far as zookeeper goes. Just like
rabbitmq and openvswitch, its a mature thing, written in a language
other than Python, which needs its own care and feeding (and that
feeding is something like 90% zk specific, not 'java headaches').

> * Redislock will bring with it no additional developer facing language 
> dependencies (Redis is written in ANSI C and works ... without external 
> dependencies [1]) while also providing a plethora of language bindings [2].
>
>
> I apologize for questioning the proposed solution so late into the 
> development of this thread and for not making the summit conversations to 
> talk more with everyone whom worked on the proposal. While the ship may have 
> sailed on this point for now I figured I'd ask why we might go down the path 
> of Zookeeper+Java when a solution with likely little to no development effort 
> already exists, can support just about any production/development 
> environment, has lots of bindings, and (IMHO) would integrate with the larger 
> community easier; many OpenStack developers and deployers already know Redis. 
> With the inclusion of ZK+Java in DevStack and the act of making it the 
> default it essentially creates new hard dependencies one of which is Java and 
> I'd like to avoid that if at all possible; basically I think we can do better.


I think its fine to raise the question, but lets perhaps set some priorities.

1) The default should be mature
2) The default should be suitable for developer use on a modest laptop
3) The default should be suitable for use in the majority of clouds

I believe zk meets all those priorities, and redis does not. Its
possible that etcd and or consul do: though they are much newer and so
perhaps fail on the maturity scale. I'm certain redis does not - at
least, not unless the previously reported defects have been fixed in
the last 2 years.

-Rob



-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

__
OpenStack Development Mailing 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] Outcome of distributed lock manager discussion @ the summit

2015-11-05 Thread Robert Collins
On 5 November 2015 at 11:32, Fox, Kevin M <kevin@pnnl.gov> wrote:
> To clarify that statement a little more,
>
> Speaking only for myself as an op, I don't want to support yet one more 
> snowflake in a sea of snowflakes, that works differently then all the rest, 
> without a very good reason.
>
> Java has its own set of issues associated with the JVM. Care, and feeding 
> sorts of things. If we are to invest time/money/people in learning how to 
> properly maintain it, its easier to justify if its not just a one off for 
> just DLM,
>
> So I wouldn't go so far as to say we're vehemently opposed to java, just that 
> DLM on its own is probably not a strong enough feature all on its own to 
> justify requiring pulling in java. Its been only a very recent thing that you 
> could convince folks that DLM was needed at all. So either make java 
> optional, or find some other use cases that needs java badly enough that you 
> can make java a required component. I suspect some day searchlight might be 
> compelling enough for that, but not today.
>
> As for the default, the default should be good reference. if most sites would 
> run with etc or something else since java isn't needed, then don't default 
> zookeeper on.

So lets be clear about the discussion at the summit.

There were three, non-conflicting and distinct concerns raised about Java.

One is the 'its a new platform for us operators to understand
operations around' - which is fair, and indeed, Java has different
(not better, different) behaviours to the CPython VM.

Secondly, 'us operators do not want to be a special snowflake, we
*want* to run the majority configuration' - which makes sense, and is
one reason to aim for a convergent stack where possible.

Thirdly, 'many of our customers *will not* run Oracle's JVM and the
stability and performance of Zookeeper on openjdk is an unknown'. The
argument was that we can't pick zk because the herd run it on Oracle's
JVM not openjdk - now there are some unquantified bits here, but it is
known that openjdk has had sufficient differences to Oracle JVM to
cause subtle bugs, so if most large zk shops are running Oracle JVM
then indeed this becomes a special-snowflake risk.

I don't recall *anyone* saying they thought zk was bad, or that they
would refuse to run it if we had chosen zk rather than tooz. We got
stuck on that third issue - there was no way to answer it in the
session, and its obviously a terrifying risk to take.

And because for every option some operators were going to be unhappy,
we fell back to the choice of not making a choice.

There are a bunch of parameters around DLM usage that we haven't
quantified yet - we can talk capabilities sensibly, but we don't yet
know how much load we will put on the DLM, nor how it will scale
relative to cloud size. My naive expectation is that we'll need a
-very- large cloud to stress the cluster size of any decent DLM, but
that request rate / latency could be a potential issue as clouds scale
(e.g. need care and feeding).

-Rob


-- 
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud

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


  1   2   3   4   5   6   7   8   9   10   >