date:20150904

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Ken'ichi Ohmichi

2015-09-04 12:14 GMT+09:00 Ken'ichi Ohmichi :
> Hi Andrew,
>
> Sorry for this late response, I missed it.
>
> 2015-06-25 23:22 GMT+09:00 Andrew Laski :
>> I have been growing concerned recently with some attempts to formalize
>> scheduler hints, both with API validation and Nova objects defining them,
>> and want to air those concerns and see if others agree or can help me see
>> why I shouldn't worry.
>>
>> Starting with the API I think the strict input validation that's being done,
>> as seen in
>> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
>> is unnecessary, and potentially problematic.
>>
>> One problem is that it doesn't indicate anything useful for a client.  The
>> schema indicates that there are hints available but can make no claim about
>> whether or not they're actually enabled.  So while a microversion bump would
>> typically indicate a new feature available to an end user, in the case of a
>> new scheduler hint a microversion bump really indicates nothing at all.  It
>> does ensure that if a scheduler hint is used that it's spelled properly and
>> the data type passed is correct, but that's primarily useful because there
>> is no feedback mechanism to indicate an invalid or unused scheduler hint.  I
>> think the API schema is a poor proxy for that deficiency.
>>
>> Since the exposure of a hint means nothing as far as its usefulness, I don't
>> think we should be codifying them as part of our API schema at this time.
>> At some point I imagine we'll evolve a more useful API for passing
>> information to the scheduler as part of a request, and when that happens I
>> don't think needing to support a myriad of meaningless hints in older API
>> versions is going to be desirable.
>>
>> Finally, at this time I'm not sure we should take the stance that only
>> in-tree scheduler hints are supported.  While I completely agree with the
>> desire to expose things in cross-cloud ways as we've done and are looking to
>> do with flavor and image properties I think scheduling is an area where we
>> want to allow some flexibility for deployers to write and expose scheduling
>> capabilities that meet their specific needs.  Over time I hope we will get
>> to a place where some standardization can happen, but I don't think locking
>> in the current scheduling hints is the way forward for that.  I would love
>> to hear from multi-cloud users here and get some input on whether that's
>> crazy and they are expecting benefits from validation on the current
>> scheduler hints.
>>
>> Now, objects.  As part of the work to formalize the request spec sent to the
>> scheduler there's an effort to make a scheduler hints object.  This
>> formalizes them in the same way as the API with no benefit that I can see.
>> I won't duplicate my arguments above, but I feel the same way about the
>> objects as I do with the API.  I don't think needing to update and object
>> version every time a new hint is added is useful at this time, nor do I
>> think we should lock in the current in-tree hints.
>>
>> In the end this boils down to my concern that the scheduling hints api is a
>> really horrible user experience and I don't want it to be solidified in the
>> API or objects yet.  I think we should re-examine how they're handled before
>> that happens.
>
> Now we are discussing this on https://review.openstack.org/#/c/217727/
> for allowing out-of-tree scheduler-hints.
> When we wrote API schema for scheduler-hints, it was difficult to know
> what are available API parameters for scheduler-hints.
> Current API schema exposes them and I guess that is useful for API users also.
>
> One idea is that: How about auto-extending scheduler-hint API schema
> based on loaded schedulers?
> Now API schemas of "create/update/resize/rebuild a server" APIs are
> auto-extended based on loaded extensions by using stevedore
> library[1].
> I guess we can apply the same way for scheduler-hints also in long-term.
> Each scheduler needs to implement a method which returns available API
> parameter formats and nova-api tries to get them then extends
> scheduler-hints API schema with them.
> That means out-of-tree schedulers also will be available if they
> implement the method.
> # In short-term, I can see "blocking additionalProperties" validation
> disabled by the way.

https://review.openstack.org/#/c/220440 is a prototype for the above idea.

Thanks
Ken Ohmichi

__
OpenStack Development Mailing 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] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread Thierry Carrez

Hi PTLs,

Here is the proposed slot allocation for every "big tent" project team
at the Mitaka Design Summit in Tokyo. This is based on the requests the
liberty PTLs have made, space availability and project activity &
collaboration needs.

We have a lot less space (and time slots) in Tokyo compared to
Vancouver, so we were unable to give every team what they wanted. In
particular, there were far more workroom requests than we have
available, so we had to cut down on those quite heavily. Please note
that we'll have a large lunch room with roundtables inside the Design
Summit space that can easily be abused (outside of lunch) as space for
extra discussions.

Here is the allocation:

| fb: fishbowl 40-min slots
| wr: workroom 40-min slots
| cm: Friday contributors meetup
| | day: full day, morn: only morning, aft: only afternoon

Neutron: 12fb, cm:day
Nova: 14fb, cm:day
Cinder: 5fb, 4wr, cm:day
Horizon: 2fb, 7wr, cm:day   
Heat: 4fb, 8wr, cm:morn
Keystone: 7fb, 3wr, cm:day
Ironic: 4fb, 4wr, cm:morn
Oslo: 3fb, 5wr
Rally: 1fb, 2wr
Kolla: 3fb, 5wr, cm:aft
Ceilometer: 2fb, 7wr, cm:morn
TripleO: 2fb, 1wr, cm:full
Sahara: 2fb, 5wr, cm:aft
Murano: 2wr, cm:full
Glance: 3fb, 5wr, cm:full   
Manila: 2fb, 4wr, cm:morn
Magnum: 5fb, 5wr, cm:full   
Swift: 2fb, 12wr, cm:full   
Trove: 2fb, 4wr, cm:aft
Barbican: 2fb, 6wr, cm:aft
Designate: 1fb, 4wr, cm:aft
OpenStackClient: 1fb, 1wr, cm:morn
Mistral: 1fb, 3wr   
Zaqar: 1fb, 3wr
Congress: 3wr
Cue: 1fb, 1wr
Solum: 1fb
Searchlight: 1fb, 1wr
MagnetoDB: won't be present

Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA) 
PuppetOpenStack: 2fb, 3wr
Documentation: 2fb, 4wr, cm:morn
Quality Assurance: 4fb, 4wr, cm:full
OpenStackAnsible: 2fb, 1wr, cm:aft
Release management: 1fb, 1wr (shared meetup with QA)
Security: 2fb, 2wr
ChefOpenstack: will camp in the lunch room all week
App catalog: 1fb, 1wr
I18n: cm:morn
OpenStack UX: 2wr
Packaging-deb: 2wr
Refstack: 2wr
RpmPackaging: 1fb, 1wr

We'll start working on laying out those sessions over the available
rooms and time slots. If you have constraints (I already know
searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
Manila with Cinder, Solum with Magnum...) please let me know, we'll do
our best to limit them.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Ken'ichi Ohmichi

Hi Alex,

Thanks for  your comment.
IMO, this idea is different from the extension we will remove.
That is modularity for the maintenance burden.
By this idea, we can put the corresponding schema in each filter.

2015年9月4日(金) 19:04 Alex Xu :

> 2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi :
>
>> Hi Andrew,
>>
>> Sorry for this late response, I missed it.
>>
>> 2015-06-25 23:22 GMT+09:00 Andrew Laski :
>> > I have been growing concerned recently with some attempts to formalize
>> > scheduler hints, both with API validation and Nova objects defining
>> them,
>> > and want to air those concerns and see if others agree or can help me
>> see
>> > why I shouldn't worry.
>> >
>> > Starting with the API I think the strict input validation that's being
>> done,
>> > as seen in
>> >
>> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da
>> ,
>> > is unnecessary, and potentially problematic.
>> >
>> > One problem is that it doesn't indicate anything useful for a client.
>> The
>> > schema indicates that there are hints available but can make no claim
>> about
>> > whether or not they're actually enabled.  So while a microversion bump
>> would
>> > typically indicate a new feature available to an end user, in the case
>> of a
>> > new scheduler hint a microversion bump really indicates nothing at
>> all.  It
>> > does ensure that if a scheduler hint is used that it's spelled properly
>> and
>> > the data type passed is correct, but that's primarily useful because
>> there
>> > is no feedback mechanism to indicate an invalid or unused scheduler
>> hint.  I
>> > think the API schema is a poor proxy for that deficiency.
>> >
>> > Since the exposure of a hint means nothing as far as its usefulness, I
>> don't
>> > think we should be codifying them as part of our API schema at this
>> time.
>> > At some point I imagine we'll evolve a more useful API for passing
>> > information to the scheduler as part of a request, and when that
>> happens I
>> > don't think needing to support a myriad of meaningless hints in older
>> API
>> > versions is going to be desirable.
>> >
>> > Finally, at this time I'm not sure we should take the stance that only
>> > in-tree scheduler hints are supported.  While I completely agree with
>> the
>> > desire to expose things in cross-cloud ways as we've done and are
>> looking to
>> > do with flavor and image properties I think scheduling is an area where
>> we
>> > want to allow some flexibility for deployers to write and expose
>> scheduling
>> > capabilities that meet their specific needs.  Over time I hope we will
>> get
>> > to a place where some standardization can happen, but I don't think
>> locking
>> > in the current scheduling hints is the way forward for that.  I would
>> love
>> > to hear from multi-cloud users here and get some input on whether that's
>> > crazy and they are expecting benefits from validation on the current
>> > scheduler hints.
>> >
>> > Now, objects.  As part of the work to formalize the request spec sent
>> to the
>> > scheduler there's an effort to make a scheduler hints object.  This
>> > formalizes them in the same way as the API with no benefit that I can
>> see.
>> > I won't duplicate my arguments above, but I feel the same way about the
>> > objects as I do with the API.  I don't think needing to update and
>> object
>> > version every time a new hint is added is useful at this time, nor do I
>> > think we should lock in the current in-tree hints.
>> >
>> > In the end this boils down to my concern that the scheduling hints api
>> is a
>> > really horrible user experience and I don't want it to be solidified in
>> the
>> > API or objects yet.  I think we should re-examine how they're handled
>> before
>> > that happens.
>>
>> Now we are discussing this on https://review.openstack.org/#/c/217727/
>> for allowing out-of-tree scheduler-hints.
>> When we wrote API schema for scheduler-hints, it was difficult to know
>> what are available API parameters for scheduler-hints.
>> Current API schema exposes them and I guess that is useful for API users
>> also.
>>
>> One idea is that: How about auto-extending scheduler-hint API schema
>> based on loaded schedulers?
>> Now API schemas of "create/update/resize/rebuild a server" APIs are
>> auto-extended based on loaded extensions by using stevedore
>> library[1].
>>
>
> Emwe will deprecate the extension from our API. this sounds like add
> more extension mechanism.
>
>
>> I guess we can apply the same way for scheduler-hints also in long-term.
>> Each scheduler needs to implement a method which returns available API
>> parameter formats and nova-api tries to get them then extends
>> scheduler-hints API schema with them.
>> That means out-of-tree schedulers also will be available if they
>> implement the method.
>> # In short-term, I can see "blocking

Re: [openstack-dev] [murano] [dashboard] Remove the owner filter from "Package Definitions" page

2015-09-04 Thread Ekaterina Chernova

Agreed.

Currently, pagination is broken on "Package definitions" page now, so
removing that filter
will fix it back. Also, 'Other' tab looks unhelpful, admin should indicate
to witch tenant this package belongs to.
This improvement will be added later.

Regards,
Kate.

On Fri, Sep 4, 2015 at 1:06 PM, Alexander Tivelkov 
wrote:

> +1 on this.
>
> Filtering by ownership makes sense only on Catalog view (i.e. on the page
> of usable apps) but not on the admin-like console like the list of package
> definitions.
>
> --
> Regards,
> Alexander Tivelkov
>
> On Fri, Sep 4, 2015 at 12:36 PM, Dmitro Dovbii 
> wrote:
>
>> Hi folks!
>>
>> I want suggest you to delete owner filter (3 tabs) from Package
>> Definition page. Previously this filter was available for all users and we
>> agreed that it is useless. Now it is available only for admin but I think
>> this fact still doesn't improve the UX. Moreover, this filter prevents the
>> implementation of the search by name, because the work of the two filters
>> can be inconsistent.
>> So, please express your opinion on this issue. If you agree, I will
>> remove this filter ASAP.
>>
>> Best regards,
>> Dmytro Dovbii
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread Steven Hardy

On Fri, Sep 04, 2015 at 12:14:06PM +0200, Thierry Carrez wrote:

> 
> We'll start working on laying out those sessions over the available
> rooms and time slots. If you have constraints (I already know
> searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
> Manila with Cinder, Solum with Magnum...) please let me know, we'll do
> our best to limit them.

If possible it'd be best to avoid significant overlap between the Heat and
TripleO sessions as a number of folks are heavily involved with both.

Also between TripleO and Kolla if possible, as again there are some key
folks involved in cross-team efforts to enable containerized TripleO.

Thanks!

Steve

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

Re: [openstack-dev] [murano] [dashboard] Remove the owner filter from "Package Definitions" page

2015-09-04 Thread Alexander Tivelkov

+1 on this.

Filtering by ownership makes sense only on Catalog view (i.e. on the page
of usable apps) but not on the admin-like console like the list of package
definitions.

--
Regards,
Alexander Tivelkov

On Fri, Sep 4, 2015 at 12:36 PM, Dmitro Dovbii  wrote:

> Hi folks!
>
> I want suggest you to delete owner filter (3 tabs) from Package Definition
> page. Previously this filter was available for all users and we agreed that
> it is useless. Now it is available only for admin but I think this fact
> still doesn't improve the UX. Moreover, this filter prevents the
> implementation of the search by name, because the work of the two filters
> can be inconsistent.
> So, please express your opinion on this issue. If you agree, I will remove
> this filter ASAP.
>
> Best regards,
> Dmytro Dovbii
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [openstack-announce] [release][nova] python-novaclient release 2.28.0 (liberty)

2015-09-04 Thread Sean Dague

On 09/02/2015 05:48 PM, Matt Riedemann wrote:
> 
> 
> On 9/2/2015 3:40 PM, Jeremy Stanley wrote:
>> On 2015-09-02 10:55:56 -0400 (-0400), d...@doughellmann.com wrote:
>>> We are thrilled to announce the release of:
>>>
>>> python-novaclient 2.27.0: Client library for OpenStack Compute API
>> [...]
>>
>> Just as a heads up, there's some indication that this release is
>> currently broken by many popular service providers (behavior ranging
>> from 401 unauthorized errors to hanging indefinitely due, it seems,
>> to filtering or not supporting version detection in various ways).
>>
>>  https://launchpad.net/bugs/1491579
>>
> 
> And:
> 
> https://bugs.launchpad.net/python-novaclient/+bug/1491325
> 
> We have a fix for ^ and I plan on putting in the request for 2.27.1
> tonight once the fix is merged.  That should unblock manila.
> 
> For the version discovery bug, we plan on talking about that in the nova
> meeting tomorrow.

The issues exposed in novaclient version detection working correctly
against various clouds has now be fixed in 2.28.0 - the bug
https://bugs.launchpad.net/python-novaclient/+bug/1491579 has been
updated to hopefully contain all the relevant details of the issue.

-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

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Alex Xu

2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi :

> Hi Andrew,
>
> Sorry for this late response, I missed it.
>
> 2015-06-25 23:22 GMT+09:00 Andrew Laski :
> > I have been growing concerned recently with some attempts to formalize
> > scheduler hints, both with API validation and Nova objects defining them,
> > and want to air those concerns and see if others agree or can help me see
> > why I shouldn't worry.
> >
> > Starting with the API I think the strict input validation that's being
> done,
> > as seen in
> >
> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da
> ,
> > is unnecessary, and potentially problematic.
> >
> > One problem is that it doesn't indicate anything useful for a client.
> The
> > schema indicates that there are hints available but can make no claim
> about
> > whether or not they're actually enabled.  So while a microversion bump
> would
> > typically indicate a new feature available to an end user, in the case
> of a
> > new scheduler hint a microversion bump really indicates nothing at all.
> It
> > does ensure that if a scheduler hint is used that it's spelled properly
> and
> > the data type passed is correct, but that's primarily useful because
> there
> > is no feedback mechanism to indicate an invalid or unused scheduler
> hint.  I
> > think the API schema is a poor proxy for that deficiency.
> >
> > Since the exposure of a hint means nothing as far as its usefulness, I
> don't
> > think we should be codifying them as part of our API schema at this time.
> > At some point I imagine we'll evolve a more useful API for passing
> > information to the scheduler as part of a request, and when that happens
> I
> > don't think needing to support a myriad of meaningless hints in older API
> > versions is going to be desirable.
> >
> > Finally, at this time I'm not sure we should take the stance that only
> > in-tree scheduler hints are supported.  While I completely agree with the
> > desire to expose things in cross-cloud ways as we've done and are
> looking to
> > do with flavor and image properties I think scheduling is an area where
> we
> > want to allow some flexibility for deployers to write and expose
> scheduling
> > capabilities that meet their specific needs.  Over time I hope we will
> get
> > to a place where some standardization can happen, but I don't think
> locking
> > in the current scheduling hints is the way forward for that.  I would
> love
> > to hear from multi-cloud users here and get some input on whether that's
> > crazy and they are expecting benefits from validation on the current
> > scheduler hints.
> >
> > Now, objects.  As part of the work to formalize the request spec sent to
> the
> > scheduler there's an effort to make a scheduler hints object.  This
> > formalizes them in the same way as the API with no benefit that I can
> see.
> > I won't duplicate my arguments above, but I feel the same way about the
> > objects as I do with the API.  I don't think needing to update and object
> > version every time a new hint is added is useful at this time, nor do I
> > think we should lock in the current in-tree hints.
> >
> > In the end this boils down to my concern that the scheduling hints api
> is a
> > really horrible user experience and I don't want it to be solidified in
> the
> > API or objects yet.  I think we should re-examine how they're handled
> before
> > that happens.
>
> Now we are discussing this on https://review.openstack.org/#/c/217727/
> for allowing out-of-tree scheduler-hints.
> When we wrote API schema for scheduler-hints, it was difficult to know
> what are available API parameters for scheduler-hints.
> Current API schema exposes them and I guess that is useful for API users
> also.
>
> One idea is that: How about auto-extending scheduler-hint API schema
> based on loaded schedulers?
> Now API schemas of "create/update/resize/rebuild a server" APIs are
> auto-extended based on loaded extensions by using stevedore
> library[1].
>

Emwe will deprecate the extension from our API. this sounds like add
more extension mechanism.


> I guess we can apply the same way for scheduler-hints also in long-term.
> Each scheduler needs to implement a method which returns available API
> parameter formats and nova-api tries to get them then extends
> scheduler-hints API schema with them.
> That means out-of-tree schedulers also will be available if they
> implement the method.
> # In short-term, I can see "blocking additionalProperties" validation
> disabled by the way.
>
> Thanks
> Ken Ohmichi
>
> ---
> [1]:
> https://github.com/openstack/nova/blob/master/doc/source/api_plugins.rst#json-schema
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

Re: [openstack-dev] [sahara] FFE request for heat wait condition support

2015-09-04 Thread Vitaly Gridnev

+1 for FFE, because of

 1. Low risk of issues, fully covered with current scenario tests;
 2. Implementation already on review

On Fri, Sep 4, 2015 at 12:54 PM, Sergey Reshetnyak  wrote:

> Hi,
>
> I would like to request FFE for wait condition support for Heat engine.
> Wait condition reports signal about booting instance.
>
> Blueprint:
> https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions
>
> Spec:
>
> https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst
>
> Patch:
> https://review.openstack.org/#/c/169338/
>
> Thanks,
> Sergey Reshetnyak
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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

Re: [openstack-dev] FFE Request for completion of data driven assignment testing in Keystone

2015-09-04 Thread Henry Nash

Great, thanks.

Henry
> On 4 Sep 2015, at 09:17, Thierry Carrez  wrote:
> 
> Morgan Fainberg wrote:
>> 
>>>I would like to request an FFE for the remaining two patches that
>>>are already in review
>>>(https://review.openstack.org/#/c/153897/ and 
>>> https://review.openstack.org/#/c/154485/). 
>>>These contain only test code and no functional changes, and
>>>increase our test coverage - as well as enable other items to be
>>>re-use the list_role_assignment backend method.
>>> 
>>> Do we need a FFE for changes to tests?
>>> 
>> 
>> I would say "no". 
> 
> Right. Extra tests (or extra docs for that matter) don't count as a
> "feature" for the freeze. In particular it doesn't change the behavior
> of the software or invalidate testing that may have been conducted.
> 
> -- 
> 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] [murano] [dashboard] Remove the owner filter from "Package Definitions" page

2015-09-04 Thread Dmitro Dovbii

Hi folks!

I want suggest you to delete owner filter (3 tabs) from Package Definition
page. Previously this filter was available for all users and we agreed that
it is useless. Now it is available only for admin but I think this fact
still doesn't improve the UX. Moreover, this filter prevents the
implementation of the search by name, because the work of the two filters
can be inconsistent.
So, please express your opinion on this issue. If you agree, I will remove
this filter ASAP.

Best regards,
Dmytro Dovbii
__
OpenStack Development Mailing 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] [sahara] FFE request for heat wait condition support

2015-09-04 Thread Sergey Reshetnyak

Hi,

I would like to request FFE for wait condition support for Heat engine.
Wait condition reports signal about booting instance.

Blueprint:
https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions

Spec:
https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst

Patch:
https://review.openstack.org/#/c/169338/

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

Re: [openstack-dev] [openstack-announce] [release][nova] python-novaclient release 2.28.0 (liberty)

2015-09-04 Thread Sean Dague

On 09/04/2015 07:15 AM, Sean Dague wrote:
> On 09/02/2015 05:48 PM, Matt Riedemann wrote:
>>
>>
>> On 9/2/2015 3:40 PM, Jeremy Stanley wrote:
>>> On 2015-09-02 10:55:56 -0400 (-0400), d...@doughellmann.com wrote:
 We are thrilled to announce the release of:

 python-novaclient 2.27.0: Client library for OpenStack Compute API
>>> [...]
>>>
>>> Just as a heads up, there's some indication that this release is
>>> currently broken by many popular service providers (behavior ranging
>>> from 401 unauthorized errors to hanging indefinitely due, it seems,
>>> to filtering or not supporting version detection in various ways).
>>>
>>>  https://launchpad.net/bugs/1491579
>>>
>>
>> And:
>>
>> https://bugs.launchpad.net/python-novaclient/+bug/1491325
>>
>> We have a fix for ^ and I plan on putting in the request for 2.27.1
>> tonight once the fix is merged.  That should unblock manila.
>>
>> For the version discovery bug, we plan on talking about that in the nova
>> meeting tomorrow.
> 
> The issues exposed in novaclient version detection working correctly
> against various clouds has now be fixed in 2.28.0 - the bug
> https://bugs.launchpad.net/python-novaclient/+bug/1491579 has been
> updated to hopefully contain all the relevant details of the issue.

It also looks like a big reason that this unexpected behavior in the
field existed was because configuring SSL termination correctly (so that
link following in the rest documents work) requires setting a ton of
additional and divergent configuration options in various services.
Thanks for folks looking into the issue in the bug and helping explain
the behavior we saw.

We're not yet testing for that in Tempest, so people are probably not
realizing that their API environments are a bit janky.

Honestly, the fact that deployers are required to do this is crazy. The
service catalog already has this information, and the services should be
reflecting this back. However people spent a lot of time working around
the service catalog here probably because they didn't understand it, and
creating a configuration hairball in the process.

This I think raises the importance of really getting the Service Catalog
into shape in this next cycle so that we can get ahead of issues like
this one in the future, and actually ensure that out of the box cloud
installs work in situations like this.

-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

Re: [openstack-dev] [all] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread Flavio Percoco


On 04/09/15 12:14 +0200, Thierry Carrez wrote:

Hi PTLs,

Here is the proposed slot allocation for every "big tent" project team
at the Mitaka Design Summit in Tokyo. This is based on the requests the
liberty PTLs have made, space availability and project activity &
collaboration needs.

We have a lot less space (and time slots) in Tokyo compared to
Vancouver, so we were unable to give every team what they wanted. In
particular, there were far more workroom requests than we have
available, so we had to cut down on those quite heavily. Please note
that we'll have a large lunch room with roundtables inside the Design
Summit space that can easily be abused (outside of lunch) as space for
extra discussions.

Here is the allocation:

| fb: fishbowl 40-min slots
| wr: workroom 40-min slots
| cm: Friday contributors meetup
| | day: full day, morn: only morning, aft: only afternoon

Neutron: 12fb, cm:day
Nova: 14fb, cm:day
Cinder: 5fb, 4wr, cm:day
Horizon: 2fb, 7wr, cm:day   
Heat: 4fb, 8wr, cm:morn
Keystone: 7fb, 3wr, cm:day
Ironic: 4fb, 4wr, cm:morn
Oslo: 3fb, 5wr
Rally: 1fb, 2wr
Kolla: 3fb, 5wr, cm:aft
Ceilometer: 2fb, 7wr, cm:morn
TripleO: 2fb, 1wr, cm:full
Sahara: 2fb, 5wr, cm:aft
Murano: 2wr, cm:full
Glance: 3fb, 5wr, cm:full   
Manila: 2fb, 4wr, cm:morn
Magnum: 5fb, 5wr, cm:full   
Swift: 2fb, 12wr, cm:full   
Trove: 2fb, 4wr, cm:aft
Barbican: 2fb, 6wr, cm:aft
Designate: 1fb, 4wr, cm:aft
OpenStackClient: 1fb, 1wr, cm:morn
Mistral: 1fb, 3wr   
Zaqar: 1fb, 3wr
Congress: 3wr
Cue: 1fb, 1wr
Solum: 1fb
Searchlight: 1fb, 1wr
MagnetoDB: won't be present

Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA) 
PuppetOpenStack: 2fb, 3wr
Documentation: 2fb, 4wr, cm:morn
Quality Assurance: 4fb, 4wr, cm:full
OpenStackAnsible: 2fb, 1wr, cm:aft
Release management: 1fb, 1wr (shared meetup with QA)
Security: 2fb, 2wr
ChefOpenstack: will camp in the lunch room all week
App catalog: 1fb, 1wr
I18n: cm:morn
OpenStack UX: 2wr
Packaging-deb: 2wr
Refstack: 2wr
RpmPackaging: 1fb, 1wr

We'll start working on laying out those sessions over the available
rooms and time slots. If you have constraints (I already know
searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
Manila with Cinder, Solum with Magnum...) please let me know, we'll do
our best to limit them.


From a very selfish POV, I'd like to avoid conflicts between Glance
and Zaqar.

From a community POV, It'd be cool if we could avoid conflicts between
Zaqar and Sahara (at least in 1wr slot) since we'd like to dedicate 1
to Sahara.

Cheers,
Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [sahara] Request for Feature Freeze Exception

2015-09-04 Thread Sergey Reshetnyak

+1 from me.

Thanks,
Sergey R.

2015-09-03 23:27 GMT+03:00 Ethan Gafford :

> Agreed. We've talked about this for a while, and it's very low risk.
>
> Thanks,
> Ethan
>
> - Original Message -
> From: "michael mccune" 
> To: openstack-dev@lists.openstack.org
> Sent: Thursday, September 3, 2015 3:53:41 PM
> Subject: Re: [openstack-dev] [sahara] Request for Feature Freeze Exception
>
> On 09/03/2015 02:49 PM, Vitaly Gridnev wrote:
> > Hey folks!
> >
> > I would like to propose to add to list of FFE's following blueprint:
> > https://blueprints.launchpad.net/sahara/+spec/drop-hadoop-1
> >
> > Reasoning of that is following:
> >
> >   1. HDP 1.3.2 and Vanilla 1.2.1 are not gated for a whole release
> > cycle, so it can be reason of several bugs in these versions;
> >   2. Minimal risk of removal: it doesn't touch versions that we already
> > have.
> >   3. All required changes was already uploaded to the review:
> >
> https://review.openstack.org/#/q/status:open+project:openstack/sahara+branch:master+topic:bp/drop-hadoop-1,n,z
>
> this sounds reasonable to me
>
> mike
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Sylvain Bauza




Le 04/09/2015 12:18, Ken'ichi Ohmichi a écrit :


Hi Alex,

Thanks for  your comment.
IMO, this idea is different from the extension we will remove.
That is modularity for the maintenance burden.
By this idea, we can put the corresponding schema in each filter.




While I think it could be a nice move to have stevedore-loaded filters 
for the FilterScheduler due to many reasons, I actually wouldn't want to 
delay more than needed the compatibility change for the API validation 
relaxing the scheduler hints.


In order to have a smooth transition, I'd rather just provide a change 
for using stevedore with the filters and weighters (even if the 
weighters are not using the API), and then once implemented, then do the 
necessary change on the API level like the one you proposed.


In the meantime, IMHO we should accept rather sooner than later (meaning 
for Liberty) https://review.openstack.org/#/c/217727/


Thanks for that good idea, I like it,

-Sylvain


2015年9月4日(金) 19:04 Alex Xu >:


2015-09-04 11:14 GMT+08:00 Ken'ichi Ohmichi >:

Hi Andrew,

Sorry for this late response, I missed it.

2015-06-25 23:22 GMT+09:00 Andrew Laski >:
> I have been growing concerned recently with some attempts to
formalize
> scheduler hints, both with API validation and Nova objects
defining them,
> and want to air those concerns and see if others agree or
can help me see
> why I shouldn't worry.
>
> Starting with the API I think the strict input validation
that's being done,
> as seen in
>

http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
> is unnecessary, and potentially problematic.
>
> One problem is that it doesn't indicate anything useful for
a client.  The
> schema indicates that there are hints available but can make
no claim about
> whether or not they're actually enabled.  So while a
microversion bump would
> typically indicate a new feature available to an end user,
in the case of a
> new scheduler hint a microversion bump really indicates
nothing at all.  It
> does ensure that if a scheduler hint is used that it's
spelled properly and
> the data type passed is correct, but that's primarily useful
because there
> is no feedback mechanism to indicate an invalid or unused
scheduler hint.  I
> think the API schema is a poor proxy for that deficiency.
>
> Since the exposure of a hint means nothing as far as its
usefulness, I don't
> think we should be codifying them as part of our API schema
at this time.
> At some point I imagine we'll evolve a more useful API for
passing
> information to the scheduler as part of a request, and when
that happens I
> don't think needing to support a myriad of meaningless hints
in older API
> versions is going to be desirable.
>
> Finally, at this time I'm not sure we should take the stance
that only
> in-tree scheduler hints are supported.  While I completely
agree with the
> desire to expose things in cross-cloud ways as we've done
and are looking to
> do with flavor and image properties I think scheduling is an
area where we
> want to allow some flexibility for deployers to write and
expose scheduling
> capabilities that meet their specific needs. Over time I
hope we will get
> to a place where some standardization can happen, but I
don't think locking
> in the current scheduling hints is the way forward for
that.  I would love
> to hear from multi-cloud users here and get some input on
whether that's
> crazy and they are expecting benefits from validation on the
current
> scheduler hints.
>
> Now, objects.  As part of the work to formalize the request
spec sent to the
> scheduler there's an effort to make a scheduler hints
object.  This
> formalizes them in the same way as the API with no benefit
that I can see.
> I won't duplicate my arguments above, but I feel the same
way about the
> objects as I do with the API.  I don't think needing to
update and object
> version every time a new hint is added is useful at this
time, nor do I
> think we should lock in the current in-tree hints.
>
> In the end this boils down to my concern that the scheduling

Re: [openstack-dev] [all] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread Dmitry Tantsur


On 09/04/2015 12:14 PM, Thierry Carrez wrote:

Hi PTLs,

Here is the proposed slot allocation for every "big tent" project team
at the Mitaka Design Summit in Tokyo. This is based on the requests the
liberty PTLs have made, space availability and project activity &
collaboration needs.

We have a lot less space (and time slots) in Tokyo compared to
Vancouver, so we were unable to give every team what they wanted. In
particular, there were far more workroom requests than we have
available, so we had to cut down on those quite heavily. Please note
that we'll have a large lunch room with roundtables inside the Design
Summit space that can easily be abused (outside of lunch) as space for
extra discussions.

Here is the allocation:

| fb: fishbowl 40-min slots
| wr: workroom 40-min slots
| cm: Friday contributors meetup
| | day: full day, morn: only morning, aft: only afternoon

Neutron: 12fb, cm:day
Nova: 14fb, cm:day
Cinder: 5fb, 4wr, cm:day
Horizon: 2fb, 7wr, cm:day   
Heat: 4fb, 8wr, cm:morn
Keystone: 7fb, 3wr, cm:day
Ironic: 4fb, 4wr, cm:morn
Oslo: 3fb, 5wr
Rally: 1fb, 2wr
Kolla: 3fb, 5wr, cm:aft
Ceilometer: 2fb, 7wr, cm:morn
TripleO: 2fb, 1wr, cm:full
Sahara: 2fb, 5wr, cm:aft
Murano: 2wr, cm:full
Glance: 3fb, 5wr, cm:full   
Manila: 2fb, 4wr, cm:morn
Magnum: 5fb, 5wr, cm:full   
Swift: 2fb, 12wr, cm:full   
Trove: 2fb, 4wr, cm:aft
Barbican: 2fb, 6wr, cm:aft
Designate: 1fb, 4wr, cm:aft
OpenStackClient: 1fb, 1wr, cm:morn
Mistral: 1fb, 3wr   
Zaqar: 1fb, 3wr
Congress: 3wr
Cue: 1fb, 1wr
Solum: 1fb
Searchlight: 1fb, 1wr
MagnetoDB: won't be present

Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA) 
PuppetOpenStack: 2fb, 3wr
Documentation: 2fb, 4wr, cm:morn
Quality Assurance: 4fb, 4wr, cm:full
OpenStackAnsible: 2fb, 1wr, cm:aft
Release management: 1fb, 1wr (shared meetup with QA)
Security: 2fb, 2wr
ChefOpenstack: will camp in the lunch room all week
App catalog: 1fb, 1wr
I18n: cm:morn
OpenStack UX: 2wr
Packaging-deb: 2wr
Refstack: 2wr
RpmPackaging: 1fb, 1wr

We'll start working on laying out those sessions over the available
rooms and time slots. If you have constraints (I already know
searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
Manila with Cinder, Solum with Magnum...) please let me know, we'll do
our best to limit them.



Would be cool to avoid conflicts between Ironic and TripleO.

__
OpenStack Development Mailing List (not for 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] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread Nikhil Komawar

No dedicated time slot for cross-project sessions this time around?

On 9/4/15 6:14 AM, Thierry Carrez wrote:
> Hi PTLs,
>
> Here is the proposed slot allocation for every "big tent" project team
> at the Mitaka Design Summit in Tokyo. This is based on the requests the
> liberty PTLs have made, space availability and project activity &
> collaboration needs.
>
> We have a lot less space (and time slots) in Tokyo compared to
> Vancouver, so we were unable to give every team what they wanted. In
> particular, there were far more workroom requests than we have
> available, so we had to cut down on those quite heavily. Please note
> that we'll have a large lunch room with roundtables inside the Design
> Summit space that can easily be abused (outside of lunch) as space for
> extra discussions.
>
> Here is the allocation:
>
> | fb: fishbowl 40-min slots
> | wr: workroom 40-min slots
> | cm: Friday contributors meetup
> | | day: full day, morn: only morning, aft: only afternoon
>
> Neutron: 12fb, cm:day
> Nova: 14fb, cm:day
> Cinder: 5fb, 4wr, cm:day  
> Horizon: 2fb, 7wr, cm:day 
> Heat: 4fb, 8wr, cm:morn
> Keystone: 7fb, 3wr, cm:day
> Ironic: 4fb, 4wr, cm:morn
> Oslo: 3fb, 5wr
> Rally: 1fb, 2wr
> Kolla: 3fb, 5wr, cm:aft
> Ceilometer: 2fb, 7wr, cm:morn
> TripleO: 2fb, 1wr, cm:full
> Sahara: 2fb, 5wr, cm:aft
> Murano: 2wr, cm:full
> Glance: 3fb, 5wr, cm:full 
> Manila: 2fb, 4wr, cm:morn
> Magnum: 5fb, 5wr, cm:full 
> Swift: 2fb, 12wr, cm:full 
> Trove: 2fb, 4wr, cm:aft
> Barbican: 2fb, 6wr, cm:aft
> Designate: 1fb, 4wr, cm:aft
> OpenStackClient: 1fb, 1wr, cm:morn
> Mistral: 1fb, 3wr 
> Zaqar: 1fb, 3wr
> Congress: 3wr
> Cue: 1fb, 1wr
> Solum: 1fb
> Searchlight: 1fb, 1wr
> MagnetoDB: won't be present
>
> Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)   
> PuppetOpenStack: 2fb, 3wr
> Documentation: 2fb, 4wr, cm:morn
> Quality Assurance: 4fb, 4wr, cm:full
> OpenStackAnsible: 2fb, 1wr, cm:aft
> Release management: 1fb, 1wr (shared meetup with QA)
> Security: 2fb, 2wr
> ChefOpenstack: will camp in the lunch room all week
> App catalog: 1fb, 1wr
> I18n: cm:morn
> OpenStack UX: 2wr
> Packaging-deb: 2wr
> Refstack: 2wr
> RpmPackaging: 1fb, 1wr
>
> We'll start working on laying out those sessions over the available
> rooms and time slots. If you have constraints (I already know
> searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
> Manila with Cinder, Solum with Magnum...) please let me know, we'll do
> our best to limit them.
>

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Andrew Laski

On 09/04/15 at 06:54pm, Ken'ichi Ohmichi wrote:

2015-09-04 12:14 GMT+09:00 Ken'ichi Ohmichi :

Hi Andrew,

Sorry for this late response, I missed it.

2015-06-25 23:22 GMT+09:00 Andrew Laski :

I have been growing concerned recently with some attempts to formalize
scheduler hints, both with API validation and Nova objects defining them,
and want to air those concerns and see if others agree or can help me see
why I shouldn't worry.

Starting with the API I think the strict input validation that's being done,
as seen in
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
is unnecessary, and potentially problematic.

One problem is that it doesn't indicate anything useful for a client. The
schema indicates that there are hints available but can make no claim about
whether or not they're actually enabled. So while a microversion bump would
typically indicate a new feature available to an end user, in the case of a
new scheduler hint a microversion bump really indicates nothing at all. It
does ensure that if a scheduler hint is used that it's spelled properly and
the data type passed is correct, but that's primarily useful because there
is no feedback mechanism to indicate an invalid or unused scheduler hint. I
think the API schema is a poor proxy for that deficiency.

Since the exposure of a hint means nothing as far as its usefulness, I don't
think we should be codifying them as part of our API schema at this time.
At some point I imagine we'll evolve a more useful API for passing
information to the scheduler as part of a request, and when that happens I
don't think needing to support a myriad of meaningless hints in older API
versions is going to be desirable.

Finally, at this time I'm not sure we should take the stance that only
in-tree scheduler hints are supported. While I completely agree with the
desire to expose things in cross-cloud ways as we've done and are looking to
do with flavor and image properties I think scheduling is an area where we
want to allow some flexibility for deployers to write and expose scheduling
capabilities that meet their specific needs. Over time I hope we will get
to a place where some standardization can happen, but I don't think locking
in the current scheduling hints is the way forward for that. I would love
to hear from multi-cloud users here and get some input on whether that's
crazy and they are expecting benefits from validation on the current
scheduler hints.

Now, objects. As part of the work to formalize the request spec sent to the
scheduler there's an effort to make a scheduler hints object. This
formalizes them in the same way as the API with no benefit that I can see.
I won't duplicate my arguments above, but I feel the same way about the
objects as I do with the API. I don't think needing to update and object
version every time a new hint is added is useful at this time, nor do I
think we should lock in the current in-tree hints.

In the end this boils down to my concern that the scheduling hints api is a
really horrible user experience and I don't want it to be solidified in the
API or objects yet. I think we should re-examine how they're handled before
that happens.

Now we are discussing this on https://review.openstack.org/#/c/217727/
for allowing out-of-tree scheduler-hints.
When we wrote API schema for scheduler-hints, it was difficult to know
what are available API parameters for scheduler-hints.
Current API schema exposes them and I guess that is useful for API users also.

One idea is that: How about auto-extending scheduler-hint API schema
based on loaded schedulers?
Now API schemas of "create/update/resize/rebuild a server" APIs are
auto-extended based on loaded extensions by using stevedore
library[1].
I guess we can apply the same way for scheduler-hints also in long-term.
Each scheduler needs to implement a method which returns available API
parameter formats and nova-api tries to get them then extends
scheduler-hints API schema with them.
That means out-of-tree schedulers also will be available if they
implement the method.
# In short-term, I can see "blocking additionalProperties" validation
disabled by the way.

https://review.openstack.org/#/c/220440 is a prototype for the above idea.

I like the idea of providing strict API validation for the scheduler
hints if it accounts for out of tree extensions like this would do. I
do have a slight concern about how this works in a world where the
scheduler does eventually get an HTTP interface that Nova uses and the
code isn't necessarily accessible, but that can be worried about later.

This does mean that the scheduler hints are not controlled by
microversions though, since we don't have a mechanism for out of tree
extensions to signal their presence that way. And even if they could it
would still mean that identical microversions

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Sylvain Bauza

Le 04/09/2015 14:57, Nikola Đipanov a écrit :

On 06/25/2015 04:50 PM, Monty Taylor wrote:

On 06/25/2015 10:22 AM, Andrew Laski wrote:

I have been growing concerned recently with some attempts to formalize
scheduler hints, both with API validation and Nova objects defining
them, and want to air those concerns and see if others agree or can help
me see why I shouldn't worry.

Starting with the API I think the strict input validation that's being
done, as seen in
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
is unnecessary, and potentially problematic.

One problem is that it doesn't indicate anything useful for a client.
The schema indicates that there are hints available but can make no
claim about whether or not they're actually enabled. So while a
microversion bump would typically indicate a new feature available to an
end user, in the case of a new scheduler hint a microversion bump really
indicates nothing at all. It does ensure that if a scheduler hint is
used that it's spelled properly and the data type passed is correct, but
that's primarily useful because there is no feedback mechanism to
indicate an invalid or unused scheduler hint. I think the API schema is
a poor proxy for that deficiency.

Since the exposure of a hint means nothing as far as its usefulness, I
don't think we should be codifying them as part of our API schema at
this time. At some point I imagine we'll evolve a more useful API for
passing information to the scheduler as part of a request, and when that
happens I don't think needing to support a myriad of meaningless hints
in older API versions is going to be desirable.

I totally agree.

If hints are to become an object, then need to be _real_ resources that
can be listed, and that have structured metadata that has an API.
Flavors are a great example of this. From an end user perspective, I can
ask the cloud what flavors exist, those flavors tell me information that
I can use to make a decision, and I can pass in a reference to those
things. If I pass in an invalid flavor, I get a meaningful error message.

Finally, at this time I'm not sure we should take the stance that only
in-tree scheduler hints are supported. While I completely agree with
the desire to expose things in cross-cloud ways as we've done and are
looking to do with flavor and image properties I think scheduling is an
area where we want to allow some flexibility for deployers to write and
expose scheduling capabilities that meet their specific needs. Over
time I hope we will get to a place where some standardization can
happen, but I don't think locking in the current scheduling hints is the
way forward for that. I would love to hear from multi-cloud users here
and get some input on whether that's crazy and they are expecting
benefits from validation on the current scheduler hints.

As a multi-cloud user, I do not use scheduler hints because there is no
API to discover that they exist, and also no shared sense of semantics.
(I know a flavor that claims 8G of RAM will give me, you guessed it, 8G
of ram) So I consider scheduler hints currently to be COMPLETE vendor
lock-in and/or only things to be used by private cloud folks who are
also admins of their clouds.

I would not touch them with a 10 foot pole until such a time as there is
an actual API for listing, describing and selecting them.

I would suggest that if we make one of those, we should quickly
formalize meanings of fields - so that cloud can have specific hints
that seem like cloud content - but that the way I learn about them is
the same, and if there are two hints that do the same thing I can expect
them to look the same in two different clouds.

So this kind of argumentation keeps confusing me TBH. Unless I am not
understanding some basic things about how Nova works, the above argument
cleanly applies to flavors as well. Flavor '42' is not going to be the
same thing across clouds, but that's not where this ends. Once you throw
in extra_specs, in particular related to PCI devices and NUMA/CPU
pinning features. There is really no discoverability there whatsoever (*).

What I am trying to get to is not whether this is right or wrong, but to
point out the fact that Flavors are simply not a good abstraction that
can have reasonable meaning "across cloud boundaries" (i.e. different
Nova deployments), at least the way they are implemented at the moment.
We should not pretend that they are, and try to demonize useful code
making use of them, but come up with a better abstraction that can have
reasonable meaning across different deployments.

I think this is what Andrew was hinting at when he said that scheduling
is an area that cannot reasonably be standardized in this way.

I recently spoke to John briefly about this and got the feeling that he
has similar views - but I'd encourage him to comment if he wishes to do so.

(*) For PCI

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Andrew Laski

On 09/04/15 at 01:57pm, Nikola Đipanov wrote:

On 06/25/2015 04:50 PM, Monty Taylor wrote:

On 06/25/2015 10:22 AM, Andrew Laski wrote:

I have been growing concerned recently with some attempts to formalize
scheduler hints, both with API validation and Nova objects defining
them, and want to air those concerns and see if others agree or can help
me see why I shouldn't worry.

Starting with the API I think the strict input validation that's being
done, as seen in
http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
is unnecessary, and potentially problematic.

One problem is that it doesn't indicate anything useful for a client.
The schema indicates that there are hints available but can make no
claim about whether or not they're actually enabled. So while a
microversion bump would typically indicate a new feature available to an
end user, in the case of a new scheduler hint a microversion bump really
indicates nothing at all. It does ensure that if a scheduler hint is
used that it's spelled properly and the data type passed is correct, but
that's primarily useful because there is no feedback mechanism to
indicate an invalid or unused scheduler hint. I think the API schema is
a poor proxy for that deficiency.

Since the exposure of a hint means nothing as far as its usefulness, I
don't think we should be codifying them as part of our API schema at
this time. At some point I imagine we'll evolve a more useful API for
passing information to the scheduler as part of a request, and when that
happens I don't think needing to support a myriad of meaningless hints
in older API versions is going to be desirable.

I totally agree.

Finally, at this time I'm not sure we should take the stance that only
in-tree scheduler hints are supported. While I completely agree with
the desire to expose things in cross-cloud ways as we've done and are
looking to do with flavor and image properties I think scheduling is an
area where we want to allow some flexibility for deployers to write and
expose scheduling capabilities that meet their specific needs. Over
time I hope we will get to a place where some standardization can
happen, but I don't think locking in the current scheduling hints is the
way forward for that. I would love to hear from multi-cloud users here
and get some input on whether that's crazy and they are expecting
benefits from validation on the current scheduler hints.

I would not touch them with a 10 foot pole until such a time as there is
an actual API for listing, describing and selecting them.

I think this is what Andrew was hinting at when he said that scheduling
is an area that cannot reasonably be standardized in this way.

Essentially. Flavors work out because they can be queried in order to
get at the important information. It doesn't matter what the flavor is
called in each cloud

[openstack-dev] [Openstack] [Horizon] [Sahara] FFE request for Sahara unified job interface map UI

2015-09-04 Thread Ethan Gafford

Hello all,

I request a FFE for the change at: https://review.openstack.org/#/c/209683/

This change enables a significant improvement to UX in Sahara's elastic data 
processing flow which is already in the server and client layers of Sahara. 
Because it specifically aims at improving ease of use and comprehensibility, 
Horizon integration is critical to the success of the feature. The change 
itself is reasonably modular and thus low-risk; it will have no impact outside 
Sahara's job template creation and launch flow, and (failing unforseen issues) 
no impact to users of the existing flow who choose not to use this feature.

Thank you,
Ethan

__
OpenStack Development Mailing List (not for 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] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread gord chung




On 04/09/2015 6:14 AM, Thierry Carrez wrote:

Hi PTLs,

Here is the proposed slot allocation for every "big tent" project team
at the Mitaka Design Summit in Tokyo. This is based on the requests the
liberty PTLs have made, space availability and project activity &
collaboration needs.

We have a lot less space (and time slots) in Tokyo compared to
Vancouver, so we were unable to give every team what they wanted. In
particular, there were far more workroom requests than we have
available, so we had to cut down on those quite heavily. Please note
that we'll have a large lunch room with roundtables inside the Design
Summit space that can easily be abused (outside of lunch) as space for
extra discussions.

Here is the allocation:

| fb: fishbowl 40-min slots
| wr: workroom 40-min slots
| cm: Friday contributors meetup
| | day: full day, morn: only morning, aft: only afternoon

Neutron: 12fb, cm:day
Nova: 14fb, cm:day
Cinder: 5fb, 4wr, cm:day
Horizon: 2fb, 7wr, cm:day   
Heat: 4fb, 8wr, cm:morn
Keystone: 7fb, 3wr, cm:day
Ironic: 4fb, 4wr, cm:morn
Oslo: 3fb, 5wr
Rally: 1fb, 2wr
Kolla: 3fb, 5wr, cm:aft
Ceilometer: 2fb, 7wr, cm:morn
TripleO: 2fb, 1wr, cm:full
Sahara: 2fb, 5wr, cm:aft
Murano: 2wr, cm:full
Glance: 3fb, 5wr, cm:full   
Manila: 2fb, 4wr, cm:morn
Magnum: 5fb, 5wr, cm:full   
Swift: 2fb, 12wr, cm:full   
Trove: 2fb, 4wr, cm:aft
Barbican: 2fb, 6wr, cm:aft
Designate: 1fb, 4wr, cm:aft
OpenStackClient: 1fb, 1wr, cm:morn
Mistral: 1fb, 3wr   
Zaqar: 1fb, 3wr
Congress: 3wr
Cue: 1fb, 1wr
Solum: 1fb
Searchlight: 1fb, 1wr
MagnetoDB: won't be present

Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA) 
PuppetOpenStack: 2fb, 3wr
Documentation: 2fb, 4wr, cm:morn
Quality Assurance: 4fb, 4wr, cm:full
OpenStackAnsible: 2fb, 1wr, cm:aft
Release management: 1fb, 1wr (shared meetup with QA)
Security: 2fb, 2wr
ChefOpenstack: will camp in the lunch room all week
App catalog: 1fb, 1wr
I18n: cm:morn
OpenStack UX: 2wr
Packaging-deb: 2wr
Refstack: 2wr
RpmPackaging: 1fb, 1wr

We'll start working on laying out those sessions over the available
rooms and time slots. If you have constraints (I already know
searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
Manila with Cinder, Solum with Magnum...) please let me know, we'll do
our best to limit them.

this works well for us. thanks! i would say, if possible, please avoid 
overlaps between Ceilometer and Oslo.


cheers,

--
gord


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

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

2015-09-04 Thread Emilien Macchi



On 09/03/2015 03:00 PM, Emilien Macchi wrote:
> 
> 
> On 09/02/2015 02:56 PM, Emilien Macchi wrote:
>>
>>
>> On 09/02/2015 02:48 PM, Anita Kuno wrote:
>>> On 09/02/2015 02:09 PM, Emilien Macchi wrote:
 TL;DR, I propose to move our developer documentation from wiki to 
 something like 
 http://docs.openstack.org/developer/puppet-openstack
>>>
 (Look at http://docs.openstack.org/developer/tempest/ for 
 example).
>>>
>>> Looking at the tempest example:
>>> http://git.openstack.org/cgit/openstack/tempest/tree/doc/source
>>> we see that the .rst files all live in the tempest repo in doc/source
>>> (with the exception of the README.rst file with is referenced from
>>> within doc/source when required:
>>> http://git.openstack.org/cgit/openstack/tempest/tree/doc/source/overview.rst)
>>>
>>> So question: Where should the source .rst files for puppet developer
>>> documentation live? They will need a home.
>>
>> I guess we would need a new repository for that.
>> It could be puppet-openstack-doc (kiss)
>> or something else, any suggestion is welcome.
> 
> Are we ok for the name?
> proposal:
> puppet-openstack-doc
> puppet-openstack-documentation

Let's go for puppet-openstack-docs.

> 
> Any suggestion is welcome,
> 
>>>
>>> Thanks,
>>> Anita.
>>>
>>>
 For now, most of our documentation is on 
 https://wiki.openstack.org/wiki/Puppet but I think it would be 
 great to use RST format and Gerrit so anyone could submit 
 documentation contribute like we do for code.
>>>
 I propose a basic table of contents now: Puppet modules 
 introductions Coding Guide Reviewing code
>>>
 I'm taking the opportunity of the puppet sprint to run this 
 discussion and maybe start some work of people agrees to move on.
>>>
 Thanks,
>>>
>>>
>>>
 __
>>>
>>>
>>>
>>> OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: 
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Emilien Macchi



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

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Nikola Đipanov

On 09/04/2015 02:31 PM, Sylvain Bauza wrote:
> 
> 
> Le 04/09/2015 14:57, Nikola Đipanov a écrit :
>> On 06/25/2015 04:50 PM, Monty Taylor wrote:
>>> On 06/25/2015 10:22 AM, Andrew Laski wrote:
 I have been growing concerned recently with some attempts to formalize
 scheduler hints, both with API validation and Nova objects defining
 them, and want to air those concerns and see if others agree or can
 help
 me see why I shouldn't worry.

 Starting with the API I think the strict input validation that's being
 done, as seen in
 http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,

 is unnecessary, and potentially problematic.

 One problem is that it doesn't indicate anything useful for a client.
 The schema indicates that there are hints available but can make no
 claim about whether or not they're actually enabled.  So while a
 microversion bump would typically indicate a new feature available
 to an
 end user, in the case of a new scheduler hint a microversion bump
 really
 indicates nothing at all.  It does ensure that if a scheduler hint is
 used that it's spelled properly and the data type passed is correct,
 but
 that's primarily useful because there is no feedback mechanism to
 indicate an invalid or unused scheduler hint.  I think the API
 schema is
 a poor proxy for that deficiency.

 Since the exposure of a hint means nothing as far as its usefulness, I
 don't think we should be codifying them as part of our API schema at
 this time.  At some point I imagine we'll evolve a more useful API for
 passing information to the scheduler as part of a request, and when
 that
 happens I don't think needing to support a myriad of meaningless hints
 in older API versions is going to be desirable.
>>> I totally agree.
>>>
>>> If hints are to become an object, then need to be _real_ resources that
>>> can be listed, and that have structured metadata that has an API.
>>> Flavors are a great example of this. From an end user perspective, I can
>>> ask the cloud what flavors exist, those flavors tell me information that
>>> I can use to make a decision, and I can pass in a reference to those
>>> things. If I pass in an invalid flavor, I get a meaningful error
>>> message.
>>>
 Finally, at this time I'm not sure we should take the stance that only
 in-tree scheduler hints are supported.  While I completely agree with
 the desire to expose things in cross-cloud ways as we've done and are
 looking to do with flavor and image properties I think scheduling is an
 area where we want to allow some flexibility for deployers to write and
 expose scheduling capabilities that meet their specific needs.  Over
 time I hope we will get to a place where some standardization can
 happen, but I don't think locking in the current scheduling hints is
 the
 way forward for that.  I would love to hear from multi-cloud users here
 and get some input on whether that's crazy and they are expecting
 benefits from validation on the current scheduler hints.
>>> As a multi-cloud user, I do not use scheduler hints because there is no
>>> API to discover that they exist, and also no shared sense of semantics.
>>> (I know a flavor that claims 8G of RAM will give me, you guessed it, 8G
>>> of ram) So I consider scheduler hints currently to be COMPLETE vendor
>>> lock-in and/or only things to be used by private cloud folks who are
>>> also admins of their clouds.
>>>
>>> I would not touch them with a 10 foot pole until such a time as there is
>>> an actual API for listing, describing and selecting them.
>>>
>>> I would suggest that if we make one of those, we should quickly
>>> formalize meanings of fields - so that cloud can have specific hints
>>> that seem like cloud content - but that the way I learn about them is
>>> the same, and if there are two hints that do the same thing I can expect
>>> them to look the same in two different clouds.
>>>
>> So this kind of argumentation keeps confusing me TBH. Unless I am not
>> understanding some basic things about how Nova works, the above argument
>> cleanly applies to flavors as well. Flavor '42' is not going to be the
>> same thing across clouds, but that's not where this ends. Once you throw
>> in extra_specs, in particular related to PCI devices and NUMA/CPU
>> pinning features. There is really no discoverability there whatsoever
>> (*).
>>
>> What I am trying to get to is not whether this is right or wrong, but to
>> point out the fact that Flavors are simply not a good abstraction that
>> can have reasonable meaning "across cloud boundaries" (i.e. different
>> Nova deployments), at least the way they are implemented at the moment.
>> We should not pretend that they are, and try to demonize useful code
>> making use

[openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Monty Taylor


mordred@camelot:~$ neutron net-create test-net-mt
Policy doesn't allow create_network to be performed.

Thank you neutron. Excellent job.

Here's what that looks like at the REST layer:

DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 
13:55:47 GMT connection: close content-type: application/json; 
charset=UTF-8 content-length: 130 x-openstack-request-id: 
req-ba05b555-82f4-4aaf-91b2-bae37916498d
RESP BODY: {"NeutronError": {"message": "Policy doesn't allow 
create_network to be performed.", "type": "PolicyNotAuthorized", 
"detail": ""}}


As a user, I am not confused. I do not think that maybe I made a mistake 
with my credentials. The cloud in question simply does not allow user 
creation of networks. I'm fine with that. (as a user, that might make 
this cloud unusable to me - but that's a choice I can now make with 
solid information easily. Turns out, I don't need to create networks for 
my application, so this actually makes it easier for me personally)


In any case- rather than complaining and being a whiny brat about 
something that annoys me - I thought I'd say something nice about 
something that the neutron team has done that especially pleases me. I 
would love it if this became the experience across the board in 
OpenStack for times when a feature of the API is disabled by local 
policy. It's possible it already is and I just haven't directly 
experienced it - so please don't take this as a backhanded condemnation 
of anyone else.


Monty

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

Re: [openstack-dev] Scheduler hints, API and Objects

2015-09-04 Thread Nikola Đipanov

On 06/25/2015 04:50 PM, Monty Taylor wrote:
> On 06/25/2015 10:22 AM, Andrew Laski wrote:
>> I have been growing concerned recently with some attempts to formalize
>> scheduler hints, both with API validation and Nova objects defining
>> them, and want to air those concerns and see if others agree or can help
>> me see why I shouldn't worry.
>>
>> Starting with the API I think the strict input validation that's being
>> done, as seen in
>> http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/scheduler_hints.py?id=53677ebba6c86bd02ae80867028ed5f21b1299da,
>> is unnecessary, and potentially problematic.
>>
>> One problem is that it doesn't indicate anything useful for a client. 
>> The schema indicates that there are hints available but can make no
>> claim about whether or not they're actually enabled.  So while a
>> microversion bump would typically indicate a new feature available to an
>> end user, in the case of a new scheduler hint a microversion bump really
>> indicates nothing at all.  It does ensure that if a scheduler hint is
>> used that it's spelled properly and the data type passed is correct, but
>> that's primarily useful because there is no feedback mechanism to
>> indicate an invalid or unused scheduler hint.  I think the API schema is
>> a poor proxy for that deficiency.
>>
>> Since the exposure of a hint means nothing as far as its usefulness, I
>> don't think we should be codifying them as part of our API schema at
>> this time.  At some point I imagine we'll evolve a more useful API for
>> passing information to the scheduler as part of a request, and when that
>> happens I don't think needing to support a myriad of meaningless hints
>> in older API versions is going to be desirable.
> 
> I totally agree.
> 
> If hints are to become an object, then need to be _real_ resources that
> can be listed, and that have structured metadata that has an API.
> Flavors are a great example of this. From an end user perspective, I can
> ask the cloud what flavors exist, those flavors tell me information that
> I can use to make a decision, and I can pass in a reference to those
> things. If I pass in an invalid flavor, I get a meaningful error message.
> 
>> Finally, at this time I'm not sure we should take the stance that only
>> in-tree scheduler hints are supported.  While I completely agree with
>> the desire to expose things in cross-cloud ways as we've done and are
>> looking to do with flavor and image properties I think scheduling is an
>> area where we want to allow some flexibility for deployers to write and
>> expose scheduling capabilities that meet their specific needs.  Over
>> time I hope we will get to a place where some standardization can
>> happen, but I don't think locking in the current scheduling hints is the
>> way forward for that.  I would love to hear from multi-cloud users here
>> and get some input on whether that's crazy and they are expecting
>> benefits from validation on the current scheduler hints.
> 
> As a multi-cloud user, I do not use scheduler hints because there is no
> API to discover that they exist, and also no shared sense of semantics.
> (I know a flavor that claims 8G of RAM will give me, you guessed it, 8G
> of ram) So I consider scheduler hints currently to be COMPLETE vendor
> lock-in and/or only things to be used by private cloud folks who are
> also admins of their clouds.
> 
> I would not touch them with a 10 foot pole until such a time as there is
> an actual API for listing, describing and selecting them.
> 
> I would suggest that if we make one of those, we should quickly
> formalize meanings of fields - so that cloud can have specific hints
> that seem like cloud content - but that the way I learn about them is
> the same, and if there are two hints that do the same thing I can expect
> them to look the same in two different clouds.
> 

So this kind of argumentation keeps confusing me TBH. Unless I am not
understanding some basic things about how Nova works, the above argument
cleanly applies to flavors as well. Flavor '42' is not going to be the
same thing across clouds, but that's not where this ends. Once you throw
in extra_specs, in particular related to PCI devices and NUMA/CPU
pinning features. There is really no discoverability there whatsoever (*).

What I am trying to get to is not whether this is right or wrong, but to
point out the fact that Flavors are simply not a good abstraction that
can have reasonable meaning "across cloud boundaries" (i.e. different
Nova deployments), at least the way they are implemented at the moment.
We should not pretend that they are, and try to demonize useful code
making use of them, but come up with a better abstraction that can have
reasonable meaning across different deployments.

I think this is what Andrew was hinting at when he said that scheduling
is an area that cannot reasonably be standardized in this way.

I recently spoke to John briefly about this and got

Re: [openstack-dev] [Openstack] [Horizon] [Sahara] FFE request for Sahara unified job interface map UI

2015-09-04 Thread michael mccune


On 09/04/2015 10:40 AM, Ethan Gafford wrote:

Hello all,

I request a FFE for the change at: https://review.openstack.org/#/c/209683/

This change enables a significant improvement to UX in Sahara's elastic data 
processing flow which is already in the server and client layers of Sahara. 
Because it specifically aims at improving ease of use and comprehensibility, 
Horizon integration is critical to the success of the feature. The change 
itself is reasonably modular and thus low-risk; it will have no impact outside 
Sahara's job template creation and launch flow, and (failing unforseen issues) 
no impact to users of the existing flow who choose not to use this feature.

Thank you,
Ethan


+1 from me, this feature has received much attention and seems pretty 
low-risk of introducing critical errors.


mike


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

[openstack-dev] [Manila] Gate breakage and technical FFEs

2015-09-04 Thread Ben Swartzlander

The Manila gate is finally unblocked, thanks to the efforts of Valeriy! 
I see patches going in now so all of the features which were granted 
technical FFEs should start merging IMMEDIATELY.


By my calculations, we lost approximately 30 hours of time to merge 
stuff before the scheduled feature freeze, so I'm going to grant about 
30 hours from now, plus the weekend to get everything in.


The new deadline is Tuesday 8/8, at 1200 UTC. Everything must be merged 
by that time, or it will be rescheduled to Mitaka, no exceptions, no 
excuses (if the gate breaks again, then fix it).


Those of you who weren't going to make the original deadline and were 
planning on asking for FFEs should consider yourself lucky. The gate 
getting stuck has bought you nearly 5 extra days to get your patches in 
order. For this reason I don't plan to grant any additional FFEs.


The following patches are on my list to get -2 if they're not merged by 
the deadline.


Migration

179790 - ganso - Add Share Migration feature
179791 - ganso - Share Migration support in generic driver
220278 - ganso - Add Share Migration tempest functional tests

CGs

215343 - cknight - Add DB changes for consistency-groups
215344 - cknight - Scheduler changes for consistency groups
215345 - cknight - Add Consistency Groups API
219891 - cknight - Consistency Group Support for the Generic Driver
215346 - cknight - Add functional tests for Manila consistency groups

NetApp CGs

215347 - cknight - Consistency groups in NetApp cDOT drivers

Mount Automation

201669 - vponomaryov - Add share hooks

Tempest Plugin

201955 - mkoderer - Use Tempest plugin interface

Windows SMB Driver

200154 - plucian - Add Windows SMB share driver

GlusterFS Driver

214462 - chenk - glusterfs*: factor out common parts
214921 - chenk - glusterfs/common: refactor GlusterManager
215021 - chenk - glusterfs-native: cut back on redundancy
215172 - chenk - glusterfs/layout: add layout base classes
215173 - chenk - glusterfs: volume mapped share layout
215293 - chenk - glusterfs: directory mapped share layout


-Ben Swartzlander


__
OpenStack Development Mailing 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] [ptl][release] flushing unreleased client library changes

2015-09-04 Thread Doug Hellmann


PTLs,

We have quite a few unreleased client changes pending, and it would
be good to go ahead and publish them so they can be tested as part
of the release candidate process. I have the full list of changes for
each project below, so please find yours and review them and then
propose a release request to the openstack/releases repository.

On a separate note, for next cycle we need to do a better job of
releasing these much much earlier (a few of these changes are at
least a month old). Remember that changes to libraries do not go
into the gate for consuming projects until that library is released.
If you have any suggestions for how to do improve our tracking for
needed releases, let me know.

Doug


[ Unreleased changes in openstack/python-barbicanclient ]

Changes in python-barbicanclient 3.3.0..97cc46a
---
4572293 2015-08-27 19:38:39 -0500 Add epilog to parser
17ed50a 2015-08-25 14:58:25 + Add Unit Tests for Store and Update Payload 
when Payload is zero
34256de 2015-08-25 09:56:24 -0500 Allow Barbican Client Secret Update 
Functionality

[ Unreleased changes in openstack/python-ceilometerclient ]

Changes in python-ceilometerclient 1.4.0..2006902
-
2006902 2015-08-26 14:09:00 + Updated from global requirements
2429dae 2015-08-25 01:32:56 + Don't try to get aodh endpoint if auth_url 
didn't provided
6498d55 2015-08-13 20:21:24 + Updated from global requirements

[ Unreleased changes in openstack/python-cinderclient ]

Changes in python-cinderclient 1.3.1..1c82825
-
1c82825 2015-09-02 17:18:28 -0700 Update path to subunit2html in post_test_hook
471aea8 2015-09-02 00:53:40 + Adds command to fetch specified backend 
capabilities
2d979dc 2015-09-01 22:35:28 +0800 Volume status management for volume migration
50758ba 2015-08-27 09:39:58 -0500 Fixed test_password_prompted
dc6e823 2015-08-26 23:04:16 -0700 Fix help message for reset-state commands
f805f5a 2015-08-25 15:15:20 +0300 Add functional tests for python-cinderclient
8cc3ee2 2015-08-19 18:05:34 +0300 Add support '--all-tenants' for cinder 
backup-list
2c3169e 2015-08-11 10:18:01 -0400 CLI: Non-disruptive backup
5e26906 2015-08-11 13:14:04 +0300 Add tests for python-cinderclient
780a129 2015-08-09 15:57:00 +0900 Replace assertEqual(None, *) with 
assertIsNone in tests
a9405b1 2015-08-08 05:36:45 -0400 CLI: Clone CG
03542ee 2015-08-04 14:21:52 -0700 Fix ClientException init when there is no 
message on py34
2ec9a22 2015-08-03 11:14:44 +0800 Fixes table when there are multiline in 
result data
04caf88 2015-07-30 18:24:57 +0300 Set default OS_VOLUME_API_VERSION to '2'
bae0bb3 2015-07-27 01:28:00 + Add commands for modifying image metadata
629e548 2015-07-24 03:34:55 + Updated from global requirements
b51e43e 2015-07-21 01:04:02 + Remove H302
b426b71 2015-07-20 13:21:02 +0800 Show backup and volume info in backup_restore
dc1186d 2015-07-16 19:45:08 -0700 Add response message when volume delete
075381d 2015-07-15 09:20:48 +0800 Add more details for replication
953f766 2015-07-14 18:51:58 +0800 New mock release(1.1.0) broke unit/function 
tests
8afc06c 2015-07-08 12:11:07 -0500 Remove unnecessary check for tenant 
information
c23586b 2015-07-08 11:42:59 +0800 Remove redundant statement and refactor
891ef3e 2015-06-25 13:27:42 + Use shared shell arguments provided by Session

[ Unreleased changes in openstack/python-congressclient ]

Changes in python-congressclient 1.1.0..0874721
---
0f699f8 2015-09-02 14:47:32 +0800 Add actions listing command
d7fa523 2015-08-26 14:09:29 + Updated from global requirements
36f2b47 2015-08-11 01:38:32 + Updated from global requirements
ee07cb3 2015-07-27 15:47:12 +0800 Fix constant name
f9858a8 2015-07-27 15:19:04 +0800 Support version list API in client
9693132 2015-06-20 22:38:10 +0900 Adding a test of datasource table show CLI
a102014 2015-05-21 04:52:12 -0300 Favor the use of importlib over Python 
internal __import__ statement
726d560 2015-05-07 23:37:04 + Updated from global requirements
b8a176b 2015-04-24 16:31:49 +0800 Replace stackforge with openstack in 
README.rst
8c31d3f 2015-03-31 15:33:53 -0700 Add api bindings for datasource 
request-request trigger

[ Unreleased changes in openstack/python-cueclient ]

Changes in python-cueclient 0.0.1..d9ac712
--
d9ac712 2015-08-26 14:09:42 + Updated from global requirements
47b81c3 2015-08-11 13:38:14 -0700 Update python-binding section for keystone v3 
support
d30c3b1 2015-08-11 01:38:34 + Updated from global requirements
14e5f05 2015-08-06 10:15:13 -0700 Adding size field cue cluster list command
0c7559b 2015-07-16 10:29:07 -0700 Rename end_points to endpoints in API
0e36051 2015-07-13 12:55:29 -0700 updating docs from stackforge->openstack
cda 2015-07-13 12:29:04 -0700 fixing oslo_serialization

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Monty Taylor


On 09/04/2015 10:55 AM, Morgan Fainberg wrote:




On Sep 4, 2015, at 07:04, Monty Taylor 
wrote:

mordred@camelot:~$ neutron net-create test-net-mt Policy doesn't
allow create_network to be performed.

Thank you neutron. Excellent job.

Here's what that looks like at the REST layer:

DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015
13:55:47 GMT connection: close content-type: application/json;
charset=UTF-8 content-length: 130 x-openstack-request-id:
req-ba05b555-82f4-4aaf-91b2-bae37916498d RESP BODY:
{"NeutronError": {"message": "Policy doesn't allow create_network
to be performed.", "type": "PolicyNotAuthorized", "detail": ""}}

As a user, I am not confused. I do not think that maybe I made a
mistake with my credentials. The cloud in question simply does not
allow user creation of networks. I'm fine with that. (as a user,
that might make this cloud unusable to me - but that's a choice I
can now make with solid information easily. Turns out, I don't need
to create networks for my application, so this actually makes it
easier for me personally)



The 403 (yay good HTTP error choice) and message is great here.

We should make this the default (I think we can do something like
this baking it into the enforcer in oslo.policy so that it is
consistent across openstack).


Great idea!


Obviously the translation of errors
would be more difficult if the enforcer is generating messages.


The type: "PolicyNotAuthorized" is a good general key. Also - even 
though the command I sent was:


neutron net-create

On the command line, the entry in the policy_file is "create_network" - 
so honestly I think that policy.json and oslo.policy should have (or be 
able to have) all of the info needed to create almost the exact same 
message. Perhaps "NeutronError" would just need to be 
"OpenStackPolicyError"?


Oh. Wait. You meant translation like i18n translation. In that case, I 
think it's easy:


message=_("Policy doesn't allow %(policy_key)s to be performed", 
policy_key="create_network")


/me waves hands


--Morgan



__



OpenStack Development Mailing List (not for usage questions)

Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




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

[openstack-dev] [DevStack][Keystone][Ironic][Swit] FYI: Defaulting to Keystone v3 API

2015-09-04 Thread Lucas Alvares Gomes

Hi,

This is email is just a FYI: Recently the patch [1] got merged in
DevStack and broke the Ironic gate [2], I haven't had time to dig into
the problem yet so I reverted the patch [3] to unblock our gate.

The work to convert to v3 seems to be close enough but not yet there
so I just want to bring a broader attention to it with this email.

Also, the Ironic job that is currently running in the DevStack gate is
not testing Ironic with the Swift module, there's a patch [4] changing
that so I hope we will be able to identify the problem before we break
things next time .

[1] https://review.openstack.org/#/c/186684/
[2] 
http://logs.openstack.org/68/217068/14/check/gate-tempest-dsvm-ironic-agent_ssh/18d8590/logs/devstacklog.txt.gz#_2015-09-04_09_04_55_994
[3] https://review.openstack.org/220532
[4] https://review.openstack.org/#/c/220516/

Cheers,
Lucas

__
OpenStack Development Mailing 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] [Congress] bugs for liberty release

2015-09-04 Thread Tim Hinrichs

Hi all,

I've found a few bugs that we could/should fix by the liberty release.  I
tagged them with "liberty-rc".  If we could all pitch in, that'd be great.
Let me know which ones you'd like to work on so I can assign them to you in
launchpad.

https://bugs.launchpad.net/congress/+bugs/?field.tag=liberty-rc

Thanks,
Tim
__
OpenStack Development Mailing List (not for 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] Feature Freeze Exception proposal

2015-09-04 Thread Nikhil Komawar

Hi Malini et.al.,

We had a sync up earlier today on this topic and a few items were
discussed including new comments on the spec and existing code proposal.
You can find the logs of the conversation here [1].

There are 3 main outcomes of the discussion:
1. We hope to get a commitment on the feature (spec and the code) that
the comments would be addressed and code would be ready by Sept 18th;
after which the RC1 is planned to be cut [2]. Our hope is that the spec
is merged way before and implementation to the very least is ready if
not merged. The comments on the spec and merge proposal are currently
implementation details specific so we were positive on this front.
2. The decision to grant FFE will be on Tuesday Sept 8th after the spec
has newer patch sets with major concerns addressed.
3. We cannot commit to granting a backport to this feature so, we ask
the implementors to consider using the plug-ability and modularity of
the taskflow library. You may consult developers who have already worked
on adopting this library in Glance (Flavio, Sabari and Harsh). Deployers
can then use those scripts and put them back in their Liberty
deployments even if it's not in the standard tarball.

Please let me know if you have more questions.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-glance/%23openstack-glance.2015-09-04.log.html#t2015-09-04T14:29:47
[2] https://wiki.openstack.org/wiki/Liberty_Release_Schedule

On 9/3/15 1:13 PM, Bhandaru, Malini K wrote:
> Thank you Nikhil and Brian!
>
> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com] 
> Sent: Thursday, September 03, 2015 9:42 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception proposal
>
> We agreed to hold off on granting it a FFE until tomorrow.
>
> There's a sync up meeting on this topic tomorrow, Friday Sept 4th at
> 14:30 UTC ( #openstack-glance ). Please be there to voice your opinion and 
> cast your vote.
>
> On 9/3/15 9:15 AM, Brian Rosmaita wrote:
>> I added an agenda item for this for today's Glance meeting:
>>https://etherpad.openstack.org/p/glance-team-meeting-agenda
>>
>> I'd prefer to hold my vote until after the meeting.
>>
>> cheers,
>> brian
>>
>>
>> On 9/3/15, 6:14 AM, "Kuvaja, Erno"  wrote:
>>
>>> Malini, all,
>>>
>>> My current opinion is -1 for FFE based on the concerns in the spec 
>>> and implementation.
>>>
>>> I'm more than happy to realign my stand after we have updated spec 
>>> and a) it's agreed to be the approach as of now and b) we can 
>>> evaluate how much work the implementation needs to meet with the revisited 
>>> spec.
>>>
>>> If we end up to the unfortunate situation that this functionality 
>>> does not merge in time for Liberty, I'm confident that this is one of 
>>> the first things in Mitaka. I really don't think there is too much to 
>>> go, we just might run out of time.
>>>
>>> Thanks for your patience and endless effort to get this done.
>>>
>>> Best,
>>> Erno
>>>
 -Original Message-
 From: Bhandaru, Malini K [mailto:malini.k.bhand...@intel.com]
 Sent: Thursday, September 03, 2015 10:10 AM
 To: Flavio Percoco; OpenStack Development Mailing List (not for 
 usage
 questions)
 Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception 
 proposal

 Flavio, first thing in the morning Kent will upload a new BP that 
 addresses the comments. We would very much appreciate a +1 on the 
 FFE.

 Regards
 Malini

 -Original Message-
 From: Flavio Percoco [mailto:fla...@redhat.com]
 Sent: Thursday, September 03, 2015 1:52 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception 
 proposal

 On 02/09/15 22:11 -0400, Nikhil Komawar wrote:
> Hi,
>
> I wanted to propose 'Single disk image OVA import' [1] feature 
> proposal for exception. This looks like a decently safe proposal 
> that should be able to adjust in the extended time period of 
> Liberty. It has been discussed at the Vancouver summit during a 
> work session and the proposal has been trimmed down as per the 
> suggestions then; has been overall accepted by those present during 
> the discussions (barring a few changes needed on the spec itself). 
> It being a addition to already existing import task, doesn't 
> involve API change or change to any of the core Image functionality as of 
> now.
>
> Please give your vote: +1 or -1 .
>
> [1] https://review.openstack.org/#/c/194868/
 I'd like to see support for OVF being, finally, implemented in Glance.
 Unfortunately, I think there are too many open questions in the spec 
 right now to make this FFE worthy.

 Could those questions be answered to before the EOW?

 With those questions answered, we'll be able to provide

Re: [openstack-dev] [DevStack][Keystone][Ironic][Swit][Barbican] FYI: Defaulting to Keystone v3 API

2015-09-04 Thread Steve Martinelli


This change also affected Barbican too, but they quickly tossed up a patch
to resolve the gate failures [1]. As much as I would like DevStack and
OpenStackClient to default to Keystone's v3 API, we should - considering
how close we are in the schedule, revert the initial patch (which I see
sdague already did). We need to determine which projects are hosting their
own devstack plugin scripts and update those first before bringing back the
original patch.

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

Thanks,

Steve Martinelli
OpenStack Keystone Core



From:   Lucas Alvares Gomes 
To: OpenStack Development Mailing List

Date:   2015/09/04 10:07 AM
Subject:[openstack-dev] [DevStack][Keystone][Ironic][Swit] FYI:
Defaulting  to Keystone v3 API



Hi,

This is email is just a FYI: Recently the patch [1] got merged in
DevStack and broke the Ironic gate [2], I haven't had time to dig into
the problem yet so I reverted the patch [3] to unblock our gate.

The work to convert to v3 seems to be close enough but not yet there
so I just want to bring a broader attention to it with this email.

Also, the Ironic job that is currently running in the DevStack gate is
not testing Ironic with the Swift module, there's a patch [4] changing
that so I hope we will be able to identify the problem before we break
things next time .

[1] https://review.openstack.org/#/c/186684/
[2]
http://logs.openstack.org/68/217068/14/check/gate-tempest-dsvm-ironic-agent_ssh/18d8590/logs/devstacklog.txt.gz#_2015-09-04_09_04_55_994

[3] https://review.openstack.org/220532
[4] https://review.openstack.org/#/c/220516/

Cheers,
Lucas

__
OpenStack Development Mailing 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] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Morgan Fainberg



> On Sep 4, 2015, at 07:04, Monty Taylor  wrote:
> 
> mordred@camelot:~$ neutron net-create test-net-mt
> Policy doesn't allow create_network to be performed.
> 
> Thank you neutron. Excellent job.
> 
> Here's what that looks like at the REST layer:
> 
> DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 13:55:47 GMT 
> connection: close content-type: application/json; charset=UTF-8 
> content-length: 130 x-openstack-request-id: 
> req-ba05b555-82f4-4aaf-91b2-bae37916498d
> RESP BODY: {"NeutronError": {"message": "Policy doesn't allow create_network 
> to be performed.", "type": "PolicyNotAuthorized", "detail": ""}}
> 
> As a user, I am not confused. I do not think that maybe I made a mistake with 
> my credentials. The cloud in question simply does not allow user creation of 
> networks. I'm fine with that. (as a user, that might make this cloud unusable 
> to me - but that's a choice I can now make with solid information easily. 
> Turns out, I don't need to create networks for my application, so this 
> actually makes it easier for me personally)
> 

The 403 (yay good HTTP error choice) and message is great here.

We should make this the default (I think we can do something like this baking 
it into the enforcer in oslo.policy so that it is consistent across openstack). 
Obviously the translation of errors would be more difficult if the enforcer is 
generating messages. 

--Morgan



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

Re: [openstack-dev] [sahara] FFE request for heat wait condition support

2015-09-04 Thread michael mccune


makes sense to me, +1

mike

On 09/04/2015 06:37 AM, Vitaly Gridnev wrote:

+1 for FFE, because of
  1. Low risk of issues, fully covered with current scenario tests;
  2. Implementation already on review

On Fri, Sep 4, 2015 at 12:54 PM, Sergey Reshetnyak
> wrote:

Hi,

I would like to request FFE for wait condition support for Heat engine.
Wait condition reports signal about booting instance.

Blueprint:
https://blueprints.launchpad.net/sahara/+spec/sahara-heat-wait-conditions

Spec:

https://github.com/openstack/sahara-specs/blob/master/specs/liberty/sahara-heat-wait-conditions.rst

Patch:
https://review.openstack.org/#/c/169338/

Thanks,
Sergey Reshetnyak

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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Best Regards,
Vitaly Gridnev
Mirantis, Inc


__
OpenStack Development Mailing 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] FFE Request for completion of data driven assignment testing in Keystone

2015-09-04 Thread Morgan Fainberg

Henry,

I've applied the -2 (for Feature Freeze) to a bunch of patchsets, I think I
excluded your testing ones, but if the testing ones got -2'd please let me
know so I can remove the -2.

--Morgan

On Fri, Sep 4, 2015 at 2:07 AM, Henry Nash 
wrote:

> Great, thanks.
>
> Henry
> > On 4 Sep 2015, at 09:17, Thierry Carrez  wrote:
> >
> > Morgan Fainberg wrote:
> >>
> >>>I would like to request an FFE for the remaining two patches that
> >>>are already in review
> >>>(https://review.openstack.org/#/c/153897/ and
> https://review.openstack.org/#/c/154485/).
> >>>These contain only test code and no functional changes, and
> >>>increase our test coverage - as well as enable other items to be
> >>>re-use the list_role_assignment backend method.
> >>>
> >>> Do we need a FFE for changes to tests?
> >>>
> >>
> >> I would say "no".
> >
> > Right. Extra tests (or extra docs for that matter) don't count as a
> > "feature" for the freeze. In particular it doesn't change the behavior
> > of the software or invalidate testing that may have been conducted.
> >
> > --
> > 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ptl][release] flushing unreleased client library changes

2015-09-04 Thread Ben Swartzlander


On 09/04/2015 12:39 PM, Doug Hellmann wrote:

PTLs,

We have quite a few unreleased client changes pending, and it would
be good to go ahead and publish them so they can be tested as part
of the release candidate process. I have the full list of changes for
each project below, so please find yours and review them and then
propose a release request to the openstack/releases repository.


Manila had multiple gate-breaking bugs this week and I've extended our 
feature freeze to next Tuesday to compensate. As a result our L-3 
milestone release is not really representative of Liberty and we'd 
rather not do a client release until we reach RC1.


-Ben Swartzlander



On a separate note, for next cycle we need to do a better job of
releasing these much much earlier (a few of these changes are at
least a month old). Remember that changes to libraries do not go
into the gate for consuming projects until that library is released.
If you have any suggestions for how to do improve our tracking for
needed releases, let me know.

Doug


[ Unreleased changes in openstack/python-barbicanclient ]

Changes in python-barbicanclient 3.3.0..97cc46a
---
4572293 2015-08-27 19:38:39 -0500 Add epilog to parser
17ed50a 2015-08-25 14:58:25 + Add Unit Tests for Store and Update Payload 
when Payload is zero
34256de 2015-08-25 09:56:24 -0500 Allow Barbican Client Secret Update 
Functionality

[ Unreleased changes in openstack/python-ceilometerclient ]

Changes in python-ceilometerclient 1.4.0..2006902
-
2006902 2015-08-26 14:09:00 + Updated from global requirements
2429dae 2015-08-25 01:32:56 + Don't try to get aodh endpoint if auth_url 
didn't provided
6498d55 2015-08-13 20:21:24 + Updated from global requirements

[ Unreleased changes in openstack/python-cinderclient ]

Changes in python-cinderclient 1.3.1..1c82825
-
1c82825 2015-09-02 17:18:28 -0700 Update path to subunit2html in post_test_hook
471aea8 2015-09-02 00:53:40 + Adds command to fetch specified backend 
capabilities
2d979dc 2015-09-01 22:35:28 +0800 Volume status management for volume migration
50758ba 2015-08-27 09:39:58 -0500 Fixed test_password_prompted
dc6e823 2015-08-26 23:04:16 -0700 Fix help message for reset-state commands
f805f5a 2015-08-25 15:15:20 +0300 Add functional tests for python-cinderclient
8cc3ee2 2015-08-19 18:05:34 +0300 Add support '--all-tenants' for cinder 
backup-list
2c3169e 2015-08-11 10:18:01 -0400 CLI: Non-disruptive backup
5e26906 2015-08-11 13:14:04 +0300 Add tests for python-cinderclient
780a129 2015-08-09 15:57:00 +0900 Replace assertEqual(None, *) with 
assertIsNone in tests
a9405b1 2015-08-08 05:36:45 -0400 CLI: Clone CG
03542ee 2015-08-04 14:21:52 -0700 Fix ClientException init when there is no 
message on py34
2ec9a22 2015-08-03 11:14:44 +0800 Fixes table when there are multiline in 
result data
04caf88 2015-07-30 18:24:57 +0300 Set default OS_VOLUME_API_VERSION to '2'
bae0bb3 2015-07-27 01:28:00 + Add commands for modifying image metadata
629e548 2015-07-24 03:34:55 + Updated from global requirements
b51e43e 2015-07-21 01:04:02 + Remove H302
b426b71 2015-07-20 13:21:02 +0800 Show backup and volume info in backup_restore
dc1186d 2015-07-16 19:45:08 -0700 Add response message when volume delete
075381d 2015-07-15 09:20:48 +0800 Add more details for replication
953f766 2015-07-14 18:51:58 +0800 New mock release(1.1.0) broke unit/function 
tests
8afc06c 2015-07-08 12:11:07 -0500 Remove unnecessary check for tenant 
information
c23586b 2015-07-08 11:42:59 +0800 Remove redundant statement and refactor
891ef3e 2015-06-25 13:27:42 + Use shared shell arguments provided by Session

[ Unreleased changes in openstack/python-congressclient ]

Changes in python-congressclient 1.1.0..0874721
---
0f699f8 2015-09-02 14:47:32 +0800 Add actions listing command
d7fa523 2015-08-26 14:09:29 + Updated from global requirements
36f2b47 2015-08-11 01:38:32 + Updated from global requirements
ee07cb3 2015-07-27 15:47:12 +0800 Fix constant name
f9858a8 2015-07-27 15:19:04 +0800 Support version list API in client
9693132 2015-06-20 22:38:10 +0900 Adding a test of datasource table show CLI
a102014 2015-05-21 04:52:12 -0300 Favor the use of importlib over Python 
internal __import__ statement
726d560 2015-05-07 23:37:04 + Updated from global requirements
b8a176b 2015-04-24 16:31:49 +0800 Replace stackforge with openstack in 
README.rst
8c31d3f 2015-03-31 15:33:53 -0700 Add api bindings for datasource 
request-request trigger

[ Unreleased changes in openstack/python-cueclient ]

Changes in python-cueclient 0.0.1..d9ac712
--
d9ac712 2015-08-26 14:09:42 + Updated from global requirements
47b81c3 2015-08-11 13:38:14 -0700 Update python-binding section for keystone v3 
support
d30c3b1 2015-08-11

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Mathieu Gagné

On 2015-09-04 12:50 PM, Monty Taylor wrote:
> On 09/04/2015 10:55 AM, Morgan Fainberg wrote:
>>
>> Obviously the translation of errors
>> would be more difficult if the enforcer is generating messages.
> 
> The type: "PolicyNotAuthorized" is a good general key. Also - even
> though the command I sent was:
> 
> neutron net-create
> 
> On the command line, the entry in the policy_file is "create_network" -
> so honestly I think that policy.json and oslo.policy should have (or be
> able to have) all of the info needed to create almost the exact same
> message. Perhaps "NeutronError" would just need to be
> "OpenStackPolicyError"?
> 
> Oh. Wait. You meant translation like i18n translation. In that case, I
> think it's easy:
> 
> message=_("Policy doesn't allow %(policy_key)s to be performed",
> policy_key="create_network")
> 
> /me waves hands
> 

I don't feel like this error message would be user-friendly:

"Policy doesn't allow os_compute_api:os-instance-actions to be performed"

Policy name aren't human readable and match nothing on the client side.

-- 
Mathieu

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

Re: [openstack-dev] [Neutron] cloud-init IPv6 support

2015-09-04 Thread Henry Gessau

Some thought has been given to this. See
https://bugs.launchpad.net/neutron/+bug/1460177

I like the third option, a well-known name using DNS.

On Thu, Sep 03, 2015, Kevin Benton  wrote:
> I think that's different than what is being asked here. That patch appears to
> just add IPv6 interface information if it's available in the metadata. This
> thread is about getting cloud-init to connect to an IPv6 address instead of
> 169.254.169.254 for pure IPv6 environments.
>
> On Thu, Sep 3, 2015 at 11:41 AM, Joshua Harlow  > wrote:
>
> I'm pretty sure this got implemented :)
>
> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1042
> 
> 
> and https://bugs.launchpad.net/cloud-init/+bug/1391695
>
> That's the RHEL support, since cloud-init translates a ubuntu style
> networking style the ubuntu/debian style format should also work.
>
>
> Steve Gordon wrote:
>
> - Original Message -
>
> From: "Kevin Benton">
>
> When we discussed this before on the neutron channel, I thought 
> it was
> because cloud-init doesn't support IPv6. We had wasted quite a bit
> of time
> talking about adding support to our metadata service because I was
> under
> the impression that cloud-init already did support IPv6.
>
> IIRC, the argument against adding IPv6 support to cloud-init was
> that it
> might be incompatible with how AWS chooses to implement IPv6
> metadata, so
> AWS would require a fork or other incompatible alternative to
> cloud-init in
> all of their images.
>
> Is that right?
>
>
> That's certainly my understanding of the status quo, I was enquiring
> primarily to check it was still accurate.
>
> -Steve
>
> On Thu, Sep 3, 2015 at 7:30 AM, Sean M. Collins >  wrote:
>
> It's not a case of cloud-init supporting IPv6 - The Amazon EC2
> metadata
> API defines transport level details about the API - and
> currently only
> defines a well known IPv4 link local address to connect to. No
> well known
> link local IPv6 address has been defined.
>
> I usually recommend config-drive for IPv6 enabled clouds due
> to this.
> --
> Sent from my Android device with K-9 Mail. Please excuse my
> brevity.
> 
> __
> OpenStack Development Mailing 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
>
>
>
>
> -- 
> Kevin Benton
>
>
> __
> OpenStack Development Mailing 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] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread Jim Rollenhagen

On Fri, Sep 04, 2015 at 01:52:41PM +0200, Dmitry Tantsur wrote:
> On 09/04/2015 12:14 PM, Thierry Carrez wrote:
> >Hi PTLs,
> >
> >Here is the proposed slot allocation for every "big tent" project team
> >at the Mitaka Design Summit in Tokyo. This is based on the requests the
> >liberty PTLs have made, space availability and project activity &
> >collaboration needs.
> >
> >We have a lot less space (and time slots) in Tokyo compared to
> >Vancouver, so we were unable to give every team what they wanted. In
> >particular, there were far more workroom requests than we have
> >available, so we had to cut down on those quite heavily. Please note
> >that we'll have a large lunch room with roundtables inside the Design
> >Summit space that can easily be abused (outside of lunch) as space for
> >extra discussions.
> >
> >Here is the allocation:
> >
> >| fb: fishbowl 40-min slots
> >| wr: workroom 40-min slots
> >| cm: Friday contributors meetup
> >| | day: full day, morn: only morning, aft: only afternoon
> >
> >Neutron: 12fb, cm:day
> >Nova: 14fb, cm:day
> >Cinder: 5fb, 4wr, cm:day 
> >Horizon: 2fb, 7wr, cm:day
> >Heat: 4fb, 8wr, cm:morn
> >Keystone: 7fb, 3wr, cm:day
> >Ironic: 4fb, 4wr, cm:morn
> >Oslo: 3fb, 5wr
> >Rally: 1fb, 2wr
> >Kolla: 3fb, 5wr, cm:aft
> >Ceilometer: 2fb, 7wr, cm:morn
> >TripleO: 2fb, 1wr, cm:full
> >Sahara: 2fb, 5wr, cm:aft
> >Murano: 2wr, cm:full
> >Glance: 3fb, 5wr, cm:full
> >Manila: 2fb, 4wr, cm:morn
> >Magnum: 5fb, 5wr, cm:full
> >Swift: 2fb, 12wr, cm:full
> >Trove: 2fb, 4wr, cm:aft
> >Barbican: 2fb, 6wr, cm:aft
> >Designate: 1fb, 4wr, cm:aft
> >OpenStackClient: 1fb, 1wr, cm:morn
> >Mistral: 1fb, 3wr
> >Zaqar: 1fb, 3wr
> >Congress: 3wr
> >Cue: 1fb, 1wr
> >Solum: 1fb
> >Searchlight: 1fb, 1wr
> >MagnetoDB: won't be present
> >
> >Infrastructure: 3fb, 4wr (shared meetup with Ironic and QA)  
> >PuppetOpenStack: 2fb, 3wr
> >Documentation: 2fb, 4wr, cm:morn
> >Quality Assurance: 4fb, 4wr, cm:full
> >OpenStackAnsible: 2fb, 1wr, cm:aft
> >Release management: 1fb, 1wr (shared meetup with QA)
> >Security: 2fb, 2wr
> >ChefOpenstack: will camp in the lunch room all week
> >App catalog: 1fb, 1wr
> >I18n: cm:morn
> >OpenStack UX: 2wr
> >Packaging-deb: 2wr
> >Refstack: 2wr
> >RpmPackaging: 1fb, 1wr
> >
> >We'll start working on laying out those sessions over the available
> >rooms and time slots. If you have constraints (I already know
> >searchlight wants to avoid conflicts with Horizon, Kolla with Magnum,
> >Manila with Cinder, Solum with Magnum...) please let me know, we'll do
> >our best to limit them.
> >
> 
> Would be cool to avoid conflicts between Ironic and TripleO.

I'd also like to save room for one Ironic/Nova session, and one
Ironic/Neutron session.

// jim

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

Re: [openstack-dev] custom lbaas driver

2015-09-04 Thread Srikumar Chari

Hello,

I am trying to write an custom lbaas v2.0 driver. Was wondering if there's
a document on how to go about that. I see a number of implementations as
part of the source code but they all seem to be different. For instance
HAProxy is completely different when compared to the other vendors. I am
assuming that HAProxy is the "standard" as it is the default load balancer
for OpenStack. Is there a design doc or some kinda write up?

This thread was the closest I could get to a write-up:
https://openstack.nimeyo.com/21628/openstack-dev-neutron-lbaas-need-help-with-lbaas-drivers
.

I guess I could reverse engineering the HAProxy namespace driver but I am
probably going to miss some of the design elements. Any help/pointers/links
would be great.

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

Re: [openstack-dev] [ptl][release] flushing unreleased client library changes

2015-09-04 Thread Doug Hellmann

Excerpts from Ben Swartzlander's message of 2015-09-04 14:51:10 -0400:
> On 09/04/2015 12:39 PM, Doug Hellmann wrote:
> > PTLs,
> >
> > We have quite a few unreleased client changes pending, and it would
> > be good to go ahead and publish them so they can be tested as part
> > of the release candidate process. I have the full list of changes for
> > each project below, so please find yours and review them and then
> > propose a release request to the openstack/releases repository.
> 
> Manila had multiple gate-breaking bugs this week and I've extended our 
> feature freeze to next Tuesday to compensate. As a result our L-3 
> milestone release is not really representative of Liberty and we'd 
> rather not do a client release until we reach RC1.

Keep in mind that the unreleased changes are not being used to test
anything at all in the gate, so there's an integration "penalty" for
delaying releases. You can have as many releases as you want, and we can
create the stable branch from the last useful release any time after it
is created. So, I still recommend releasing early and often unless you
anticipate making API or CLI breaking changes between now and RC1.

Doug

> 
> -Ben Swartzlander
> 
> > On a separate note, for next cycle we need to do a better job of
> > releasing these much much earlier (a few of these changes are at
> > least a month old). Remember that changes to libraries do not go
> > into the gate for consuming projects until that library is released.
> > If you have any suggestions for how to do improve our tracking for
> > needed releases, let me know.
> >
> > Doug
> >
> >
> > [ Unreleased changes in openstack/python-barbicanclient ]
> >
> > Changes in python-barbicanclient 3.3.0..97cc46a
> > ---
> > 4572293 2015-08-27 19:38:39 -0500 Add epilog to parser
> > 17ed50a 2015-08-25 14:58:25 + Add Unit Tests for Store and Update 
> > Payload when Payload is zero
> > 34256de 2015-08-25 09:56:24 -0500 Allow Barbican Client Secret Update 
> > Functionality
> >
> > [ Unreleased changes in openstack/python-ceilometerclient ]
> >
> > Changes in python-ceilometerclient 1.4.0..2006902
> > -
> > 2006902 2015-08-26 14:09:00 + Updated from global requirements
> > 2429dae 2015-08-25 01:32:56 + Don't try to get aodh endpoint if 
> > auth_url didn't provided
> > 6498d55 2015-08-13 20:21:24 + Updated from global requirements
> >
> > [ Unreleased changes in openstack/python-cinderclient ]
> >
> > Changes in python-cinderclient 1.3.1..1c82825
> > -
> > 1c82825 2015-09-02 17:18:28 -0700 Update path to subunit2html in 
> > post_test_hook
> > 471aea8 2015-09-02 00:53:40 + Adds command to fetch specified backend 
> > capabilities
> > 2d979dc 2015-09-01 22:35:28 +0800 Volume status management for volume 
> > migration
> > 50758ba 2015-08-27 09:39:58 -0500 Fixed test_password_prompted
> > dc6e823 2015-08-26 23:04:16 -0700 Fix help message for reset-state commands
> > f805f5a 2015-08-25 15:15:20 +0300 Add functional tests for 
> > python-cinderclient
> > 8cc3ee2 2015-08-19 18:05:34 +0300 Add support '--all-tenants' for cinder 
> > backup-list
> > 2c3169e 2015-08-11 10:18:01 -0400 CLI: Non-disruptive backup
> > 5e26906 2015-08-11 13:14:04 +0300 Add tests for python-cinderclient
> > 780a129 2015-08-09 15:57:00 +0900 Replace assertEqual(None, *) with 
> > assertIsNone in tests
> > a9405b1 2015-08-08 05:36:45 -0400 CLI: Clone CG
> > 03542ee 2015-08-04 14:21:52 -0700 Fix ClientException init when there is no 
> > message on py34
> > 2ec9a22 2015-08-03 11:14:44 +0800 Fixes table when there are multiline in 
> > result data
> > 04caf88 2015-07-30 18:24:57 +0300 Set default OS_VOLUME_API_VERSION to '2'
> > bae0bb3 2015-07-27 01:28:00 + Add commands for modifying image metadata
> > 629e548 2015-07-24 03:34:55 + Updated from global requirements
> > b51e43e 2015-07-21 01:04:02 + Remove H302
> > b426b71 2015-07-20 13:21:02 +0800 Show backup and volume info in 
> > backup_restore
> > dc1186d 2015-07-16 19:45:08 -0700 Add response message when volume delete
> > 075381d 2015-07-15 09:20:48 +0800 Add more details for replication
> > 953f766 2015-07-14 18:51:58 +0800 New mock release(1.1.0) broke 
> > unit/function tests
> > 8afc06c 2015-07-08 12:11:07 -0500 Remove unnecessary check for tenant 
> > information
> > c23586b 2015-07-08 11:42:59 +0800 Remove redundant statement and refactor
> > 891ef3e 2015-06-25 13:27:42 + Use shared shell arguments provided by 
> > Session
> >
> > [ Unreleased changes in openstack/python-congressclient ]
> >
> > Changes in python-congressclient 1.1.0..0874721
> > ---
> > 0f699f8 2015-09-02 14:47:32 +0800 Add actions listing command
> > d7fa523 2015-08-26 14:09:29 + Updated from global requirements
> > 36f2b47 2015-08-11 01:38:32 + Updated from global requirements
> > ee07cb3

Re: [openstack-dev] [ptl][release] flushing unreleased client library changes

2015-09-04 Thread Doug Hellmann

Excerpts from Ihar Hrachyshka's message of 2015-09-04 21:07:47 +0200:
> > On 04 Sep 2015, at 18:39, Doug Hellmann  wrote:
> > 
> > 
> > PTLs,
> > 
> > We have quite a few unreleased client changes pending, and it would
> > be good to go ahead and publish them so they can be tested as part
> > of the release candidate process. I have the full list of changes for
> > each project below, so please find yours and review them and then
> > propose a release request to the openstack/releases repository.
> > 
> > On a separate note, for next cycle we need to do a better job of
> > releasing these much much earlier (a few of these changes are at
> > least a month old). Remember that changes to libraries do not go
> > into the gate for consuming projects until that library is released.
> > If you have any suggestions for how to do improve our tracking for
> > needed releases, let me know.
> > 
> > Doug
> > 
> > 
> > [ Unreleased changes in openstack/python-barbicanclient ]
> > 
> > Changes in python-barbicanclient 3.3.0..97cc46a
> 
> 
> +++
> 
> It may also block some efforts, f.e. we cannot move with fullstack tests for 
> QoS feature in neutron because those rely on neutronclient changes that are 
> not yet released.

The next release of neutronclient has some breaking changes, and since
we're heading into a 3-day weekend here in the US Kyle and I have agreed
to put that release off until Tuesday of next week. I'll do it early
US/Eastern time.

Doug

> 
> Ihar

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

Re: [openstack-dev] [Manila] Gate breakage and technical FFEs

2015-09-04 Thread Ben Swartzlander


On 09/04/2015 12:36 PM, Ben Swartzlander wrote:
The Manila gate is finally unblocked, thanks to the efforts of 
Valeriy! I see patches going in now so all of the features which were 
granted technical FFEs should start merging IMMEDIATELY.


By my calculations, we lost approximately 30 hours of time to merge 
stuff before the scheduled feature freeze, so I'm going to grant about 
30 hours from now, plus the weekend to get everything in.


The new deadline is Tuesday 8/8, at 1200 UTC. Everything must be 
merged by that time, or it will be rescheduled to Mitaka, no 
exceptions, no excuses (if the gate breaks again, then fix it).


Important correction: that's September 8 not August 8. My brain isn't a 
full strength after these last 2 days...



Those of you who weren't going to make the original deadline and were 
planning on asking for FFEs should consider yourself lucky. The gate 
getting stuck has bought you nearly 5 extra days to get your patches 
in order. For this reason I don't plan to grant any additional FFEs.


The following patches are on my list to get -2 if they're not merged 
by the deadline.


Migration

179790 - ganso - Add Share Migration feature
179791 - ganso - Share Migration support in generic driver
220278 - ganso - Add Share Migration tempest functional tests

CGs

215343 - cknight - Add DB changes for consistency-groups
215344 - cknight - Scheduler changes for consistency groups
215345 - cknight - Add Consistency Groups API
219891 - cknight - Consistency Group Support for the Generic Driver
215346 - cknight - Add functional tests for Manila consistency groups

NetApp CGs

215347 - cknight - Consistency groups in NetApp cDOT drivers

Mount Automation

201669 - vponomaryov - Add share hooks

Tempest Plugin

201955 - mkoderer - Use Tempest plugin interface

Windows SMB Driver

200154 - plucian - Add Windows SMB share driver

GlusterFS Driver

214462 - chenk - glusterfs*: factor out common parts
214921 - chenk - glusterfs/common: refactor GlusterManager
215021 - chenk - glusterfs-native: cut back on redundancy
215172 - chenk - glusterfs/layout: add layout base classes
215173 - chenk - glusterfs: volume mapped share layout
215293 - chenk - glusterfs: directory mapped share layout


-Ben Swartzlander


__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

[openstack-dev] [nova][i18n] Is there any point in using _() in python-novaclient?

2015-09-04 Thread Matt Riedemann


I noticed this today:

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

And it got me thinking about something I've wondered before - why do we 
even use _() in python-novaclient?  It doesn't have any .po files for 
babel message translation, it has no babel config, there is nothing in 
setup.cfg about extracting messages and compiling them into .mo's, there 
is nothing on Transifex for python-novaclient, etc.


Is there a way to change your locale and get translated output in nova 
CLIs?  I didn't find anything in docs from a quick google search.


Comparing to python-openstackclient, that does have a babel config and 
some locale po files in tree, at least for de and zh_TW.


So if this doesn't work in python-novaclient, do we need any of the i18n 
code in there?  It doesn't really hurt, but it seems pointless to push 
changes for it or try to keep user-facing messages in mind in the code.


--

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-dev] [app-catalog] App Catalog IRC meeting minutes - 9/3/2015

2015-09-04 Thread Christopher Aedo

We had a good meeting yesterday which included a little cheer for the
Community App Catalog project being accepted into the big tent (thanks
to everyone who has been supporting our efforts all along!)  The bulk
of the meeting was then devoted to discussing our plans for the next
generation of the site.  We've started the effort by outlining on
etherpad [1] all the features we need the site to support.  Next up we
are going to start evaluating potential frameworks we can use to build
a new site quickly while still making it easy to deploy and support
(and extend down the road.)  If you have useful opinions/experience
and are interested in helping plan this, please check out the etherpad
and join us on IRC to discuss.

As always, please join us on IRC (#openstack-app-catalog), or speak up
here on the mailing list if you want to help us make this the top
destination for people using OpenStack clouds!

[1] https://etherpad.openstack.org/p/app-catalog-v2-backend

-Christopher

=
#openstack-meeting-3: app-catalog
=
Meeting started by docaedo at 17:00:15 UTC.  The full logs are available
at
http://eavesdrop.openstack.org/meetings/app_catalog/2015/app_catalog.2015-09-03-17.00.log.html
.

Meeting summary
---
* rollcall  (docaedo, 17:00:30)

* Status updates (docaedo)  (docaedo, 17:01:21)
  * LINK: https://review.openstack.org/#/c/217957/  (docaedo, 17:01:43)
  * LINK: https://review.openstack.org/#/c/219809/  (docaedo, 17:02:57)
  * LINK: http://bit.ly/1N37aMS  (docaedo, 17:03:09)
  * LINK: https://review.openstack.org/#/c/218898/  (docaedo, 17:06:31)

* Review/discuss "new site plans" etherpad (docaedo)  (docaedo,
  17:10:47)
  * LINK: https://etherpad.openstack.org/p/app-catalog-v2-backend
(docaedo, 17:10:52)

* Open discussion  (docaedo, 17:38:11)

Meeting ended at 17:43:30 UTC.

People present (lines said)
---
* docaedo (55)
* kfox (47)
* ativelkov (17)
* kzaitsev_mb (9)
* j^2 (4)
* openstack (3)

Generated by `MeetBot`_ 0.1.4

__
OpenStack Development Mailing 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] [Glance] Liberty RC reviews

2015-09-04 Thread Nikhil Komawar

Hi all,

Please take some time to go through the etherpad I've created to
prioritize reviews needed for Liberty RC period. These reviews have been
categorized to help pick your favorite but all of them are important. As
we have a decent amount of time to identify bugs and fix them, reviewing
the mentioned merge proposals would be beneficial in the near future.

https://etherpad.openstack.org/p/glance-liberty-rc-reviews

-- 

Thanks,
Nikhil


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

Re: [openstack-dev] [Manila] Gate breakage and technical FFEs

2015-09-04 Thread Ben Swartzlander


On 09/04/2015 12:36 PM, Ben Swartzlander wrote:
The Manila gate is finally unblocked, thanks to the efforts of 
Valeriy! I see patches going in now so all of the features which were 
granted technical FFEs should start merging IMMEDIATELY.


By my calculations, we lost approximately 30 hours of time to merge 
stuff before the scheduled feature freeze, so I'm going to grant about 
30 hours from now, plus the weekend to get everything in.


The new deadline is Tuesday 8/8, at 1200 UTC. Everything must be 
merged by that time, or it will be rescheduled to Mitaka, no 
exceptions, no excuses (if the gate breaks again, then fix it).


Those of you who weren't going to make the original deadline and were 
planning on asking for FFEs should consider yourself lucky. The gate 
getting stuck has bought you nearly 5 extra days to get your patches 
in order. For this reason I don't plan to grant any additional FFEs.


The following patches are on my list to get -2 if they're not merged 
by the deadline.


Migration

179790 - ganso - Add Share Migration feature
179791 - ganso - Share Migration support in generic driver
220278 - ganso - Add Share Migration tempest functional tests

CGs

215343 - cknight - Add DB changes for consistency-groups
215344 - cknight - Scheduler changes for consistency groups
215345 - cknight - Add Consistency Groups API
219891 - cknight - Consistency Group Support for the Generic Driver
215346 - cknight - Add functional tests for Manila consistency groups

NetApp CGs

215347 - cknight - Consistency groups in NetApp cDOT drivers

Mount Automation

201669 - vponomaryov - Add share hooks

Tempest Plugin

201955 - mkoderer - Use Tempest plugin interface

Windows SMB Driver

200154 - plucian - Add Windows SMB share driver

GlusterFS Driver

214462 - chenk - glusterfs*: factor out common parts
214921 - chenk - glusterfs/common: refactor GlusterManager
215021 - chenk - glusterfs-native: cut back on redundancy
215172 - chenk - glusterfs/layout: add layout base classes
215173 - chenk - glusterfs: volume mapped share layout
215293 - chenk - glusterfs: directory mapped share layout



Also a note for core reviewers: for the 2 chains of patches (CGs and 
GlusterFS) please workflow them in reverse order so they go through the 
gate all at once. I would rather avoid a situation where we have to back 
out a half-merged feature in the event it doesn't make the deadline.




-Ben Swartzlander


__ 


OpenStack Development Mailing 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] FFE Request for moving inherited assignment to core in Keystone

2015-09-04 Thread Henry Nash

Keystone has, for a number of releases,  supported the concept of inherited 
role assignments via the OS-INHERIT extension. At the Keystone mid-cycle we 
agreed moving this to core this was a good target for Liberty, but this was 
held by needing the data driver testing to be in place  
(https://review.openstack.org/#/c/190996/ 
).

Inherited roles are becoming an integral part of Keystone, especially with the 
move to hierarchal projects (which is core already) - and so moving inheritance 
to core makes a lot of sense.  At the same time as the move, we want to tidy up 
the API (https://review.openstack.org/#/c/200434/ 
) to be more consistent with project 
hierarchies (before the old API semantics get too widely used), although we 
will continue to support the old API via the extension for a number of cycles.

I would like to request an FFE for the move of inheritance to core.

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

Re: [openstack-dev] [TripleO] Status of CI changes

2015-09-04 Thread James Slagle

On Thu, Sep 3, 2015 at 2:34 AM, Derek Higgins  wrote:
> Hi All,
>
> The patch to reshuffle our CI jobs has merged[1], along with the patch to
> switch the f21-noha job to be instack based[2] (with centos images).
>
> So the current status is that our CI has been removed from most of the non
> tripleo projects (with the exception of nova/neutron/heat and ironic
> where it is only available with check experimental until we are sure its
> reliable).
>
> The last big move is to pull in some repositories into the upstream[3]
> gerrit so until this happens we still have to worry about some projects
> being on gerrithub (the instack based CI pulls them in from gerrithub for
> now). I'll follow up with a mail once this happens
>
> A lot of CI stuff still needs to be worked on (and improved) e.g.
>  o Add ceph support to the instack based job
>  o Add ha support to the instack based job
>  o Improve the logs exposed
>  o Pull out a lot of workarounds that have gone into the CI job
>  o move out some of the parts we still use in tripleo-incubator
>  o other stuff
>
> Please make yourself known if your interested in any of the above
>

As usual, a huge thanks for your effort in pushing this forward.

I've been working on getting the instack-undercloud documentation
updated with the OpenStack theme, as well as getting them updated to
match what the CI job is testing:
https://fedorapeople.org/~slagle/tripleo-docs/

These docs will eventually be hosted at
http://docs.openstack.org/developer/tripleo-docs
when the below mentioned patch [3] merges.

There's also some set of content from the existing tripleo-incubator
documentation that is still relevant, so I think we should roll that
into tripleo-docs as well. I'll have a look at that once the repo is
setup.


> [1] https://review.openstack.org/#/c/205479/
> [2] https://review.openstack.org/#/c/185151/
> [3] https://review.openstack.org/#/c/215186/




-- 
-- James Slagle
--

__
OpenStack Development Mailing 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] 9/4 state of the gate

2015-09-04 Thread Matt Riedemann

There are a few things blowing up in the last 24 hours so might as well 
make people aware.


1. gate-tempest-dsvm-large-ops was failing at a decent rate:

https://bugs.launchpad.net/nova/+bug/1491949

Turns out devstack was changed to run multihost=true and that doesn't 
work so well with the large-ops job that's creating hundreds of fake 
instances on a single node.  We reverted the devstack change so things 
should be good there now.



2. gate-tempest-dsvm-cells was regressed because nova has an in-tree 
blacklist regex of tests that don't work with cells and renaming some of 
those in tempest broke the regex.


https://bugs.launchpad.net/nova/+bug/1492255

There is a patch in the gate but it's getting bounced on #3.  Long-term 
we want to bring that blacklist regex down to 0 and instead use feature 
toggles in Tempest for the cells job, we just aren't there yet.  Help 
wanted...



3. gate-tempest-dsvm-full-ceph is broken with glance-store 0.9.0:

https://bugs.launchpad.net/glance-store/+bug/1492432

It looks like the gate-tempest-dsvm-full-ceph-src-glance_store job was 
not actually testing trunk glance_store code because of a problem in the 
upper-constraints.txt file in the requirements repo - pip was capping 
glance_store at 0.8.0 in the src job so we actually haven't been testing 
latest glance-store.  dhellmann posted a fix:


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

But I'm assuming glance-store 0.9.0 is still busted. I've posted a 
change which I think might be related:


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

If ^ fixes the issue we'll need to blacklist 0.9.0 from global-requirements.

--

As always, it's fun to hit this stuff right before the weekend, 
especially a long US holiday weekend. :)


--

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

Re: [openstack-dev] [neutron] pushing changes through the gate

2015-09-04 Thread Kyle Mestery

I would like to second everything Armando has said below. Please, Neutron
core reviewers, follow the advice below for the rest of the Liberty cycle
as we work to merge patches targeted at Liberty.

I'd also like to thank Armando for jumping in and running things the past
week while I was on a (planned last spring) vacation with my family. He's
done a fabulous job, and his tireless effort this week shouldn't go
unnoticed.

Thanks for all your hard work Armando!

Kyle

On Thu, Sep 3, 2015 at 5:00 PM, Armando M.  wrote:

>
>
> On 2 September 2015 at 09:40, Armando M.  wrote:
>
>> Hi,
>>
>> By now you may have seen that I have taken out your change from the gate
>> and given it a -2: don't despair! I am only doing it to give priority to
>> the stuff that needs to merge in order to get [1] into a much better shape.
>>
>> If you have an important fix, please target it for RC1 or talk to me or
>> Doug (or Kyle when he's back from his time off), before putting it in the
>> gate queue. If everyone is not conscious of the other, we'll only end up
>> stepping on each other, and nothing moves forward.
>>
>> Let's give priority to gate stabilization fixes, and targeted stuff.
>>
>> Happy merging...not!
>>
>> Many thanks,
>> Armando
>>
>> [1] https://launchpad.net/neutron/+milestone/liberty-3
>> [2] https://launchpad.net/neutron/+milestone/liberty-rc1
>>
>
> Download files for the milestone are available in [1]. We still have a lot
> to do as there are outstanding bugs and blueprints that will have to be
> merged in the RC time windows.
>
> Please be conscious of what you approve. Give priority to:
>
> - Targeted bugs and blueprints in [2];
> - Gate stability fixes or patches that aim at helping troubleshooting;
>
> In these busy times, please refrain from proposing/merging:
>
> - Silly rebase generators (e.g. spelling mistakes);
> - Cosmetic changes (e.g. minor doc strings/comment improvements);
> - Refactoring required while dealing with the above;
> - A dozen of patches stacked on top of each other;
>
> Every rule has its own exception, so don't take this literally.
>
> If you are unsure, please reach out to me, Kyle or your Lieutenant and
> we'll target stuff that is worth targeting.
>
> As for the rest, I am gonna be merciless and -2 anything than I can find,
> in order to keep our gate lean and sane :)
>
> Thanks and happy hacking.
>
> A.
>
> [1] https://launchpad.net/neutron/+milestone/liberty-3
> [2] https://launchpad.net/neutron/+milestone/liberty-rc1
>
>
__
OpenStack Development Mailing 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] [neutron] FFE process for Liberty

2015-09-04 Thread Kyle Mestery

Folks, Armando did a great job targeting things which missed Liberty-3
towards Liberty-RC1 here [1]. For the most part, I hope most of those will
land in the coming week or so, so lets work as a team to land those.

For things which are not already targeted there (or were targeted by
someone else, like [2]), the process to get these in as an FFE is to send
an email to the openstack-dev list and request this. We'll review these in
the team meeting next Tuesday morning and see what we can add. At this
point, things are mostly full, given we already have 15 BPs targeted. But
if something is small enough or only needs one more patch to land, we'll
concentrate on helping to move it along.

Thanks!
Kyle

[1] https://launchpad.net/neutron/+milestone/liberty-rc1
[2] https://blueprints.launchpad.net/neutron/+spec/ovs-tunnel-csum-option
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] cloud-init IPv6 support

2015-09-04 Thread Kevin Benton

Right, it depends on your perspective of who 'owns' the API. Is it
cloud-init or EC2?

At this point I would argue that cloud-init is in control because it would
be a large undertaking to switch all of the AMI's on Amazon to something
else. However, I know Sean disagrees with me on this point so I'll let him
reply here.


On Thu, Sep 3, 2015 at 4:03 PM, Fox, Kevin M  wrote:

> So if we define the well known address and cloud-init adopts it, then
> Amazon should be inclined to adopt it too. :)
>
> Why always chase Amazon?
>
> Thanks,
> Kevin
> 
> From: Steve Gordon [sgor...@redhat.com]
> Sent: Thursday, September 03, 2015 11:06 AM
> To: Kevin Benton
> Cc: OpenStack Development Mailing List (not for usage questions); PAUL
> CARVER
> Subject: Re: [openstack-dev] [Neutron] cloud-init IPv6 support
>
> - Original Message -
> > From: "Kevin Benton" 
> >
> > When we discussed this before on the neutron channel, I thought it was
> > because cloud-init doesn't support IPv6. We had wasted quite a bit of
> time
> > talking about adding support to our metadata service because I was under
> > the impression that cloud-init already did support IPv6.
> >
> > IIRC, the argument against adding IPv6 support to cloud-init was that it
> > might be incompatible with how AWS chooses to implement IPv6 metadata, so
> > AWS would require a fork or other incompatible alternative to cloud-init
> in
> > all of their images.
> >
> > Is that right?
>
> That's certainly my understanding of the status quo, I was enquiring
> primarily to check it was still accurate.
>
> -Steve
>
> > On Thu, Sep 3, 2015 at 7:30 AM, Sean M. Collins 
> wrote:
> >
> > > It's not a case of cloud-init supporting IPv6 - The Amazon EC2 metadata
> > > API defines transport level details about the API - and currently only
> > > defines a well known IPv4 link local address to connect to. No well
> known
> > > link local IPv6 address has been defined.
> > >
> > > I usually recommend config-drive for IPv6 enabled clouds due to this.
> > > --
> > > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> > >
> __
> > > OpenStack Development Mailing 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
>



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

Re: [openstack-dev] [Neutron] cloud-init IPv6 support

2015-09-04 Thread Kevin Benton

Thanks for pointing that out. I like the DNS option too. That has to be
done carefully though to make sure it's not easy for an attacker to get the
name of the DNS entry that the instance tries to look up.

On Fri, Sep 4, 2015 at 10:53 AM, Henry Gessau  wrote:

> Some thought has been given to this. See
> https://bugs.launchpad.net/neutron/+bug/1460177
>
> I like the third option, a well-known name using DNS.
>
>
> On Thu, Sep 03, 2015, Kevin Benton  
> wrote:
>
> I think that's different than what is being asked here. That patch appears
> to just add IPv6 interface information if it's available in the metadata.
> This thread is about getting cloud-init to connect to an IPv6 address
> instead of 169.254.169.254 for pure IPv6 environments.
>
> On Thu, Sep 3, 2015 at 11:41 AM, Joshua Harlow 
> wrote:
>
>> I'm pretty sure this got implemented :)
>>
>> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1042
>> and https://bugs.launchpad.net/cloud-init/+bug/1391695
>>
>> That's the RHEL support, since cloud-init translates a ubuntu style
>> networking style the ubuntu/debian style format should also work.
>>
>>
>> Steve Gordon wrote:
>>
>>> - Original Message -
>>>
 From: "Kevin Benton"

 When we discussed this before on the neutron channel, I thought it was
 because cloud-init doesn't support IPv6. We had wasted quite a bit of
 time
 talking about adding support to our metadata service because I was under
 the impression that cloud-init already did support IPv6.

 IIRC, the argument against adding IPv6 support to cloud-init was that it
 might be incompatible with how AWS chooses to implement IPv6 metadata,
 so
 AWS would require a fork or other incompatible alternative to
 cloud-init in
 all of their images.

 Is that right?

>>>
>>> That's certainly my understanding of the status quo, I was enquiring
>>> primarily to check it was still accurate.
>>>
>>> -Steve
>>>
>>> On Thu, Sep 3, 2015 at 7:30 AM, Sean M. Collins< 
 s...@coreitpro.com>  wrote:

 It's not a case of cloud-init supporting IPv6 - The Amazon EC2 metadata
> API defines transport level details about the API - and currently only
> defines a well known IPv4 link local address to connect to. No well
> known
> link local IPv6 address has been defined.
>
> I usually recommend config-drive for IPv6 enabled clouds due to this.
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> __
> OpenStack Development Mailing 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
>>>
>>
>
>
> --
> Kevin Benton
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
>
>


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

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread John Griffith

On Fri, Sep 4, 2015 at 11:35 AM, Mathieu Gagné  wrote:

> On 2015-09-04 12:50 PM, Monty Taylor wrote:
> > On 09/04/2015 10:55 AM, Morgan Fainberg wrote:
> >>
> >> Obviously the translation of errors
> >> would be more difficult if the enforcer is generating messages.
> >
> > The type: "PolicyNotAuthorized" is a good general key. Also - even
> > though the command I sent was:
> >
> > neutron net-create
> >
> > On the command line, the entry in the policy_file is "create_network" -
> > so honestly I think that policy.json and oslo.policy should have (or be
> > able to have) all of the info needed to create almost the exact same
> > message. Perhaps "NeutronError" would just need to be
> > "OpenStackPolicyError"?
> >
> > Oh. Wait. You meant translation like i18n translation. In that case, I
> > think it's easy:
> >
> > message=_("Policy doesn't allow %(policy_key)s to be performed",
> > policy_key="create_network")
> >
> > /me waves hands
> >
>
> I don't feel like this error message would be user-friendly:
>
> "Policy doesn't allow os_compute_api:os-instance-actions to be performed"
>
> Policy name aren't human readable and match nothing on the client side.
>
> --
> Mathieu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

Ok, so this:

ubuntu@devbox:~$ cinder reset-state 9dee0fae-864c-44f9-bdd7-3330a0f4e899
Reset state for volume 9dee0fae-864c-44f9-bdd7-3330a0f4e899 failed: Policy
doesn't allow volume_extension:volume_admin_actions:reset_status to be
performed. (HTTP 403) (Request-ID: req-8ed2c895-0d1f-4b2c-9859-ee15c19267de)
ERROR: Unable to reset the state for the specified volume(s).
ubuntu@devbox:~$

Is no good?  You would like to see "less" in the output; like just the
command name itself and "Policy doesn't allow"?

To Mathieu's point, fair statement WRT the visibility of the policy name.


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

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Morgan Fainberg

On Fri, Sep 4, 2015 at 10:35 AM, Mathieu Gagné  wrote:

> On 2015-09-04 12:50 PM, Monty Taylor wrote:
> > On 09/04/2015 10:55 AM, Morgan Fainberg wrote:
> >>
> >> Obviously the translation of errors
> >> would be more difficult if the enforcer is generating messages.
> >
> > The type: "PolicyNotAuthorized" is a good general key. Also - even
> > though the command I sent was:
> >
> > neutron net-create
> >
> > On the command line, the entry in the policy_file is "create_network" -
> > so honestly I think that policy.json and oslo.policy should have (or be
> > able to have) all of the info needed to create almost the exact same
> > message. Perhaps "NeutronError" would just need to be
> > "OpenStackPolicyError"?
> >
> > Oh. Wait. You meant translation like i18n translation. In that case, I
> > think it's easy:
> >
> > message=_("Policy doesn't allow %(policy_key)s to be performed",
> > policy_key="create_network")
> >
> > /me waves hands
> >
>
> I don't feel like this error message would be user-friendly:
>
> "Policy doesn't allow os_compute_api:os-instance-actions to be performed"
>
> Policy name aren't human readable and match nothing on the client side.
>
>
To be fair the message can be improved. Right now this is so far above what
you get in most cases. Digging a bit deeper, a lot of this is in
oslo.policy but it appears we have projects doing custom layers of
enforcement that change the results. The short solution is to clean up and
consistently raise an exception up and then work on the messaging.
__
OpenStack Development Mailing List (not for 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][api] New API Guidelines Ready for Cross Project Review

2015-09-04 Thread Everett Toews

On Aug 27, 2015, at 10:48 AM, Everett Toews  wrote:

> Hi All,
> 
> The following API guidelines are ready for cross project review. They will be 
> merged on Sept. 4 if there's no further feedback.
> 
> 1. Add description of pagination parameters
> https://review.openstack.org/#/c/190743/
> 
> 2. Require "OpenStack-" in headers
> https://review.openstack.org/#/c/215683/
> 
> 3. Add the condition for using a project term
> https://review.openstack.org/#/c/208264/
> 
> 4. Added note about caching of responses when using https
> https://review.openstack.org/#/c/185288/
> 
> 5. add section describing 501 common mistake
> https://review.openstack.org/#/c/183456/

API guidelines 2-5 above have been merged. Guideline 1 needs further work.

Thanks for you feedback,
Everett


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

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Monty Taylor


On 09/04/2015 01:42 PM, John Griffith wrote:

On Fri, Sep 4, 2015 at 11:35 AM, Mathieu Gagné  wrote:


On 2015-09-04 12:50 PM, Monty Taylor wrote:

On 09/04/2015 10:55 AM, Morgan Fainberg wrote:


Obviously the translation of errors
would be more difficult if the enforcer is generating messages.


The type: "PolicyNotAuthorized" is a good general key. Also - even
though the command I sent was:

neutron net-create

On the command line, the entry in the policy_file is "create_network" -
so honestly I think that policy.json and oslo.policy should have (or be
able to have) all of the info needed to create almost the exact same
message. Perhaps "NeutronError" would just need to be
"OpenStackPolicyError"?

Oh. Wait. You meant translation like i18n translation. In that case, I
think it's easy:

message=_("Policy doesn't allow %(policy_key)s to be performed",
policy_key="create_network")

/me waves hands



I don't feel like this error message would be user-friendly:

"Policy doesn't allow os_compute_api:os-instance-actions to be performed"

Policy name aren't human readable and match nothing on the client side.

--
Mathieu

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



Ok, so this:

ubuntu@devbox:~$ cinder reset-state 9dee0fae-864c-44f9-bdd7-3330a0f4e899
Reset state for volume 9dee0fae-864c-44f9-bdd7-3330a0f4e899 failed: Policy
doesn't allow volume_extension:volume_admin_actions:reset_status to be
performed. (HTTP 403) (Request-ID: req-8ed2c895-0d1f-4b2c-9859-ee15c19267de)
ERROR: Unable to reset the state for the specified volume(s).
ubuntu@devbox:~$

Is no good?  You would like to see "less" in the output; like just the
command name itself and "Policy doesn't allow"?

To Mathieu's point, fair statement WRT the visibility of the policy name.


Totally agree on the policy name. The one I did happened to be clear - 
that is not always the case. I'd love to see that.


But more to your question - yes, as an end user, I do't know what a 
volume_extension:volume_admin_actions:reset_status is - but I do know 
that I ran "cinder reset-state" - so getting:


'Cloud policy does not allow you to run reset_status"

would be fairly clear to me.

The other bits, the 403, the request-id and then the additional error 
message are a bit too busy. (they seem like output for a debug or 
verbose flag IMHO)


NOW -

 ERROR: Unable to reset the state for the specified volume(s) - Policy 
does not allow reset_status


would also work and would also be clear "this did not occur, the reason 
is that you are not allowed to do this because the cloud admin has set a 
policy.


Now that I'm talking out loud though - I'm policy is a little confusing 
- because policy is not an end-user concept in any way.


"Your cloud administrator has disabled this API function"

is clearer and more to the point with less jargon.

I think the key points to communicate (verbally or through crafting):

- Yes, you logged in
- Yes, the API you called is a correct and real API
- No, you did not make a syntax error
- No, you are not allowed to call that real API on _this_ cloud

(without knowing those things, I tend to debug a TON of things before 
figuring out "oh, the cloud admin turned off part of the API)



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

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Mathieu Gagné

On 2015-09-04 2:41 PM, Monty Taylor wrote:
> On 09/04/2015 01:42 PM, John Griffith wrote:
>>
>> Is no good?  You would like to see "less" in the output; like just the
>> command name itself and "Policy doesn't allow"?
>>
>> To Mathieu's point, fair statement WRT the visibility of the policy name.
> 
> Totally agree on the policy name. The one I did happened to be clear -
> that is not always the case. I'd love to see that.
> 
> But more to your question - yes, as an end user, I do't know what a
> volume_extension:volume_admin_actions:reset_status is - but I do know
> that I ran "cinder reset-state" - so getting:
> 
> 'Cloud policy does not allow you to run reset_status"
> 
> would be fairly clear to me.

Don't assume the user will run it from the (supposedly) deprecated
Cinder CLI. It could be from the new openstackclient or even an SDK
written in Ruby which might not name it "reset_status".

I would prefer a generic message over an overly specific message which
makes a lot of wrong assumption about the consumer.

-- 
Mathieu

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

Re: [openstack-dev] [ptl][release] flushing unreleased client library changes

2015-09-04 Thread Ihar Hrachyshka

> On 04 Sep 2015, at 18:39, Doug Hellmann  wrote:
> 
> 
> PTLs,
> 
> We have quite a few unreleased client changes pending, and it would
> be good to go ahead and publish them so they can be tested as part
> of the release candidate process. I have the full list of changes for
> each project below, so please find yours and review them and then
> propose a release request to the openstack/releases repository.
> 
> On a separate note, for next cycle we need to do a better job of
> releasing these much much earlier (a few of these changes are at
> least a month old). Remember that changes to libraries do not go
> into the gate for consuming projects until that library is released.
> If you have any suggestions for how to do improve our tracking for
> needed releases, let me know.
> 
> Doug
> 
> 
> [ Unreleased changes in openstack/python-barbicanclient ]
> 
> Changes in python-barbicanclient 3.3.0..97cc46a


+++

It may also block some efforts, f.e. we cannot move with fullstack tests for 
QoS feature in neutron because those rely on neutronclient changes that are not 
yet released.

Ihar


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

Re: [openstack-dev] FFE Request for moving inherited assignment to core in Keystone

2015-09-04 Thread Dolph Mathews

-1

Unless there's something more to this, I don't think it's worth any sort of
risk to stability just to shuffle API implementations around that can't
wait for mikata.

On Fri, Sep 4, 2015 at 12:28 PM, Henry Nash 
wrote:

> Keystone has, for a number of releases,  supported the concept of
> inherited role assignments via the OS-INHERIT extension. At the Keystone
> mid-cycle we agreed moving this to core this was a good target for Liberty,
> but this was held by needing the data driver testing to be in place  (
> https://review.openstack.org/#/c/190996/).
>
> Inherited roles are becoming an integral part of Keystone, especially with
> the move to hierarchal projects (which is core already) - and so moving
> inheritance to core makes a lot of sense.  At the same time as the move, we
> want to tidy up the API (https://review.openstack.org/#/c/200434/
> ) to be more consistent with
> project hierarchies (before the old API semantics get too widely used),
> although we will continue to support the old API via the extension for a
> number of cycles.
>
> I would like to request an FFE for the move of inheritance to core.
>
> Henry
>
> __
> OpenStack Development Mailing 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] [Neutron] cloud-init IPv6 support

2015-09-04 Thread Fox, Kevin M

Adding a dns server adds more complexity into the mix. You need to support both 
a dns server and a metadata server at that point.

From: Kevin Benton [blak...@gmail.com]
Sent: Friday, September 04, 2015 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] cloud-init IPv6 support

Thanks for pointing that out. I like the DNS option too. That has to be done 
carefully though to make sure it's not easy for an attacker to get the name of 
the DNS entry that the instance tries to look up.

On Fri, Sep 4, 2015 at 10:53 AM, Henry Gessau 
> wrote:
Some thought has been given to this. See
https://bugs.launchpad.net/neutron/+bug/1460177

I like the third option, a well-known name using DNS.

On Thu, Sep 03, 2015, Kevin Benton 
 wrote:
I think that's different than what is being asked here. That patch appears to 
just add IPv6 interface information if it's available in the metadata. This 
thread is about getting cloud-init to connect to an IPv6 address instead of 
169.254.169.254 for pure IPv6 environments.

On Thu, Sep 3, 2015 at 11:41 AM, Joshua Harlow 
> wrote:
I'm pretty sure this got implemented :)

http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1042
 and https://bugs.launchpad.net/cloud-init/+bug/1391695

That's the RHEL support, since cloud-init translates a ubuntu style networking 
style the ubuntu/debian style format should also work.

Steve Gordon wrote:
- Original Message -
From: "Kevin Benton">

When we discussed this before on the neutron channel, I thought it was
because cloud-init doesn't support IPv6. We had wasted quite a bit of time
talking about adding support to our metadata service because I was under
the impression that cloud-init already did support IPv6.

IIRC, the argument against adding IPv6 support to cloud-init was that it
might be incompatible with how AWS chooses to implement IPv6 metadata, so
AWS would require a fork or other incompatible alternative to cloud-init in
all of their images.

Is that right?

That's certainly my understanding of the status quo, I was enquiring primarily 
to check it was still accurate.

-Steve

On Thu, Sep 3, 2015 at 7:30 AM, Sean M. 
Collins<s...@coreitpro.com>
  wrote:

It's not a case of cloud-init supporting IPv6 - The Amazon EC2 metadata
API defines transport level details about the API - and currently only
defines a well known IPv4 link local address to connect to. No well known
link local IPv6 address has been defined.

I usually recommend config-drive for IPv6 enabled clouds due to this.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
__
OpenStack Development Mailing 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

--
Kevin Benton

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

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

Re: [openstack-dev] [puppet] hosting developer documentation on http://docs.openstack.org/developer/

2015-09-04 Thread Anita Kuno

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 09/04/2015 09:28 AM, Emilien Macchi wrote:
> 
> 
> On 09/03/2015 03:00 PM, Emilien Macchi wrote:
>> 
>> 
>> On 09/02/2015 02:56 PM, Emilien Macchi wrote:
>>> 
>>> 
>>> On 09/02/2015 02:48 PM, Anita Kuno wrote:
 On 09/02/2015 02:09 PM, Emilien Macchi wrote:
> TL;DR, I propose to move our developer documentation from
> wiki to something like 
> http://docs.openstack.org/developer/puppet-openstack
 
> (Look at http://docs.openstack.org/developer/tempest/ for 
> example).
 
 Looking at the tempest example: 
 http://git.openstack.org/cgit/openstack/tempest/tree/doc/source

 
we see that the .rst files all live in the tempest repo in doc/source
 (with the exception of the README.rst file with is referenced
 from within doc/source when required: 
 http://git.openstack.org/cgit/openstack/tempest/tree/doc/source/ove
rview.rst)


 
So question: Where should the source .rst files for puppet developer
 documentation live? They will need a home.
>>> 
>>> I guess we would need a new repository for that. It could be
>>> puppet-openstack-doc (kiss) or something else, any suggestion
>>> is welcome.
>> 
>> Are we ok for the name? proposal: puppet-openstack-doc 
>> puppet-openstack-documentation
> 
> Let's go for puppet-openstack-docs.

Here is a patch: https://review.openstack.org/#/c/220555/
I still need to offer the co-responding patch to the governance repo.

Thanks,
Anita.

> 
>> 
>> Any suggestion is welcome,
>> 
 
 Thanks, Anita.
 
 
> For now, most of our documentation is on 
> https://wiki.openstack.org/wiki/Puppet but I think it would
> be great to use RST format and Gerrit so anyone could
> submit documentation contribute like we do for code.
 
> I propose a basic table of contents now: Puppet modules 
> introductions Coding Guide Reviewing code
 
> I'm taking the opportunity of the puppet sprint to run this
>  discussion and maybe start some work of people agrees to
> move on.
 
> Thanks,
 
 
 
> __





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




> 

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

 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
>>> 
>>> 
>>> 
>>> 
__
>>>
>>> 
OpenStack Development Mailing 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
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJV6b4eAAoJELmKyZugNFU0oIAH/Atinp6F+2/fF/rOJXRSAY1q
CMprTm2x0eNGDTH/Cy17U305qj4cSXdzcpv3yv7iLDQRFcSCvWwzcTXxmUjIKrRe
1n8EI+vi/kg/MoSMBSAk84o6Zt9YM2pTbIr/rFzvb0qEesx7r2eErV6lpRJbpUvm
qFU0+GBBoDJi5DN2T1Y4qV3MhgxNJLpJfzorT4Nn4AAGXqWSvKM1y1YEtTIiK0wn
d7VoWdcffDI4/hPyMnjOngKf0mj5v66KJkL6eYrY9InqMrCTjwg0v6YlQ+gp3wHw
oZWe34WDU/DPQBJyhq7UOcK0khnHIvfJorCo1lOz2V3uZE5g+NBB8Z9dBTlfbvk=
=Ju1R
-END PGP SIGNATURE-

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

Re: [openstack-dev] [all] Mitaka Design Summit - Proposed slot allocation

2015-09-04 Thread Thierry Carrez

Nikhil Komawar wrote:
> No dedicated time slot for cross-project sessions this time around?

That's on the Tuesday. 3 parallel sessions all day.
In addition, the Ops track runs on Tuesday and Wednesday.

-- 
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-dev] [keystone] FFE Request for Reseller

2015-09-04 Thread Henrique Truta

Hi Folks,

As you may know, the Reseller Blueprint was proposed and approved in Kilo (
https://review.openstack.org/#/c/139824/) with the developing postponed to
Liberty.

During this time, the 3 main patches of the chain were split into 8,
becoming smaller and easier to review. The first 2 of them were merged
before liberty-3 freeze, and some of the others have already received +2s.
The code is very mature, having a keystone core member support through the
whole release cycle.

I would like to request an FFE for the remaining 9 patches (reseller core)
which are already in review (starting from
https://review.openstack.org/#/c/213448/ to
https://review.openstack.org/#/c/161854/).

Henrique
__
OpenStack Development Mailing List (not for 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][networking-sfc]

2015-09-04 Thread Armando M.

On 4 September 2015 at 15:33, Paul Carver  wrote:

>
> Can someone from the Docs team take a look at why there isn't a docs URL
> for the networking-sfc repo?
>

Everything in OpenStack is code driven. And doc publishing happens through
code review as much as anything else. [1] Should provide pointers, but
another great source of recipes and clues can be found on [2]. You'll find
your answer in there somewhere.

HTH
Armando

[1]
http://docs.openstack.org/infra/manual/creators.html#add-basic-jenkins-jobs
[2] https://github.com/openstack-infra/project-config/commits/master


>
> Compare [1] vs [2]
> The first URL appears to be a rendering of the docs/source/index.rst from
> the Neutron Git repo, but the second one gives a Not Found even though
> there is a docs/source/index.rst in the networking-sfc repo.
>
> If I've guessed the wrong URL, please let me know. I just guessed that
> replacing the name of the neutron repo in the URL with the name of the
> networking-sfc repo should have given me the right URL.
>
> Compare [3] vs [4]
>
> Both of these exist and as far as I can tell [1] is rendered from [3] and
> I would just naturally expect [2] to be rendered from [4] but it isn't.
>
> [1] http://docs.openstack.org/developer/neutron/
> [2] http://docs.openstack.org/developer/networking-sfc/
> [3]
> https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/index.rst
> [4]
> https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/index.rst
>
> __
> OpenStack Development Mailing 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] 9/4 state of the gate

2015-09-04 Thread Matt Riedemann




On 9/4/2015 3:13 PM, Matt Riedemann wrote:

There are a few things blowing up in the last 24 hours so might as well
make people aware.

1. gate-tempest-dsvm-large-ops was failing at a decent rate:

https://bugs.launchpad.net/nova/+bug/1491949

Turns out devstack was changed to run multihost=true and that doesn't
work so well with the large-ops job that's creating hundreds of fake
instances on a single node.  We reverted the devstack change so things
should be good there now.


2. gate-tempest-dsvm-cells was regressed because nova has an in-tree
blacklist regex of tests that don't work with cells and renaming some of
those in tempest broke the regex.

https://bugs.launchpad.net/nova/+bug/1492255

There is a patch in the gate but it's getting bounced on #3.  Long-term
we want to bring that blacklist regex down to 0 and instead use feature
toggles in Tempest for the cells job, we just aren't there yet.  Help
wanted...


3. gate-tempest-dsvm-full-ceph is broken with glance-store 0.9.0:

https://bugs.launchpad.net/glance-store/+bug/1492432

It looks like the gate-tempest-dsvm-full-ceph-src-glance_store job was
not actually testing trunk glance_store code because of a problem in the
upper-constraints.txt file in the requirements repo - pip was capping
glance_store at 0.8.0 in the src job so we actually haven't been testing
latest glance-store.  dhellmann posted a fix:

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

But I'm assuming glance-store 0.9.0 is still busted. I've posted a
change which I think might be related:

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

If ^ fixes the issue we'll need to blacklist 0.9.0 from
global-requirements.

--

As always, it's fun to hit this stuff right before the weekend,
especially a long US holiday weekend. :)



I haven't seen the elastic-recheck bot comment on any changes in awhile 
either so I'm wondering if that's not running.


Also, here is another new(ish) gate bug I'm just seeing tonight (bumped 
a fix for #3 above):


https://bugs.launchpad.net/keystonemiddleware/+bug/1492508

--

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

Re: [openstack-dev] Tracing a request (NOVA)

2015-09-04 Thread Akira Yoshiyama

You may like below:
https://gist.github.com/yosshy/5da0c2d6af1b446088bc

Akira

> Hi,
>
> I'm trying to trace a request made for an instance and looking at the flow
> in the code.
> I'm just trying to understand better how the request goes from the
> dashboard to the nova-api , to the other internal components of nova and to
> the scheduler and back with a suitable host and launching of the instance.
>
> i just want to understand as to how the request goes from the api-call to
> the nova-api and so on after that.
> I have understood the nova-scheduler and in that, the filter_scheduler
> receives something called request_spec that is the specifications of the
> request that is made, and I want to see where this comes from. I was not
> very successful in reverse engineering this.
>
> I could use some help as I want to implement a scheduling algorithm of my
> own but for that I need to understand how and where the requests come in
> and how the flow works.
>
> If someone could guide me as to where i can find help or point in some
> direction then it would be of great help.
>
> --
> Dhvanan Shah
>


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

Re: [openstack-dev] This is what disabled-by-policy should look like to the user

2015-09-04 Thread Adam Young


On 09/04/2015 10:04 AM, Monty Taylor wrote:

mordred@camelot:~$ neutron net-create test-net-mt
Policy doesn't allow create_network to be performed.

Thank you neutron. Excellent job.

Here's what that looks like at the REST layer:

DEBUG: keystoneclient.session RESP: [403] date: Fri, 04 Sep 2015 
13:55:47 GMT connection: close content-type: application/json; 
charset=UTF-8 content-length: 130 x-openstack-request-id: 
req-ba05b555-82f4-4aaf-91b2-bae37916498d
RESP BODY: {"NeutronError": {"message": "Policy doesn't allow 
create_network to be performed.", "type": "PolicyNotAuthorized", 
"detail": ""}}


As a user, I am not confused. I do not think that maybe I made a 
mistake with my credentials. The cloud in question simply does not 
allow user creation of networks. I'm fine with that. (as a user, that 
might make this cloud unusable to me - but that's a choice I can now 
make with solid information easily. Turns out, I don't need to create 
networks for my application, so this actually makes it easier for me 
personally)


In any case- rather than complaining and being a whiny brat about 
something that annoys me - I thought I'd say something nice about 
something that the neutron team has done that especially pleases me.


Then let my Hijack:

Policy is still broken.  We need the pieces of Dynamic policy.

I am going to call for a cross project policy discussion for the 
upcoming summit.  Please, please, please all the projects attend. The 
operators have made it clear they need better policy support.



I would love it if this became the experience across the board in 
OpenStack for times when a feature of the API is disabled by local 
policy. It's possible it already is and I just haven't directly 
experienced it - so please don't take this as a backhanded 
condemnation of anyone else.


Monty

__ 


OpenStack Development Mailing 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] [docs][networking-sfc]

2015-09-04 Thread Paul Carver



Can someone from the Docs team take a look at why there isn't a docs URL 
for the networking-sfc repo?


Compare [1] vs [2]
The first URL appears to be a rendering of the docs/source/index.rst 
from the Neutron Git repo, but the second one gives a Not Found even 
though there is a docs/source/index.rst in the networking-sfc repo.


If I've guessed the wrong URL, please let me know. I just guessed that 
replacing the name of the neutron repo in the URL with the name of the 
networking-sfc repo should have given me the right URL.


Compare [3] vs [4]

Both of these exist and as far as I can tell [1] is rendered from [3] 
and I would just naturally expect [2] to be rendered from [4] but it isn't.


[1] http://docs.openstack.org/developer/neutron/
[2] http://docs.openstack.org/developer/networking-sfc/
[3] 
https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/index.rst
[4] 
https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/index.rst


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

Re: [openstack-dev] [infra][third-party][CI] Third-party oses in devstack-gate

2015-09-04 Thread Evgeny Antyshev


On 01.09.2015 12:28, Evgeny Antyshev wrote:

Hello!

This letter I address to those third-party CI maintainers who needs to 
amend

the upstream devstack-gate to satisfy their environment.

Some folks that I know use inline patching at job level,
some make private forks of devstack-gate (I even saw one on github).
There have been a few improvements to devstack-gate, which made it 
easier to use it
downstream, f.e. introducing DEVSTACK_LOCAL_CONFIG 
(https://review.openstack.org/145321)


We particularly need it to recognize our rhel-based distribution as a 
Fedora OS.
We cannot define it explicitly in is_fedora() as it is not officially 
supported upstream,

but we can introduce the variable DEVSTACK_GATE_IS_FEDORA which makes
is_fedora() agnostic to distributions and to succeed if run on an 
undefined OS.


Here is the change: https://review.openstack.org/215029
I welcome everyone interested in the matter
to tell us if we do it right or not, and to review the change.


Prepending with [infra] tag to draw more attention

--
Best regards,
Evgeny Antyshev.


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

Re: [openstack-dev] [Openstack-operators] [Neutron] Allowing DNS suffix to be set per subnet (at least per tenant)

2015-09-04 Thread Ihar Hrachyshka

> On 04 Sep 2015, at 08:14, Daniel Comnea  wrote:
> 
> Kevin,
> 
> am i right in saying that the merge above was packaged into Liberty ?
> 
> Any chance to be ported to Juno?
> 

There is no chance a new feature will be backported to any stable branch, even 
Kilo. At least in upstream.

Ihar


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

Re: [openstack-dev] [Openstack] [ANN] OpenStack Kilo on Ubuntu fully automated with Ansible! Ready for NFV L2 Bridges via Heat!

2015-09-04 Thread Jose Manuel Ferrer Mosteiro

 

Hi 

It is a pre pre pre pre pre pre pre alpha version that just installs the
juno ubuntu guide until dashboard included. Block Storage Service is
very important but does not work now. 

vCenter will be always the operating system that makes my life easyer.
Today is Ubuntu. 

The hypervisor is also Ubuntu but it will be Ubuntu, CentOs and Debian. 

I will announce the project when the project is more advanced. 

Thanks 

On 2015-08-31 15:08, Sabrina Bajorat wrote: 

> That is great !!! Can it be use with Debian 7 too? 
> 
> Thanks 
> 
> On Mon, Aug 31, 2015 at 2:54 PM, Jose Manuel Ferrer Mosteiro 
>  wrote:
> 
> Nice job. I am doing a vmware vcenter like in 
> https://github.com/elmanytas/ansible-openstack-vcenter [1] and I solved the 
> problem of duplicate endpoints in line 106 of 
> https://github.com/elmanytas/ansible-openstack-vcenter/blob/master/etc_ansible/roles/keystone/tasks/main.yml
>  [2] . This makes playbooks idempotents. 
> 
> Maybe you could be interested. 
> 
> On 2015-08-26 00:30, Martinx - ジェームズ wrote: 
> Hello Stackers!
> 
> I'm proud to announce an Ansible Playbook to deploy OpenStack on Ubuntu!
> 
> Check it out!
> 
> * https://github.com/sandvine/os-ansible-deployment-lite [3]
> 
> Powered by Sandvine! ;-)
> 
> Basically, this is the automation of what we have documented here:
> 
> * http://docs.openstack.org/kilo/install-guide/install/apt/content/ [4]
> 
> Instructions:
> 
> 1- Install Ubuntu 14.04, fully upgraded (with
> "linux-generic-lts-vivid" installed), plus "/etc/hostname" and
> "/etc/hosts" configured according.
> 
> 2- Deploy OpenStack with 1 command:
> 
> * Open vSwtich (default):
> 
> bash <(curl -s
> https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh
>  [5])
> 
> * Linux Bridges (alternative):
> 
> bash <(curl -s
> https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install-lbr.sh
>  [6])
> 
> 3- Launch a NFV L2 Stack:
> 
> heat stack-create demo -f
> ~/os-ansible-deployment-lite/misc/os-heat-templates/nfv-l2-bridge-basic-stack-ubuntu-little.yaml
> 
> IMPORTANT NOTES:
> 
> Only runs the "step 2" on top of a fresh installed Ubuntu 14.04! Can
> be a Server or Desktop but, fresh installed. Do not pre-install MySQL,
> RabbitMQ, Keystone, etc... Let Ansible to its magic!
> 
> Also, make sure you can use "sudo" without password.
> 
> Some features of our Ansible Playbook:
> 
> 1- Deploys OpenStack with one single command, in one physical box
> (all-in-one), helper script (./os-deploy.sh) available;
> 
> 2- Supports NFV instances that can act as a L2 Bridge between two
> VXLAN Networks;
> 
> 3- Plenty of Heat Templates;
> 
> 4- 100% Ubuntu based;
> 
> 5- Very simple setup (simpler topology; dummy interfaces for both
> "br-ex" and "vxlan"; no containers for each service (yet));
> 
> 6- Ubuntu PPA available, with a few OpenStack patches backported from
> Liberty, to Kilo (to add "port_security_enabled" Heat support);
> 
> https://launchpad.net/~sandvine/+archive/ubuntu/cloud-archive-kilo/ [7]
> 
> 7- Only requires one physical ethernet card;
> 
> 8- Both "Linux Bridges" and "Open vSwitch" deployments are supported;
> 
> 9- Planning to add DPDK support;
> 
> 10- Multi-node support under development;
> 
> 11- IPv6 support comming...
> 
> * Notes about Vagrant support:
> 
> Under development (it doesn't work yet).
> 
> There is a preliminary Vagrant support (there is still a bug on MySQL
> startup, pull requests are welcome).
> 
> Just "git clone" our Ansible playbooks and run "vagrant up" (or
> ./os-deploy-vagrant.sh to auto-config your Ansible vars / files for
> you).
> 
> We tried it only with Mac / VirtualBox but, it does not support
> VT-in-VT (nested virtualization), so, we're looking for KVM / Libvirt
> on Ubuntu Desktop instead. But it would be nice to, at least, launch
> OpenStack in a VirtualBox on you Mac... =)
> 
> Hope you guys enjoy it!
> 
> Cheers!
> Thiago
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
> [8]
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
> [8]
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
> [8]
> Post to : openst...@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack 
> [8]
 

Links:
--
[1] https://github.com/elmanytas/ansible-openstack-vcenter
[2]
https://github.com/elmanytas/ansible-openstack-vcenter/blob/master/etc_ansible/roles/keystone/tasks/main.yml
[3] https://github.com/sandvine/os-ansible-deployment-lite
[4] http://docs.openstack.org/kilo/install-guide/install/apt/content/
[5]
https://raw.githubusercontent.com/sandvine/os-ansible-deployment-lite/kilo/misc/os-install.sh
[6]

Re: [openstack-dev] [Openstack-operators] [Neutron] Allowing DNS suffix to be set per subnet (at least per tenant)

2015-09-04 Thread Daniel Comnea

Kevin,

am i right in saying that the merge above was packaged into Liberty ?

Any chance to be ported to Juno?


Cheers,
Dani



On Fri, Sep 4, 2015 at 12:21 AM, Kevin Benton  wrote:

> Support for that blueprint already merged[1] so it's a little late to
> change it to per-subnet. If that is too fine-grained for your use-case, I
> would file an RFE bug[2] to allow it to be set at the subnet level.
>
>
> 1. https://review.openstack.org/#/c/200952/
> 2.
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#rfe-submission-guidelines
>
> On Thu, Sep 3, 2015 at 1:07 PM, Maish Saidel-Keesing 
> wrote:
>
>> On 09/03/15 20:51, Gal Sagie wrote:
>>
>> I am not sure if this address what you need specifically, but it would be
>> worth checking these
>> two approved liberty specs:
>>
>> 1)
>> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/internal-dns-resolution.rst
>> 2)
>> https://github.com/openstack/neutron-specs/blob/master/specs/liberty/external-dns-resolution.rst
>>
>> Thanks Gal,
>>
>> So I see that from the bp [1] the fqdn will be configurable for each and
>> every port ?
>>
>> I think that this does open up a number of interesting possibilities, but
>> I would also think that it would be sufficient to do this on a subnet level?
>>
>> We do already have the option of setting nameservers per subnet - I
>> assume the data model is already implemented - which is interesting  -
>> because I don't see that as part of the information that is sent by dnsmasq
>> so it must be coming from neutron somewhere.
>>
>> The domain suffix - definitely is handled by dnsmasq.
>>
>>
>>
>> On Thu, Sep 3, 2015 at 8:37 PM, Steve Wormley 
>> wrote:
>>
>>> As far as I am aware it is not presently built-in to Openstack. You'll
>>> need to add a dnsmasq_config_file option to your dhcp agent configurations
>>> and then populate the file with:
>>> domain=DOMAIN_NAME,CIDR for each network
>>> i.e.
>>> domain=example.com,10.11.22.0/24
>>> ...
>>>
>>> -Steve
>>>
>>>
>>> On Thu, Sep 3, 2015 at 1:04 AM, Maish Saidel-Keesing <
>>> mais...@maishsk.com> wrote:
>>>
 Hello all (cross-posting to openstack-operators as well)

 Today the setting of the dns suffix that is provided to the instance is
 passed through dhcp_agent.

 There is the option of setting different DNS servers per subnet (and
 and therefore tenant) but the domain suffix is something that stays the
 same throughout the whole system is the domain suffix.

 I see that this is not a current neutron feature.

 Is this on the roadmap? Are there ways to achieve this today? If so I
 would be very interested in hearing how.

 Thanks
 --
 Best Regards,
 Maish Saidel-Keesing


 __
 OpenStack Development Mailing 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
>>>
>>>
>>
>>
>> --
>> Best Regards ,
>>
>> The G.
>>
>>
>> --
>> Best Regards,
>> Maish Saidel-Keesing
>>
>> ___
>> OpenStack-operators mailing list
>> openstack-operat...@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
>
> --
> Kevin Benton
>
> ___
> 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

[openstack-dev] What's Up, Doc? 4 September, 2015

2015-09-04 Thread Lana Brindley

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi everyone,

This has been a fairly busy week, with Summit preparations beginning,
more newly migrated RST books going live, and testing starting on the
Install Guide. I've been spending time on sorting out the Liberty
blueprints still outstanding, and also working on some old bugs.

== Progress towards Liberty ==

40 days to go!

* RST conversion:
** Is now completed! Well done and a huge thank you to everyone who
converted pages, approved reviews, and participated in publishing the
new guides. This was a truly phenomenal effort :)

* User Guides information architecture overhaul
** Some user analysis has begun, and we have a new blueprint:
https://blueprints.launchpad.net/openstack-manuals/+spec/user-guides-reo
rganised

* Greater focus on helping out devs with docs in their repo
** A certain amount of progress has been made here, and some wrinkles
sorted out which will improve this process for the future.

* Improve how we communicate with and support our corporate contributors
** If you currently work on documentation for a company that would like
to improve their upstream commits for documentation, please contact me!

* Improve communication with Docs Liaisons
** I'm very pleased to see liaisons getting more involved in our bugs
and reviews. Keep up the good work!

* Clearing out old bugs
** The last lot of old bugs are still languishing. I'm assuming you all
hate them so very much that I've decided to give you three more to pick
from. Have at it!

== Countdown to Summit ==

With the Liberty release less than two months away, that means it's
nearly Summit time again: https://www.openstack.org/summit/tokyo-2015/

The schedule has now been released, congratulations to everyone who had
a talk accepted this time around:
https://www.openstack.org/summit/tokyo-2015/schedule/

All ATCs should have received their pass by now, so now is the time to
be booking your travel and accommodation:
https://www.openstack.org/summit/tokyo-2015/tokyo-and-travel/

== Conventions ==

A new governance patch has landed which changes the way we capitalise
service names (I know almost exactly 50% of you will be happy about
this!):
https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_pr
oject_names
Please be aware of this when editing files, and remember that the
'source of truth' for these things is the projects.yaml file:
http://git.openstack.org/cgit/openstack/governance/tree/reference/projec
ts.yaml

== Docs Tools ==

openstack-doc-tools 0.30.0 and openstackdocstheme 1.2.1 have been
released. openstack-doc-tools allows translation of the Install Guide.
openstackdocstheme contains fixes for the inclusion of metatags, removes
unused images and javascript files, and fixes the "Docs Home" link.

== Doc team meeting ==

The APAC meeting was not held this week. The minutes from the previous
US meeting are here:
https://wiki.openstack.org/wiki/Documentation/MeetingLogs#2015-08-26

The next meetings are:
US: Wednesday 9 September, 14:00:00 UTC
APAC: Wednesday 16 September, 00:30:00 UTC

Please go ahead and add any agenda items to the meeting page here:
https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_
meeting

== Spotlight bugs for this week ==

Let's give these three a little love:

https://bugs.launchpad.net/openstack-manuals/+bug/1280092 end user guide
lacks doc on admin password injection

https://bugs.launchpad.net/openstack-manuals/+bug/1282765 Chapter 6.
Block Storage in OpenStack Cloud Administrator Guide

https://bugs.launchpad.net/openstack-manuals/+bug/1284215 Driver for IBM
SONAS and Storwize V7000 Unified

- --

Remember, if you have content you would like to add to this newsletter,
or you would like to be added to the distribution list, please email me
directly at openst...@lanabrindley.com, or visit:
https://wiki.openstack.org/w/index.php?title=Documentation/WhatsUpDoc

Keep on doc'ing!

Lana

- -- 
Lana Brindley
Technical Writer
Rackspace Cloud Builders Australia
http://lanabrindley.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJV6TlFAAoJELppzVb4+KUy/zkIAKYKbKdw78Nv8dpB8d9Rj4qh
+JTK2rTlz/Up5F10OzIoJoNMIvySeKH+jHV1CP0qL9KigYaepkEeMn8RnNSayYww
cgSmk/8gpzGTTd17JK0Rrn+RjOb3XMYeNH2d4OkvIQPGBAYsnerODrvEK3GG7YHO
oo5xYSkLdYH54qnXhhvNZxjxDclT1P5QgpUP6M6KcB3bcKt4niHGLHnBHFoqvlMR
gJA1BtKR6CackhZbkJpPFCpEHimm4xdWwF+q7xRezy599MbkkPAIxR/oMuEkqU2H
zj+tm9sHDxOoH2j4Hfkbw7xxF+/NjvGtm41JCPsUVBxuAocaBbJ1kZRbbRzrafI=
=2TAI
-END PGP SIGNATURE-

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

Re: [openstack-dev] FFE Request for completion of data driven assignment testing in Keystone

2015-09-04 Thread Thierry Carrez

Morgan Fainberg wrote:
> 
>> I would like to request an FFE for the remaining two patches that
>> are already in review
>> (https://review.openstack.org/#/c/153897/ and 
>> https://review.openstack.org/#/c/154485/). 
>> These contain only test code and no functional changes, and
>> increase our test coverage - as well as enable other items to be
>> re-use the list_role_assignment backend method.
>>
>> Do we need a FFE for changes to tests?
>>
> 
> I would say "no". 

Right. Extra tests (or extra docs for that matter) don't count as a
"feature" for the freeze. In particular it doesn't change the behavior
of the software or invalidate testing that may have been conducted.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [infra][third-party][CI] Third-party oses in devstack-gate

2015-09-04 Thread Daniel Mellado

El 04/09/15 a las 08:11, Evgeny Antyshev escribió:
> On 01.09.2015 12:28, Evgeny Antyshev wrote:
>> Hello!
>>
>> This letter I address to those third-party CI maintainers who needs
>> to amend
>> the upstream devstack-gate to satisfy their environment.
>>
>> Some folks that I know use inline patching at job level,
>> some make private forks of devstack-gate (I even saw one on github).
>> There have been a few improvements to devstack-gate, which made it
>> easier to use it
>> downstream, f.e. introducing DEVSTACK_LOCAL_CONFIG
>> (https://review.openstack.org/145321)
>>
>> We particularly need it to recognize our rhel-based distribution as a
>> Fedora OS.
>> We cannot define it explicitly in is_fedora() as it is not officially
>> supported upstream,
>> but we can introduce the variable DEVSTACK_GATE_IS_FEDORA which makes
>> is_fedora() agnostic to distributions and to succeed if run on an
>> undefined OS.
>>
>> Here is the change: https://review.openstack.org/215029
>> I welcome everyone interested in the matter
>> to tell us if we do it right or not, and to review the change.
>>
> Prepending with [infra] tag to draw more attention
>
Personally I think that would be great, as it would greatly help finding
Fedora-ish issues with devstack, which are now only being raised by
developers due to the lack of a gate.

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

80 matches

Mail list logo