Re: [openstack-dev] [nova] gate "gate-nova-python27-db" is broken due to oslo.context 2.6.0

[Ronald Bradford]

Hi All,

For Oslo libraries we ensure that API's are backward compatible for 1+ releases.
When an Oslo API adds a new class attribute (as in this example of
is_admin_project and 4 other attributes) added to Oslo Context in
2.6.0,  these are added to ensure this API is also forward compatible
with existing project code for any contract with the base class
instantiation or manipulation.

The issue seen is presently Nova specific (as other projects can
utilize 2.6.0) and it is related to projects that sub-class
oslo.context, and how unit tests are written for using class
parameters.  Ideally, to implement using oslo.context correctly
OpenStack projects should:

* Not perform direct dictionary to dictionary comparisons with the
to_dict() method as this does not support when new attributes at
added. Two patches (one to nova) address this in offending projects
[5][6]
* Unit tests should focus on attributes specific to the sub-classed
signature, e.g. [7].  Oslo context provides an extensive set of unit
tests for base class functionality. This is a wish list item for
projects to implement.

The to_dict() method exists as a convenience method only and is not an
API contract. The resulting set of keys should be used accordingly.
This is why there is no major release version.
There is a note from our discussion in Oslo to improve our
documentation to describe the API use of to_dict() better and state we
will not remove to_dict() keys within a release, but that may happen
between releases.

There is a subsequent problem with how Nova performs a warning test
[8]. Additional reviews are looking at addressing this sub-class usage
of from_dict() and to_dict().

Regards

Ronald


[5] https://review.openstack.org/#/c/343694/,
[6] https://review.openstack.org/#/c/342367/
[7] https://review.openstack.org/#/c/342869/
[8] 
http://git.openstack.org/cgit/openstack/nova/tree/nova/tests/unit/test_context.py#n144

On Mon, Jul 18, 2016 at 10:50 AM, Matt Riedemann
 wrote:
> On 7/18/2016 9:42 AM, Matt Riedemann wrote:
>>
>> On 7/18/2016 9:09 AM, Markus Zoeller wrote:
>>>
>>> Since yesterday, Nova uses "oslo.context" 2.6.0 [1] but the needed
>>> change [2] is not yet in place, which broke "gate-nova-python27-db"[3].
>>> Logstash counts 70 hits/h [4]. Most folks will be at the midcycle in
>>> Portland and won't be available for the next 2h or so.
>>> If you can have a look at it and merge it, that would be great.
>>>
>>> References:
>>> [1]
>>>
>>> https://github.com/openstack/requirements/commit/238389c4ee1bd3cc9be4931dd2639aea2dae70f1
>>>
>>> [2] https://review.openstack.org/#/c/342604/1
>>> [3] https://bugs.launchpad.net/nova/+bug/1603979
>>> [4] logstash: http://goo.gl/79yFb9
>>>
>>
>> This is an API change for oslo.context, why wasn't it released as 3.0.0?
>>
>> Seems we should revert the upper-constraints bump and blacklist 2.6.0,
>> then get that released as 3.0.0.
>>
>
> Here is the blacklist:
>
> https://review.openstack.org/#/c/343683/
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [oslo] Backwards compatibility policy

[Ronald Bradford]

This was a good session lead by Robert to fully understand the
repercussions of not ensuring backward compatibility guidelines.

In layman's terms, an Oslo API change made in Mitaka (the last release)
must remain fully backward compatible throughout the entire Newton release
(the current release).
A great reason is for all other OpenStack projects that do/may use and
adopt any Oslo changes from Mitaka.
If Oslo DID NOT maintain backwards compatibility throughout the full length
of the next cycle, then projects that had either implemented or plan to
implement Mitaka Oslo features may then have failing gate tests during this
cycle causing rework.
Oslo needs to remain stable during an entire cycle to ensure projects can
work consistently with Oslo libraries.

Thanks to Angus Lees (Gus) who in true debate form took the side of nay to
validate the proposal and enable a clear discussion (in the second of last
session).

Ronald



On Fri, Apr 29, 2016 at 2:13 PM, Robert Collins 
wrote:

> 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 
> 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 Development Mailing List (not for 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] Removing Nova specifics from oslo.log

[Ronald Bradford]

Julien,

As mentioned I have been working thru the App Agnostic Parameters blueprint
that will cover review of context attributes and kwarg specific use of
oslo.log.
Presently due to legacy nova usage this current pattern is needed as it.

There was also a discussion at Austin with Michael Still regarding our work
with Nova to enhance usage of resource uuids that will enable some
subsequent deprecated usage of instance specific context and kwargs, but
this requires some pre-requisite work.


Regards

Ronald

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Apr 15, 2016 at 4:11 AM, Julien Danjou <jul...@danjou.info> wrote:

> On Thu, Apr 14 2016, Joshua Harlow wrote:
>
> > Well not entirely IMHO. I think oslo should obviously be easy to use
> inside
> > openstack and as well outside, with preference to inside openstack
> (especially
> > for libraries that start with 'oslo.*'). When we can make it more useable
> > outside openstack (and without hurting the mission of openstack being the
> > primary target for 'oslo.*' libraries) then obviously we should try to
> do our
> > best to...
> >
> > Will all the oslo.* libraries as they exist be forever perfect at a
> given point
> > in time, no. We can always do better, which is where the community comes
> in :)
>
> I tend to agree with you Josh, though you might want to keep in mind
> that OpenStack is now composed of 54 teams and even more projects. So at
> this stage making libraries "for OpenStack" is going to become a very
> vague definition as the need for generic code is going to increase.
>
> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */
>
> __
> OpenStack Development Mailing 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] oslo.context and name fields

[Ronald Bradford]

Sean,

I've taken your WIP https://review.openstack.org/#/c/302744/ a step forward
and its in review now.
I'd value Jamie's input on your proposed from_environ signature change to
see if that does meet his indented goal.

Regards

Ronald



Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Tue, Apr 5, 2016 at 9:53 PM, Jamie Lennox <jamielen...@gmail.com> wrote:

> from_environ was mine, it's reasonably new and at the time i was blocked
> upon getting a release before pushing it out to services. Since then i've
> been distracted with other things. The intent at the time was exactly this
> to standardize the values on the context object, though in my case i was
> particularly interested with how we could handle authentication plugins.
>
> The problems i hit were specifically around how we could seperate values
> that were relevant to things like policy from values that were relevant for
> RPC etc rather that the big to_dict that is used for everything at the
> moment.
>
> There were a number of problems with this, however nothing that would
> prevent more standardization of the base attributes and using from_environ
> now.
>
>
> On 6 April 2016 at 07:39, Ronald Bradford <m...@ronaldbradford.com> wrote:
>
>> I have created a version that use constructor arguments. [5]
>> I will review in more detail across projects the use of keystone
>> middleware to see if we can utilize a constructor environment attribute to
>> simply constructor usage.
>>
>> [5] https://review.openstack.org/301918
>>
>> Ronald Bradford
>>
>> Web Site: http://ronaldbradford.com
>> LinkedIn:  http://www.linkedin.com/in/ronaldbradford
>> Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
>> Skype: RonaldBradford
>> GTalk: Ronald.Bradford
>> IRC: rbradfor
>>
>>
>> On Tue, Apr 5, 2016 at 3:49 PM, Sean Dague <s...@dague.net> wrote:
>>
>>> Cool. Great.
>>>
>>> In looking at this code a bit more I think we're missing out on some
>>> commonality by the fact that this nice bit of common parsing -
>>>
>>> https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L138-L161
>>> is actually hidden behind a factory pattern, and not used by anyone in
>>> OpenStack -
>>> http://codesearch.openstack.org/?q=from_environ=nope==
>>>
>>> If instead of standardizing the args to the context constructor, we
>>> could remove a bunch of them and extract that data from a passed
>>> environment during the constructor that should remove a bunch of parsing
>>> code in every project. It would also mean that we could easily add
>>> things like project_name and user_name in, and they would be available
>>> to all consumers.
>>>
>>> -Sean
>>>
>>> On 04/05/2016 03:39 PM, Ronald Bradford wrote:
>>> > Sean,
>>> >
>>> > I cannot speak to historically why there were not there, but I am
>>> > working through the app-agnostic-logging-parameters blueprint [1] right
>>> > now and it's very related to this.  As part of this work I would be
>>> > reviewing attributes that are more commonly used in subclassed context
>>> > objects for inclusion into the base oslo.context class, a step before a
>>> > more kwargs init() approach that many subclassed context object
>>> utilize now.
>>> >
>>> > I am also proposing the standardization of context arguments [2]
>>> > (specifically ids), and names are not mentioned but I would like to
>>> > follow the proposed convention.
>>> >
>>> > However, as you point out in the middleware [3], if the information is
>>> > already available I see no reason not to facilite the base oslo.context
>>> > class to consume this for subsequent use by logging.  FYI the
>>> > get_logging_values() work in [4] is specially to add logging only
>>> values
>>> > and this can be the first use case.
>>> >
>>> > While devstack uses these logging format string options, the defaults
>>> > (which I presume are operator centric do not).  One of my goals of the
>>> > Austin Ops summit it to get to talk with actual operators and find out
>>> > what is really in use.   Regardless, the capacity to choose should be
>>> > a

Re: [openstack-dev] [oslo] oslo.context and name fields

[Ronald Bradford]

I have created a version that use constructor arguments. [5]
I will review in more detail across projects the use of keystone middleware
to see if we can utilize a constructor environment attribute to simply
constructor usage.

[5] https://review.openstack.org/301918

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Tue, Apr 5, 2016 at 3:49 PM, Sean Dague <s...@dague.net> wrote:

> Cool. Great.
>
> In looking at this code a bit more I think we're missing out on some
> commonality by the fact that this nice bit of common parsing -
>
> https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L138-L161
> is actually hidden behind a factory pattern, and not used by anyone in
> OpenStack -
> http://codesearch.openstack.org/?q=from_environ=nope==
>
> If instead of standardizing the args to the context constructor, we
> could remove a bunch of them and extract that data from a passed
> environment during the constructor that should remove a bunch of parsing
> code in every project. It would also mean that we could easily add
> things like project_name and user_name in, and they would be available
> to all consumers.
>
> -Sean
>
> On 04/05/2016 03:39 PM, Ronald Bradford wrote:
> > Sean,
> >
> > I cannot speak to historically why there were not there, but I am
> > working through the app-agnostic-logging-parameters blueprint [1] right
> > now and it's very related to this.  As part of this work I would be
> > reviewing attributes that are more commonly used in subclassed context
> > objects for inclusion into the base oslo.context class, a step before a
> > more kwargs init() approach that many subclassed context object utilize
> now.
> >
> > I am also proposing the standardization of context arguments [2]
> > (specifically ids), and names are not mentioned but I would like to
> > follow the proposed convention.
> >
> > However, as you point out in the middleware [3], if the information is
> > already available I see no reason not to facilite the base oslo.context
> > class to consume this for subsequent use by logging.  FYI the
> > get_logging_values() work in [4] is specially to add logging only values
> > and this can be the first use case.
> >
> > While devstack uses these logging format string options, the defaults
> > (which I presume are operator centric do not).  One of my goals of the
> > Austin Ops summit it to get to talk with actual operators and find out
> > what is really in use.   Regardless, the capacity to choose should be
> > available when possible if the information is already identified without
> > subsequent lookup.
> >
> >
> > Ronald
> >
> >
> > [1]
> https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
> > [2] https://review.openstack.org/#/c/290907/
> > [3]
> http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
> > [4] https://review.openstack.org/#/c/274186/
> >
> >
> >
> >
> >
> > On Tue, Apr 5, 2016 at 2:31 PM, Sean Dague <s...@dague.net
> > <mailto:s...@dague.net>> wrote:
> >
> > I was trying to clean up the divergent logging definitions in
> devstack
> > as part of scrubbing out 'tenant' references -
> > https://review.openstack.org/#/c/301801/ and in doing so stumbled
> over
> > the fact that the extremely useful project_name and user_name fields
> are
> > not in base oslo.context.
> >
> >
> https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L148-L159
> >
> > These are always available to be set -
> >
> http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
> >
> > And they are extremely valuable when a human is looking at logs, as
> you
> > actually can remember names when looking at various services to cross
> > reference things. Nova has a custom context that sets these things -
> >
> https://github.com/openstack/nova/blob/d57a4e8be9147bd79be12d3f5adccc9289a375b6/nova/api/auth.py#L114-L115
> >
> > I would really like these to be available in all services using
> > oslo.context.
> >
> > So the quest

Re: [openstack-dev] [oslo] oslo.context and name fields

[Ronald Bradford]

Sean,

I cannot speak to historically why there were not there, but I am working
through the app-agnostic-logging-parameters blueprint [1] right now and
it's very related to this.  As part of this work I would be reviewing
attributes that are more commonly used in subclassed context objects for
inclusion into the base oslo.context class, a step before a more kwargs
init() approach that many subclassed context object utilize now.

I am also proposing the standardization of context arguments [2]
(specifically ids), and names are not mentioned but I would like to follow
the proposed convention.

However, as you point out in the middleware [3], if the information is
already available I see no reason not to facilite the base oslo.context
class to consume this for subsequent use by logging.  FYI the
get_logging_values() work in [4] is specially to add logging only values
and this can be the first use case.

While devstack uses these logging format string options, the defaults
(which I presume are operator centric do not).  One of my goals of the
Austin Ops summit it to get to talk with actual operators and find out what
is really in use.   Regardless, the capacity to choose should be available
when possible if the information is already identified without subsequent
lookup.


Ronald


[1]
https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
[2] https://review.openstack.org/#/c/290907/
[3]
http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
[4] https://review.openstack.org/#/c/274186/





On Tue, Apr 5, 2016 at 2:31 PM, Sean Dague  wrote:

> I was trying to clean up the divergent logging definitions in devstack
> as part of scrubbing out 'tenant' references -
> https://review.openstack.org/#/c/301801/ and in doing so stumbled over
> the fact that the extremely useful project_name and user_name fields are
> not in base oslo.context.
>
>
> https://github.com/openstack/oslo.context/blob/c63a359094907bc50cc5e1be716508ddee825dfa/oslo_context/context.py#L148-L159
>
> These are always available to be set -
>
> http://docs.openstack.org/developer/keystonemiddleware/api/keystonemiddleware.auth_token.html#what-auth-token-adds-to-the-request-for-use-by-the-openstack-service
>
> And they are extremely valuable when a human is looking at logs, as you
> actually can remember names when looking at various services to cross
> reference things. Nova has a custom context that sets these things -
>
> https://github.com/openstack/nova/blob/d57a4e8be9147bd79be12d3f5adccc9289a375b6/nova/api/auth.py#L114-L115
>
> I would really like these to be available in all services using
> oslo.context.
>
> So the question is, were these not implemented on purpose? Is the
> opposition to putting them into oslo.context?
>
> Please let me know before I start going down this path.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Our Install Guides Only Cover Defcore - What about big tent?

[Ronald Bradford]

The only downside I see of these examples are there is no way in the
documentation to determine the release version or cycle.  (i.e. you have to
read the contents in conjunction with the URL).

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Mar 25, 2016 at 4:20 PM, Jim Rollenhagen <j...@jimrollenhagen.com>
wrote:

> On Fri, Mar 25, 2016 at 03:20:30PM -0400, Doug Hellmann wrote:
> > Excerpts from Jim Rollenhagen's message of 2016-03-25 10:45:30 -0700:
> > > On Fri, Mar 25, 2016 at 09:10:05AM -0400, Doug Hellmann wrote:
> > > > Excerpts from Lana Brindley's message of 2016-03-24 08:50:49 +1000:
> > > > > On 24/03/16 08:01, Doug Hellmann wrote:
> > > > > > Excerpts from Lana Brindley's message of 2016-03-24 07:14:35
> +1000:
> > > > > >> Hi Mike, and sorry I missed you on IRC to discuss this there.
> That said, I think it's great that you took this to the mailing list,
> especially seeing the conversation that has ensued.
> > > > > >>
> > > > > >> More inline ...
> > > > > >>
> > > > > >> On 24/03/16 01:06, Mike Perez wrote:
> > > > > >>> Hey all,
> > > > > >>>
> > > > > >>> I've been talking to a variety of projects about lack of
> install guides. This
> > > > > >>> came from me not having a great experience with trying out
> projects in the big
> > > > > >>> tent.
> > > > > >>>
> > > > > >>> Projects like Manila have proposed install docs [1], but they
> were rejected
> > > > > >>> by the install docs team because it's not in defcore. One of
> Manila's goals of
> > > > > >>> getting these docs accepted is to apply for the operators tag
> > > > > >>> ops:docs:install-guide [2] so that it helps their maturity
> level in the project
> > > > > >>> navigator [3].
> > > > > >>>
> > > > > >>> Adrian Otto expressed to me having the same issue for Magnum.
> I think it's
> > > > > >>> funny that a project that gets keynote time at the OpenStack
> conference can't
> > > > > >>> be in the install docs personally.
> > > > > >>>
> > > > > >>> As seen from the Manila review [1], the install docs team is
> suggesting these
> > > > > >>> to be put in their developer guide.
> > > > > >>
> > > > > >> As Steve pointed out, these now have solid plans to go in. That
> was because both projects opened a conversation with us and we worked with
> them over time to give them the docs they required.
> > > > > >>
> > > > > >>>
> > > > > >>> I don't think this is a great idea. Mainly because they are
> for developers,
> > > > > >>> operators aren't going to be looking in there for install
> information. Also the
> > > > > >>> Developer doc page [4] even states "This page contains
> documentation for Python
> > > > > >>> developers, who work on OpenStack itself".
> > > > > >>
> > > > > >> I agree, but it's a great place to start. In fact, I've just
> merged a change to the Docs Contributor Guide (on the back of a previous
> mailing list conversation) that explicitly states this:
> > > > > >>
> > > > > >>
> http://docs.openstack.org/contributor-guide/quickstart/new-projects.html
> > > > > >
> > > > > > I think you're missing that most of us are disagreeing that it is
> > > > > > a good place to start. It's fine to have the docs in a repository
> > > > > > managed by the project team. It's not good at all to publish them
> > > > > > under docs.o.o/developer because they are not for developers, and
> > > > > > so it's confusing. This is why we ended up with a different place
> > > > > > for release notes to be published, instead of just adding reno to
> > > > > > the existing developer documentation build, for example.
> > > > > >
> > > > >
> > > > > All docs need to be drafted somewhere. I don't care where that is,

Re: [openstack-dev] [kite] Seeking core reviewers

[Ronald Bradford]

Thanks Doug.

I've shortened your workload a bit --
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090491.html



Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Mar 25, 2016 at 12:05 PM, Douglas Mendizábal <
douglas.mendiza...@rackspace.com> wrote:

> Thanks for the patches, Ronald.  Adam Young is right, Kite is pretty
> much dead.
>
> I'll add to my list of spring cleaning to-dos to remove Kite from
> governance and infra.
>
> Thanks,
> Douglas Mendizábal (redrobot)
>
> On 3/25/16 10:08 AM, Ronald Bradford wrote:
> > Thanks all for feedback.
> >
> > I have proposed a non maintained patch [1] based on comments here.
> > I will speak with the Barbican team.
> >
> > Ronald
> >
> > [1] https://review.openstack.org/#/c/297719/
> >
> >
> > Ronald Bradford
> >
> > Web Site: http://ronaldbradford.com <http://ronaldbradford.com/>
> > LinkedIn:  http://www.linkedin.com/in/ronaldbradford
> > Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
> > Skype: RonaldBradford
> > GTalk: Ronald.Bradford
> > IRC: rbradfor
> >
> >
> > On Fri, Mar 25, 2016 at 5:02 AM, Thierry Carrez <thie...@openstack.org
> > <mailto:thie...@openstack.org>> wrote:
> >
> > Ian Cordasco wrote:
> >
> > I believe Kite is no longer actively developed or maintained and
> > was started by the Barbican folks. You should find them in
> > #openstack-barbican.
> >
> >
> > Yeah. It's still technically a repository under the Barbican team.
> > Someone from Barbican should propose a governance change to get rid
> > of it (or approve someone else's change getting rid of it).
> >
> > Keeping abandoned repositories in your official list does not
> > reflect well on your project team (or OpenStack in general).
> >
> > --
> > Thierry Carrez (ttx)
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kite][barbican] Notice to retire kite and python-kiteclient projects

[Ronald Bradford]

>From the initial ML discussion [1], the following are instructions to
retire a project [2].
The kite and python_kiteclient projects are moving to a non maintained
status.

First is the removal of project gates. [3]
Second is updating code repos, [4],[5]. See README for how code can still
be accessed
Finally, is the removal of projects from infrastructure [6]


[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/090409.html
[2] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
[3] https://review.openstack.org/#/c/297746/
[4] https://review.openstack.org/#/c/297719/
[5] https://review.openstack.org/#/c/297741/
[6] https://review.openstack.org/#/c/297738/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kite] Seeking core reviewers

[Ronald Bradford]

Thanks all for feedback.

I have proposed a non maintained patch [1] based on comments here.
I will speak with the Barbican team.

Ronald

[1] https://review.openstack.org/#/c/297719/


Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Mar 25, 2016 at 5:02 AM, Thierry Carrez <thie...@openstack.org>
wrote:

> Ian Cordasco wrote:
>
>> I believe Kite is no longer actively developed or maintained and was
>> started by the Barbican folks. You should find them in #openstack-barbican.
>>
>
> Yeah. It's still technically a repository under the Barbican team. Someone
> from Barbican should propose a governance change to get rid of it (or
> approve someone else's change getting rid of it).
>
> Keeping abandoned repositories in your official list does not reflect well
> on your project team (or OpenStack in general).
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [kite] Seeking core reviewers

[Ronald Bradford]

As part of the initiative to replace all legacy Oslo Incubator code in
OpenStack with graduate libraries we are working through all projects.
I have been unable to find any IRC contact information on the wiki or
kite-core group in order to help with several reviews [1] for the project.

Any assistance from kite contributors appreciated.

[1]
https://review.openstack.org/#/q/status:open+project:openstack/kite+branch:master+topic:oslo_incubator_cleanup


Regards

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

Re: [openstack-dev] [chef] ec2-api cookbook

[Ronald Bradford]

Samuel,

Could you detail when your IRC meeting is, [1] indicates it's on Tuesdays.

[1] https://wiki.openstack.org/wiki/Meetings/EC2API

Regards

Ronald

On Thu, Mar 24, 2016 at 1:36 PM, Samuel Cassiba  wrote:

> On Thu, Mar 24, 2016 at 3:33 AM, Anastasia Kravets 
> wrote:
>
>> Hi, team!
>>
>> If you remember, we've created a cookbook for ec2-api service. After last
>> discussion I’ve refactored it, have added specs.
>> The final version is located on cloudscaling github:
>> https://github.com/cloudscaling/cookbook-openstack-ec2.
>> How do we proceed to integrate our cookbook to your project?
>>
>> Regards,
>> Anastasia
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> Hi Anastasia,
>
> That's great news! We'll have to go through the process of getting a new
> repo added under our project. Would you be able to attend Monday's meeting
> to discuss it further?
>
> Thanks,
>
> Samuel
>
> __
> OpenStack Development Mailing 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] [glance] Glance Mitaka: Passing the torch

[Ronald Bradford]

I am not involved in Glance, however this was well worth reading for the
experiences during the cycle, not just as a PTL but as a team and the
communication of improving the software development process.




On Wed, Mar 9, 2016 at 11:47 PM, Bhandaru, Malini K <
malini.k.bhand...@intel.com> wrote:

> Flavio, Glance and OpenStack benefited during your reign or period of
> humble service.
> Will miss you at the helm. Also thank you for anointing/attracting two new
> solid cores: Brian and Sabari
> Malini
>
>
> -Original Message-
> From: Tom Fifield [mailto:t...@openstack.org]
> Sent: Wednesday, March 09, 2016 7:55 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch
>
> A beautiful post, sir. Thank you for everything!
>
> On 09/03/16 22:15, Flavio Percoco wrote:
> >
> > Greetings,
> >
> > I'm not going to run for Glance's PTL position for the Newton timeframe.
> >
> > There are many motivations behind this choice. Some of them I'm
> > willing to discuss in private if people are interested but I'll go as
> > far as saying there are personal and professional reasons for me to
> > not run again.
> >
> > As I've always done in my past cycles as PTL, I'd like to take some
> > time to summarize what's happened in the past cycle not only for the
> > new PTL to know what's coming up but for the community to know how
> > things went.
> >
> > Before I even start, I'd like to thank everyone in the Glance community.
> > I truly
> > believe this was a great cycle for the project and the community has
> > gotten stronger. None of this would have been possible without the
> > help of all of you and for that, I'm deeply in debt with you all. It
> > does not just take an employer to get someone to contribute to a
> > project. Being paid, for those who are, to do Open Source is not
> > enough. It takes passion, motivation and a lot of patience to analyze
> > a technology, think out of the box and look for ways it can be
> > improved either by fixing bugs or by implementing new features. The
> > amount of time and dedication this process requires is probably worth
> > way more than what we get back from it.
> >
> > Now, with all that being said, here's Glance Mitaka for all of you:
> >
> > Completed Features
> > ==
> >
> > I think I've mentioned this already but I'm proud of it so I'll say it
> > again.
> > The prioritization and scheduling of Glance Mitaka went so well that
> > we managed to release M-3 without any feature freeze exception (FFE)
> > request. This doesn't mean all the features were implemented. In fact,
> > at least 4 were pushed back to Newton. However, the team communicated,
> > reviewed, sprinted and coded in such a way that we were able to
> > re-organize the schedule to avoid wasting time on things we new
> > weren't going to make it. This required transparency and hard
> > decisions but that's part of the job, right?
> >
> > * [0] CIM Namespace Metadata
> > * [1] Support download from and upload to Cinder volumes
> > * [2] Glance db purge utility
> > * [3] Deprecate Glance v3 API
> > * [4] Implement trusts for Glance
> > * [5] Migrate the HTTP Store to Use Requests
> > * [6] Glance Image Signing and Verification
> > * [7] Supporting OVF Single Disk Image Upload
> > * [8] Prevention of Unauthorized errors during upload/download in
> > Swift driver
> > * [9] Add filters using an ‘in’ operator
> >
> > [0]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/cim-namespace-metadata-definitions.html
> >
> > [1]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/cinder-store-upload-download.html
> >
> > [2]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/database-purge.html
> >
> > [3]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/deprecate-v3-api.html
> >
> > [4]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/glance-trusts.html
> >
> > [5]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/http-store-on-requests.html
> >
> > [6]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/image-signing-and-verification-support.html
> >
> > [7]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/ovf-lite.html
> >
> > [8]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/prevention-of-401-in-swift-driver.html
> >
> > [9]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/v2-add-filters-with-in-operator.html
> >
> >
> > If the above doesn't sound impressive to you, let me fill you in with
> > some extra info about Glance's community.
> >
> > Community
> > =
> >
> > Glance's community currently has 12 core members, 3 of which joined
> > during Mitaka and 2 of those 3 members joined at the end of 

Re: [openstack-dev] [bug-smash] Global OpenStack Bug Smash Mitaka

[Ronald Bradford]

I attended the first day of the bugsmash event in New York and I have some
general feedback for future organizers of these types of events.  Hopefully
others can also share their experiences.

These comments are for the benefit of making the event better the next
time. As I attended only one location and one of three days, the experience
may have been vastly different elsewhere.

Connectivity.  The University location blocked IRC, git and gerrit ports.
One should be prepared for this situation when talking about the use of IRC
(but not being able to demonstrate your local client for example).  Knowing
how to adjust devstack to use https was something we needed to do.  I was
told you could communicate with gerrit over https but never got to see
that.  Having a reference to this, say the wiki would be great.


Prerequisites:  It would likely be more ideal if your focus is on fixing
bugs rather then talking about the process of how to contribute to fixing
bugs in OpenStack then stating that installing devstack as a pre-requisite.
At NYC almost all attendees have never installed devstack, so a good
portion of the day was getting this setup.  As such it was requested by
some devstack cores to propose this in docs, and hence
http://docs-draft.openstack.org/54/290854/1/check/gate-devstack-publish-docs/d6e9b5b//doc/build/html/guides/first-time.html
via https://review.openstack.org/#/c/290854/.   Again, this was just our
experience but this guide is for the absolute first time devstack user, and
it's detailed for that purpose.

Approach: There are multiple ways to consider addressing bugs, do you even
need devstack, or do you just use the code and unit tests. I think it's
important to cultivate the varied approaches and provide demonstrations of
each.  Which way to do you start, again it depends.   I feel that given the
NYC audience (and this may also not reflect others), that a live demo of
devstack, looking at screen logs, restarting a service, even changing
something (say a logging format, or a line of code) will show the audience
the impact of using devstack and validating manually the impact of your
code change.  Demonstrating unit tests, and other tox environments such as
pep8 is also a solid grounding in fixing bugs well and consistently.

Audience: The NYC event lacked any prep information (e.g. a surveymonkey)
of the level of attendee, this could have facilitated splitting the first
day into different tracks based on skills level.  For a 3 day event,
perhaps advertising day 1 specifically as getting your environment ready,
informs people.

Baseline:  At our event one of the outcomes was for a few cloud images to
be spun up with devstack and code. This solves some of the connectivity
issues, and also solves this first day getting started.  It enables it to
be potential more a homework task.  I think is a great way, having a public
cloud image and devstack and sample code base.  It serves as the basis of
demo land, can be cloned for attendees at any location.

My 2 cents to making this type of event even better next time.







Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Thu, Jan 28, 2016 at 4:11 AM, Wang, Shane <shane.w...@intel.com> wrote:

> *Save the Date:*
> *Global OpenStack Bug Smash*
> *Wednesday-Friday, March 2-4, 2016*
> *RSVP by Friday, February 19*
>
> How can you help make the OpenStack Mitaka release stable and bug-free
> while having fun with your peers? Join Intel, Rackspace, Mirantis, IBM, HP,
> Huawei, CESI and others in a global bug smash across four continents as we
> work together. Then, join us later in April in Austin, Texas, U.S.A. at the
> OpenStack Summit to get re-acquainted & celebrate our accomplishments!
>
> *OUR GOAL*
> Our key goal is to collaborate round-the-clock and around the world to fix
> as many bugs as possible across the wide range of OpenStack projects. In
> the process, we’ll also help onboard and grow the number of OpenStack
> developers, and increase our collective knowledge of OpenStack tools and
> processes. To ease collaboration among all of the participants and ensure
> that core reviews can be conducted promptly, we will use the IRC channel,
> the mailing list, and Gerrit and enlist core reviewers in the event.
>
> *GET INVOLVED*
> Simply choose a place near you—and register by Friday, February 19.
> Registration is free, and we encourage you to invite others who may be
> interested.
>
>
>- Australia
>- China
>- India
>
>
>- Russia
>- United Kingdom
>- United States
>
>
> Visit the link below for additional details:
> *https://etherpad.openstack.org/p/OpenStack-Bug-Smash-Mitaka*
> <https://ethe

Re: [openstack-dev] [Openstack-operators] [glance] Remove `run_tests.sh` and `tools/*`

[Ronald Bradford]

+1 from me.   I am all for standardizing this.

Personally when I started looking at OpenStack code as new contributor this
was very confusing with the online docs that listed run_tests.sh but the
first project I looked at, this didn't exist and it was all tox based.

I went on to blog about my first experience of tox, as this was lacking in
OpenStack docs.

Ronald



On Fri, Mar 4, 2016 at 11:16 AM, Steve Martinelli 
wrote:

> The keystone team did the same during Liberty while we were moving towards
> using oslo.* projects instead of oslo-incubator [0]. We also noticed that
> they were rarely used, and we did not go through a deprecation process
> since these are developer tools. We're still finding a few spots in our
> docs that need updating, but overall it was an easy transition.
>
> [0]
> https://github.com/openstack/keystone/commit/55e9514cbd4e712e2c317335294355cf1596d870
>
> stevemar
>
> [image: Inactive hide details for Flavio Percoco ---2016/03/04 06:51:47
> AM---Hey Folks, I'm looking at doing some cleanups in our repo]Flavio
> Percoco ---2016/03/04 06:51:47 AM---Hey Folks, I'm looking at doing some
> cleanups in our repo and I would like to start by
>
> From: Flavio Percoco 
> To: openstack-dev@lists.openstack.org
> Cc: openstack-operat...@lists.openstack.org
> Date: 2016/03/04 06:51 AM
> Subject: [Openstack-operators] [glance] Remove `run_tests.sh` and
> `tools/*`
> --
>
>
>
> Hey Folks,
>
> I'm looking at doing some cleanups in our repo and I would like to start by
> deprecating the `run_tests` script and the contents in the `tools/` dir.
>
> As far as I can tell, no one is using this code - we're not even using it
> in the
> gate - as it was broken until recently, I believe. The recommended way to
> run
> tests is using `tox` and I believe having this script in the code base
> misleads
> new contributors and other users.
>
> So, before we do this. I wanted to get feedback from a broader audience
> and give
> a heads up to folks that might be using this code.
>
> Any objections? Something I'm missing?
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
> [attachment "signature.asc" deleted by Steve Martinelli/Toronto/IBM]
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> ___
> OpenStack-operators mailing list
> openstack-operat...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing List (not for 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] PTL for Newton and beyond

[Ronald Bradford]

Dims,

As my first project and cycle in OpenStack I have really appreciated your
input and direction as I was starting out and during Mitaka cycle.
It has been great to learn just a bit of what PTL of Oslo is and does, so
thanks for all your hard work.
I hope I can work with the team to help turn those "impossible tasks" to
"possible".

Best to your next pursuit.

I recently watched an Oslo presentation from a prior conference, there was
a quote while I will leave as anonymous for now.

"OpenStack is like an aircraft carrier, you have to be very careful when
your steering it, it does not move quickly".So, it sounds like a lot is
possible, it just can take some time to adjust the course of a complex
system of projects.

Ronald



On Thu, Mar 3, 2016 at 9:28 AM, Doug Hellmann  wrote:

> Excerpts from Davanum Srinivas (dims)'s message of 2016-03-03 06:32:42
> -0500:
> > Team,
> >
> > It has been great working with you all as PTL for Oslo. Looks like the
> > nominations open up next week for elections and am hoping more than
> > one of you will step up for the next cycle(s). I can show you the
> > ropes and help smoothen the transition process if you let me know
> > about your interest in being the next PTL. With the move to more
> > automated testing in our CI (periodic jobs running against oslo.*
> > master) and the adoption of the release process (logging reviews in
> > /releases repo) the load should be considerably less on you.
> > especially proud of all the new people joining as both oslo cores and
> > project cores and hitting the ground running. Big shout out to Doug
> > Hellmann for his help and guidance when i transitioned into the PTL
> > role.
>
> Thanks, Dims, you've done awesome work during your terms. It has
> been great to see the team gel and mature under your leadership.
>
> > Main challenges will be to get back confidence of all the projects
> > that use the oslo libraries, NOT be the first thing they look for when
> > things break (Better backward compat, better test matrix) and
> > evangelizing that Oslo is still the common play ground for *all*
> > projects and not just the headache of some nut jobs who are willing to
> > take up the impossible task of defining and nurturing these libraries.
> > There's a lot of great work ahead of us and i am looking forward to
> > continue to work with you all.
>
> Excellent analysis, too.  We're in a good position to build on that
> testing and stability work and continue with the adoption and hardening
> tasks. I'm looking forward to working out the details with the rest of
> the team.
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [docs] Can we get the "configuration reference" of master more often?

[Ronald Bradford]

On Thu, Mar 3, 2016 at 9:51 AM, Andreas Jaeger  wrote:

> On 2016-03-03 15:37, Markus Zoeller wrote:
> > The "configuration reference" manual at [1] is really helpful to get
> > an overview of the options and we (Nova folks) were wondering if we
> > could have that updated more often [2].
> >
> > Right now it is from November 2015 [3] and we (Nova folks) put a lot of
> > effort this cycle in improving the help of our config options but they
> > aren't yet (fully) reflected in that guide.
> >
>

>From what little I have read, this Nova work is around consolidation and
grouping of existing options, and not the addition of new options?
The nova.flagmappings files [5] defines a relationship of the displayed
table of options (the heading in the nova.headers file) and the options.
The group information can be specified as a prefix to the option,
e.g. database/backend database.

the "Description of conductor configuration options" table for example in
[1] (sorry no direct linking possible, feature perhaps?) , where a table
may contain options from multiple groups or namespaces.


> > Different options would be:
> > A: per milestone
> > B: per merge of a commit which contains "DocImpact" in its message
> > C: daily/nightly
> >
> > Personally I think daily/nightly would be sufficient.
> >
> > AFAIK the generation of that guide is done with [4] and IIUC there is
> > no necessity of human intervention in that process, or did I miss
> > something?
>

I have been looking into this process at present in free time to understand
and see how docs are generated. From my discussion with Gauvain it is both
manual and time consuming.


>
> The flagmappings file is manually updated - if a new option shows up, we
> need to know to which table it should be added. Doug and Gauvain
>

table or tables.  There is a 1 to n mapping of option to table, expressed
as one line in the file. The nova file has no example, cinder is a place to
look at.



> discussed automating this in the future but this needs first some changes,
>


[5]
http://git.openstack.org/cgit/openstack/openstack-manuals/tree/tools/autogenerate-config-flagmappings/nova.flagmappings
__
OpenStack Development Mailing List (not for 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] Documenting configuration options lifespan

[Ronald Bradford]

> > * When an option is changed, or marked as deprecated, during normal
> reviews
> > it should then be identified accordingly with these new attributes.
> > * The "changed" attribute would only be applicable moving forward with a
> > developer change in default value, ranges etc (changing help text or
> > re-ordering is not a change).
>
> Would "changed" hold a list of changes, to provide a history? Or would
> it just describe the difference since the last release?
>
>
I would consider "changed" as last release the option has changed, so that
effectively for a given current release did the option change in that
release, or not.  An option could change in multiple releases, and would be
indicated as such during each release cycle.

I do not see this feature providing specifics such as "Option X changed
default value from False to True".  It would be that in a section "Changed
Options" there is a list of options marked as changed. The use of comparing
generated configuration files between releases as used now would determine
specifics.  The goal here is to narrow down the time to do the work across
many projects and projects with many options.




> > * Any new options get the "released" attribute.
>
> And that would be set to the version in which the new attribute was
> added? Maybe "added_in" is a better name?
>
> Yes, added or first_added is a better name.



> > * Initial work to fill in the "deprecated" and "removal" information
> (i.e.
> > for a small number of existing options per project) would add strong
> value
> > to generated documentation.
>
> Amen.
>
> Doug
>
> > * Additional work to add the initial "released" information can be left
> to
> > an intro contributor task.  Information of an options existence in a
> > project can be automated via analysis of branches to provide details of
> the
> > seed info needed.
> >
> > As for implementation, the use of a named tuple attribute for
> > oslo_config.cfg.Opt [1] is one approach.  Determining how to take
> advantage
> > of debtcollector and versionutils should be considered.
> >
> > [1]
> >
> http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n636
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [oslo][all] Documenting configuration options lifespan

[Ronald Bradford]

After evaluation of oslo-config-generator and one of it's common uses by
operators in configuration option evaluation with upgrades, I am proposing
adding some meta data for all configuration options to provide better
applicable documentation as projects continue to evolve.

I can see an easier and system generated means to provide information such
as "What's New", "What's Changed", "What's Deprecated" for project
configurations in each new release, in system documentation and release
notes.  This will greatly simplify the review of newer available releases
and improve the experience of upgraded deployments.

For each configuration option I'm proposing we can identify "released",
"changed", "deprecated", "removal" release info, e.g. K,L,M,N etc.

Initial seeding of existing configuration options is that no information is
needed. i.e. no upfront investment to start.
Possible work items moving forward would include:

* When an option is changed, or marked as deprecated, during normal reviews
it should then be identified accordingly with these new attributes.
* The "changed" attribute would only be applicable moving forward with a
developer change in default value, ranges etc (changing help text or
re-ordering is not a change).
* Any new options get the "released" attribute.
* Initial work to fill in the "deprecated" and "removal" information (i.e.
for a small number of existing options per project) would add strong value
to generated documentation.
* Additional work to add the initial "released" information can be left to
an intro contributor task.  Information of an options existence in a
project can be automated via analysis of branches to provide details of the
seed info needed.

As for implementation, the use of a named tuple attribute for
oslo_config.cfg.Opt [1] is one approach.  Determining how to take advantage
of debtcollector and versionutils should be considered.

[1]
http://git.openstack.org/cgit/openstack/oslo.config/tree/oslo_config/cfg.py#n636
__
OpenStack Development Mailing List (not for 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] documentation on using the oslo.db opportunistic test feature

[Ronald Bradford]

>
>
>
> 1) Being able to do a grant with a prefix like
>
> GRANT all on 'openstack_ci%'.* to openstack_citest
>
> Then using that prefix in the random db generation. That would at least
> limit scope. That seems the easiest to do with the existing infrastructure.
>

To use this syntax correctly in MySQL, note they have to be backquotes (`).
   And your missing the @host scope.


 GRANT ALL ON `openstack_ci%`.* TO openstack_citest@localhost
__
OpenStack Development Mailing 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][doc][all] Removal of deprecate oslo.og log_format configuration option

[Ronald Bradford]

The deprecated log_format option is being removed [1]

This option can be found across many projects generally in sample
configuration files [2].  These should be automatically removed if these
files are auto generated via oslo-config-generator or in sphinx generated
documentation.  In other projects using legacy Oslo Incubator code, this
option is in place.  These projects should consider migrating to the
olso.log library.


[1] https://review.openstack.org/#/c/263903/
[2] http://codesearch.openstack.org/?q=log_format=nope==
__
OpenStack Development Mailing List (not for 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] Announcing our new Olso Project

[Ronald Bradford]

For the #OpenStack Mitaka M3 freeze and final release we have made it even
easier to play and win Oslo Bingo.
Simply pick the next release word. Free entry at
http://j.mp/Oslo-bingo-Mitaka

Follow the results on Twitter - https://twitter.com/OsloBingo

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Mon, Feb 1, 2016 at 12:50 PM, Ronald Bradford <m...@ronaldbradford.com>
wrote:

> The Olso team is proud to announce the release of Oslo Bingo.  In Oslo
> we like to spice up our release notes using meaningful random
> adjectives [1].
>
> Each month the Oslo team will select an adjective to be the Oslo Bingo
> word of the month.
>
> For February 2016 we have selected "jazzed" (from rlrossit).
>
> To play, simply pick the first Oslo project that will have release
> notes using our Bingo word of the month (i.e. jazzed). Check out
> recent release notes that selected "overjoyed" [2] and "jubilant" [3]
> to see what we mean.
>
> Entry is free for all at http://j.mp/Oslo-bingo [4]
>
> The winner each month will get a limited edition Oslo t-shirt,
> sponsored by HPE (quantity and sizes limited):
> http://j.mp/Oslo-bingo-prize
>
> More details at [5]
>
>
> [1]
> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py#n33
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/085000.html
> [3]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083797.html
> [4] http://j.mp/Oslo-bingo
> [5] https://etherpad.openstack.org/p/Oslo_Bingo
>
__
OpenStack Development Mailing List (not for 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] tenant vs. project

[Ronald Bradford]

I am taking on the task in the Oslo Logging/Context projects to ensure
project replaces a deprecated use of tenant.

This includes the end user/operator view of logging configuration options
[1] replacing tenant with project, and RequestContext used across most
projects that has an inconsistent mixture of terms.

[1] http://docs.openstack.org/developer/oslo.log/opts.html



Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Fri, Feb 12, 2016 at 10:34 AM, Monty Taylor <mord...@inaugust.com> wrote:

> On 02/12/2016 07:36 AM, Jay Pipes wrote:
>
>> On 02/12/2016 07:01 AM, Sean Dague wrote:
>>
>>> Ok... this is going to be one of those threads, but I wanted to try to
>>> get resolution here.
>>>
>>> OpenStack is wildly inconsistent in it's use of tenant vs. project. As
>>> someone that wasn't here at the beginning, I'm not even sure which one
>>> we are supposed to be transitioning from -> to.
>>>
>>> At a minimum I'd like to make all of devstack use 1 term, which is the
>>> term we're trying to get to. That will help move the needle.
>>>
>>> However, again, I'm not sure which one that is supposed to be (comments
>>> in various places show movement in both directions). So people with
>>> deeper knowledge here, can you speak up as to which is the deprecated
>>> term and which is the term moving forward.
>>>
>>
>> "Project" is the term that should be used.
>>
>
> Yes.
>
> FWIW - The ansible modules in ansible 2.0 (as well as the shade library)
> use the term "project" regardless of whether the cloud in question is
> running keystone v2 or v3. It's the least I could do to try to nudge
> consumption in the right direction.
>
>
>
> __
> OpenStack Development Mailing 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] the trouble with names

[Ronald Bradford]

While we all consider to look at this problem from within the perspective
of OpenStack, the consumer of OpenStack is somebody that is wanting to run
a cloud, and not develop a cloud (granted there is overlap in said
implementation).  They are also comparing clouds and features (e.g.
compute, storage), reading about the new features of cloud providers etc.
 The service catalog, the UI (i.e. names inside Horizon like Compute) need
to present generic names.

It would make it easier for consumers of API's to not need a translation
registry to know nova means compute.   This means that the translation is
internal with us developers. We should be able to live with that.

#2  IMO opinion serves best what OpenStack software is used for, and who it
is designed for.



Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford <http://twitter.com/ronaldbradford>
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Thu, Feb 4, 2016 at 10:45 AM, Sean Dague <s...@dague.net> wrote:

> On 02/04/2016 10:31 AM, Nick Chase wrote:
> > What about using a combination of two word names, and generic names. For
> > example, you might have
> >
> > cinder-blockstorage
> >
> > and
> >
> > foo-blockstorage
> >
> > The advantage there is that we don't need to do the thesaurus.com
> > <http://thesaurus.com> thing, but also, it enables to specify just
> >
> > blockstorage
> >
> > via a registry.  The advantage of THAT is that if a user wants to change
> > out the "default" blockstorage engine (for example) we could provide
> > them with a way to do that.  The non-default would have to support the
> > same API, of course, but it definitely fits with the "pluggable" nature
> > of OpenStack.
>
> This feels a bit like all the downsides of #1 (people have to know about
> codenames, and make projects know about the codenames of other projects)
> + all the downsides of #2 (we still need a naming registry).
>
> I do agree it is a 4th option, but the downsides seem higher than either
> #1 or #2.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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][doc][fuel] Removal of logging use_syslog_rfc_format configuration option

[Ronald Bradford]

In Mitaka we are planning on removing the deprecated logging configuration
option use_syslog_rfc_format [1]

Matches in openstack-manuals [2] and fuel-library puppet modules [3] should
be removed to avoid any dated documentation or errors in operation
respectively.

This option can also be found as a comment in sample configuration files of
multiple projects which should be removed automatically if these files are
generated via Sphinx.
In other projects using legacy Oslo Incubator code, this option is in
place.  These projects should consider migrating to the olso.log library.

Regards

Ronald

[1] https://review.openstack.org/#/c/263785/
[2]
http://codesearch.openstack.org/?q=use_syslog_rfc_format=nope==openstack-manuals
[3]
http://codesearch.openstack.org/?q=use_syslog_rfc_format=nope==fuel-library
__
OpenStack Development Mailing 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][all] Announcing our new Olso Project

[Ronald Bradford]

The Olso team is proud to announce the release of Oslo Bingo.  In Oslo
we like to spice up our release notes using meaningful random
adjectives [1].

Each month the Oslo team will select an adjective to be the Oslo Bingo
word of the month.

For February 2016 we have selected "jazzed" (from rlrossit).

To play, simply pick the first Oslo project that will have release
notes using our Bingo word of the month (i.e. jazzed). Check out
recent release notes that selected "overjoyed" [2] and "jubilant" [3]
to see what we mean.

Entry is free for all at http://j.mp/Oslo-bingo [4]

The winner each month will get a limited edition Oslo t-shirt,
sponsored by HPE (quantity and sizes limited):
http://j.mp/Oslo-bingo-prize

More details at [5]


[1] 
http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py#n33
[2] http://lists.openstack.org/pipermail/openstack-dev/2016-January/085000.html
[3] http://lists.openstack.org/pipermail/openstack-dev/2016-January/083797.html
[4] http://j.mp/Oslo-bingo
[5] https://etherpad.openstack.org/p/Oslo_Bingo

__
OpenStack Development Mailing List (not for 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] Improving deprecated options identification and documentation

[Ronald Bradford]

Markus,



> > Yes, in what release it is to be removed, e.g. Mitaka.  So when is
> > that release cycle, i.e. now once removed there is no record.
>
> The information at which point in time a removal will happen can be
> derived from a combination of:
> * the "Deprecation Notes" (e.g. Nova's at [1]) and
> * the "follows_standard_deprecation" policy [2].
> I don't see the immediate need to duplicate that information.
>
>
The potential duplication you refer to enables code scanning/automation to
detect and even initiate steps at the start of a release cycle to remove
deprecated options.
Looking at documented notes is a more inconsistent manual approach. The
number of deprecated options should not be high, I do not see the issue in
ensuring this information is in code as well as docs.



> I agree that there should be an explanation in ``deprecation_reason``
> if ``deprecated_for_removal=True`` **why** we deprecated it and which
> follow up actions seem to be reasonable for the ops.
>
>
Thanks!  I think for now, stating a reason, stating what release it was
deprecated and what release it should be removed provides a starting point
with a low barrier of entry to see results.

Ronald (rbradfor)



> References:
> [1] Nova's current release notes based on "reno"; "Deprecation Notes":
>
>
> http://docs.openstack.org/releasenotes/nova/unreleased.html#deprecation-notes
> [2] OpenStack governance docs; tag "assert_follows_standard_deprecation":
>
>
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
>
> Regards, Markus Zoeller (markus_z)
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

[Ronald Bradford]

On Thu, Jan 14, 2016 at 11:58 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> On 01/14/2016 11:45 AM, Ronald Bradford wrote:
>>
>> Presently the oslo.config Opt class has the attributes
>> deprecated_for_removal and deprecated_reason [1]
>>
>> I would like to propose that we use deprecated_reason (at a minimum) to
>> detail in what release an option was deprecated in, and what release it
>> is then removed in.
>
>
> You mean what release it *will* be removed in, right? Clearly, once it's
> removed, there won't be any indication it ever existed ;)
>

Yes, in what release it is to be removed, e.g. Mitaka.  So when is
that release cycle, i.e. now once removed there is no record.


>
> Any improvement in this regard I think would enhance the user experience
> considerably, thank you Ronald for tackling this area. I'd also suggest
> cc'ing (or sending a separate ML post) to the openstack-operators@ ML to
> gather feedback from ops folks.
>


will do!

__
OpenStack Development Mailing 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] Improving deprecated options identification and documentation

[Ronald Bradford]

Presently the oslo.config Opt class has the attributes
deprecated_for_removal and deprecated_reason [1]

I would like to propose that we use deprecated_reason (at a minimum) to
detail in what release an option was deprecated in, and what release it is
then removed in.
I see examples of deprecated_for_removal=True but no information on why or
when.  i.e. Ideally I'd like to move to an implied situation of
 if deprecated_for_removal=True then deprecated_reason is mandatory.

A great example is an already documented help message in oslo.log
configuration option use_syslog_rfc_format that at least provides a
guideline.  [2] shows a proposed review to take this low road approach.
An image of what the change actually looks like in documentation using this
approach [3].  This also needs  #267151 that fixes an issue where
deprecated options are not producing a warning message in docs.

The high road would be to have a discussion about if there is a better way
to mark and manage deprecated options. For example, if there was a
deprecated_release and a removal_release attribute then a level of tooling
could make this easier.  I would be wary in considering this, as it adds
complexity (is it needed), and just how many options are deprecated.  I'd
appreciate thoughts and feedback.

Regards

Ronald


[1] http://docs.openstack.org/developer/oslo.config/opts.html
[2] https://review.openstack.org/#/c/267176/
[3] http://postimg.org/image/vdkh3x46t/full/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [devstack][QA] Changing logging format to match documented defaults

[Ronald Bradford]

Ian,


On Tue, Dec 22, 2015 at 3:22 PM, Ian Wienand <iwien...@redhat.com> wrote:
>
> On 12/23/2015 05:55 AM, Ronald Bradford wrote:
> > I have observed that devstack uses custom logging formatting that
> > differs from the documented defaults. An example is for nova.  which
> > is defined in [1]
>
> The original point mentioned there of using "*_name" for extra
> verbosity still seems relevant [1]
>
> > logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s
> > %(name)s [%(request_id)s *%(user_identity)s*] %(instance)s%(message)s
>
> user_identity is still just "{user} {tenant} ..." (which is id's, I
> believe?) [2].


For reference, here are messages using before and after suggestions with
and without context. Presently, the default value defines 5 distinct
components including user and tenant/project.

Before:

2015-12-18 18:22:52.788 DEBUG oslo_concurrency.lockutils
[*req-bcd393ce-523e-454e-b05a-7b80f82aaaf0
None None*] Acquired semaphore "singleton_lock" lock
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:197

2015-12-23 17:21:12.570 DEBUG nova.quota
[*req-a65d797f-1e7e-48b4-a0b7-92f48e5f6bcd
admin demo*] Quota limits for project 9c011aa5646640abae282b9093515333:
{'project_id': u'9c011aa5646640abae282b9093515333'} reserve
/opt/stack/nova/nova/quota.py:559

After:

2015-12-18 18:28:10.890 DEBUG oslo_concurrency.lockutils
[*req-2d7df976-5004-4da2-83cc-2ed96ee42049
- - - - -*] Acquired semaphore "singleton_lock" lock
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:197

2015-12-23 17:24:44.228 11197 DEBUG nova.quota
[*req-bfc10adf-5a05-4fd1-a671-32547f48f391
bc455368223742729898fb85c995694d 9c011aa5646640abae282b9093515333 - - -*]
Quota limits for project 9c011aa5646640abae282b9093515333: {'project_id':
u'9c011aa5646640abae282b9093515333'} reserve
/opt/stack/nova/nova/quota.py:559

You can see within the [context] the change to using more information to
identify the user, and ids rather than name. The goal of this change
however is to ensure the context string is consistent across various
projects and is what is in place to be deployed in production systems.

As mentioned by Doug, there is an additional option to specify an
alternative format of user_identity (if necessary). However I have found to
make the message identical to historical name values, the minimum
requirements of oslo.log in nova would need to bump from 1.8.0 to 1.14.0

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

[openstack-dev] [devstack][QA] Changing logging format to match documented defaults

[Ronald Bradford]

Hi All,

I have observed that devstack uses custom logging formatting that differs
from the documented defaults. An example is for nova.

logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s
%(name)s [%(request_id)s *%(user_name)s %(project_name)s*]
%(instance)s%(message)s

which is defined in [1] , compared with

logging_context_format_string = %(asctime)s.%(msecs)03d %(levelname)s
%(name)s [%(request_id)s *%(user_identity)s*] %(instance)s%(message)s

which is the current Liberty specified default [2].  This infact is the
Oslo Logging default value and then can effectively be not defined at all.

In my manual tests I see not see failures when changing this in nova, but
as I know Infra and QA relies on devstack I would like to solicit feedback
from team members before proposing any changes to bring these to being
consistent.  This logging variable is also defined differently across 4
projects (nova, cinder, keystone and glance) so ultimately the goal would
be to ensure they may present documented configuration defaults.

[1] http://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/nova#n580
[2]
http://docs.openstack.org/liberty/config-reference/content/list-of-compute-config-options.html#config_table_nova_logging

Regards

Ronald
__
OpenStack Development Mailing 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] Reviewing code coverage syntax/use across projects

[Ronald Bradford]

As part of reviewing the code coverage on various projects I have found
that a number had failing coverage jobs when not configured correctly (many
also work just fine).  Starting initially in various Oslo projects my goal
has been to just ensure coverage is defined, runs without errors and is
generally consistent with existing syntax. [1]   This investigation has
been part of looking at projects when building a general code coverage
index and historical statistics. [2]

My initial minimum focus is to ensure the following (when either not
defined or partially defined):

   - A [tox:cover] section


   - The use of  python setup.py test --coverage syntax when not defined.
   Note this is "test" and not "testr"


   - The definition of an applicable .coveragerc to including branches and
   omit unit tests from coverage results.


   - Applicable .gitignore of various artifacts.


I would also like to start the larger discussion on several points I have
come across (for the wider community of projects) including:

   - The removal in  .coveragerc  omit= option of  [project]/openstack/*
   when the source tree no longer has this directory. Thanks to an explanation
   from dhellmann this seems to be an incubator artifact that is no longer
   generally used (but does exist in some projects).


   - The use of  python setup "test" syntax rather then "testr" for
   coverage usage.


   - the testr command for setuptools is deprecated (via lifeless)


   - There seems a lack of clearly defined Openstack docs around what is
   generally found, e.g. [3],[4],[5]. Hopefully the outcome of this discussion
   can be some updating of docs.


   - Anything else relevant regarding code coverage being more consistent
   for OpenStack.


Regards


Ronald




[1] https://review.openstack.org/#/q/topic:fix_coverage,n,z
[2] https://review.openstack.org/#/c/221494/
[3] https://wiki.openstack.org/wiki/Testr
[4] https://wiki.openstack.org/wiki/CoverageTesting
[5] http://docs.openstack.org/developer/cinder/devref/unit_tests.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Infra][Cross Project] Proposing a centralized location for code coverage reports

[Ronald Bradford]

Hi All,

In last week's Cross Project IRC meeting [1] I sought to determine the
merits and feasibility of having a central web location for code
coverage of various/all OpenStack projects.

Presently a few projects add code coverage as a non-voting gate and
that provides a per-commit viewing option, for example [2],[3].
I would first propose after a merge is committed, that coverage that
was generated for the commit is copied to a set and fixed URL so this
can be easily referenced in documentation, etc. (e.g.
coverage.openstack.org/openstack-infra/cover and
coverage.openstack.org/openstack/designate/cover respectively)

The purpose of recording code coverage is not to down vote any code
contributions due to lack of code coverage. The purpose includes:

1. Provide a central location to see current code coverage across
projects, and provide known public URLs.
2. Enable an entry point for discussion of improving code coverage,
especially as a means for newer developers to contribute to projects.
3. To provide analysis of project code coverage by recording coverage
reports over time.

fungi provided https://review.openstack.org/#/c/192253/ which is a
draft spec for a much wider ci-watch effort however I see this a more
specific example. I am seeking feedback from various projects on
interest, concerns and recommendations before creating a spec.

I see the initial steps to implement this as.

1. Agree on future domain url location for reports (e.g.
coverage.openstack.org)
2. Add to the merge committing process a step similar to the existing
coverage-log publisher (project-config/jenkins/jobs/macros.yaml) to
agreed location.
3. Provide initially a top level index page at url for published reports

These steps enable a single current occurrence of code coverage per
project. It is not the objective to keep the historical HTML output.

Following this, the next steps are to record coverage for historical
analysis with the following.

1. Alter tox.ini [testenv:cover]  to produce a text based version (aka
coverage report -m).  This is much easier to parse and compare
different versions. I would propose we keep a weekly/daily dated file
of this output, which would be automatically published as per previous
publisher.
2. Use these dated files to produce basic per project analysis of
lines/percentage coverage over time, publishing this to a set
directory structure (e.g. /analysis/) and linked from the top level
index page.  Over time this can be improved to provide simple
graphical output.



[1]
http://eavesdrop.openstack.org/meetings/crossproject/2015/crossproject.2015-08-25-21.00.html
[2]
http://logs.openstack.org/82/165682/8/check/nodepool-coverage/08c6340/cover/
[3]
http://logs.openstack.org/38/212738/12/check/designate-coverage/bc2e329/cover/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstackclient] Use and practices of --format shell for defining individual variables

[Ronald Bradford]

Thanks Doug,

I knew there would be a more definitive and simple use.
eval is that way!

Ronald


Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford http://twitter.com/ronaldbradford
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Tue, May 26, 2015 at 1:19 PM, Doug Hellmann d...@doughellmann.com
wrote:

 Excerpts from Ronald Bradford's message of 2015-05-26 11:18:09 -0400:
  Hi list,
 
  I came across the following neutron client specific syntax and decided to
  see if I could reproduce using the openstack client and it's flexible
  formatting capabilities
 
 
  $ NIC_ID1=$(neutron net-show public | awk '/ id /{print $4}')
 
  $  echo $NIC_ID1
  210d976e-16a3-42dc-ac31-f01810dbd297
 
  I can get similar syntax (unfortunately lowercase variable name only)
 with:
  NOTE: It may be nice to be able to pass an option to UPPERCASE all shell
  variables names.
 
  $ openstack network show public -c id --format shell --prefix nic_
  nic_id=210d976e-16a3-42dc-ac31-f01810dbd297
 
  However to use this I effectively have to place in a file and source that
  file to expose this variable to my current running shell.
  Reproducing the same syntax does not work obviously.

 It's actually meant to be used with an eval statement:

  $ eval $(openstack network show public -c id --format shell --prefix nic_)
  $ echo $nic_id

 Doug

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

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

[openstack-dev] [openstackclient] Use and practices of --format shell for defining individual variables

[Ronald Bradford]

Hi list,

I came across the following neutron client specific syntax and decided to
see if I could reproduce using the openstack client and it's flexible
formatting capabilities


$ NIC_ID1=$(neutron net-show public | awk '/ id /{print $4}')

$  echo $NIC_ID1
210d976e-16a3-42dc-ac31-f01810dbd297

I can get similar syntax (unfortunately lowercase variable name only) with:
NOTE: It may be nice to be able to pass an option to UPPERCASE all shell
variables names.

$ openstack network show public -c id --format shell --prefix nic_
nic_id=210d976e-16a3-42dc-ac31-f01810dbd297

However to use this I effectively have to place in a file and source that
file to expose this variable to my current running shell.
Reproducing the same syntax does not work obviously.

$ NIC_ID2=$(openstack network show public -c id --format shell)
$  echo $NIC_ID2
id=210d976e-16a3-42dc-ac31-f01810dbd297

And even stripping out the name= portion still results in a quoted
response.

$ NIC_ID3=$(openstack network show public -c id --format shell | cut -d=
-f2)
$ echo $NIC_ID3
210d976e-16a3-42dc-ac31-f01810dbd297

So in order to accurately reproduce I need the following which seems more
long winded then the original.

$ NIC_ID4=$(openstack network show public -c id --format shell | cut -d=
-f2 | tr -d '')
$ echo $NIC_ID4
210d976e-16a3-42dc-ac31-f01810dbd297

While I presume the intended use to create a file to source variables is
there any merit it supporting per variable definition as in this example?

Any thoughts appreciated.


Regards

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

Re: [openstack-dev] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

[Ronald Bradford]

To summarize. I believe we have 3 decisions from my original email but I
have also uncovered some more problems.

1. replication controller instead of rc

Adrian, regarding rc and replication controller.  The OSC uses verbose
commands including multi words. This includes availability zone, volume
type and security group role.  As this precedent is set, replication
controller rather then rc is inline with current syntax.   While I
personally am not for verbose operations in general or multi word options,
given the breath of commands already available you may not intrinsically
know what rc was, e.g. a OSC user that does not work with containers.

I believe replication controller is the appropriate choice here.

2. execute or exec

This is clearly a new type of action that requires OSC to provide
recommended guidance on. I am 50/50 here.

3. set or update

While I consider the word set to be more an attribute specific term,
update implies a change of multiple attributes. If I just looked at the
usage I would say update.  However, looking at the actual usage openstack
client set syntax uses named parameters to set multiple parameters.

$ openstack help quota set
usage: openstack quota set [-h] [--class] [--properties properties]
   [--ram ram] [--secgroup-rules secgroup-rules]
   [--instances instances] [--key-pairs
key-pairs]
   [--fixed-ips fixed-ips] [--secgroups
secgroups]
   [--injected-file-size injected-file-size]
   [--floating-ips floating-ips]
   [--injected-files injected-files]
   [--cores cores]
   [--injected-path-size injected-path-size]
   [--gigabytes gigabytes] [--volumes volumes]
   [--snapshots snapshots]
   [--volume-type volume-type]
   project/class


Looking into the help syntax of a Magnum update option, I find it
supports add, replace and remove operations.  This complicates
matters.

$ magnum help bay-update
usage: magnum bay-update bay op path=value [path=value ...]

Update information about the given bay.

Positional arguments:
  bay UUID or name of bay
  op  Operations: 'add', 'replace' or 'remove'
  path=value  Attributes to add/replace or remove (only PATH is necessary
on
remove)

I see the name specific parameters as a lot of work, I would be a fan of
more general name=value attributes.

Does update really then become  set and unset? Opinions.

4. service is already used by Identity. See
http://docs.openstack.org/developer/python-openstackclient/command-objects/service.html

5. container is already used by Swift. See
http://docs.openstack.org/developer/python-openstackclient/command-objects/container.html


I have no suggestions on 4. and 5.
Given these last 2 entanglements the OSC will quickly become unusable as
more clients which it integrate.

Regards

Ronald

Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn:  http://www.linkedin.com/in/ronaldbradford
Twitter:@RonaldBradford http://twitter.com/ronaldbradford
Skype: RonaldBradford
GTalk: Ronald.Bradford
IRC: rbradfor


On Mon, May 25, 2015 at 1:30 AM, Steve Martinelli steve...@ca.ibm.com
wrote:

 Hey Ronald,

 Thanks for asking first, as more folks are adopting OSC plugins for their
 respective clients we should probably streamline this a bit, but the ML
 works for now.

 Just 2 remarks...

 I'd actually prefer 'replication controller' (which you prefer) instead
 of 'rc' (as adrian suggested). The reason for this is that in OSC we try
 not to abbreviate when possible.

 Also, instead of 'update', is this analogous to user update or volume
 update? We've been using the key term 'set' instead wherever possible.

 For a complete list of current commands in vanilla OSC:
 http://docs.openstack.org/developer/python-openstackclient/command-list.html
 (see the lack of update :))

 Thanks,

 Steve Martinelli
 OpenStack Keystone Core

 Adrian Otto adrian.o...@rackspace.com wrote on 05/24/2015 10:35:12 PM:

  From: Adrian Otto adrian.o...@rackspace.com
  To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.org
  Date: 05/24/2015 10:35 PM
  Subject: Re: [openstack-dev] [openstackclient] [magnum] Review of
  object and actions for magnumclient implementation
 
  Thanks for taking the initiative on this! Remarks in-line...

 
  On May 24, 2015, at 11:20 AM, Ronald Bradford m...@ronaldbradford.com
 wrote:

  I have outlined in the blueprint  (https://blueprints.launchpad.net/
  python-openstackclient/+spec/magnum-support) the object and actions
  mappings that are currently available in the magnumclient.
  I have separated the list of actions that are presently used and
  actions that are not for review and discussion. Specifically These
  actions DO

[openstack-dev] [openstackclient] [magnum] Review of object and actions for magnumclient implementation

[Ronald Bradford]

I have outlined in the blueprint  (
https://blueprints.launchpad.net/python-openstackclient/+spec/magnum-support)
the object and actions mappings that are currently available in the
magnumclient.

I have separated the list of actions that are presently used and actions
that are not for review and discussion. Specifically These actions DO NOT
match.

bay [ update ]
container [ execute | start | stop ]
pod [ update ]
replication controller [ update ]
service [ update ]

I would appreciate feedback on if these actions update, execute,
start and stop are appropriate to use.

Regards

Ronald
__
OpenStack Development Mailing List (not for 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] Replace mysql-python with mysqlclient

[Ronald Bradford]

Has anybody considered the native python connector for MySQL that supports
Python 3.

Here are the Ubuntu Packages.


$ apt-get show python-mysql.connector
E: Invalid operation show
rbradfor@rubble:~$ apt-cache show python-mysql.connector
Package: python-mysql.connector
Priority: optional
Section: universe/python
Installed-Size: 386
Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
Original-Maintainer: Sandro Tosi mo...@debian.org
Architecture: all
Source: mysql-connector-python
Version: 1.1.6-1
Replaces: mysql-utilities ( 1.3.5-2)
Depends: python:any (= 2.7.5-5~), python:any ( 2.8)
Breaks: mysql-utilities ( 1.3.5-2)
Filename:
pool/universe/m/mysql-connector-python/python-mysql.connector_1.1.6-1_all.deb
Size: 67196
MD5sum: 22b2cb35cf8b14ac0bf4493b0d676adb
SHA1: de626403e1b14f617e9acb0a6934f044fae061c7
SHA256: 99e34f67d085c28b49eb8145c281deaa6d2b2a48d741e6831e149510087aab94
Description-en: pure Python implementation of MySQL Client/Server protocol
 MySQL driver written in Python which does not depend on MySQL C client
 libraries and implements the DB API v2.0 specification (PEP-249).
 .
 MySQL Connector/Python is implementing the MySQL Client/Server protocol
 completely in Python. This means you don't have to compile anything or
MySQL
 (client library) doesn't even have to be installed on the machine.
Description-md5: bb7e2eba7769d706d44e0ef91171b4ed
Homepage: http://dev.mysql.com/doc/connector-python/en/index.html
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu

$ apt-cache show python3-mysql.connector
Package: python3-mysql.connector
Priority: optional
Section: universe/python
Installed-Size: 385
Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
Original-Maintainer: Sandro Tosi mo...@debian.org
Architecture: all
Source: mysql-connector-python
Version: 1.1.6-1
Depends: python3:any (= 3.3.2-2~)
Filename:
pool/universe/m/mysql-connector-python/python3-mysql.connector_1.1.6-1_all.deb
Size: 64870
MD5sum: 461208ed1b89d516d6f6ce43c003a173
SHA1: bd439c4057824178490b402ad6c84067e1e2884e
SHA256: 487af52b98bc5f048faf4dc73420eff20b75a150e1f92c82de2ecdd4671659ae
Description-en: pure Python implementation of MySQL Client/Server protocol
(Python3)
 MySQL driver written in Python which does not depend on MySQL C client
 libraries and implements the DB API v2.0 specification (PEP-249).
 .
 MySQL Connector/Python is implementing the MySQL Client/Server protocol
 completely in Python. This means you don't have to compile anything or
MySQL
 (client library) doesn't even have to be installed on the machine.
 .
 This package contains the Python 3 version of mysql.connector.
Description-md5: 4bca3815f5856ddf4a629b418ec76c8f
Homepage: http://dev.mysql.com/doc/connector-python/en/index.html
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu


Ronald Bradford

Web Site: http://ronaldbradford.com
LinkedIn: http://www.linkedin.com/in/ronaldbradford
Twitter: @RonaldBradford http://twitter.com/ronaldbradford
Skype: RonaldBradford
GTalk:  Ronald.Bradford



On Thu, May 7, 2015 at 9:39 PM, Mike Bayer mba...@redhat.com wrote:



 On 5/7/15 5:32 PM, Thomas Goirand wrote:

 If there are really fixes and features we

 need in Py2K then of course we have to either convince MySQLdb to merge
 them or switch to mysqlclient.


 Given the no reply in 6 months I think that's enough to say it:
 mysql-python is a dangerous package with a non-responsive upstream. That's
 always bad, and IMO, enough to try to get rid of it. If you think switching
 to PyMYSQL is effortless, and the best way forward, then let's do that ASAP!


 haha - id rather have drop eventlet + mysqlclient :)

 as far as this thread, where this has been heading is that django has
 already been recommending mysqlclient and it's become apparent just what a
 barrage of emails and messages have been sent Andy Dustman's way, with no
 response.I agree this is troubling behavior, and I've alerted people at
 RH internal that we need to start thinking about this package switch.My
 original issue was that for Fedora etc., changing it in this way is
 challenging, and from my discussions with packaging people, this is
 actually correct - this isn't an easy way to do it for them and there have
 been many emails as a result.  My other issue is the SQLAlchemy testing
 issue - I'd essentially have to just stop testing mysql-python and switch
 to mysqlclient entirely, which means i need to revise all my docs and get
 all my users to switch also when the SQLAlchemy MySQLdb dialect eventually
 diverges from mysql-python 1.2.5, hence the whole thing is in a
 not-minor-enough way my problem as well.A simple module name change for
 mysqlclient, then there's no problem.   But there you go - assuming
 continued crickets from AD, and seeing that people continue find it
 important to appease projects like Trac that IMO quite amateurishly
 hardcode import MySQLdb, I don't see much other option

Re: [openstack-dev] [all] Replace mysql-python with mysqlclient

[Ronald Bradford]

I guess I may have spoken too soon.
https://wiki.openstack.org/wiki/PyMySQL_evaluation states   Oracle refuses
to publish MySQL-connector-Python on Pypi, which is critical to the
Openstack infrastructure.

I am unclear when this statement was made and who is involved in this
discussion.  As I have contacts in the MySQL engineering and Oracle
Corporation product development teams I will endeavor to seek a more
current and definitive response and statement.

Regards

Ronald



On Fri, May 8, 2015 at 10:33 AM, Ronald Bradford m...@ronaldbradford.com
wrote:

 Has anybody considered the native python connector for MySQL that supports
 Python 3.

 Here are the Ubuntu Packages.


 $ apt-get show python-mysql.connector
 E: Invalid operation show
 rbradfor@rubble:~$ apt-cache show python-mysql.connector
 Package: python-mysql.connector
 Priority: optional
 Section: universe/python
 Installed-Size: 386
 Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
 Original-Maintainer: Sandro Tosi mo...@debian.org
 Architecture: all
 Source: mysql-connector-python
 Version: 1.1.6-1
 Replaces: mysql-utilities ( 1.3.5-2)
 Depends: python:any (= 2.7.5-5~), python:any ( 2.8)
 Breaks: mysql-utilities ( 1.3.5-2)
 Filename:
 pool/universe/m/mysql-connector-python/python-mysql.connector_1.1.6-1_all.deb
 Size: 67196
 MD5sum: 22b2cb35cf8b14ac0bf4493b0d676adb
 SHA1: de626403e1b14f617e9acb0a6934f044fae061c7
 SHA256: 99e34f67d085c28b49eb8145c281deaa6d2b2a48d741e6831e149510087aab94
 Description-en: pure Python implementation of MySQL Client/Server protocol
  MySQL driver written in Python which does not depend on MySQL C client
  libraries and implements the DB API v2.0 specification (PEP-249).
  .
  MySQL Connector/Python is implementing the MySQL Client/Server protocol
  completely in Python. This means you don't have to compile anything or
 MySQL
  (client library) doesn't even have to be installed on the machine.
 Description-md5: bb7e2eba7769d706d44e0ef91171b4ed
 Homepage: http://dev.mysql.com/doc/connector-python/en/index.html
 Bugs: https://bugs.launchpad.net/ubuntu/+filebug
 Origin: Ubuntu

 $ apt-cache show python3-mysql.connector
 Package: python3-mysql.connector
 Priority: optional
 Section: universe/python
 Installed-Size: 385
 Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
 Original-Maintainer: Sandro Tosi mo...@debian.org
 Architecture: all
 Source: mysql-connector-python
 Version: 1.1.6-1
 Depends: python3:any (= 3.3.2-2~)
 Filename:
 pool/universe/m/mysql-connector-python/python3-mysql.connector_1.1.6-1_all.deb
 Size: 64870
 MD5sum: 461208ed1b89d516d6f6ce43c003a173
 SHA1: bd439c4057824178490b402ad6c84067e1e2884e
 SHA256: 487af52b98bc5f048faf4dc73420eff20b75a150e1f92c82de2ecdd4671659ae
 Description-en: pure Python implementation of MySQL Client/Server protocol
 (Python3)
  MySQL driver written in Python which does not depend on MySQL C client
  libraries and implements the DB API v2.0 specification (PEP-249).
  .
  MySQL Connector/Python is implementing the MySQL Client/Server protocol
  completely in Python. This means you don't have to compile anything or
 MySQL
  (client library) doesn't even have to be installed on the machine.
  .
  This package contains the Python 3 version of mysql.connector.
 Description-md5: 4bca3815f5856ddf4a629b418ec76c8f
 Homepage: http://dev.mysql.com/doc/connector-python/en/index.html
 Bugs: https://bugs.launchpad.net/ubuntu/+filebug
 Origin: Ubuntu


 Ronald Bradford

 Web Site: http://ronaldbradford.com
 LinkedIn: http://www.linkedin.com/in/ronaldbradford
 Twitter: @RonaldBradford http://twitter.com/ronaldbradford
 Skype: RonaldBradford
 GTalk:  Ronald.Bradford



 On Thu, May 7, 2015 at 9:39 PM, Mike Bayer mba...@redhat.com wrote:



 On 5/7/15 5:32 PM, Thomas Goirand wrote:

 If there are really fixes and features we

 need in Py2K then of course we have to either convince MySQLdb to merge
 them or switch to mysqlclient.


 Given the no reply in 6 months I think that's enough to say it:
 mysql-python is a dangerous package with a non-responsive upstream. That's
 always bad, and IMO, enough to try to get rid of it. If you think switching
 to PyMYSQL is effortless, and the best way forward, then let's do that ASAP!


 haha - id rather have drop eventlet + mysqlclient :)

 as far as this thread, where this has been heading is that django has
 already been recommending mysqlclient and it's become apparent just what a
 barrage of emails and messages have been sent Andy Dustman's way, with no
 response.I agree this is troubling behavior, and I've alerted people at
 RH internal that we need to start thinking about this package switch.My
 original issue was that for Fedora etc., changing it in this way is
 challenging, and from my discussions with packaging people, this is
 actually correct - this isn't an easy way to do it for them and there have
 been many emails as a result.  My other issue is the SQLAlchemy testing
 issue - I'd

Re: [openstack-dev] Navigating the ever changing OpenStack codebase

[Ronald Bradford]

Thanks again for the clarification. Your initial --notests was an option I
was unaware of and I didn't take the time to try variations. I was familiar
with invoking test names by regex I just thought it was more a convention.

Regards

Ronald



On Tue, Apr 28, 2015 at 2:48 PM, Doug Hellmann d...@doughellmann.com
wrote:

 Excerpts from Ronald Bradford's message of 2015-04-28 14:24:37 -0400:
  Thanks Doug. For others following this thread. The following creates and
  activates the tox virtual environment.
 
  # Note: its --spacenotests not --notests

 Sorry, that was a typo on my part. The option name is actually
 '--notest' (no s at the end). That causes tox to do everything it
 would normally do, except for the step where it runs the command list
 for the named environment.

  $ tox -epy27 -- notests

 This becomes:

  $ tox -e py27 --notest

 Doug

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

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

Re: [openstack-dev] Navigating the ever changing OpenStack codebase

[Ronald Bradford]

Thanks Doug. For others following this thread. The following creates and
activates the tox virtual environment.

# Note: its --spacenotests not --notests
$ tox -epy27 -- notests
$ source .tox/py27/bin/activate
(py27)$ openstack help


-- 
http://ronaldbradford.com/blog/running-openstack-tests-with-tox-2015-04-28/

01010010 0110 01101110 0111 01101100 01100100 0010 0110
01110010 0111 01100100 01100110 0110 01110010 01100100


*Ronald Bradford*
MySQL Expert specializing in Performance Tuning, Scalability and High
Availability

Lead Author - Effective MySQL: Replication Techniques In Depth
http://effectivemysql.com/book/replication-techniques/ - 2012, Author -
Effective MySQL: Backup and Recovery
http://effectivemysql.com/book/replication-techniques/ - 2012,
Author - Effective MySQL: Optimizing SQL Statements
http://effectivemysql.com/book/optimizing-sql-statements/ - 2011,  Co-author
- Expert PHP and MySQL http://expertphpandmysql.com/ - 2010
All-time top MySQL Blogger - 2011
http://mysqlpreacher.com/wordpress/2011/01/mysql-community-blogging-%E2%80%93-planetmysql-part-2/
, Oracle ACE Director - 2010
http://apex.oracle.com/pls/otn/f?p=19297:4:134763154226248::NO:4:P4_ID:1820
,  MySQL Community Member of the Year - 2009
http://www.mysql.com/why-mysql/awards/community-2009.html

Download Contact Details:  http://effectivemysql.com/contact-details/

Web Site: http://ronaldbradford.com
Linked In: http://www.linkedin.com/in/ronaldbradford
Twitter: @RonaldBradford http://twitter.com/ronaldbradford,
@MySQLExpert http://twitter.com/MySQLExpert
Skype: RonaldBradford
GTalk:  Ronald.Bradford



On Tue, Apr 28, 2015 at 10:44 AM, Doug Hellmann d...@doughellmann.com
wrote:

 Excerpts from Kevin L. Mitchell's message of 2015-04-27 17:38:25 -0500:
  On Mon, 2015-04-27 at 21:42 +, Jeremy Stanley wrote:
   I consider it an unfortunate oversight that those files weren't
   deleted a very, very long time ago.
 
  Unfortunately, there's one problem with that: you can't tell tox to use
  a virtualenv that you've built.  We need this capability at present, so
  we have to run tests using run_tests.sh instead of tox :(  I have an
  issue open on tox to address this need, but haven't seen any movement on
  that; so until then, I have to oppose the removal of run_tests.sh…
  despite how much *I'd* like to see it bite the dust!

 I had a similar requirement at one point and was able to use tox
 --notests to create the virtualenv, then modify it to add the tools I
 wanted, then run tox again to run the tests.

 Doug

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

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

[openstack-dev] Navigating the ever changing OpenStack codebase

[Ronald Bradford]

Hi All,

I have recently become involved in OpenStack development. After installing
a few devstacks (and buying some H/W for my own physical cloud) I settled
into learning, reviewing and debugging the Python OpenStack Client (seemed
an easy access point). I even published a blog post just 7 days ago on my
experiences of Python Virtual Environments (something I was not yet
familiar with. Python being about 10+ on my list of known languages) at
http://ronaldbradford.com/blog/inconsistent-messaging-for-openstackclient-2015-04-20/.
Since then I've been debugging the code and preparing to write some test
cases for what I consider is a small bug, and understand how to work on
making a contribution to that.

Specifically, the following two code snippets have become SOP (Standard
Operating Procedure) jumping around VMs and projects and I suspect if you
are a developer of this project, something you are very familiar with.

git clone git://git.openstack.org/openstack/python-openstackclient
cd python-openstackclient
python tools/install_venv.py
source .venv/bin/activate

./run_tests.sh



Today I went to pickup where I left off last week and I find with an
updated code base and run_tests.sh didn't work. Infact it not longer exists
in this project. See https://review.openstack.org/#/c/177066/

I also found that tools/install_venv.py also gone, see
https://review.openstack.org/#/c/177086/

So, I'm back to knowing almost nil about running tests and debugging my own
code in under a week.

While I appreciate the OpenStack codebase is a growing and evolving project
and I'm still a relative newbie, I'm a little lost in the traceability and
the audibility of a structural change (in other words, how you run unit
tests and setup virtual environments).  I suspect I'm missing something in
the information flow.

I'm on a few mailing lists, in a few IRC rooms, but I found this out by
looking at commit messages at
https://git.openstack.org/cgit/openstack/python-openstackclient/.  I am
unfamiliar with what is the best place for looking at information to remain
informed.

run_tests.sh is a great example where there was no deprecation message and
there is indeed no backward compatibility.  i.e. a run_test.sh that states:
Run tox instead.  This would at least not catch newbies off guard as much
when reading various documentation.

I also am lead to believe each project is self-governed (which is great as
it doesn't hobble projects by decision making) but that also leads to
different approaches on different projects. You don't want each project to
become siloed and difficult to navigate between them.  There was a choice
many years ago to standardize on Python. There are choices on coding
standards. Does this exist for testing too?

As somebody new to OpenStack code base and willing to contribute, even the
How to Contribute (https://wiki.openstack.org/wiki/How_To_Contribute
) while helpful is a lot to tackle. This next step to getting to know the
code, and I've not found a great source for this. I found it better to just
get stuck in downloading, reading and running it.  I looked back and came
across this link I did read some time ago --
http://docs.openstack.org/developer/cinder/devref/development.environment.html


Anybody able to provide recommendations for the new developer in the OS
space I would greatly appreciate it.

Having written this email draft I have delved into reading more about
testing. I started with the projects HACKING.rst which lead to
https://wiki.openstack.org/wiki/Testr and now
https://wiki.openstack.org/wiki/Testing. I should point out the last link
specifically states.

run_tests.sh

There is an older convention, as follows. Most projects have a shell
script, named run_tests.sh, that runs the unit tests of that project.  ...

So I've solved how to run tests the new way, took longer to write this
email. Still none the wiser how to run my code in a developer virtual
environment.

Regards

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