Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

[Ryan Rossiter]

> On Jan 28, 2016, at 5:01 PM, Dan Smith  wrote:
> 
>> I know we have some projects (heat, I think?) that don't have UUIDs at
>> all. Are they using oslo.versionedobjects? I suppose we could move them
>> to a string field instead of a UUID field, instead of flipping the
>> enforcement flag on. Alternately, if we add a new class we wouldn't have
>> to ever actually deprecate the UUIDField class, though we might add a
>> warning to the docs that it isn't doing any validation and the new class
>> is preferred.
> 
> If a project isn't using UUIDs then they have no reason to use a
> UUIDField and thus aren't affected. If they are, then they're doing
> something wrong.
> 
>> I'll be curious to see what Dan and Sean have to say when they catch up
>> on this thread.
> 
> I think Ryan summed it up very well earlier, but I will echo and
> elaborate here for clarity.
> 
> To be honest, I think the right thing to do is deprecate the
> non-validating behavior and have projects use in-project validating
> fields for UUIDs (i.e. their own UUIDField implementation). When we can,
> release a major version with the validating behavior turned on.
> 
> I don't like the validate=False flag because it's hard (or at least
> ugly) to deprecate. Even allowing the call signature to tolerate it for
> compatibility but still doing the validation is terrible, IMHO. If
> people feel it is absolutely critical to have an implementation in o.vo
> right now, then we can do the parallel class option, but we basically
> just have to alias the old one to the new one when we "drop" the
> non-validating functionality, IMHO, which is just more baggage. To quote
> Ryan, "if you know you're going to break people, just don't do it."
> 
> This is a really minor issue in my opinion -- the amount of code a
> project needs to replicate is exceedingly small, especially if they just
> subclass the existing field and override the one method required to
> ensure coercion. For a point of reference, nova has a lot of these
> fields which are too nova-specific to put into o.vo; adding one more for
> this is immeasurably small:
> 
> https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L76-L621
> 
> Cinder also has some already:
> 
> https://github.com/openstack/cinder/blob/master/cinder/objects/fields.py

You’re welcome for the extra Cinder evidence, Dan ;).

> 
> And to again echo Ryan's comments, we have always landed things in nova,
> sync'd them to o.vo and removed our local copy once we can depend on a
> new-enough o.vo release. This is effectively the same behavior for this
> change and really just isn't that big of a deal. Please, let's do the
> safest thing for the projects that consume our library, and for the
> people who have to use the same gate as all the rest of us.

For anyone who cares how this works, here’s a typical process for doing custom 
fields:

1) Put the field in Nova [1]
2) Put the new field in o.vo [2]
3) After o.vo is released, re-sync [3]

[1] 
https://github.com/openstack/nova/commit/b9247f52d17e18d075b995ac8a438ec5e65eacbf
[2] 
https://github.com/openstack/oslo.versionedobjects/commit/2e083bce6e4b325cb89baea4b1d6173d58c8f5bd
[3] 
https://github.com/openstack/nova/commit/3c83a47bb70ad9db6c7900e6c752f08777fa0787

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


-
Thanks,

Ryan Rossiter (rlrossit)


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

Re: [openstack-dev] [oslo] nominating Alexis Lee for oslo-core

[Doug Hellmann]

Excerpts from Davanum Srinivas (dims)'s message of 2016-01-29 06:17:39 -0600:
> Matt,
> 
> yes, that's a concern for sure. We work closely with all the new Oslo
> cores to defer to experts first and learn. This goes into the debate
> about the right mixture of Generalists and Specialists in the project
> as well.

Right. I trust everyone on the team to exercise judgment when
choosing which patches to review, and how to review them. I proposed
Alexis for oslo-core rather than oslo-config-core because his general
approach and collaboration on the config work he has already done
convinced me that my trust would not be misplaced. The fact that
we don't actually have a separate oslo-config-core group in gerrit
is an oversight, and didn't enter into it.

Doug

> 
> Thanks,
> Dims
> 
> On Fri, Jan 29, 2016 at 5:42 AM, Matt Riedemann
>  wrote:
> >
> >
> > On 1/29/2016 11:33 AM, Davanum Srinivas wrote:
> >>
> >> Matt,
> >>
> >> yes, Nomination is for oslo-core. We would like to expand the core
> >> group as well in addition to subject matter experts (example Dmitry
> >> Uklhov for Oslo.Messaging core yesterday). The hope and expectation is
> >> that Alexis would expand his reviews and expertise across all Oslo
> >> projects over a period of time.
> >>
> >> Thanks,
> >> Dims
> >>
> >> On Fri, Jan 29, 2016 at 5:24 AM, Matt Riedemann
> >>  wrote:
> >>>
> >>>
> >>>
> >>> On 1/28/2016 10:05 PM, Doug Hellmann wrote:
> 
> 
>  I am nominating Alexis Lee (lxsli) for oslo-core.
> 
>  Alexis has been working on adding configuration file reloading to
>  oslo.config this cycle. The work isn't complete, but at this point
>  he probably knows as much or more about the internals of that library
>  as any of us. :-) He has also shown, with some of his other recent
>  proposals, that he has a ideas for the future of configuration
>  management and an interest in contributing to Oslo.
> 
>  Please indicate yea or nay with the usual +1/-1 vote here.
> 
>  Doug
> 
> 
> 
>  http://stackalytics.com/?release=all_type=all=commits_id=alexisl
> 
> 
>  __
>  OpenStack Development Mailing List (not for usage questions)
>  Unsubscribe:
>  openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> >>>
> >>> As an outsider, this is just a question, but I don't see an
> >>> oslo-config-core
> >>> group. I'm assuming that because of lxsli's work on oslo.config this
> >>> nomination is coming up, but is the nomination for oslo-core, as in all
> >>> of
> >>> the oslo projects? Including things like oslo.versionedobjects and
> >>> oslo.messaging?
> >>>
> >>> I'm just wondering how things get broken down because there are obviously
> >>> subject matter experts in certain projects in oslo, but I wouldn't
> >>> consider
> >>> them as being cores across all projects just because they are core on
> >>> one.
> >>> Or am I misunderstanding?
> >>>
> >>> --
> >>>
> >>> 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
> >>
> >>
> >>
> >>
> >
> > So people are made core and then expected to become experts on the other
> > projects? I get that is a carrot, but it seems like that could put the stick
> > on the consuming projects if non-expert cores are approving changes they
> > shouldn't be.
> >
> > Anyway, my two cents...
> >
> >
> > --
> >
> > Thanks,
> >
> > Matt Riedemann
> >
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core reviewers

[Igor Marnat]

Folks,
I'm not a core reviewer, but if I was, I'd definitely vote with +1.

Good job, Anastasia! Keep going!

Regards,
Igor Marnat

On Fri, Jan 29, 2016 at 10:23 AM, Elisha, Moshe (Nokia - IL) <
moshe.eli...@nokia.com> wrote:

> A very big +1
> 
> From: Renat Akhmerov [rakhme...@mirantis.com]
> Sent: Friday, January 29, 2016 8:13 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to core
>  reviewers
>
> Team,
>
> I’d like to promote Anastasia Kuznetsova to the core team. What she’s been
> doing for 2 years is hard to overestimate. She’s done a huge amount of work
> reviewing code, bugfixing and participating in public discussions including
> our IRC channel #openstack-mistral. She is very reliable, diligent and
> consistent about her work.
>
> Please vote.
>
> Renat Akhmerov
> @ 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
>
__
OpenStack Development Mailing 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] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

I would not check that. We are not talking about installing browser plugins 
when users may not know what they want. Putting extra checks will create a more 
fool-proof but less configurable software. I’d vote for letting users shoot 
their feet using their plugins but making Fuel more flexible.


> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin  написав(ла):
> 
> > jsonpatch
> 
> There were +1's regarding overriding VIPs above. I'd stick with that. It is 
> done for tasks now. But we will need to check conflicts between plugins there 
> (as for tasks).
> 
> 
> Aleksey Kasatkin
> 
> 
> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  > wrote:
> Frankly, I have not though about how to deal with multiple plugins yet. 
> However, what I think is that we must not restrict this too much and let 
> users configure it more flexibly even if it allows to shoot one’s foot. 
> Perhaps we can add a per-cluster priority for enabled plugins which users can 
> configure via UI, CLI or API. My other thought is that we should not invent 
> our own mechanics for changing a configuration and use an existing one, say, 
> jsonpatch. What do you guys think?
> 
> P. S. [0] is really needed for 8.0 for implementing an important epic, so 
> please check it out. If it does not break anything, lets merge it ASAP.
> 
> - romcheg
> 
>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin > > написав(ла):
>> 
>> AFAIC, it is better to remove by name then. Otherwise, you do not know what 
>> VIPs you are removing.
>> Another option - remove "built-in" VIPs using some specific expression.
>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so you 
>> cannot remove them this way.
>> 
>> And the order of plugins processing is not defined so there is no warranty 
>> you will remove all VIPs on those network roles.
>> Seems, checking for such conflict between plugins is needed.
>> 
>> The original goal, actually, was to remove VIPs for controllers (or for some 
>> particular node role, maybe),
>> so we should maybe find a way to do exactly this.
>> 
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko > > wrote:
>> > How are we handling this now for multiple plugins?
>> 
>> OK, so right now we can only add VIPs to array, we can't remove them. So 
>> overriding would disable such possibility of adding VIPs from different 
>> plugins. But with [0] patch it will be still possible to add and to remove 
>> by providing empty array. But we'll have the problem with multiple plugins 
>> in such case.
>> I've changed my mind :) I vote for leaving as in [0] since it's less 
>> destructive comparing to what we have now.
>> 
>> Regards,
>> Alex
>> 
>> [0] https://review.openstack.org/#/c/273169/1 
>> 
>> 
>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko > > wrote:
>> Well, with merging instead of overriding, I believe, this problem with 
>> multiple plugins still exists, right? How are we handling this now for 
>> multiple plugins?
>> Since VIPs is array I also vote for overriding, since merging it could be a 
>> pain (how do you remove existing element during array merge?).
>> 
>> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin > > wrote:
>> Roman, please provide more details on how VIPs are overridden. And how do 
>> you deal with multiple plugins.
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin > > wrote:
>> Good idea, overally.
>> 
>> How about multiple plugins? We don't have any sequence or priorities between 
>> them.
>> What if one plugin assumes that VIP is present but other one wants to remove 
>> it?
>> 
>> 
>> Aleksey Kasatkin
>> 
>> 
>> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk > > wrote:
>> +1 to overriding VIPs
>> 
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>> 
>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin > > wrote:
>> +1 to overriding VIPs
>> 
>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko > > wrote:
>> Folks,
>> 
>> currently merge policy for network roles only allows to add new VIPs to 
>> already existing roles [1]. If a plugin supplies a VIP with a name that 
>> already exists but with different parameters, Nailgun will not allow to do 
>> that. We faced a need to override configuration of several VIPs by 
>> completely removing them from network roles by supplying something like [2]. 
>> To enable that I’ve made a temporary workaround [3] to 

Re: [openstack-dev] [ceilometer] :Regarding wild card configuration in pipeline.yaml

[gordon chung]

  I have a meter subscription m1.* for publisher p1 and I need a subset of m1.* 
 notifications for ex:m1.xyz.* for publisher p2.
If we add p2 to already exisiting sink along with p1,  p2 will get other 
notification's along with m1.xyz.* which are not needed for p2.

To avoid this we had the following entry in pipeline;

sources:
  -name : m1meter
   meters: m1.*,!m1.xyz.*
   sinks:
-m1sink
   .
  -name : m2meter
   meters:m1.xyz.*
   sinks:
-m2sink
sinks:
 -name: m1sink
  publishers:
   -p1

  -name: m2sink
  publishers:
   -p1
   -p2


you will unfortunately need to explicitly list out your required meters 
explicitly (without) wildcard.



>From reply mail it seems there is no strict restriction to support this.Could 
>you please let me know how should we handle such cases in ceilometer.
If we do code modification in pipeline module of ceilometer does it effects any 
other parts of ceilometer frame work.

the code filtering happens here: 
https://github.com/openstack/ceilometer/blob/master/ceilometer/pipeline.py#L275-L287
 and similarly in previous releases.

it will not affect anything other than pipeline filtering so it should be safe 
to change. you are welcome to push your change to community. as i mentioned 
previously, i don't think there is a restriction on having either wildcard or 
negative wildcard support in one pipeline. it was just how it was implemented 
as we did not have a requirement to deal with both (and the added complexity of 
ordering that comes with it)



--
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] [bug-smash] Global OpenStack Bug Smash Mitaka

[Doug Hellmann]

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

I know there is quite a lot of concern in the community about this
event being scheduled for the same dates as our feature freeze and
the Mitaka 3 milestone. I am working with the organizers to try to
reschedule. We will post more info here when we have it.

Doug

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

Re: [openstack-dev] [Fuel] Overriding and removing VIPs from plugins

[Igor Kalnitsky]

Roman P. wrote:
> Putting extra checks will create a more fool-proof but less configurable
> software. I’d vote for letting users shoot their feet using their plugins
> but making Fuel more flexible.

I won't agree here. You see, what if two plugins wants to override the
core network role? Consider that plugin A wants to extend VIPs:

id: "mgmt/vip"
default_mapping: "management"
properties:
  vip:
- name: "management"
  namespace: "haproxy"
# new VIP we want to add
- name: "myvip"
  namespace: "haproxy"

while plugin B wants to remove them:

id: "mgmt/vip"
default_mapping: "management"
properties:
  vip: []

How do you suppose to resolve this action? We don't know in which
order they will be resolved, and I'm strongly against unpredictable
situation (especiall it may be different time-to-time and depends on
which order plugins will be selected).

Moreover, it makes a little sense to try to resolve this situation. If
two plugins change something in core, they are probably incompatible.
Manual actions are required.

So that's, basically, why I think we should warn user about
incompatible changes to core stuff. Just like we do for deployment
tasks.

- igor

On Fri, Jan 29, 2016 at 4:18 PM, Roman Prykhodchenko  wrote:
> I would not check that. We are not talking about installing browser plugins
> when users may not know what they want. Putting extra checks will create a
> more fool-proof but less configurable software. I’d vote for letting users
> shoot their feet using their plugins but making Fuel more flexible.
>
>
> 29 січ. 2016 р. о 15:05 Aleksey Kasatkin 
> написав(ла):
>
>> jsonpatch
>
> There were +1's regarding overriding VIPs above. I'd stick with that. It is
> done for tasks now. But we will need to check conflicts between plugins
> there (as for tasks).
>
>
> Aleksey Kasatkin
>
>
> On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  wrote:
>>
>> Frankly, I have not though about how to deal with multiple plugins yet.
>> However, what I think is that we must not restrict this too much and let
>> users configure it more flexibly even if it allows to shoot one’s foot.
>> Perhaps we can add a per-cluster priority for enabled plugins which users
>> can configure via UI, CLI or API. My other thought is that we should not
>> invent our own mechanics for changing a configuration and use an existing
>> one, say, jsonpatch. What do you guys think?
>>
>> P. S. [0] is really needed for 8.0 for implementing an important epic, so
>> please check it out. If it does not break anything, lets merge it ASAP.
>>
>> - romcheg
>>
>> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
>> написав(ла):
>>
>> AFAIC, it is better to remove by name then. Otherwise, you do not know
>> what VIPs you are removing.
>> Another option - remove "built-in" VIPs using some specific expression.
>> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
>> you cannot remove them this way.
>>
>> And the order of plugins processing is not defined so there is no warranty
>> you will remove all VIPs on those network roles.
>> Seems, checking for such conflict between plugins is needed.
>>
>> The original goal, actually, was to remove VIPs for controllers (or for
>> some particular node role, maybe),
>> so we should maybe find a way to do exactly this.
>>
>>
>>
>> Aleksey Kasatkin
>>
>>
>> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
>> wrote:
>>>
>>> > How are we handling this now for multiple plugins?
>>>
>>> OK, so right now we can only add VIPs to array, we can't remove them. So
>>> overriding would disable such possibility of adding VIPs from different
>>> plugins. But with [0] patch it will be still possible to add and to remove
>>> by providing empty array. But we'll have the problem with multiple plugins
>>> in such case.
>>> I've changed my mind :) I vote for leaving as in [0] since it's less
>>> destructive comparing to what we have now.
>>>
>>> Regards,
>>> Alex
>>>
>>> [0] https://review.openstack.org/#/c/273169/1
>>>
>>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko
>>>  wrote:

 Well, with merging instead of overriding, I believe, this problem with
 multiple plugins still exists, right? How are we handling this now for
 multiple plugins?
 Since VIPs is array I also vote for overriding, since merging it could
 be a pain (how do you remove existing element during array merge?).

 On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin
  wrote:
>
> Roman, please provide more details on how VIPs are overridden. And how
> do you deal with multiple plugins.
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin
>  wrote:
>>
>> Good idea, overally.
>>
>> How 

[openstack-dev] [glance] Virtual Mid-Cycle meeting next week

[Flavio Percoco]

Greetings,

As promissed (although I promissed it yday), here's the link to vote for the
days you'd like the Glance Virtual Midcycle to happen. We'll be meeting just for
2 days and at maximum for 3 hours. The 2 days with more votes are the ones that
will be picked. Since there's such a short notice, I'll be actively pinging you
all and I'll close the vote on Monday Feb 1st.

http://doodle.com/poll/eck5hr5d746fdxh6

Thank you all for jumping in with such a short notice,
Flavio

P.S: I'll be sending the details of the meeting out with the invitation.

--
@flaper87
Flavio Percoco


signature.asc
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] [Fuel] Overriding and removing VIPs from plugins

[Aleksey Kasatkin]

> jsonpatch

There were +1's regarding overriding VIPs above. I'd stick with that. It is
done for tasks now. But we will need to check conflicts between plugins
there (as for tasks).


Aleksey Kasatkin


On Fri, Jan 29, 2016 at 1:23 PM, Roman Prykhodchenko  wrote:

> Frankly, I have not though about how to deal with multiple plugins yet.
> However, what I think is that we must not restrict this too much and let
> users configure it more flexibly even if it allows to shoot one’s foot.
> Perhaps we can add a per-cluster priority for enabled plugins which users
> can configure via UI, CLI or API. My other thought is that we should not
> invent our own mechanics for changing a configuration and use an existing
> one, say, jsonpatch. What do you guys think?
>
> P. S. [0] is really needed for 8.0 for implementing an important epic, so
> please check it out. If it does not break anything, lets merge it ASAP.
>
> - romcheg
>
> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin 
> написав(ла):
>
> AFAIC, it is better to remove by name then. Otherwise, you do not know
> what VIPs you are removing.
> Another option - remove "built-in" VIPs using some specific expression.
> Anyway, you do not know where other VIPs (VIPs of other plugins) live so
> you cannot remove them this way.
>
> And the order of plugins processing is not defined so there is no warranty
> you will remove all VIPs on those network roles.
> Seems, checking for such conflict between plugins is needed.
>
> The original goal, actually, was to remove VIPs for controllers (or for
> some particular node role, maybe),
> so we should maybe find a way to do exactly this.
>
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko 
> wrote:
>
>> > How are we handling this now for multiple plugins?
>>
>> OK, so right now we can only add VIPs to array, we can't remove them. So
>> overriding would disable such possibility of adding VIPs from different
>> plugins. But with [0] patch it will be still possible to add and to remove
>> by providing empty array. But we'll have the problem with multiple plugins
>> in such case.
>> I've changed my mind :) I vote for leaving as in [0] since it's less
>> destructive comparing to what we have now.
>>
>> Regards,
>> Alex
>>
>> [0] https://review.openstack.org/#/c/273169/1
>>
>> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko > > wrote:
>>
>>> Well, with merging instead of overriding, I believe, this problem with
>>> multiple plugins still exists, right? How are we handling this now for
>>> multiple plugins?
>>> Since VIPs is array I also vote for overriding, since merging it could
>>> be a pain (how do you remove existing element during array merge?).
>>>
>>> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin <
>>> akasat...@mirantis.com> wrote:
>>>
 Roman, please provide more details on how VIPs are overridden. And how
 do you deal with multiple plugins.


 Aleksey Kasatkin


 On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin <
 akasat...@mirantis.com> wrote:

> Good idea, overally.
>
> How about multiple plugins? We don't have any sequence or priorities
> between them.
> What if one plugin assumes that VIP is present but other one wants to
> remove it?
>
>
> Aleksey Kasatkin
>
>
> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> +1 to overriding VIPs
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin <
>> vkuk...@mirantis.com> wrote:
>>
>>> +1 to overriding VIPs
>>>
>>> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko 
>>> wrote:
>>>
 Folks,

 currently merge policy for network roles only allows to add new
 VIPs to already existing roles [1]. If a plugin supplies a VIP with a 
 name
 that already exists but with different parameters, Nailgun will not 
 allow
 to do that. We faced a need to override configuration of several VIPs 
 by
 completely removing them from network roles by supplying something like
 [2]. To enable that I’ve made a temporary workaround [3] to the merging
 policy that only handles one cornerstone.

 I’ve talked to ikalnitsky and we realized that this functionality
 of merging new VIPs from plugins to an existing network role is 
 actually
 wrong and should be replaced by complete overriding. Let’s discuss this
 possibility here.


 References:

 1.
 https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
 2. http://xsnippet.org/361361/
 3. 

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

[gordon chung]

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

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

cheers,

-- 
gord


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

[openstack-dev] [Fuel] [Fuel UI] UI text guidelines

[Olga Gusarenko]

Good Friday to everyone!

This is just to inform you that UI text guidelines are now available in the
Contributor Guide:

http://docs.openstack.org/contributor-guide/ui-text-guidelines.html

This will be interesting for designers and developers, as well as
reviewers, who works on OpenStack user interfaces. Please follow these
recommendations to ensure UI usability and consistency.

Special thanks to Linette Williams and Gudrun Wolfgram for working on this!

-- 
Best regards,
Olga Gusarenko

Technical Writer | Mirantis, Kharkiv | 38, Lenin av., Kharkiv, Ukraine
ogusare...@mirantis.com | skype: gusarenko.olga
__
OpenStack Development Mailing 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][API]what's the purpose of fping in nova API?

[Chen CH Ji]

 In doing some API work on http://developer.openstack.org/api-ref-compute-v2.1.htmlnoticed that fping was [1] and try to ping the instance to check whether it's pingable or not..but this is running on API service host which mostly have no access to instance with private IP?Just curious about it ...[1] https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/fping.py#L53


__
OpenStack Development Mailing 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] [Fuel] [Fuel UI] UI text guidelines

[Vitaly Kramskikh]

Olga,

That's awesome! This document will help us a lot. Thanks for your work!

2016-01-29 17:01 GMT+03:00 Olga Gusarenko :

> Good Friday to everyone!
>
> This is just to inform you that UI text guidelines are now available in
> the Contributor Guide:
>
> http://docs.openstack.org/contributor-guide/ui-text-guidelines.html
>
> This will be interesting for designers and developers, as well as
> reviewers, who works on OpenStack user interfaces. Please follow these
> recommendations to ensure UI usability and consistency.
>
> Special thanks to Linette Williams and Gudrun Wolfgram for working on this!
>
> --
> Best regards,
> Olga Gusarenko
>
> Technical Writer | Mirantis, Kharkiv | 38, Lenin av., Kharkiv, Ukraine
> ogusare...@mirantis.com | skype: gusarenko.olga
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Vitaly Kramskikh,
Fuel UI Tech Lead,
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] [Nova][Neutron] Scheduling with routed networks

[Armando M.]

On 29 January 2016 at 12:16, Jay Pipes  wrote:

> On 01/28/2016 09:15 PM, Carl Baldwin wrote:
>
>> Hi Nova and Neutron,
>>
>> It was a pleasure to attend the Nova mid-cycle in Bristol this week.
>>
>
> Indeed, I thought the mid-cycle was super-productive.


Yup, I always thought that Nova folks had tails, horns and pitchforks...it
turns out I was wrong!


>
>
> I think we made a lot of progress.  I spent a little time capturing
>> the highlights of what we discussed about scheduling and routed
>> networks in a new revision to the backlog spec [1] that I created a
>> couple of weeks ago.
>>
>> I also captured my understanding of the discussion we had this
>> afternoon as things were winding down.  I remember Jay Pipes, Andrew
>> Laskey, Dan Smith, John Garbutt, and Armando Migliaccio actively
>> participating in that discussion with me.  I would appreciate it if
>> you could visit this spec and record any thoughts or conclusions that
>> I might have missed or mis-understood.
>>
>
> Will do for sure. I'll also keep you updated on the progress of the
> generic-resource-pools work which intersects with the routed networks
> features.
>

It's my intention of going over the spec whilst my memory is fresh...I need
some _light reading_ for my journey back anyway :)

Cheers,
Armando


>
> Best,
> -jay
>
>
> Thanks,
>> Carl Baldwin
>>
>> [1] https://review.openstack.org/#/c/263898/
>>
>> __
>> OpenStack Development Mailing 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] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Martinx - ジェームズ]

Oh, that's okay... Thanks guys!:)

On 29 January 2016 at 06:39, Sergey Kraynev  wrote:
> Sean, thank you for the spotting.
>
> Martinx, According to the information mentioned by Sean, we unfortunately
> can not do it :(
>
> On 29 January 2016 at 10:45, Sean M. Collins  wrote:
>>
>> Kilo is in the "security supported" stage of the lifecycle. So no,
>> that's not going to get backported.
>>
>> http://docs.openstack.org/releases/index.html
>> --
>> Sean M. Collins
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Regards,
> Sergey.
>
> __
> OpenStack Development Mailing 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] Announcing Ekko -- Scalable block-based backup for OpenStack

[Fausto Marzi]

What motivates me every day and every night, is to provide the most
advanced solution for a set a problems to solve, Open Source and in
OpenStack. What motivates me is to work with brilliant people like minded,
capable of doing great things working together. It is not the competition
and It is not the PTL or Core label that gives you that.

In OpenStack most of the time, new project born because there's a group of
people in a company that needs to provide a solution for a set of problems,
and the same people/company allocate resources, time and efforts. Now if
every company start his own project, we are likely to going to have many
individual tools to provide a similar set of solutions. Is this what we
want? I hope not.

Starting new projects is a tremendously hard work and with limited
resources most of the time. So why not join, work as a community, provide a
remarkable service/tool and secure the result for who decide to use
OpenStack.

We have to do the effort of trying hard to work together, smooth
differences, improve others rather than block them. Honestly as a PTL I try
to do that, every single bloody day, dealing with managers, companies,
customers, engineers, code, bugs and community. However I do not think a
PTL should be elected 2 consecutive times, for official projects, because
it's a great experience that anyone that deserve it, should learn from. But
this is just my opinion.

That said, what we are trying to do, with Sam (that is showing an open
attitude and constructive approach), is to understand if the solution make
sense itself, if we can work together as a Team and if it make sense to
include it in Freezer. If not, it is crystal clear, that no one in the
world, can stop a very committed and capable person to do what he/she wants
to do. Even less in the Open Source and here. We probably need to avoid
fragmentation and at the same time no limiting new ideas, but potentiate
them.

Happy to hear your thoughts on this.

Thanks,
Fausto



On Thu, Jan 28, 2016 at 8:55 PM, Ian Wells  wrote:

> On 27 January 2016 at 11:06, Flavio Percoco  wrote:
>
>> FWIW, the current governance model does not prevent competition. That's
>> not to
>> be understood as we encourage it but rather than there could be services
>> with
>> some level of overlap that are still worth being separate.
>>
>
> There should always be the possibility to compete; it's always possible
> that rethinking an idea produces a better implementation of the same API.
> But we don't separate API from implementation in Openstack - the 'XXX API'
> cannot easily be divorced from the project containing the implementation
> when the definition of the 'XXX API' is 'the API implemented by the XXX
> code'.  We should separate them - the API is the only thing that a tenant
> will ever actually care about, not the implementation choice behind it.
>
> What Jay is referring to is that regardless the projects do similar
>> things, the
>> same or totally different things, we should strive to have different
>> APIs. The
>> API shouldn't overlap in terms of endpoints and the way they are exposed.
>>
>
> And for this, perhaps we should have an API namespace registry, so that
> when two groups implement the same endpoints they have to implement the
> same API?  I think Jay's point is that we muddy the waters here by having
> confusingly similar-but-different APIs.
>
> [The counterargument is that service discovery usually determines what API
> you're getting, so that if two services claim to be different service types
> in Keystone then they are *not* the same API and should be allowed free
> reign of their URI namespace, but I see that's not working for us.]
>
> And, coming back to the original point, if Freezer and Ekko both implement
> backups, and they can come to an agreement on what 'a backup' is and an API
> definition for it, that means that they could exist as independent projects
> with independent codebases that both implement /backup - but, importantly,
> in a consistent way that doesn't confuse app developers.  That will only
> work if the API definition stands separate from the projects, though.
>
> --
> Ian.
>
> __
> OpenStack Development Mailing 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] [tripleo] use mitaka CI tested repo

[Dan Prince]

On Fri, 2016-01-29 at 08:17 -0500, Emilien Macchi wrote:
> Hi,
> 
> I'm wondering why don't we use Mitaka CI tested repository [1].
> IIRC, TripleO is currently using a snapshot which is updated
> asynchronously by TripleO CI folks.
> The problem is that we're not consistent with what RDO CI is testing.
> In
> my memory and tell me if I'm wrong but it happens we're using an old
> snapshot of packages which is older that is actually tested &
> verified
> by RDO CI.
> 
> The benefit of using this tested repo would be:
> * this repository is already gated by Weirdo [2] which is running the
> same jobs as Puppet OpenStack CI.
> * you would not have less jobs failures, because RDO CI would have
> detected bugs before.
> * tripleo folks could focus a bit more on features & bugfixes in
> TripleO
> itself, rather than debugging CI issues and slowing down the review
> process.
> * Puppet OpenStack CI became really stable since we're using this
> repository. We have a very few number of issues since then.
> 
> Though, something I don't like in my proposal:
> * tripleo would not bring short feedback to RDO folks if something is
> broken
> 
> But is TripleO supposed to debug other projects in the same time?
> Don't
> we have enough challenges in our project?
> 
> This would be a temporary solution I think, until TripleO would be
> part
> of other upstream project gate (nova, etc) maybe one day.
> But at this time, I honestly think TripleO (which is an installer)
> folks, spend too much time at debugging CI for some reasons that are
> related to projects outside tripleo (puppet modules, openstack bugs,
> packaging issues, etc).
> 
> This is just a proposal and an idea to help TripleO folks to focus on
> their review process, instead of debugging CI failures every week.

The problem I think is largly due to the fact that the RDO CI doesn't
test the same things we do in the TripleO CI. It is essentially a
different CI system.

Because the CI systems are different different breakages happen when
you try to update one component vs. another. This is why we have to
maintain 'current-tripleo' separately between RDO and TripleO.

I agree it would be nice if we could consolidate on a single repository
across these projects. It would allow us to focus on review more...
(less CI fixing).

Perhaps a test matrix comparing the two CI systems would help us get
them closer to parity with what is covered. Even better would be just
simply contributing to the same CI systems and scripts.

Dan

> 
> 
> Thanks for reading so far.
> Your feedback and comments are more than welcome.
> 
> [1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.re
> po
> [2] https://github.com/redhat-openstack/weirdo
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> 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] [Fuel] [Fuel UI] Node role list grouping

[Bogdan Dobrelya]

On 29.01.2016 13:35, Vladimir Kuklin wrote:
>> We removed role as abstraction from library. It's very very artificial
>> abstraction. Instead we use tasks, grouping them to different
>> combinations. That allows plugin developers to adjust reference
>> architecture to their needs.

I only replied to that. We did not remove role as abstraction

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] [Rally] Failure running rally unit tests

[Sudhir Verma]

Hi,

I am running the rally test 
https://github.com/openstack/rally/blob/master/tests/unit/test_osclients.py#L87 
there is a function "test_create_keystone_client_v2"
when i am testing that function i am getting an error i.e: 
"keystoneclient.openstack.common.apiclient.exceptions.ConnectionRefused: Unable 
to establish connection to http://auth_url;

The error is:
http://paste.openstack.org/show/485380/

Thanks & Regards,
Sudhir Verma

__
OpenStack Development Mailing 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] [Fuel] [Fuel UI] Node role list grouping

[Julia Aranovich]

Sergii,

Just to clarify: we rely on a role 'limits' attribute [1] to define is role
required for deployment ('min' limit presented in the role description) or
recommended for deployment ('recommended' limit). Roles without 'min' or
'recommended' limit are considered as optional for basic deployment.

[1]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L23-L24


On Fri, Jan 29, 2016 at 1:27 PM Vladimir Kuklin 
wrote:

> Sergii
>
> I disagree with you here a little bit. Role abstraction is a useful thing
> from high-level standpoint. I would suggest that this list of roles
> grouping, e.g. which roles are mandatory and which are configured within
> which group can be specified:
>
> 1) in global settings of Nailgun
> 2) per-plugin
> 3) per environment in UI
>
> This should cover all the cases even for very flexible roles allocation.
>
> On Fri, Jan 29, 2016 at 12:58 PM, Sergii Golovatiuk <
> sgolovat...@mirantis.com> wrote:
>
>> Hi,
>>
>>
>> On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich > > wrote:
>>
>>> Hi folks,
>>>
>>> Our team has started a redesign of node roles panel [1] on Add
>>> Nodes/Edit Roles screens in Fuel UI.
>>> Currently, node roles panel takes a big part of the screen and User have
>>> to scroll down to node list to check nodes and then scroll up again to
>>> check roles. This becomes more actual for desktops with a small screen.
>>>
>>> And we faced with the question of grouping new role containers in the
>>> panel. There is out initial suggestion [2]:
>>>
>>> [image: role-list-grouping-1.png]
>>>
>>>- the first group (the first line on the screenshot) is roles which
>>>are required or recommended for deployment (controller, compute, cinder,
>>>etc.).
>>>
>>> It's not true. There can be deployments without Controllers or without
>> computes or without Storage.
>>
>>>
>>>- the second group is optional roles which are not mandatory for
>>>deployment (base-os, virt, etc.)
>>>- the last group is roles which are unavailable at the moment
>>>because of some restrictions. For example, mongo role can not be assigned
>>>to a node if ceilometer setting is not enabled on Settings tab
>>>
>>> BUT there is also a suggestion [3] (see comment #6) to add a new role
>>> 'category' attribute into its yaml description [4] that will reflect the
>>> role function.
>>> For example, cinder, ceph-osd, cinder-vmware roles are from Storage
>>> category; compute, ironic are Compute and so on.
>>> This new 'category' attribute will also allow proper calculating of an
>>> environment capacity: it does not make sense to count CPU and RAM of
>>> non-compute nodes or HDD of non-storage nodes.
>>>
>>> So, we have an initial proposal for such a grouping by a role category:
>>>
>>> CONTROLLER: controller
>>> COMPUTE: compute, virt, compute-vmware, ironic
>>> STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
>>> OTHER: base-os, mongo
>>>
>>> And we ask your help to review this grouping, i.e. to define the list of
>>> possible role categories and to distribute the roles between these
>>> categories.
>>>
>>
>> We removed role as abstraction from library. It's very very artificial
>> abstraction. Instead we use tasks, grouping them to different combinations.
>> That allows plugin developers to adjust reference architecture to their
>> needs.
>>
>>
>>>
>>> Best regards,
>>> Julia
>>>
>>> P.S. We also should take into account, that Fuel plugins can also
>>> provide their own roles.
>>>
>>> [1]
>>> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
>>> [2]
>>> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
>>> [3] https://bugs.launchpad.net/fuel/+bug/1375750
>>> [4]
>>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
>>>
>>>
>>>
>>> __
>>> OpenStack Development Mailing 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
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [oslo] nominating Alexis Lee for oslo-core

[Matt Riedemann]

On 1/28/2016 10:05 PM, Doug Hellmann wrote:

I am nominating Alexis Lee (lxsli) for oslo-core.

Alexis has been working on adding configuration file reloading to
oslo.config this cycle. The work isn't complete, but at this point
he probably knows as much or more about the internals of that library
as any of us. :-) He has also shown, with some of his other recent
proposals, that he has a ideas for the future of configuration
management and an interest in contributing to Oslo.

Please indicate yea or nay with the usual +1/-1 vote here.

Doug

http://stackalytics.com/?release=all_type=all=commits_id=alexisl

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



As an outsider, this is just a question, but I don't see an 
oslo-config-core group. I'm assuming that because of lxsli's work on 
oslo.config this nomination is coming up, but is the nomination for 
oslo-core, as in all of the oslo projects? Including things like 
oslo.versionedobjects and oslo.messaging?


I'm just wondering how things get broken down because there are 
obviously subject matter experts in certain projects in oslo, but I 
wouldn't consider them as being cores across all projects just because 
they are core on one. Or am I misunderstanding?


--

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] [oslo] nominating Alexis Lee for oslo-core

[Matt Riedemann]

On 1/29/2016 11:33 AM, Davanum Srinivas wrote:

Matt,

yes, Nomination is for oslo-core. We would like to expand the core
group as well in addition to subject matter experts (example Dmitry
Uklhov for Oslo.Messaging core yesterday). The hope and expectation is
that Alexis would expand his reviews and expertise across all Oslo
projects over a period of time.

Thanks,
Dims

On Fri, Jan 29, 2016 at 5:24 AM, Matt Riedemann
 wrote:



On 1/28/2016 10:05 PM, Doug Hellmann wrote:


I am nominating Alexis Lee (lxsli) for oslo-core.

Alexis has been working on adding configuration file reloading to
oslo.config this cycle. The work isn't complete, but at this point
he probably knows as much or more about the internals of that library
as any of us. :-) He has also shown, with some of his other recent
proposals, that he has a ideas for the future of configuration
management and an interest in contributing to Oslo.

Please indicate yea or nay with the usual +1/-1 vote here.

Doug


http://stackalytics.com/?release=all_type=all=commits_id=alexisl

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



As an outsider, this is just a question, but I don't see an oslo-config-core
group. I'm assuming that because of lxsli's work on oslo.config this
nomination is coming up, but is the nomination for oslo-core, as in all of
the oslo projects? Including things like oslo.versionedobjects and
oslo.messaging?

I'm just wondering how things get broken down because there are obviously
subject matter experts in certain projects in oslo, but I wouldn't consider
them as being cores across all projects just because they are core on one.
Or am I misunderstanding?

--

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






So people are made core and then expected to become experts on the other 
projects? I get that is a carrot, but it seems like that could put the 
stick on the consuming projects if non-expert cores are approving 
changes they shouldn't be.


Anyway, my two cents...

--

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] [Fuel] [Fuel UI] Node role list grouping

[Bogdan Dobrelya]

On 29.01.2016 10:58, Sergii Golovatiuk wrote:
> Hi,
> 
> 
> On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich
> > wrote:
> 
> Hi folks,
> 
> Our team has started a redesign of node roles panel [1] on Add
> Nodes/Edit Roles screens in Fuel UI.
> Currently, node roles panel takes a big part of the screen and User
> have to scroll down to node list to check nodes and then scroll up
> again to check roles. This becomes more actual for desktops with a
> small screen.
> 
> And we faced with the question of grouping new role containers in
> the panel. There is out initial suggestion [2]:
> 
> role-list-grouping-1.png
> 
>   * the first group (the first line on the screenshot) is roles
> which are required or recommended for deployment (controller,
> compute, cinder, etc.).
> 
> It's not true. There can be deployments without Controllers or without
> computes or without Storage. 
> 
>   * the second group is optional roles which are not mandatory for
> deployment (base-os, virt, etc.)
>   * the last group is roles which are unavailable at the moment
> because of some restrictions. For example, mongo role can not be
> assigned to a node if ceilometer setting is not enabled on
> Settings tab
> 
> BUT there is also a suggestion [3] (see comment #6) to add a new
> role 'category' attribute into its yaml description [4] that will
> reflect the role function.
> For example, cinder, ceph-osd, cinder-vmware roles are from Storage
> category; compute, ironic are Compute and so on.
> This new 'category' attribute will also allow proper calculating of
> an environment capacity: it does not make sense to count CPU and RAM
> of non-compute nodes or HDD of non-storage nodes.
> 
> So, we have an initial proposal for such a grouping by a role category:
> 
> CONTROLLER: controller
> COMPUTE: compute, virt, compute-vmware, ironic
> STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
> OTHER: base-os, mongo
> 
> And we ask your help to review this grouping, i.e. to define the
> list of possible role categories and to distribute the roles between
> these categories.
> 
> 
> We removed role as abstraction from library. It's very very artificial
> abstraction. Instead we use tasks, grouping them to different
> combinations. That allows plugin developers to adjust reference
> architecture to their needs.

That seems *very* confusing as all role labels are still sitting at
their places in task definitions. See for 'primary-controller',
'controller', 'compute' etc. We can say we "dropped" only once we:
- get rid of them in *all* places
- update task schema docs [0] lagging far behind, which is the most
critical thing to remove confusion, see related topic [1]

[0]
https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment
[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-January/085208.html

>  
> 
> 
> Best regards,
> Julia
> 
> P.S. We also should take into account, that Fuel plugins can also
> provide their own roles.
> 
> [1] 
> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
> [2] 
> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
> [3] https://bugs.launchpad.net/fuel/+bug/1375750
> [4] 
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
> 
> 
> __
> OpenStack Development Mailing 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,
Bogdan Dobrelya,
Irc #bogdando

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

Re: [openstack-dev] [oslo] nominating Alexis Lee for oslo-core

[Davanum Srinivas]

Matt,

yes, that's a concern for sure. We work closely with all the new Oslo
cores to defer to experts first and learn. This goes into the debate
about the right mixture of Generalists and Specialists in the project
as well.

Thanks,
Dims

On Fri, Jan 29, 2016 at 5:42 AM, Matt Riedemann
 wrote:
>
>
> On 1/29/2016 11:33 AM, Davanum Srinivas wrote:
>>
>> Matt,
>>
>> yes, Nomination is for oslo-core. We would like to expand the core
>> group as well in addition to subject matter experts (example Dmitry
>> Uklhov for Oslo.Messaging core yesterday). The hope and expectation is
>> that Alexis would expand his reviews and expertise across all Oslo
>> projects over a period of time.
>>
>> Thanks,
>> Dims
>>
>> On Fri, Jan 29, 2016 at 5:24 AM, Matt Riedemann
>>  wrote:
>>>
>>>
>>>
>>> On 1/28/2016 10:05 PM, Doug Hellmann wrote:


 I am nominating Alexis Lee (lxsli) for oslo-core.

 Alexis has been working on adding configuration file reloading to
 oslo.config this cycle. The work isn't complete, but at this point
 he probably knows as much or more about the internals of that library
 as any of us. :-) He has also shown, with some of his other recent
 proposals, that he has a ideas for the future of configuration
 management and an interest in contributing to Oslo.

 Please indicate yea or nay with the usual +1/-1 vote here.

 Doug



 http://stackalytics.com/?release=all_type=all=commits_id=alexisl


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

>>>
>>> As an outsider, this is just a question, but I don't see an
>>> oslo-config-core
>>> group. I'm assuming that because of lxsli's work on oslo.config this
>>> nomination is coming up, but is the nomination for oslo-core, as in all
>>> of
>>> the oslo projects? Including things like oslo.versionedobjects and
>>> oslo.messaging?
>>>
>>> I'm just wondering how things get broken down because there are obviously
>>> subject matter experts in certain projects in oslo, but I wouldn't
>>> consider
>>> them as being cores across all projects just because they are core on
>>> one.
>>> Or am I misunderstanding?
>>>
>>> --
>>>
>>> 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
>>
>>
>>
>>
>
> So people are made core and then expected to become experts on the other
> projects? I get that is a carrot, but it seems like that could put the stick
> on the consuming projects if non-expert cores are approving changes they
> shouldn't be.
>
> Anyway, my two cents...
>
>
> --
>
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

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

Re: [openstack-dev] [Nova][Neutron] Scheduling with routed networks

[Jay Pipes]

On 01/28/2016 09:15 PM, Carl Baldwin wrote:

Hi Nova and Neutron,

It was a pleasure to attend the Nova mid-cycle in Bristol this week.


Indeed, I thought the mid-cycle was super-productive.


I think we made a lot of progress.  I spent a little time capturing
the highlights of what we discussed about scheduling and routed
networks in a new revision to the backlog spec [1] that I created a
couple of weeks ago.

I also captured my understanding of the discussion we had this
afternoon as things were winding down.  I remember Jay Pipes, Andrew
Laskey, Dan Smith, John Garbutt, and Armando Migliaccio actively
participating in that discussion with me.  I would appreciate it if
you could visit this spec and record any thoughts or conclusions that
I might have missed or mis-understood.


Will do for sure. I'll also keep you updated on the progress of the 
generic-resource-pools work which intersects with the routed networks 
features.


Best,
-jay


Thanks,
Carl Baldwin

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

__
OpenStack Development Mailing 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] [tripleo] use mitaka CI tested repo

[Emilien Macchi]

Hi,

I'm wondering why don't we use Mitaka CI tested repository [1].
IIRC, TripleO is currently using a snapshot which is updated
asynchronously by TripleO CI folks.
The problem is that we're not consistent with what RDO CI is testing. In
my memory and tell me if I'm wrong but it happens we're using an old
snapshot of packages which is older that is actually tested & verified
by RDO CI.

The benefit of using this tested repo would be:
* this repository is already gated by Weirdo [2] which is running the
same jobs as Puppet OpenStack CI.
* you would not have less jobs failures, because RDO CI would have
detected bugs before.
* tripleo folks could focus a bit more on features & bugfixes in TripleO
itself, rather than debugging CI issues and slowing down the review process.
* Puppet OpenStack CI became really stable since we're using this
repository. We have a very few number of issues since then.

Though, something I don't like in my proposal:
* tripleo would not bring short feedback to RDO folks if something is broken

But is TripleO supposed to debug other projects in the same time? Don't
we have enough challenges in our project?

This would be a temporary solution I think, until TripleO would be part
of other upstream project gate (nova, etc) maybe one day.
But at this time, I honestly think TripleO (which is an installer)
folks, spend too much time at debugging CI for some reasons that are
related to projects outside tripleo (puppet modules, openstack bugs,
packaging issues, etc).

This is just a proposal and an idea to help TripleO folks to focus on
their review process, instead of debugging CI failures every week.


Thanks for reading so far.
Your feedback and comments are more than welcome.

[1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.repo
[2] https://github.com/redhat-openstack/weirdo
-- 
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] [Fuel] Overriding and removing VIPs from plugins

[Roman Prykhodchenko]

Frankly, I have not though about how to deal with multiple plugins yet. 
However, what I think is that we must not restrict this too much and let users 
configure it more flexibly even if it allows to shoot one’s foot. Perhaps we 
can add a per-cluster priority for enabled plugins which users can configure 
via UI, CLI or API. My other thought is that we should not invent our own 
mechanics for changing a configuration and use an existing one, say, jsonpatch. 
What do you guys think?

P. S. [0] is really needed for 8.0 for implementing an important epic, so 
please check it out. If it does not break anything, lets merge it ASAP.

- romcheg

> 28 січ. 2016 р. о 18:30 Aleksey Kasatkin  написав(ла):
> 
> AFAIC, it is better to remove by name then. Otherwise, you do not know what 
> VIPs you are removing.
> Another option - remove "built-in" VIPs using some specific expression.
> Anyway, you do not know where other VIPs (VIPs of other plugins) live so you 
> cannot remove them this way.
> 
> And the order of plugins processing is not defined so there is no warranty 
> you will remove all VIPs on those network roles.
> Seems, checking for such conflict between plugins is needed.
> 
> The original goal, actually, was to remove VIPs for controllers (or for some 
> particular node role, maybe),
> so we should maybe find a way to do exactly this.
> 
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 6:28 PM, Aleksandr Didenko  > wrote:
> > How are we handling this now for multiple plugins?
> 
> OK, so right now we can only add VIPs to array, we can't remove them. So 
> overriding would disable such possibility of adding VIPs from different 
> plugins. But with [0] patch it will be still possible to add and to remove by 
> providing empty array. But we'll have the problem with multiple plugins in 
> such case.
> I've changed my mind :) I vote for leaving as in [0] since it's less 
> destructive comparing to what we have now.
> 
> Regards,
> Alex
> 
> [0] https://review.openstack.org/#/c/273169/1 
> 
> 
> On Thu, Jan 28, 2016 at 5:23 PM, Aleksandr Didenko  > wrote:
> Well, with merging instead of overriding, I believe, this problem with 
> multiple plugins still exists, right? How are we handling this now for 
> multiple plugins?
> Since VIPs is array I also vote for overriding, since merging it could be a 
> pain (how do you remove existing element during array merge?).
> 
> On Thu, Jan 28, 2016 at 5:00 PM, Aleksey Kasatkin  > wrote:
> Roman, please provide more details on how VIPs are overridden. And how do you 
> deal with multiple plugins.
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 5:58 PM, Aleksey Kasatkin  > wrote:
> Good idea, overally.
> 
> How about multiple plugins? We don't have any sequence or priorities between 
> them.
> What if one plugin assumes that VIP is present but other one wants to remove 
> it?
> 
> 
> Aleksey Kasatkin
> 
> 
> On Thu, Jan 28, 2016 at 4:02 PM, Sergii Golovatiuk  > wrote:
> +1 to overriding VIPs
> 
> --
> Best regards,
> Sergii Golovatiuk,
> Skype #golserge
> IRC #holser
> 
> On Thu, Jan 28, 2016 at 12:04 PM, Vladimir Kuklin  > wrote:
> +1 to overriding VIPs
> 
> On Thu, Jan 28, 2016 at 1:43 PM, Roman Prykhodchenko  > wrote:
> Folks,
> 
> currently merge policy for network roles only allows to add new VIPs to 
> already existing roles [1]. If a plugin supplies a VIP with a name that 
> already exists but with different parameters, Nailgun will not allow to do 
> that. We faced a need to override configuration of several VIPs by completely 
> removing them from network roles by supplying something like [2]. To enable 
> that I’ve made a temporary workaround [3] to the merging policy that only 
> handles one cornerstone.
> 
> I’ve talked to ikalnitsky and we realized that this functionality of merging 
> new VIPs from plugins to an existing network role is actually wrong and 
> should be replaced by complete overriding. Let’s discuss this possibility 
> here.
> 
> 
> References:
> 
> 1. 
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/policy/merge.py#L55
>  
> 
> 2. http://xsnippet.org/361361/ 
> 3. https://review.openstack.org/#/c/273169/1 
> 
> 
> 
> - romcheg
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

[Renat Akhmerov]

> On 22 Jan 2016, at 20:01, Dan Prince  wrote:
> 
> https://github.com/dprince/tripleo-common/tree/mistral

Just a couple of cosmetic notes:
* this example can be slightly simplified by removing “type: direct” since by 
default workflows are of “direct” type. 
* action params don’t have to go on a single line (sometimes bad for 
readability), instead we can use “input:” task 
property and specify params as a regular dict.

Thanks

Renat Akhmerov
@ 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-dev] [neutron] upgrades/objects code sprint in Brno

[Ihar Hrachyshka]

Hi neutrinos,

as per latest Neutron upgrades subteam discussion, we start to plan for a  
code sprint to push forward remaining M/early N bits for upgrades story.  
The main topic of the sprint will be the objectification of the core  
codebase (ports, networks, subnets…) though other upgrade aspects will also  
get some attention.


It will be held in Europe. Specifically, in Brno, Czech Republic, Red Hat  
office.


Dates: March 14-16.

I will work locally on getting all prepared for the event.

I created an etherpad page to track details on the sprint:  
https://etherpad.openstack.org/p/code-sprint-neutron-objects-brno


For now, it’s almost empty, but I plan to add some details on traveling and  
accommodation options next week.


Cheers
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] [Fuel] [Fuel UI] Node role list grouping

[Vladimir Kuklin]

Bogdan

I do no think that this is confusing as we should have actually a place
where we tie roles to particular tasks. How do you expect our orchestrator
to generate a graph without knowing which tasks to execute on which node?

On Fri, Jan 29, 2016 at 2:59 PM, Bogdan Dobrelya 
wrote:

> On 29.01.2016 10:58, Sergii Golovatiuk wrote:
> > Hi,
> >
> >
> > On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich
> > > wrote:
> >
> > Hi folks,
> >
> > Our team has started a redesign of node roles panel [1] on Add
> > Nodes/Edit Roles screens in Fuel UI.
> > Currently, node roles panel takes a big part of the screen and User
> > have to scroll down to node list to check nodes and then scroll up
> > again to check roles. This becomes more actual for desktops with a
> > small screen.
> >
> > And we faced with the question of grouping new role containers in
> > the panel. There is out initial suggestion [2]:
> >
> > role-list-grouping-1.png
> >
> >   * the first group (the first line on the screenshot) is roles
> > which are required or recommended for deployment (controller,
> > compute, cinder, etc.).
> >
> > It's not true. There can be deployments without Controllers or without
> > computes or without Storage.
> >
> >   * the second group is optional roles which are not mandatory for
> > deployment (base-os, virt, etc.)
> >   * the last group is roles which are unavailable at the moment
> > because of some restrictions. For example, mongo role can not be
> > assigned to a node if ceilometer setting is not enabled on
> > Settings tab
> >
> > BUT there is also a suggestion [3] (see comment #6) to add a new
> > role 'category' attribute into its yaml description [4] that will
> > reflect the role function.
> > For example, cinder, ceph-osd, cinder-vmware roles are from Storage
> > category; compute, ironic are Compute and so on.
> > This new 'category' attribute will also allow proper calculating of
> > an environment capacity: it does not make sense to count CPU and RAM
> > of non-compute nodes or HDD of non-storage nodes.
> >
> > So, we have an initial proposal for such a grouping by a role
> category:
> >
> > CONTROLLER: controller
> > COMPUTE: compute, virt, compute-vmware, ironic
> > STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
> > OTHER: base-os, mongo
> >
> > And we ask your help to review this grouping, i.e. to define the
> > list of possible role categories and to distribute the roles between
> > these categories.
> >
> >
> > We removed role as abstraction from library. It's very very artificial
> > abstraction. Instead we use tasks, grouping them to different
> > combinations. That allows plugin developers to adjust reference
> > architecture to their needs.
>
> That seems *very* confusing as all role labels are still sitting at
> their places in task definitions. See for 'primary-controller',
> 'controller', 'compute' etc. We can say we "dropped" only once we:
> - get rid of them in *all* places
> - update task schema docs [0] lagging far behind, which is the most
> critical thing to remove confusion, see related topic [1]
>
> [0]
>
> https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/085208.html
>
> >
> >
> >
> > Best regards,
> > Julia
> >
> > P.S. We also should take into account, that Fuel plugins can also
> > provide their own roles.
> >
> > [1]
> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
> > [2]
> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
> > [3] https://bugs.launchpad.net/fuel/+bug/1375750
> > [4]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
> >
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 

Re: [openstack-dev] [mistral] how to split mistral log files

[Renat Akhmerov]

> On 19 Jan 2016, at 13:05, SHTILMAN, Tomer (Tomer)  
> wrote:
> 
> Thanks 
> Not sure that duplicating mistral.conf three times will be the best in this 
> case , will make things very hard to manage
> 
> 
> -Original Message-
> From: EXT Lingxian Kong [mailto:anlin.k...@gmail.com] 
> Sent: Tuesday, January 19, 2016 2:29 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [mistral] how to split mistral log files
> 
> Hi, Tomer,
> 
> If you really want Mistral services to be running on different processes or 
> different servers, I recommend you use different config file respectively, 
> log file path can be configured differently, which can achieve what you said.

I agree with Lingxian on that. Log file name is a part of configuration. Having 
any assumptions about file naming (e.g. based on a type of process that we run) 
would make it less transparent. In other words, I think there shouldn’t be any 
automatically generated names.
Another reason: some day we may want to change something else which means we’d 
get inconsistency around config parameters, some of them are ‘plain’ and some 
are ‘generated’.

> On Tue, Jan 19, 2016 at 5:19 AM, SHTILMAN, Tomer (Tomer) 
>  wrote:
>> 
>> I thought of changing
>> https://github.com/openstack/mistral/blob/master/setup.cfg
>> 
>> And creating three different console scripts
>> 
>> console_scripts =
>> 
>>mistral-engine = mistral.cmd.launch:main
>> 
>>mistral-api = mistral.cmd.launch:main
>> 
>>mistral-executor = mistral.cmd.launch:main
>> 
>>mistral-db-manage = mistral.db.sqlalchemy.migration.cli:main


I think regardless of config files this would be a nice addition slightly 
improving usability.
I see no reason why these specific scripts can’t be added. I’d say go ahead and 
send a patch.

Renat Akhmerov
@ 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] [mistral] db deadlock in task execution

[Renat Akhmerov]

Hi,

We’re aware that some of that stuff happens once in a while. Please file a 
ticket, we’ll assign someone to get it investigated.

Renat Akhmerov
@ Mirantis Inc.



> On 27 Jan 2016, at 19:30, Shtilman, Tomer (Nokia - IL) 
>  wrote:
> 
> Hi
> We are seeing an  error in task execution , transaction is rollbacked an I 
> believe its causing problems in deletion (fk violation)
> Shouldn’t we have some kind of retry mechanism for deadlock ?
> Will be happy to get any thoughts on the matter
> Thanks
>  
>  
> [root@s54-0 ~(keystone_cb2)]# mistral task-get-result 
> 1ef3e610-1731-45bb-847c-25f0804ca83d
> "RemoteError: Remote error: InvalidRequestError This Session's transaction 
> has been rolled back due to a previous exception during flush. To begin a new 
> transaction with this Session, first issue Session.rollback(). Original 
> exception was: (mysql_exceptions.OperationalError) (1213, 'Deadlock found 
> when trying to get lock; try restarting transaction') [SQL: u'UPDATE 
> executions_v2 SET updated_at=%s, state=%s WHERE executions_v2.id = 
> %s'][parameters: (datetime.datetime(2016, 1, 27, 0, 11, 30, 305004), 
> 'SUCCESS', '1ef3e610-1731-45bb-847c-25f0804ca83d')]\n[u'Traceback (most 
> recent call last):
> n', u' File 
> \"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py\", line 
> 142, in _dispatch_and_reply
> n executor_callback))
> n', u' File 
> \"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py\", line 
> 186, in _dispatch
> n executor_callback)
> n', u' File 
> \"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py\", line 
> 129, in _do_dispatch
> n result = func(ctxt, **new_args)
> n', u' File \"/usr/lib/python2.7/site-packages/mistral/engine/rpc.py\", line 
> 144, in on_action_complete
> n return self._engine.on_action_complete(action_ex_id, result)
> n', u' File \"/usr/lib/python2.7/site-packages/mistral/utils/init_.py\", line 
> 112, in _logged
> n return func(*args, **kw)
> n', u' File 
> \"/usr/lib/python2.7/site-packages/mistral/engine/default_engine.py\", line 
> 267, in on_action_complete
> n raise e
> n', u\"InvalidRequestError: This Session's transaction has been rolled back 
> due to a previous exception during flush. To begin a new transaction with 
> this Session, first issue Session.rollback().
>  
>  
> __
> OpenStack Development Mailing 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] [Rally] Failure running rally unit tests

[Aleksandr Maretskiy]

Hi

The problem is definitely in mock - some part of keystoneclient package is
actually called (having a real api request) but it should be mocked instead.
Unit test expects that keystoneclient.v2_0 is discovered, but we have
something else instead.

In latest rally version this unit test works fine (I've checked this right
now).

It is important to have real code available to make deeper investigation,
since you use custom package rhos-cert-client/tests/rhcert/suites/openstack/
is based on rally code, but osclients.py significantly differs from its
brother from rally project (according to line numbers from paste).

Can you provide your modules osclients.py and test_osclients.py?



On Fri, Jan 29, 2016 at 11:59 AM, Sudhir Verma  wrote:

> Hi,
>
> I am running the rally test
> https://github.com/openstack/rally/blob/master/tests/unit/test_osclients.py#L87
> there is a function "test_create_keystone_client_v2"
> when i am testing that function i am getting an error i.e:
> "keystoneclient.openstack.common.apiclient.exceptions.ConnectionRefused:
> Unable to establish connection to http://auth_url;
>
> The error is:
> http://paste.openstack.org/show/485380/
>
> Thanks & Regards,
> Sudhir Verma
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

[Matt Riedemann]

On 1/28/2016 11:01 PM, Dan Smith wrote:

I know we have some projects (heat, I think?) that don't have UUIDs at
all. Are they using oslo.versionedobjects? I suppose we could move them
to a string field instead of a UUID field, instead of flipping the
enforcement flag on. Alternately, if we add a new class we wouldn't have
to ever actually deprecate the UUIDField class, though we might add a
warning to the docs that it isn't doing any validation and the new class
is preferred.


If a project isn't using UUIDs then they have no reason to use a
UUIDField and thus aren't affected. If they are, then they're doing
something wrong.


I'll be curious to see what Dan and Sean have to say when they catch up
on this thread.


I think Ryan summed it up very well earlier, but I will echo and
elaborate here for clarity.

To be honest, I think the right thing to do is deprecate the
non-validating behavior and have projects use in-project validating
fields for UUIDs (i.e. their own UUIDField implementation). When we can,
release a major version with the validating behavior turned on.

I don't like the validate=False flag because it's hard (or at least
ugly) to deprecate. Even allowing the call signature to tolerate it for
compatibility but still doing the validation is terrible, IMHO. If
people feel it is absolutely critical to have an implementation in o.vo
right now, then we can do the parallel class option, but we basically
just have to alias the old one to the new one when we "drop" the
non-validating functionality, IMHO, which is just more baggage. To quote
Ryan, "if you know you're going to break people, just don't do it."

This is a really minor issue in my opinion -- the amount of code a
project needs to replicate is exceedingly small, especially if they just
subclass the existing field and override the one method required to
ensure coercion. For a point of reference, nova has a lot of these
fields which are too nova-specific to put into o.vo; adding one more for
this is immeasurably small:

https://github.com/openstack/nova/blob/master/nova/objects/fields.py#L76-L621

Cinder also has some already:

https://github.com/openstack/cinder/blob/master/cinder/objects/fields.py

And to again echo Ryan's comments, we have always landed things in nova,
sync'd them to o.vo and removed our local copy once we can depend on a
new-enough o.vo release. This is effectively the same behavior for this
change and really just isn't that big of a deal. Please, let's do the
safest thing for the projects that consume our library, and for the
people who have to use the same gate as all the rest of us.

--Dan

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



I also agree with deprecating the non-validation behavior and releasing 
with a major version bump (in theory) *but* because of the backward 
compat stance taken since liberty, we can't just drop this since it 
would break unit test jobs in several projects on stable/liberty, at 
least nova and cinder. And that's because (1) nova unit test jobs on 
liberty aren't using upper-constraints and (2) we aren't capping 
libraries in g-r in stable/liberty, because of said upper-constraints. I 
have my own issues with that, but that's the plan that everyone is 
working toward right now, so knowingly dropping the non-uuid support 
would break liberty and we can't allow that until it's gone from all of 
the projects, so we could be looking at mitaka-eol or newton-eol 
(assuming all projects were using UUIDField with real uuid's by the time 
stable/newton is created).  That sucks, I know, but that's the backward 
compat stance with upper-constraints (which I'm not a fan of) and right 
now everyone is having to deal with it until that changes, if that changes.


--

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] [mistral] Promoting Anastasia Kuznetsova to core reviewers

[Lingxian Kong]

+1 from me, welcome Anastasia!

On Fri, Jan 29, 2016 at 9:00 PM, Igor Marnat  wrote:

> Folks,
> I'm not a core reviewer, but if I was, I'd definitely vote with +1.
>
> Good job, Anastasia! Keep going!
>
> Regards,
> Igor Marnat
>
> On Fri, Jan 29, 2016 at 10:23 AM, Elisha, Moshe (Nokia - IL) <
> moshe.eli...@nokia.com> wrote:
>
>> A very big +1
>> 
>> From: Renat Akhmerov [rakhme...@mirantis.com]
>> Sent: Friday, January 29, 2016 8:13 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [mistral] Promoting Anastasia Kuznetsova to
>> core   reviewers
>>
>> Team,
>>
>> I’d like to promote Anastasia Kuznetsova to the core team. What she’s
>> been doing for 2 years is hard to overestimate. She’s done a huge amount of
>> work reviewing code, bugfixing and participating in public discussions
>> including our IRC channel #openstack-mistral. She is very reliable,
>> diligent and consistent about her work.
>>
>> Please vote.
>>
>> Renat Akhmerov
>> @ 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
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
*Regards!*
*---*
*Lingxian Kong*
__
OpenStack Development Mailing 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] spec-lite process for tripleo

[Dougal Matthews]

On 27 January 2016 at 16:21, Derek Higgins  wrote:

> Hi All,
>
> We briefly discussed feature tracking in this weeks tripleo meeting. I
> would like to provide a way for downstream consumers (and ourselves) to
> track new features as they get implemented. The main things that came out
> of the discussion is that people liked the spec-lite process that the
> glance team are using.
>
> I'm proposing we would start to use the same process, essentially small
> features that don't warrant a blueprint would instead have a wishlist bug
> opened against them and get marked with the spec-lite tag. This bug could
> then be referenced in the commit messages. For larger features blueprints
> can still be used. I think the process documented by glance[1] is a good
> model to follow so go read that and see what you think
>
> The general feeling at the meeting was +1 to doing this[2] so I hope we
> can soon start enforcing it, assuming people are still happy to proceed?
>

+1 sounds good.


>
> thanks,
> Derek.
>
> [1]
> http://docs.openstack.org/developer/glance/contributing/blueprints.html#glance-spec-lite
> [2]
> http://eavesdrop.openstack.org/meetings/tripleo/2016/tripleo.2016-01-26-14.02.log.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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-ansible][designate] : Ansible Designate Role : NoEndpointFound error

[Jonnalagadda, Venkata]

Swati,

It seems this is a known issue with keystone tool when there are changes to it. 
Have a look at below links for your problem to resolve temporarily ie., set 
endpoint for -os-endpoint :

http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-06-17.log.html
https://bugs.launchpad.net/python-designateclient/+bug/1415560
https://bugs.launchpad.net/python-designateclient/+bug/1466265

Try it out..


Thanks & Regards,

J. Venkata Mahesh
[cid:image001.gif@01D15A9E.1AB77BA0]

From: Sharma Swati6 [mailto:sharma.swa...@tcs.com]
Sent: Friday, January 29, 2016 1:44 PM
To: openstack-dev@lists.openstack.org
Cc: Pandey Preeti1 ; Partha Datta 
Subject: [openstack-dev] [openstack-ansible][designate] : Ansible Designate 
Role : NoEndpointFound error
Importance: High


Hi Folks,

This is regarding  a new specification : 
https://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/role-designate.html

While the Designate services seem to up and running now in its container, I am 
stuck up with one last issue for the designate endpoint "EndpointNotFound". 
Whenever I run any designate related command after sourcing the openrc, I get 
this error.  Snapshot also attached.

Many of them have reported the same issue at 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-05-21.log.html
 and 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-06-17.log.html
 
.

Some of these files are uploaded here: 
https://github.com/sharmaswati6/designate_files

Kindly let me know if you can help me with this to speed up the delivery.

Thanks & Regards
Swati Sharma
System Engineer
Tata Consultancy Services
Ground to 8th Floors, Building No. 1 & 2,
Skyview Corporate Park, Sector 74A,NH 8
Gurgaon - 122 004,Haryana
India
Cell:- +91-9717238784
Mailto: sharma.swa...@tcs.com
Website: http://www.tcs.com

Experience certainty. IT Services
Business Solutions
Consulting



-Sharma Swati6/DEL/TCS wrote: -
To: Jesse Pretorius 
>
From: Sharma Swati6/DEL/TCS
Date: 01/20/2016 08:50PM
Cc: 
>, 
Pandey Preeti1/DEL/TCS@TCS, Partha Datta/DEL/TCS@TCS
Subject: [openstack-dev][openstack-ansible][designate] : Ansible Designate Role

Hi Jesse,

Thanks for checking out the files on 
https://github.com/sharmaswati6/designate_files

The Designate roles are still not fully completed to be contributed on Gerrit.

While the Designate services seem to up and running now in its container, I am 
stuck up with one last issue for the designate endpoint "EndpointNotFound". 
Whenever I run any designate related command after sourcing the openrc, I get 
this error.

Many of them have reported the same issue at 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-05-21.log.html
 and 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-06-17.log.html
 
.

Kindly let me know if you can help me with this to speed up the delivery.

Thanks & Regards
Swati Sharma
System Engineer
Tata Consultancy Services
Ground to 8th Floors, Building No. 1 & 2,
Skyview Corporate Park, Sector 74A,NH 8
Gurgaon - 122 004,Haryana
India
Cell:- +91-9717238784
Mailto: sharma.swa...@tcs.com
Website: http://www.tcs.com

Experience certainty. IT Services
Business Solutions
Consulting



-Jesse Pretorius 
> wrote: -
To: sharma.swa...@tcs.com
From: Jesse Pretorius 
>
Date: 01/20/2016 02:37PM
Subject: Ansible Designate Role
Hi Swati,

It seems that you're very close to done with 
https://github.com/sharmaswati6/designate_files but have stopped working on it.

Is there a problem we can help you with?

Are you happy for us to import the role into the OpenStack namespace and then 
collaborate through gerrit to complete it?

Best regards,

Jesse

--
Jesse Pretorius
IRC: odyssey4me

=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us 

Re: [openstack-dev] Any chances to backport port_security_enabled support into Heat for Kilo 2015.1.3?

[Sergey Kraynev]

Sean, thank you for the spotting.

Martinx, According to the information mentioned by Sean, we unfortunately
can not do it :(

On 29 January 2016 at 10:45, Sean M. Collins  wrote:

> Kilo is in the "security supported" stage of the lifecycle. So no,
> that's not going to get backported.
>
> http://docs.openstack.org/releases/index.html
> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Sergey.
__
OpenStack Development Mailing 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] [Fuel] [Fuel UI] Node role list grouping

[Sergii Golovatiuk]

Hi,


On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich 
wrote:

> Hi folks,
>
> Our team has started a redesign of node roles panel [1] on Add Nodes/Edit
> Roles screens in Fuel UI.
> Currently, node roles panel takes a big part of the screen and User have
> to scroll down to node list to check nodes and then scroll up again to
> check roles. This becomes more actual for desktops with a small screen.
>
> And we faced with the question of grouping new role containers in the
> panel. There is out initial suggestion [2]:
>
> [image: role-list-grouping-1.png]
>
>- the first group (the first line on the screenshot) is roles which
>are required or recommended for deployment (controller, compute, cinder,
>etc.).
>
> It's not true. There can be deployments without Controllers or without
computes or without Storage.

>
>- the second group is optional roles which are not mandatory for
>deployment (base-os, virt, etc.)
>- the last group is roles which are unavailable at the moment because
>of some restrictions. For example, mongo role can not be assigned to a node
>if ceilometer setting is not enabled on Settings tab
>
> BUT there is also a suggestion [3] (see comment #6) to add a new role
> 'category' attribute into its yaml description [4] that will reflect the
> role function.
> For example, cinder, ceph-osd, cinder-vmware roles are from Storage
> category; compute, ironic are Compute and so on.
> This new 'category' attribute will also allow proper calculating of an
> environment capacity: it does not make sense to count CPU and RAM of
> non-compute nodes or HDD of non-storage nodes.
>
> So, we have an initial proposal for such a grouping by a role category:
>
> CONTROLLER: controller
> COMPUTE: compute, virt, compute-vmware, ironic
> STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
> OTHER: base-os, mongo
>
> And we ask your help to review this grouping, i.e. to define the list of
> possible role categories and to distribute the roles between these
> categories.
>

We removed role as abstraction from library. It's very very artificial
abstraction. Instead we use tasks, grouping them to different combinations.
That allows plugin developers to adjust reference architecture to their
needs.


>
> Best regards,
> Julia
>
> P.S. We also should take into account, that Fuel plugins can also provide
> their own roles.
>
> [1]
> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
> [2]
> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
> [3] https://bugs.launchpad.net/fuel/+bug/1375750
> [4]
> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
>
>
> __
> OpenStack Development Mailing 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] [Fuel] [Fuel UI] Node role list grouping

[Vladimir Kuklin]

Sergii

I disagree with you here a little bit. Role abstraction is a useful thing
from high-level standpoint. I would suggest that this list of roles
grouping, e.g. which roles are mandatory and which are configured within
which group can be specified:

1) in global settings of Nailgun
2) per-plugin
3) per environment in UI

This should cover all the cases even for very flexible roles allocation.

On Fri, Jan 29, 2016 at 12:58 PM, Sergii Golovatiuk <
sgolovat...@mirantis.com> wrote:

> Hi,
>
>
> On Fri, Jan 29, 2016 at 9:55 AM, Julia Aranovich 
> wrote:
>
>> Hi folks,
>>
>> Our team has started a redesign of node roles panel [1] on Add Nodes/Edit
>> Roles screens in Fuel UI.
>> Currently, node roles panel takes a big part of the screen and User have
>> to scroll down to node list to check nodes and then scroll up again to
>> check roles. This becomes more actual for desktops with a small screen.
>>
>> And we faced with the question of grouping new role containers in the
>> panel. There is out initial suggestion [2]:
>>
>> [image: role-list-grouping-1.png]
>>
>>- the first group (the first line on the screenshot) is roles which
>>are required or recommended for deployment (controller, compute, cinder,
>>etc.).
>>
>> It's not true. There can be deployments without Controllers or without
> computes or without Storage.
>
>>
>>- the second group is optional roles which are not mandatory for
>>deployment (base-os, virt, etc.)
>>- the last group is roles which are unavailable at the moment because
>>of some restrictions. For example, mongo role can not be assigned to a 
>> node
>>if ceilometer setting is not enabled on Settings tab
>>
>> BUT there is also a suggestion [3] (see comment #6) to add a new role
>> 'category' attribute into its yaml description [4] that will reflect the
>> role function.
>> For example, cinder, ceph-osd, cinder-vmware roles are from Storage
>> category; compute, ironic are Compute and so on.
>> This new 'category' attribute will also allow proper calculating of an
>> environment capacity: it does not make sense to count CPU and RAM of
>> non-compute nodes or HDD of non-storage nodes.
>>
>> So, we have an initial proposal for such a grouping by a role category:
>>
>> CONTROLLER: controller
>> COMPUTE: compute, virt, compute-vmware, ironic
>> STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
>> OTHER: base-os, mongo
>>
>> And we ask your help to review this grouping, i.e. to define the list of
>> possible role categories and to distribute the roles between these
>> categories.
>>
>
> We removed role as abstraction from library. It's very very artificial
> abstraction. Instead we use tasks, grouping them to different combinations.
> That allows plugin developers to adjust reference architecture to their
> needs.
>
>
>>
>> Best regards,
>> Julia
>>
>> P.S. We also should take into account, that Fuel plugins can also provide
>> their own roles.
>>
>> [1]
>> https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
>> [2]
>> http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
>> [3] https://bugs.launchpad.net/fuel/+bug/1375750
>> [4]
>> https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
>>
>>
>> __
>> OpenStack Development Mailing 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Horizon] Recent integration tests failures

[Itxaka Serrano Garcia]

Can confirm, had the same issue locally, was fixed after a downgrade to 
selenium 2.48.



Good catch!

Itxaka

On 01/28/2016 10:08 PM, Timur Sufiev wrote:

According to the results at
https://review.openstack.org/#/c/273697/1 capping Selenium to be not
greater than 2.49 fixes broken tests. Patch to global-requirements is
here: https://review.openstack.org/#/c/273750/

On Thu, Jan 28, 2016 at 9:22 PM Timur Sufiev > wrote:

Hello, Horizoneers

You may have noticed recent integration tests failures seemingly
unrelated to you patches, with a stacktrace like:
http://paste2.org/2Hk9138U I've already filed a bug for that,
https://bugs.launchpad.net/horizon/+bug/1539197 Appears to be a
Selenium issue, currently investigating it.




__
OpenStack Development Mailing 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] [Fuel] [Fuel UI] Node role list grouping

[Julia Aranovich]

Hi folks,

Our team has started a redesign of node roles panel [1] on Add Nodes/Edit
Roles screens in Fuel UI.
Currently, node roles panel takes a big part of the screen and User have to
scroll down to node list to check nodes and then scroll up again to check
roles. This becomes more actual for desktops with a small screen.

And we faced with the question of grouping new role containers in the
panel. There is out initial suggestion [2]:

[image: role-list-grouping-1.png]

   - the first group (the first line on the screenshot) is roles which are
   required or recommended for deployment (controller, compute, cinder, etc.).
   - the second group is optional roles which are not mandatory for
   deployment (base-os, virt, etc.)
   - the last group is roles which are unavailable at the moment because of
   some restrictions. For example, mongo role can not be assigned to a node if
   ceilometer setting is not enabled on Settings tab

BUT there is also a suggestion [3] (see comment #6) to add a new role
'category' attribute into its yaml description [4] that will reflect the
role function.
For example, cinder, ceph-osd, cinder-vmware roles are from Storage
category; compute, ironic are Compute and so on.
This new 'category' attribute will also allow proper calculating of an
environment capacity: it does not make sense to count CPU and RAM of
non-compute nodes or HDD of non-storage nodes.

So, we have an initial proposal for such a grouping by a role category:

CONTROLLER: controller
COMPUTE: compute, virt, compute-vmware, ironic
STORAGE: cinder, cinder-block-device, cinder-vmware, ceph-osd
OTHER: base-os, mongo

And we ask your help to review this grouping, i.e. to define the list of
possible role categories and to distribute the roles between these
categories.

Best regards,
Julia

P.S. We also should take into account, that Fuel plugins can also provide
their own roles.

[1] https://blueprints.launchpad.net/fuel/+spec/redesign-of-node-roles-panel
[2] http://s22.postimg.org/x8ry0lm1t/Screenshot_from_2016_01_26_17_49_24.png
[3] https://bugs.launchpad.net/fuel/+bug/1375750
[4]
https://github.com/openstack/fuel-web/blob/master/nailgun/nailgun/fixtures/openstack.yaml#L9-L142
__
OpenStack Development Mailing 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] [Fuel] Relieving CI/gate jenkins bottleneck

[Bogdan Dobrelya]

On 28.01.2016 17:48, Alex Schultz wrote:

Please let's continue discussion here [0].

[0]
http://lists.openstack.org/pipermail/openstack-dev/2016-January/085310.html

> On Thu, Jan 28, 2016 at 9:31 AM, Sergii Golovatiuk
>  wrote:
>> Hi,
>>
>> I disagree with Bogdan. We have the same case in OpenStack components.
>>
>> 1. As a compony we may have own patches on top of 'master'.
>> 2. There is no way to use tags on upstream modules so it will be very hard
>> to support it. If we need to deliver fix in previous release there won't be
>> simple way to create tag, and cherry-pick the particular commit.
>>
>> So I support Alex to continue the way we have right now.
>>
> 
> 2 is not completely true, but it does rely on upstream to provide tags
> (not all do or are responsive).  For instance, the puppet openstack
> modules do not provide updated tags for patches to the previous
> released version.  Personally I agree that the Puppetfile should point
> to clean upstream versions for the upstream fuel-library.  But I think
> we need to work out how to properly separate upstream/downstream
> fuel-library prior to switching out the Puppetfile with one that only
> consumes the complete upstream versions.  For now, we have a policy in
> place around where the modules we pull in should be located and that
> it must point to a tag.  Once we've solidified what the
> upstream/downstream fuel-library looks like, then we can adjust the
> upstream policy to not be so stringent and let the upstream
> fuel-library rely on pure upstream modules and perhaps drop the tag
> requirement while still allowing downstream to continue with custom
> tags and modules.
> 
> -Alex
> 
>>
>>
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Thu, Jan 28, 2016 at 5:07 PM, Bogdan Dobrelya 
>> wrote:
>>>
>>> On 22.01.2016 13:56, Bogdan Dobrelya wrote:
 On 22.01.2016 12:19, Matthew Mosesohn wrote:
> +1 for defaulting to upstream for CI. If we have a strong case where we
> need to make a patch in order to make unit tests pass, we could switch
> a
> module back to review.fuel-infra.org/puppet-modules/..
> .. with a FIXME and a
> LP
> bug ID so we can switch it back quickly once the upstream issue is
> resolved.  As far as I know, we don't have to worry about that
> scenario.

 Yes, exactly so. Switching upstream/downstream links of modules in the
 Puppetfile back and forth can be done as often as we need it, with no
 issues at all. With "free bonuses" though! Which is, firstly, it would
 be easier to estimate upstream-to-downstream sync status by just looking
 at the Puppetfile. Secondly, each time one's switching an upstream link
 to a downstream, reviewers may treat this as a "tech dept growing
 alarm!" and perhaps motivate patch authors to contribute changes
 upstream instead (or *faster*) rather than just stashing them
 accumulated downstream.
>>>
>>> We have a disagreement for the patches [0], [1] related to this topic.
>>> My point is that we should use direct upstream hashtags/releases as
>>> early as possible. Nothing prevents us from switching to a downstream
>>> one in case of emergency.
>>>
>>> So donwstream maintaining efforts shall not be done from the very
>>> beginning, if possible to save infra/engineering resource for something
>>> more useful.
>>>
>>> [0] https://review.openstack.org/#/c/271217
>>> [1] https://review.openstack.org/#/c/273036/
>>>

>
> -Matthew
>
> On Fri, Jan 22, 2016 at 12:51 PM, Bogdan Dobrelya
> > wrote:
>
> Another point is to use upstream links for modules w/o downstream
> patches.
> I noticed we *always* put it to the deployment/Puppetfile [0] as
>  "https://review.fuel-infra.org/puppet-modules/...;. Why should we?
> Let's just do the best to reuse upstream modules as is, eventually.
>
> [0]
> https://github.com/openstack/fuel-library/blob/master/deployment/Puppetfile
>
> Regards,
> Bogdan Dobrelya.
> Irc #bogdando
>
> 2016-01-21 11:09 GMT+01:00 Bartlomiej Piotrowski
> >:
>
> Let's drop 3.3 as well. 3.4 is oldschool enough for vintage
> lovers.
>
> BP
>
> On Thu, Jan 21, 2016 at 11:03 AM, Aleksandr Didenko
> > wrote:
>
> Hi,
>
> > I also think 3.3 is the version that ships with 14.04.
>
> 3.4.3 is shipped with Ubuntu-14.04. I think 3.4, 3.8 and 4
> should be enough.
>
> Regards,
> Alex
>
> On Wed, Jan 20, 

[openstack-dev] [Fuel][library] relax downstream policy for puppet modules managed by librarian

[Bogdan Dobrelya]

This is a continuation of the forked discussion [0].

The idea is to relax Fuel-library downstream policy and implement a
"lazy downstreaming", which is to not create a downstream fork of a
puppet module referenced in the librarian Puppetfile unless we have to
do so.

The relaxed policy would unblock an upstream switching of the rabbitmq
[1] and corosync [2] modules as well.

Pros:
- Reduced costs of maintaining downstream forks because of the laziness
of the forking process. This much better distributes load to Fuel
engineering and HW resources in time. Even though related tasks may be
one-time, HW resources and network bandwidth shall not be wasted for
keeping and cloning unnecessary forks (unless we have no choice but to
fork things)
-  A module might remain as direct upstream reference in the Puppetfile
for quite a while. This as well shows an amount of the hidden technical
debt in much more clean representation - downstream vs upstream refs in
the Puppetfile.
- Some generic, non OpenStack puppet modules will barely require
backporting of separate patches by older tags as they work just
straightforward and the latest version works for every supported Fuel
release as well. Those would save resources because of the laziness of
the relaxed process will never require to create downstream forks for
such modules!

Cons:
- I see none. For "unlucky" modules, the *same* amount of work shall be
done anyway, although with the lazy process in place it will be
distributed in time much better.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2016-January/085249.html
[1] https://review.openstack.org/#/c/271217
[2] https://review.openstack.org/#/c/273036/

-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
OpenStack Development Mailing 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] Nominate Victor Ryzhenkin to Murano Core

[Nikolay Starodubtsev]

Congratulations, Victor!



Nikolay Starodubtsev

Software Engineer

Mirantis Inc.


Skype: dark_harlequine1

2016-01-28 17:26 GMT+03:00 Dmytro Dovbii :

> Congratulations, Victor! =)
>
> 2016-01-28 16:20 GMT+02:00 Victor Ryzhenkin :
>
>> Thank you, folks! I will do my best!
>>
>> Cheers!
>>
>> --
>> Victor Ryzhenkin
>> Junior QA Engeneer
>> freerunner on #freenode
>>
>> Включено 28 января 2016 г. в 17:15:19, Serg Melikyan (
>> smelik...@mirantis.com) написал:
>>
>> Victor, welcome!
>>
>> On Thu, Jan 28, 2016 at 5:57 AM, Kirill Zaitsev 
>> wrote:
>> >
>> > +1 from me. Victor’s continued work on keeping our gates green and
>> stable is invaluable. His contribution during M cycle is also very
>> impressive. Looking forward to seeing him one of the cores.
>> >
>> > --
>> > Kirill Zaitsev
>> > Murano team
>> > Software Engineer
>> > Mirantis, Inc
>> >
>> > On 27 January 2016 at 01:10:18, Stan Lagun (sla...@mirantis.com) wrote:
>> >
>> > +1!
>> > Well deserved!
>> > Sincerely yours,
>> > Stan Lagun
>> > Principal Software Engineer @ Mirantis
>> >
>> >
>> >
>> > On Tue, Jan 26, 2016 at 5:20 AM, Yang, Lin A 
>> wrote:
>> > > Glad to see this happened. :)
>> > > Well deserved, Victor.
>> > >
>> > > Lin Yang
>> > > @Intel
>> > >
>> > >> On Jan 23, 2016, at 01:33, Serg Melikyan 
>> wrote:
>> > >>
>> > >> I would like to nominate Victor Ryzhenkin (freerunner on IRC) join
>> to the Murano
>> > >> core-reviewers team. He has been an active member of the Murano team
>> > >> for some time now. You can check his review activity report here:
>> > >> http://stackalytics.com/report/contribution/murano-group/90
>> > >>
>> > >> Team please vote for this change in reply to this message.
>> > >> --
>> > >> Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
>> > >> http://mirantis.com | smelik...@mirantis.com
>> > >>
>> > >>
>> __
>> > >> OpenStack Development Mailing 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
>> >
>>
>>
>>
>> --
>> Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
>> http://mirantis.com | smelik...@mirantis.com
>>
>> __
>> OpenStack Development Mailing 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

Re: [openstack-dev] [openstack-ansible][designate] : Ansible Designate Role : NoEndpointFound error

[Sharma Swati6]

 Hi Venkata,

Thanks for your prompt response.

We are using designate 1.5.0

>From the below links, I have added the code from 
>https://review.openstack.org/#/c/199067/1/designateclient/shell.py as well.

Also, in the link --publicurl is mentioned as  
http://controller.dmgweb.es:9001/v1 . But, soemwhere else I read it should be 
without versions. So when I do endpoint-list, I see publicurl in my system as 
http://10.16.34.6:9001/

I still get the error  "ERROR: No endpoint was found. Missing credentials?"

My openrc content is as follows-

export LC_ALL=C
 
# COMMON CINDER ENVS
export CINDER_ENDPOINT_TYPE=internalURL
 
# COMMON NOVA ENVS
export NOVA_ENDPOINT_TYPE=internalURL
 
# COMMON OPENSTACK ENVS
export OS_ENDPOINT_TYPE=internalURL
export OS_USERNAME=admin
export OS_PASSWORD=vK26yJAtoS9gCR0tjjoFHFx9iudUjVDr
export OS_PROJECT_NAME=admin
# NOTE(sigmavirus24): The tenant name setting should be removed when
# python-cinderclient stops checking for it and failing if it doesn't exist.
export OS_TENANT_NAME=admin
export OS_AUTH_URL=http://10.16.34.6:5000/v3
export OS_NO_CACHE=1
export OS_USER_DOMAIN_NAME=Default
export OS_PROJECT_DOMAIN_NAME=Default
 
# For openstackclient
export OS_IDENTITY_API_VERSION=3
export OS_AUTH_VERSION=3

Thanks & Regards
 Swati Sharma
 System Engineer
 Tata Consultancy Services
 Ground to 8th Floors, Building No. 1 & 2,
 Skyview Corporate Park, Sector 74A,NH 8
 Gurgaon - 122 004,Haryana
 India
 Cell:- +91-9717238784
 Mailto: sharma.swa...@tcs.com
 Website: http://www.tcs.com
 
 Experience certainty.  IT Services
Business Solutions
Consulting
 
 

-"Jonnalagadda, Venkata"  wrote: -
To: "OpenStack Development Mailing List (not for usage questions)" 

From: "Jonnalagadda, Venkata" 
Date: 01/29/2016 02:12PM
Cc: Pandey Preeti1 , Partha Datta 
Subject: Re: [openstack-dev] [openstack-ansible][designate] : Ansible Designate 
Role : NoEndpointFound error

Swati,
 
It seems this is a known issue with keystone tool when there are changes to it. 
Have a look at below links for your problem to resolve temporarily ie., set 
endpoint for os-endpoint :
 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-06-17.log.html
https://bugs.launchpad.net/python-designateclient/+bug/1415560
https://bugs.launchpad.net/python-designateclient/+bug/1466265
 
Try it out..
 
 
Thanks & Regards,
 
J. Venkata Mahesh

 
From: Sharma Swati6 [mailto:sharma.swa...@tcs.com] 
Sent: Friday, January 29, 2016 1:44 PM
To: openstack-dev@lists.openstack.org
Cc: Pandey Preeti1 ; Partha Datta 
Subject: [openstack-dev] [openstack-ansible][designate] : Ansible Designate 
Role : NoEndpointFound error
Importance: High
 

Hi Folks,

This is regarding  a new specification : 
https://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/role-designate.html

While the Designate services seem to up and running now in its container, I am 
stuck up with one last issue for the designate endpoint "EndpointNotFound". 
Whenever I run any designate related command after sourcing the openrc, I get 
this error.  Snapshot also attached.

Many of them have reported the same issue at 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-05-21.log.html
 and 
http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-06-17.log.html
 .

Some of these files are uploaded here: 
https://github.com/sharmaswati6/designate_files

Kindly let me know if you can help me with this to speed up the delivery.

Thanks & Regards
Swati Sharma
System Engineer
Tata Consultancy Services
Ground to 8th Floors, Building No. 1 & 2,
Skyview Corporate Park, Sector 74A,NH 8
Gurgaon - 122 004,Haryana
India
Cell:- +91-9717238784
Mailto: sharma.swa...@tcs.com
Website: http://www.tcs.com

Experience certainty. IT Services
Business Solutions
Consulting



-Sharma Swati6/DEL/TCS wrote: -

To: Jesse Pretorius 
From: Sharma Swati6/DEL/TCS
Date: 01/20/2016 08:50PM
Cc: , Pandey Preeti1/DEL/TCS@TCS, Partha 
Datta/DEL/TCS@TCS
Subject: [openstack-dev][openstack-ansible][designate] : Ansible Designate Role

Hi Jesse,

Thanks for checking out the files on 
https://github.com/sharmaswati6/designate_files

The Designate roles are still not fully completed to be contributed on Gerrit.

While the Designate services seem to up and running now in its container, I am 
stuck up with one last issue for the designate endpoint "EndpointNotFound". 
Whenever I run any designate related command after sourcing the openrc, I get 

[openstack-dev] [puppet][ec2api] - Official EC2 puppet module repo

[Marcos Fermin Lobo]

Hi,

Since I finished to "apply" for puppet-ec2api module as official puppet module 
in OpenStack (see https://review.openstack.org/#/c/252959/ and 
https://review.openstack.org/#/c/251857/), I saw that the puppet module 
repository is created https://github.com/openstack/puppet-ec2api

But the repository is still empty.

I already have the code for this module here 
https://github.com/cernops/puppet-ec2api, so I was wondering if some step more 
is needed from me in order to fill the official repository.

Thank you for your attention.

Regards,
Marcos.
__
OpenStack Development Mailing 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] use mitaka CI tested repo

[John Trowbridge]

On 01/29/2016 09:40 AM, Dan Prince wrote:
> On Fri, 2016-01-29 at 08:17 -0500, Emilien Macchi wrote:
>> Hi,
>>
>> I'm wondering why don't we use Mitaka CI tested repository [1].
>> IIRC, TripleO is currently using a snapshot which is updated
>> asynchronously by TripleO CI folks.
>> The problem is that we're not consistent with what RDO CI is testing.
>> In
>> my memory and tell me if I'm wrong but it happens we're using an old
>> snapshot of packages which is older that is actually tested &
>> verified
>> by RDO CI.
>>
>> The benefit of using this tested repo would be:
>> * this repository is already gated by Weirdo [2] which is running the
>> same jobs as Puppet OpenStack CI.
>> * you would not have less jobs failures, because RDO CI would have
>> detected bugs before.
>> * tripleo folks could focus a bit more on features & bugfixes in
>> TripleO
>> itself, rather than debugging CI issues and slowing down the review
>> process.
>> * Puppet OpenStack CI became really stable since we're using this
>> repository. We have a very few number of issues since then.
>>
>> Though, something I don't like in my proposal:
>> * tripleo would not bring short feedback to RDO folks if something is
>> broken
>>
>> But is TripleO supposed to debug other projects in the same time?
>> Don't
>> we have enough challenges in our project?
>>
>> This would be a temporary solution I think, until TripleO would be
>> part
>> of other upstream project gate (nova, etc) maybe one day.
>> But at this time, I honestly think TripleO (which is an installer)
>> folks, spend too much time at debugging CI for some reasons that are
>> related to projects outside tripleo (puppet modules, openstack bugs,
>> packaging issues, etc).
>>
>> This is just a proposal and an idea to help TripleO folks to focus on
>> their review process, instead of debugging CI failures every week.
> 
> The problem I think is largly due to the fact that the RDO CI doesn't
> test the same things we do in the TripleO CI. It is essentially a
> different CI system.
> 
> Because the CI systems are different different breakages happen when
> you try to update one component vs. another. This is why we have to
> maintain 'current-tripleo' separately between RDO and TripleO.
> 
> I agree it would be nice if we could consolidate on a single repository
> across these projects. It would allow us to focus on review more...
> (less CI fixing).
> 
> Perhaps a test matrix comparing the two CI systems would help us get
> them closer to parity with what is covered. Even better would be just
> simply contributing to the same CI systems and scripts.
>

I think contributing to the same scripts would be a big win. From the
'undercloud install' on, it is totally feasible for both CI systems to
use the same script right now.

I am working on using tripleo.sh in rdoci, which modulo the different
environment setups, would get us to the above goal.

If we could then get tripleoci consuming the same pre-built
undercloud.qcow2 that rdoci is using[1], I think the environment
differences would be negligible.

[1]
https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2

> Dan
> 
>>
>>
>> Thanks for reading so far.
>> Your feedback and comments are more than welcome.
>>
>> [1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.re
>> po
>> [2] https://github.com/redhat-openstack/weirdo
>> _
>> _
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>> cribe
>> 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] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

[Foley, Emma L]

> So, metrics are grouped by the type of resource they use, and each metric has 
> to be listed.
> Grouping isn't a problem, but creating an exhaustive list might be, 
> since there are 100+ plugins [1] in collectd which can provide 
> statistics, although not all of these are useful, and some require 
> extensive configuration. The plugins each provide multiple metrics, 
> and each metric can be duplicated for a number of instances, examples: [2].
>
> Collectd data is minimal: timestamp and volume, so there's little room to 
> find interesting meta data.
> It would be nice to see this support integrated, but it might be very 
> tedious to list all the metric names and group by resource type without any 
> form of Do the resource definitions support wildcards? Collectd can provide A 
> LOT of metrics.

One also has to put into balance the upside of going through Ceilometer, as 
Gnocchi has direct support for statsd:

  http://gnocchi.xyz/statsd.html



Supporting statsd would require some more investigation, as collectd's statsd 
plugin supports reading stats from the system, but not writing them.
 Also, what are the usage figures for gnocchi? How many people use it, 
and how easy is it to convert existing deployments to use gnocchi? I mean, if 
someone was upgrading, would their data be preserved?
 How easy is it to consume gnocchi statistics using an external 
system/application?
 I'm not against the idea, but it requires a little more consideration.

Regards,
Emma

--
Intel Research and Development Ireland Limited 
Registered in Ireland 
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare 
Registered Number: 308263



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

Re: [openstack-dev] [infra] Gate is broken

[Michael Krotscheck]

Hello, everyone!

The broken images have been deleted, and our jenkins slaves should revert
back to the previous (good) image. It's safe to submit patches again!

Michael

On Fri, Jan 29, 2016 at 7:52 AM Paul Michali  wrote:

> Thanks for hopping on it quickly!
>
>
>
> On Fri, Jan 29, 2016 at 10:41 AM Michael Krotscheck 
> wrote:
>
>> Hey everyone!
>>
>> Since the summit submission deadline is this weekend, we (the infra team)
>> have decided that it's an excellent time to break all of our slaves, so you
>> can go and submit your talks for Austin!
>>
>> That certainly sounds better than "We misconfigured pip.conf and now none
>> of our nodes know how to pip install.". A fix has been merged, however it
>> will take some time to propagate. We will keep you updated on this thread
>> and on IRC.
>>
>> Michael
>>
> __
>> OpenStack Development Mailing 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] [Fuel][Plugins] Tasks ordering between plugins

[Igor Kalnitsky]

Hey folks,

Simon P. wrote:
> 1. Run task X for plugin A (if installed).
> 2. Run task Y for plugin B (if installed).
> 3. Run task Z for plugin A (if installed).

Simon, could you please explain do you need this at the first place? I
can imagine this case only if your two plugins are kinda dependent on
each other. In this case, it's better to do what was said by Andrew W.
- set 'Task Y' to require 'Task X' and that requirement will be
satisfied anyway (even if Task X doesn't exist in the graph).


Alex S. wrote:
> Before we get rid of tasks.yaml can we provide a mechanism for plugin
> devs could leverage to have tasks executes at specific points in the
> deploy process.

Yeah, I think that may be useful sometime. However, I'd prefer to
avoid anchor usage as much as possible. There's no guarantees that
other plugin didn't make any destructive actions early, that breaks
you later. Anchors is good way to resolve possible conflicts, but they
aren't bulletproof.

- igor

On Thu, Jan 28, 2016 at 1:31 PM, Bogdan Dobrelya  wrote:
> On 27.01.2016 14:44, Simon Pasquier wrote:
>> Hi,
>>
>> I see that tasks.yaml is going to be deprecated in the future MOS
>> versions [1]. I've got one question regarding the ordering of tasks
>> between different plugins.
>> With tasks.yaml, it was possible to coordinate the execution of tasks
>> between plugins without prior knowledge of which plugins were installed [2].
>> For example, lets say we have 2 plugins: A and B. The plugins may or may
>> not be installed in the same environment and the tasks execution should be:
>> 1. Run task X for plugin A (if installed).
>> 2. Run task Y for plugin B (if installed).
>> 3. Run task Z for plugin A (if installed).
>>
>> Right now, we can set task priorities like:
>>
>> # tasks.yaml for plugin A
>> - role: ['*']
>>   stage: post_deployment/1000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_X.pp
>> puppet_modules: puppet/modules
>>
>> - role: ['*']
>>   stage: post_deployment/3000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_Z.pp
>> puppet_modules: puppet/modules
>>
>> # tasks.yaml for plugin B
>> - role: ['*']
>>   stage: post_deployment/2000
>>   type: puppet
>>   parameters:
>> puppet_manifest: puppet/manifests/task_Y.pp
>> puppet_modules: puppet/modules
>>
>> How would it be handled without tasks.yaml?
>
> I created a kinda related bug [0] and submitted a patch [1] to MOS docs
> [2] to kill some entropy on the topic of tasks schema roles versus
> groups and using wildcards for basic and custom roles from plugins as
> well. There is also a fancy picture to clarify things a bit. Would be
> nice to put more details there about custom stages as well!
>
> If plugins are not aware of each other, they cannot be strictly ordered
> like "to be the very last in the deployment" as one and only shall be
> so. That is why "coordinating the execution of tasks
> between plugins without prior knowledge of which plugins were installed"
> looks very confusing for me. Though, maybe wildcards with the "skipped"
> task type may help to organize things better?
>
> Perhaps the Fuel plugins team could answer the question better.
>
> [0] https://bugs.launchpad.net/fuel/+bug/1538982
> [1] https://review.fuel-infra.org/16509
> [2]
> https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment
>
>>
>> Regards,
>> Simon
>>
>> [1] https://review.openstack.org/#/c/271417/
>> [2] https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
>>
>>
>> __
>> OpenStack Development Mailing 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,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

[gordon chung]

On 29/01/2016 10:48 AM, Foley, Emma L wrote:
>> So, metrics are grouped by the type of resource they use, and each metric 
>> has to be listed.
>> Grouping isn't a problem, but creating an exhaustive list might be,
>> since there are 100+ plugins [1] in collectd which can provide
>> statistics, although not all of these are useful, and some require
>> extensive configuration. The plugins each provide multiple metrics,
>> and each metric can be duplicated for a number of instances, examples: [2].
>>
>> Collectd data is minimal: timestamp and volume, so there's little room to 
>> find interesting meta data.
>> It would be nice to see this support integrated, but it might be very
>> tedious to list all the metric names and group by resource type without any 
>> form of Do the resource definitions support wildcards? Collectd can provide 
>> A LOT of metrics.
> One also has to put into balance the upside of going through Ceilometer, as 
> Gnocchi has direct support for statsd:
>
>http://gnocchi.xyz/statsd.html
>
>
>
> Supporting statsd would require some more investigation, as collectd's statsd 
> plugin supports reading stats from the system, but not writing them.
>   Also, what are the usage figures for gnocchi? How many people use 
> it, and how easy is it to convert existing deployments to use gnocchi? I 
> mean, if someone was upgrading, would their data be preserved?
>   How easy is it to consume gnocchi statistics using an external 
> system/application?
>   I'm not against the idea, but it requires a little more 
> consideration.
>
> Regards,
> Emma
>
Gnocchi is intended to solve the use case of timestamp+value type data, 
that's essentially how it stores it. the best way i would describe it 
is, if you use ceilometer statistics command, you should probably be 
using Gnocchi. if you use ceilometer sample-list, it's arguable whether 
Gnocchi or legacy Ceilometer db is right. so basically do you want 
slower, full-fidelity data (ceilometer) or do you want responsive, 
light-weight data (gnocchi)

Gnocchi implements the concept of archive policies which basically 
dictates how much or little is store. it's purpose is to rollup and 
pre-calculate data so less is stored, and as a side effect, is more 
response as it has less clutter to deal with. in theory, you could 
define a granularity to store everything with no roll ups so all the 
data is preserved, but even though we store timestamp+value: the more 
you store, the bigger the size.

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] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

[gordon chung]

On 28/01/2016 2:32 AM, Foley, Emma L wrote:
> So, metrics are grouped by the type of resource they use, and each metric has 
> to be listed.
> Grouping isn't a problem, but creating an exhaustive list might be, since 
> there are 100+ plugins [1] in collectd which can provide statistics, although 
> not all of these are useful, and some require extensive configuration. The 
> plugins each provide multiple metrics, and each metric can be duplicated for 
> a number of instances, examples: [2].
>
> Collectd data is minimal: timestamp and volume, so there's little room to 
> find interesting meta data.
> It would be nice to see this support integrated, but it might be very tedious 
> to list all the metric names and group by resource type without any form of
> Do the resource definitions support wildcards? Collectd can provide A LOT of 
> metrics.
>
> Regards,
> Emma
>
> [1] https://collectd.org/wiki/index.php/Table_of_Plugins
> [2] https://collectd.org/wiki/index.php/Naming_schema

gnocchi is strongly typed when compared to classical ceilometer db where 
you can dump anything and everything. we don't support wildcards as is 
but i believe it's something we can aim to support?

Mehdi is currently in process of implementing dynamic resources which 
would give more flexiblity on what type of data we can store in Gnocchi. 
i believe from ceilometer pov, we can add support to allow wildcard 
support in regards to adding new metrics.

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] [Fuel][library] relax downstream policy for puppet modules managed by librarian

[Aleksandr Didenko]

Hi,

one of cons: there might be delay in time when we need to apply a patch to
upstream project and thus fork some project (needs some time to prepare
patch to projects, get reviews and approves, etc). Having said that I vote
for "lazy downstreaming".

Regards,
Alex

On Fri, Jan 29, 2016 at 10:12 AM, Bogdan Dobrelya 
wrote:

> This is a continuation of the forked discussion [0].
>
> The idea is to relax Fuel-library downstream policy and implement a
> "lazy downstreaming", which is to not create a downstream fork of a
> puppet module referenced in the librarian Puppetfile unless we have to
> do so.
>
> The relaxed policy would unblock an upstream switching of the rabbitmq
> [1] and corosync [2] modules as well.
>
> Pros:
> - Reduced costs of maintaining downstream forks because of the laziness
> of the forking process. This much better distributes load to Fuel
> engineering and HW resources in time. Even though related tasks may be
> one-time, HW resources and network bandwidth shall not be wasted for
> keeping and cloning unnecessary forks (unless we have no choice but to
> fork things)
> -  A module might remain as direct upstream reference in the Puppetfile
> for quite a while. This as well shows an amount of the hidden technical
> debt in much more clean representation - downstream vs upstream refs in
> the Puppetfile.
> - Some generic, non OpenStack puppet modules will barely require
> backporting of separate patches by older tags as they work just
> straightforward and the latest version works for every supported Fuel
> release as well. Those would save resources because of the laziness of
> the relaxed process will never require to create downstream forks for
> such modules!
>
> Cons:
> - I see none. For "unlucky" modules, the *same* amount of work shall be
> done anyway, although with the lazy process in place it will be
> distributed in time much better.
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/085249.html
> [1] https://review.openstack.org/#/c/271217
> [2] https://review.openstack.org/#/c/273036/
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __
> OpenStack Development Mailing 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] [Fuel][Plugins] Tasks ordering between plugins

[Simon Pasquier]

On Fri, Jan 29, 2016 at 4:27 PM, Igor Kalnitsky 
wrote:

> Hey folks,
>
> Simon P. wrote:
> > 1. Run task X for plugin A (if installed).
> > 2. Run task Y for plugin B (if installed).
> > 3. Run task Z for plugin A (if installed).
>
> Simon, could you please explain do you need this at the first place? I
> can imagine this case only if your two plugins are kinda dependent on
> each other. In this case, it's better to do what was said by Andrew W.
> - set 'Task Y' to require 'Task X' and that requirement will be
> satisfied anyway (even if Task X doesn't exist in the graph).
>

Indeed, I didn't know that it was supported. I had the (false) impression
that required tasks had to exist in the first place.
If this works then it should be ok for me.


>
>
> Alex S. wrote:
> > Before we get rid of tasks.yaml can we provide a mechanism for plugin
> > devs could leverage to have tasks executes at specific points in the
> > deploy process.
>
> Yeah, I think that may be useful sometime. However, I'd prefer to
> avoid anchor usage as much as possible. There's no guarantees that
> other plugin didn't make any destructive actions early, that breaks
> you later. Anchors is good way to resolve possible conflicts, but they
> aren't bulletproof.
>
> - igor
>
> On Thu, Jan 28, 2016 at 1:31 PM, Bogdan Dobrelya 
> wrote:
> > On 27.01.2016 14:44, Simon Pasquier wrote:
> >> Hi,
> >>
> >> I see that tasks.yaml is going to be deprecated in the future MOS
> >> versions [1]. I've got one question regarding the ordering of tasks
> >> between different plugins.
> >> With tasks.yaml, it was possible to coordinate the execution of tasks
> >> between plugins without prior knowledge of which plugins were installed
> [2].
> >> For example, lets say we have 2 plugins: A and B. The plugins may or may
> >> not be installed in the same environment and the tasks execution should
> be:
> >> 1. Run task X for plugin A (if installed).
> >> 2. Run task Y for plugin B (if installed).
> >> 3. Run task Z for plugin A (if installed).
> >>
> >> Right now, we can set task priorities like:
> >>
> >> # tasks.yaml for plugin A
> >> - role: ['*']
> >>   stage: post_deployment/1000
> >>   type: puppet
> >>   parameters:
> >> puppet_manifest: puppet/manifests/task_X.pp
> >> puppet_modules: puppet/modules
> >>
> >> - role: ['*']
> >>   stage: post_deployment/3000
> >>   type: puppet
> >>   parameters:
> >> puppet_manifest: puppet/manifests/task_Z.pp
> >> puppet_modules: puppet/modules
> >>
> >> # tasks.yaml for plugin B
> >> - role: ['*']
> >>   stage: post_deployment/2000
> >>   type: puppet
> >>   parameters:
> >> puppet_manifest: puppet/manifests/task_Y.pp
> >> puppet_modules: puppet/modules
> >>
> >> How would it be handled without tasks.yaml?
> >
> > I created a kinda related bug [0] and submitted a patch [1] to MOS docs
> > [2] to kill some entropy on the topic of tasks schema roles versus
> > groups and using wildcards for basic and custom roles from plugins as
> > well. There is also a fancy picture to clarify things a bit. Would be
> > nice to put more details there about custom stages as well!
> >
> > If plugins are not aware of each other, they cannot be strictly ordered
> > like "to be the very last in the deployment" as one and only shall be
> > so. That is why "coordinating the execution of tasks
> > between plugins without prior knowledge of which plugins were installed"
> > looks very confusing for me. Though, maybe wildcards with the "skipped"
> > task type may help to organize things better?
> >
> > Perhaps the Fuel plugins team could answer the question better.
> >
> > [0] https://bugs.launchpad.net/fuel/+bug/1538982
> > [1] https://review.fuel-infra.org/16509
> > [2]
> >
> https://docs.mirantis.com/openstack/fuel/fuel-7.0/reference-architecture.html#task-based-deployment
> >
> >>
> >> Regards,
> >> Simon
> >>
> >> [1] https://review.openstack.org/#/c/271417/
> >> [2]
> https://wiki.openstack.org/wiki/Fuel/Plugins#Plugins_deployment_order
> >>
> >>
> >>
> __
> >> OpenStack Development Mailing 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,
> > Bogdan Dobrelya,
> > Irc #bogdando
> >
> >
> __
> > OpenStack Development Mailing 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
> 

[openstack-dev] [infra] Gate is broken

[Michael Krotscheck]

Hey everyone!

Since the summit submission deadline is this weekend, we (the infra team)
have decided that it's an excellent time to break all of our slaves, so you
can go and submit your talks for Austin!

That certainly sounds better than "We misconfigured pip.conf and now none
of our nodes know how to pip install.". A fix has been merged, however it
will take some time to propagate. We will keep you updated on this thread
and on IRC.

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

Re: [openstack-dev] [infra] Gate is broken

[Paul Michali]

Thanks for hopping on it quickly!



On Fri, Jan 29, 2016 at 10:41 AM Michael Krotscheck 
wrote:

> Hey everyone!
>
> Since the summit submission deadline is this weekend, we (the infra team)
> have decided that it's an excellent time to break all of our slaves, so you
> can go and submit your talks for Austin!
>
> That certainly sounds better than "We misconfigured pip.conf and now none
> of our nodes know how to pip install.". A fix has been merged, however it
> will take some time to propagate. We will keep you updated on this thread
> and on IRC.
>
> Michael
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [oslo] nominating Alexis Lee for oslo-core

[Flavio Percoco]

On 29/01/16 10:08 -0500, Doug Hellmann wrote:

Excerpts from Davanum Srinivas (dims)'s message of 2016-01-29 06:17:39 -0600:

Matt,

yes, that's a concern for sure. We work closely with all the new Oslo
cores to defer to experts first and learn. This goes into the debate
about the right mixture of Generalists and Specialists in the project
as well.


Right. I trust everyone on the team to exercise judgment when
choosing which patches to review, and how to review them. I proposed
Alexis for oslo-core rather than oslo-config-core because his general
approach and collaboration on the config work he has already done
convinced me that my trust would not be misplaced. The fact that
we don't actually have a separate oslo-config-core group in gerrit
is an oversight, and didn't enter into it.


++

The oslo team is diverse in skills and projects to work on. I trust everyone to
respect other projects and focus on the things they have expertise on. OpenStack
and Oslo are complex enough to add an extra layer of granularity in roles and
permissions. We already do this in other teams within the same code base. It is
just more evident in Oslo because there are more, smaller, projects.

Flavio



Doug



Thanks,
Dims

On Fri, Jan 29, 2016 at 5:42 AM, Matt Riedemann
 wrote:
>
>
> On 1/29/2016 11:33 AM, Davanum Srinivas wrote:
>>
>> Matt,
>>
>> yes, Nomination is for oslo-core. We would like to expand the core
>> group as well in addition to subject matter experts (example Dmitry
>> Uklhov for Oslo.Messaging core yesterday). The hope and expectation is
>> that Alexis would expand his reviews and expertise across all Oslo
>> projects over a period of time.
>>
>> Thanks,
>> Dims
>>
>> On Fri, Jan 29, 2016 at 5:24 AM, Matt Riedemann
>>  wrote:
>>>
>>>
>>>
>>> On 1/28/2016 10:05 PM, Doug Hellmann wrote:


 I am nominating Alexis Lee (lxsli) for oslo-core.

 Alexis has been working on adding configuration file reloading to
 oslo.config this cycle. The work isn't complete, but at this point
 he probably knows as much or more about the internals of that library
 as any of us. :-) He has also shown, with some of his other recent
 proposals, that he has a ideas for the future of configuration
 management and an interest in contributing to Oslo.

 Please indicate yea or nay with the usual +1/-1 vote here.

 Doug



 
http://stackalytics.com/?release=all_type=all=commits_id=alexisl


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

>>>
>>> As an outsider, this is just a question, but I don't see an
>>> oslo-config-core
>>> group. I'm assuming that because of lxsli's work on oslo.config this
>>> nomination is coming up, but is the nomination for oslo-core, as in all
>>> of
>>> the oslo projects? Including things like oslo.versionedobjects and
>>> oslo.messaging?
>>>
>>> I'm just wondering how things get broken down because there are obviously
>>> subject matter experts in certain projects in oslo, but I wouldn't
>>> consider
>>> them as being cores across all projects just because they are core on
>>> one.
>>> Or am I misunderstanding?
>>>
>>> --
>>>
>>> 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
>>
>>
>>
>>
>
> So people are made core and then expected to become experts on the other
> projects? I get that is a carrot, but it seems like that could put the stick
> on the consuming projects if non-expert cores are approving changes they
> shouldn't be.
>
> Anyway, my two cents...
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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


--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [telemetry][ceilometer] New project: collectd-ceilometer-plugin

[Julien Danjou]

On Fri, Jan 29 2016, Foley, Emma L wrote:

> Supporting statsd would require some more investigation, as collectd's
> statsd plugin supports reading stats from the system, but not writing
> them.

I'm not sure what that means?
https://collectd.org/wiki/index.php/Plugin:StatsD seems to indicate it
can send metrics to a statsd daemon.

>  Also, what are the usage figures for gnocchi?

42?
Not sure what that means :)

> How many people use it, and how easy is it to convert existing
> deployments to use gnocchi?

We don't know how many people are using it, as usual people barely
communicate on their usage and we only know a few operators we are
working with.
There's no conversion tool as of today that I am aware of.

> I mean, if someone was upgrading, would their data be preserved?

It's not an upgrade, it'd be a migration.
So far nobody ever asked for migrating any data, considering it's
simpler to store to Ceilometer database and Gnocchi at the same time for
a while, and then ditch Ceilometer database.

> How easy is it to consume gnocchi statistics using an external
> system/application?

There's a complete REST API documented online at:

  http://gnocchi.xyz/rest.html

I'd say it's pretty easy, but I am not objective obviously.

> I'm not against the idea, but it requires a little more consideration.

Against which idea exactly?

I'm not even sure what you're trying to do and why you're doing in the
first place, so I was just throwing alternative ideas for the sake of
it.

Cheers,
-- 
Julien Danjou
;; Free Software hacker
;; https://julien.danjou.info


signature.asc
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] [oslo] nominating Alexis Lee for oslo-core

[Julien Danjou]

On Fri, Jan 29 2016, Doug Hellmann wrote:

> Right. I trust everyone on the team to exercise judgment when
> choosing which patches to review, and how to review them. I proposed
> Alexis for oslo-core rather than oslo-config-core because his general
> approach and collaboration on the config work he has already done
> convinced me that my trust would not be misplaced. The fact that
> we don't actually have a separate oslo-config-core group in gerrit
> is an oversight, and didn't enter into it.

I think that summarizes pretty well how our policy which is "forgiveness
rather than permission".

It really works well, everyone should try it. :-)

-- 
Julien Danjou
/* Free Software hacker
   https://julien.danjou.info */


signature.asc
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] [oslo] nominating Alexis Lee for oslo-core

[Sylvain Bauza]

Le 29 janv. 2016 18:45, "Julien Danjou"  a écrit :
>
> On Fri, Jan 29 2016, Doug Hellmann wrote:
>
> > Right. I trust everyone on the team to exercise judgment when
> > choosing which patches to review, and how to review them. I proposed
> > Alexis for oslo-core rather than oslo-config-core because his general
> > approach and collaboration on the config work he has already done
> > convinced me that my trust would not be misplaced. The fact that
> > we don't actually have a separate oslo-config-core group in gerrit
> > is an oversight, and didn't enter into it.
>
> I think that summarizes pretty well how our policy which is "forgiveness
> rather than permission".
>
> It really works well, everyone should try it. :-)
>

While my heart is about that, my brain thinks about some regressions could
be happening because of a +W even for a small change.

The problem with most of the projects is that fixing a regression is not
sometimes easy. Think of a DB migration, an o.vo Object being bumped or a
RPC or REST API change as examples.

Even if libraries are not related to that, think how a very small change in
a library can just wedge all our gate and how our history showed us that
fixing that is most of the time much harder in comparison.

I'm not opiniated about the proposal made, I just want to express that
things are not so easy.

-Sylvain

> --
> Julien Danjou
> /* Free Software hacker
>https://julien.danjou.info */
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Fuel][library] relax downstream policy for puppet modules managed by librarian

[Alex Schultz]

On Fri, Jan 29, 2016 at 2:12 AM, Bogdan Dobrelya  wrote:
> This is a continuation of the forked discussion [0].
>
> The idea is to relax Fuel-library downstream policy and implement a
> "lazy downstreaming", which is to not create a downstream fork of a
> puppet module referenced in the librarian Puppetfile unless we have to
> do so.
>

So what exactly would be the change to the policy? Just allowing for
different source git repo?

Currently, we have basically been enforcing the following:
1) requiring a fuel-infra mirror
2) requiring a tag

See https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules

This is being validated by the verify-fuel-library-puppetfile fuel-ci
job.  See 
https://github.com/openstack/fuel-library/blob/master/utils/jenkins/fuel_validate_puppetfile.rb

If the change you're proposing is to just relax the first requirement,
I could agree with that.  If it's to allow for the relaxing of both,
then no I don't agree. When we first switched to using using a
Puppetfile, we had discussions specifically around the tag requirement
and that is there to ensure that when we build we are always pulling
in the same expected version for every build.  While we could support
a hash instead of a tag, I would prefer that we not do that.

> The relaxed policy would unblock an upstream switching of the rabbitmq
> [1] and corosync [2] modules as well.
>
> Pros:
> - Reduced costs of maintaining downstream forks because of the laziness
> of the forking process. This much better distributes load to Fuel
> engineering and HW resources in time. Even though related tasks may be
> one-time, HW resources and network bandwidth shall not be wasted for
> keeping and cloning unnecessary forks (unless we have no choice but to
> fork things)

We aren't maintaining forks for every module, we are using normal git
sync processes to pull in the tags from the upstream modules as well.
This is completely hands off so we're not managing tags for most
upstream modules, and these days I think we're only creating tags and
managing some minor forks only the openstack modules.  And this is
primarily because the upstream openstack modules do not get new tags
the previous stable versions.  I think we only have maybe 4 commits
that are being maintained across 2 or 3 of the modules? The puppet
guys have a list.  Doing a quick look, it appears we're managing 18
custom tags (13 of which are openstack modules) and relying on 17
upstream tags.

> -  A module might remain as direct upstream reference in the Puppetfile
> for quite a while. This as well shows an amount of the hidden technical
> debt in much more clean representation - downstream vs upstream refs in
> the Puppetfile.

I'm not sure how this is addressed by using the upstream source repo
and a tagged version. This is the same problem with any versions. The
only way this gets fixed is to switch to branches across the board and
deal with the changes that pop up or have a periodic job that tests
this. But this completely violates what we agreed to when we switched
to librarian in the first place.

> - Some generic, non OpenStack puppet modules will barely require
> backporting of separate patches by older tags as they work just
> straightforward and the latest version works for every supported Fuel
> release as well. Those would save resources because of the laziness of
> the relaxed process will never require to create downstream forks for
> such modules!

What resources are we saving?  We don't create forks unless we need
to. We're using tags, it's just that the git repo is not the original
source because of the policy we put in place when we switched to
librarian.  And like I said, I'm a little more flexible on that part.

>
> Cons:
> - I see none. For "unlucky" modules, the *same* amount of work shall be
> done anyway, although with the lazy process in place it will be
> distributed in time much better.
>

A large con is that we're moving the work of creating a mirror (not
necessarily a fork as you call it), from the front of the dev cycle
when we have more time to the end where we're in a pinch because we've
run across something that evidently needs to be fixed asap.  Getting a
mirror created is currently just a ticket to fuel-infra...

As I've stated multiple times now, I tend to agree with the premise of
this proposal but it needs to be thought out and well defined as to
what we are expecting and what should be enforced. Today we have a
process that is 1) documented, 2) tested in CI, and 3) has workflows
and infrastructure to support it. I'd like to see more concrete
details on what changes you're proposing and make sure we properly
understand the impact from these changes as part of the development
process.

The reason why in the previous thread I mentioned the
upstream/downstream items needs to be solidified before this policy
change is that I believe the current policy should turn into the
downstream policy and the upstream fuel policy 

Re: [openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?

[Kevin Carter]

Thanks Bailey for the update. I intend to look over more of what you 
folks have published really soon. Thanks again for putting all of this 
out there and I hope to work with you and the team soon on more of the 
convergence pieces.

I don't know if you or any of your team are headed to the OPS and or 
OpenStack-Ansible midcycles in February but I'll be there and would love 
the opportunity to work with folks while we're all in person.

Thanks again for publishing and have a good weekend.

-- 

Kevin Carter
IRC: Cloudnull

On 01/29/2016 01:30 PM, Bailey, Darragh wrote:
> Hi,
>
>
> Those present at some of the Ansible collaboration sessions at Tokyo may
> recall a mention about Helion Lifecycle Manager (HLM), which constituted
> a collection of ansible playbooks and particular patterns used by the
> HPE Helion OS 2.0 release to deploy clouds.
>
> We promised at the time that we'd get the code out there to start some
> discussions on where we could collaborate better with openstack-ansible.
>
> I've already mentioned it to a few folks in IRC, however I think it's
> worth sharing out a bit further.
>
> The initial code for the difference ansible components has been uploaded
> to GitHub under https://github.com/hpe-helion-os earlier this month.
>
>
> https://github.com/hpe-helion-os/helion-input-model
> Defines a cloud though a combination of service input definitions
> (relatively static) and a topology that controls how network and the
> services are laid out control the shape and size of the cloud desired.
>
>
> https://github.com/hpe-helion-os/helion-configuration-processor
> The processing engine that consumes the desired cloud topology
> configuration from the input model, and generates all the hosts and
> variables that are consumed by the ansible playbooks/roles to deploy the
> requested cloud.
>
>
> https://github.com/hpe-helion-os/helion-ansible
> Contains all the ansible playbooks/roles used to deploy HPE's HOS 2.0.
> This is run against the output of the helion-configuration-processor to
> execute the build/upgrade of the cloud specification.
>
>
> Obviously lots of discussions to be had and work to be done, and
> hopefully with some help we should have a good idea by Austin as to what
> will be needed to integrate some of the concepts into the existing
> openstack-ansible project.
>
>
> Enjoy the weekend :-)
>


__
OpenStack Development Mailing 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] [Cinder] Nominating Patrick East to Cinder Core

[Sean McGinnis]

Patrick has been a strong contributor to Cinder over the last few releases, 
both with great code submissions and useful reviews. He also participates 
regularly on IRC helping answer questions and providing valuable feedback.

I would like to add Patrick to the core reviewers for Cinder. Per our 
governance process [1], existing core reviewers please respond with any 
feedback within the next five days. Unless there are no objections, I will add 
Patrick to the group by February 3rd.

Thanks!

Sean (smcginnis)

[1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess

__
OpenStack Development Mailing 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][LBaaS][Octavia] Using nova interface extension instead of networks extension

[Eichberger, German]

All,

In a recent patch [1] Bharath and I proposed to replace the call to the nova 
os-networks extension with a call to the nova-interface extension. Apparently 
os-networks is geared towards nova networks and us being neutron I see no 
reason to continue to support it. I have taken to the ML to gather feedback if 
there are cloud operators which don’t have/won't  the nova interface extension 
enabled and need us to support os-networks in Mitaka and beyond.

Thanks,
German

[1] https://review.openstack.org/#/c/273733/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

Re: [openstack-dev] [Neutron] OVS flow modification performance

[Wuhongning]

By our testing, ryu openflow has greatly improved the performance, with 500 
port vxlan flow table, from 15s to 2.5s, 6 times better.

From: IWAMOTO Toshihiro [iwam...@valinux.co.jp]
Sent: Monday, January 25, 2016 5:08 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] OVS flow modification performance

At Thu, 21 Jan 2016 02:59:16 +,
Wuhongning wrote:
>
> I don't think 400 flows can show the difference , do you have setup any 
> tunnel peer?
>
> In fact we may set the network type as "vxlan", then make a fake MD simulate 
> sending l2pop fdb add messages, to push ten's of thousands flows into the 
> testing ovs agent.

I chose this method because I didn't want to write such extra code for
measurements. ;)
Of course, I'd love to see data from other test environments and other
workload than agent restarts.

Also, we now have https://review.openstack.org/#/c/271939/ and can
profile neutron-server (and probably others, too).
I couldn't find non-trivial findings until now, though.

> 
> From: IWAMOTO Toshihiro [iwam...@valinux.co.jp]
> Sent: Monday, January 18, 2016 4:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] OVS flow modification performance
>
> At Mon, 18 Jan 2016 00:42:32 -0500,
> Kevin Benton wrote:
> >
> > Thanks for doing this. A couple of questions:
> >
> > What were your rootwrap settings when running these tests? Did you just
> > have it calling sudo directly?
>
> I used devstack's default, which runs root_helper_daemon.
>
> > Also, you mention that this is only ~10% of the time spent during flow
> > reconfiguration. What other areas are eating up so much time?
>
>
> In another run,
>
> $ for f in `cat tgidlist.n2`; do echo -n $f; opreport -n tgid:$f --merge 
> tid|head -1|tr -d '\n'; (cd bg; opreport -n tgid:$f --merge tid|head 
> -1);echo; done|sort -nr -k +2
> 10071   239058 100.000 python2.714922 100.000 python2.7
> 999592328 100.000 python2.711450 100.000 python2.7
> 757988202 100.000 python2.7(18596)
> 1109451560 100.000 python2.747964 100.000 python2.7
> 703549687 100.000 python2.740678 100.000 python2.7
> 1109349380 100.000 python2.736004 100.000 python2.7
> (legend:
>  )
>
> These processes are neutron-server, nova-api,
> neutron-openvswitch-agent, nova-conductor, dstat and nova-conductor in
> a decending order.
>
> So neutron-server uses about 3x CPU time than the ovs agent,
> nova-api's CPU usage is similar to the ovs agent's, and the others
> aren't probably significant.
>
> > Cheers,
> > Kevin Benton
> >
> > On Sun, Jan 17, 2016 at 10:12 PM, IWAMOTO Toshihiro 
> > wrote:
> >
> > > I'm sending out this mail to share the finding and discuss how to
> > > improve with those interested in neutron ovs performance.
> > >
> > > TL;DR: The native of_interface code, which has been merged recently
> > > and isn't default, seems to consume less CPU time but gives a mixed
> > > result.  I'm looking into this for improvement.
> > >
> > > * Introduction
> > >
> > > With an ML2+ovs Neutron configuration, openflow rule modification
> > > happens often and is somewhat a heavy operation as it involves
> > > exec() of the ovs-ofctl command.
> > >
> > > The native of_interface driver doesn't use the ovs-ofctl command and
> > > should have less performance impact on the system.  This document
> > > tries to confirm this hypothesis.
> > >
> > >
> > > * Method
> > >
> > > In order to focus on openflow rule operation time and avoid noise from
> > > other operations (VM boot-up, etc.), neutron-openvswitch-agent was
> > > restarted and the time it took to reconfigure the flows was measured.
> > >
> > > 1. Use devstack to start a test environment.  As debug logs generate
> > >considable amount of load, ENABLE_DEBUG_LOG_LEVEL was set to false.
> > > 2. Apply https://review.openstack.org/#/c/267905/ to enable
> > >measurement of flow reconfiguration times.
> > > 3. Boot 80 m1.nano instances.  In my setup, this generates 404 br-int
> > >flows.  If you have >16G RAM, more could be booted.
> > > 4. Stop neutron-openvswitch-agent and restart with --run-once arg.
> > >Use time, oprofile, and python's cProfile (use --profile arg) to
> > >collect data.
> > >
> > > * Results
> > >
> > > Execution time (averages of 3 runs):
> > >
> > > native 28.3s user 2.9s sys 0.4s
> > > ovs-ofctl  25.7s user 2.2s sys 0.3s
> > >
> > > ovs-ofctl runs faster and seems to use less CPU, but the above doesn't
> > > count in execution time of ovs-ofctl.
> > >
> > > Oprofile data collected by running "operf -s -t" contain the
> > > information.
> > >
> > > With of_interface=native config, "opreport tgid:" shows:
> > >
> > >samples|  %|
> > > --
> > > 87408 100.000 python2.7
> > > 

Re: [openstack-dev] [cinder] Testing Cinder upgrades - c-bak upgrade

[Michał Dulko]

On 01/20/2016 09:11 PM, Li, Xiaoyan wrote:
> @ DuncanT and @dule: 
>
> I noticed from IRC log that you are discussing about c-bak upgrade, and I am 
> working on this, please see following message. Hope I don't miss anything.
>
> As you know, currently c-bak and c-vol are in same nodes. c-bak depends on 
> c-vol service. 
>
> But it is not necessary that all c-vols needs to be upgraded before c-backs.
>
> The sequences can be random. As described in the patch 
> https://review.openstack.org/#/c/269412/,
> when c-api decides which c-bak service to create/restore, it checks the 
> version of c-vol. If c-vol is new version, find a c-bak in new version.
> If c-vol is in old version, find a c-bak in old version.
>
> Let's us think a real case. Customers upgrade c-api, c-sch, and start to 
> upgrade c-vol and c-bak.
> There are two c-vol services c-vol1 and c-vol2, and two c-bak services c-bak1 
> and c-bak2.
> There are four typical upgrade sequences as following. 
> Meanwhile, please notice that c-vol and c-bak are in same nodes in Liberty. 
> So during upgrades, if c-vol went down to upgrade, c-bak is also down. 

It's not exactly like that. You may upgrade services on a single node
one-by-one if you're for example running them in containers.

> 1. c-vol1->c-bak1->c-vol2->c-bak2
> The only insufficiency is when c-vol1 upgrades, and other c-bak services 
> haven't upgraded, the request to create/restore backups from/to volumes in 
> c-vol1 will fail with reason "no valid c-bak service
> found". It is acceptable, as it is similar to scenario in Liberty: c-vol 
> active and c-bak fails.
>
> 2. c-vol1->c-vol2->c-bak1->c-bak2
> Before c-bak1 upgrades, no back request can be completed as no active c-bak 
> services. This is reasonable.
>
> 3. c-bak1->c-vol1->c-bak2->c-vol2:
> The issue is when c-bak2 upgrades, the request to create/restore backups 
> from/to volumes in c-vol2 will fail with reason c-vol not active. This is 
> consistent with behaviors in Liberty.
>
> 4. c-bak1->c-bak2->c-vol1->c-vol2: 
> Before c-vol1 upgrades, no back request can be completed as c-vol services 
> not active This is reasonable.

Resolution on this matter from the Cinder mid-cycle is that we're fine
as long as we safely fail in case of upgrade conducted in an improper
order. And it seems we can implement that in a simple way by raising an
exception from volume.rpcapi when c-vol is pinned to a version too old.
This means that scalable backup patches aren't blocked by this issue.


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

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

[Jeremy Stanley]

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

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

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

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

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

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

Re: [openstack-dev] [openstack-ansible][designate] : Ansible Designate Role : NoEndpointFound error

[Jimmy McCrory]

Hi Swati,

It looks designate_service_setup.yml

is
not currently included in your role's main play, so the keystone service,
user, and endpoint are not being created.

On Fri, Jan 29, 2016 at 4:11 AM, Sharma Swati6 
wrote:

> Hi Venkata,
>
> Thanks for your prompt response.
>
> We are using designate 1.5.0
>
> From the below links, I have added the code from
> https://review.openstack.org/#/c/199067/1/designateclient/shell.py as
> well.
>
> Also, in the link --publicurl is mentioned as
> http://controller.dmgweb.es:9001/v1 . But, soemwhere else I read it
> should be without versions. So when I do endpoint-list, I see publicurl in
> my system as http://10.16.34.6:9001/
>
> I still get the error
>
> * "ERROR: No endpoint was found. Missing credentials?"*My openrc content
> is as follows-
>
> export LC_ALL=C
>
> # COMMON CINDER ENVS
> export CINDER_ENDPOINT_TYPE=internalURL
>
> # COMMON NOVA ENVS
> export NOVA_ENDPOINT_TYPE=internalURL
>
> # COMMON OPENSTACK ENVS
> export OS_ENDPOINT_TYPE=internalURL
> export OS_USERNAME=admin
> export OS_PASSWORD=vK26yJAtoS9gCR0tjjoFHFx9iudUjVDr
> export OS_PROJECT_NAME=admin
> # NOTE(sigmavirus24): The tenant name setting should be removed when
> # python-cinderclient stops checking for it and failing if it doesn't
> exist.
> export OS_TENANT_NAME=admin
> export OS_AUTH_URL=http://10.16.34.6:5000/v3
> export OS_NO_CACHE=1
> export OS_USER_DOMAIN_NAME=Default
> export OS_PROJECT_DOMAIN_NAME=Default
>
> # For openstackclient
> export OS_IDENTITY_API_VERSION=3
> export OS_AUTH_VERSION=3
>
> Thanks & Regards
> Swati Sharma
> System Engineer
> Tata Consultancy Services
> Ground to 8th Floors, Building No. 1 & 2,
> Skyview Corporate Park, Sector 74A,NH 8
> Gurgaon - 122 004,Haryana
> India
> Cell:- +91-9717238784
> Mailto: sharma.swa...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 
>
>
> -"Jonnalagadda, Venkata"  wrote:
> -
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> From: "Jonnalagadda, Venkata" 
> Date: 01/29/2016 02:12PM
> Cc: Pandey Preeti1 , Partha Datta <
> partha.da...@tcs.com>
> Subject: Re: [openstack-dev] [openstack-ansible][designate] : Ansible
> Designate Role : NoEndpointFound error
>
>
> Swati,
>
>
>
> It seems this is a known issue with keystone tool when there are changes
> to it. Have a look at below links for your problem to resolve temporarily
> ie., set endpoint for –os-endpoint :
>
>
>
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-06-17.log.html
>
> https://bugs.launchpad.net/python-designateclient/+bug/1415560
>
> https://bugs.launchpad.net/python-designateclient/+bug/1466265
>
>
>
> Try it out..
>
>
>
>
>
> *Thanks & Regards,*
>
>
>
> *J. Venkata Mahesh*
>
> [image: cid:image001.gif@01D0E644.243D34E0]
>
>
>
> *From:* Sharma Swati6 [mailto:sharma.swa...@tcs.com]
> *Sent:* Friday, January 29, 2016 1:44 PM
> *To:* openstack-dev@lists.openstack.org
> *Cc:* Pandey Preeti1 ; Partha Datta <
> partha.da...@tcs.com>
> *Subject:* [openstack-dev] [openstack-ansible][designate] : Ansible
> Designate Role : NoEndpointFound error
> *Importance:* High
>
>
>
>
> Hi Folks,
>
> This is regarding  a new specification :
> https://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/role-designate.html
>
> While the Designate services seem to up and running now in its container,
> I am stuck up with one last issue for the designate endpoint
> "EndpointNotFound". Whenever I run any designate related command after
> sourcing the openrc, I get this error.  Snapshot also attached.
>
> Many of them have reported the same issue at
> http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-05-21.log.html
> and 
> http://eavesdrop.openstack.org/irclogs/%23openstack-dns/%23openstack-dns.2015-06-17.log.html
> .
> 
>
> Some of these files are uploaded here:
> https://github.com/sharmaswati6/designate_files
>
> Kindly let me know if you can help me with this to speed up the delivery.
>
> Thanks & Regards
> Swati Sharma
> System Engineer
> Tata Consultancy Services
> Ground to 8th Floors, Building No. 1 & 2,
> Skyview Corporate Park, Sector 74A,NH 8
> Gurgaon - 122 004,Haryana
> India
> Cell:- +91-9717238784
> Mailto: sharma.swa...@tcs.com
> Website: http://www.tcs.com
> 
> Experience certainty. IT Services
> Business Solutions
> Consulting
> 

[openstack-dev] [openstack-ansible] Helion HLM on GitHub and what next?

[Bailey, Darragh]

Hi,


Those present at some of the Ansible collaboration sessions at Tokyo may
recall a mention about Helion Lifecycle Manager (HLM), which constituted
a collection of ansible playbooks and particular patterns used by the
HPE Helion OS 2.0 release to deploy clouds.

We promised at the time that we'd get the code out there to start some
discussions on where we could collaborate better with openstack-ansible.

I've already mentioned it to a few folks in IRC, however I think it's
worth sharing out a bit further.

The initial code for the difference ansible components has been uploaded
to GitHub under https://github.com/hpe-helion-os earlier this month.


https://github.com/hpe-helion-os/helion-input-model
Defines a cloud though a combination of service input definitions
(relatively static) and a topology that controls how network and the
services are laid out control the shape and size of the cloud desired.


https://github.com/hpe-helion-os/helion-configuration-processor
The processing engine that consumes the desired cloud topology
configuration from the input model, and generates all the hosts and
variables that are consumed by the ansible playbooks/roles to deploy the
requested cloud.


https://github.com/hpe-helion-os/helion-ansible
Contains all the ansible playbooks/roles used to deploy HPE's HOS 2.0.
This is run against the output of the helion-configuration-processor to
execute the build/upgrade of the cloud specification.


Obviously lots of discussions to be had and work to be done, and
hopefully with some help we should have a good idea by Austin as to what
will be needed to integrate some of the concepts into the existing
openstack-ansible project.


Enjoy the weekend :-)

-- 
Regards,
Darragh Bailey

"Nothing is foolproof to a sufficiently talented fool" - Unknown



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] [oslo] nominating Alexis Lee for oslo-core

[Joshua Harlow]

Julien Danjou wrote:

On Fri, Jan 29 2016, Doug Hellmann wrote:


Right. I trust everyone on the team to exercise judgment when
choosing which patches to review, and how to review them. I proposed
Alexis for oslo-core rather than oslo-config-core because his general
approach and collaboration on the config work he has already done
convinced me that my trust would not be misplaced. The fact that
we don't actually have a separate oslo-config-core group in gerrit
is an oversight, and didn't enter into it.


I think that summarizes pretty well how our policy which is "forgiveness
rather than permission".

It really works well, everyone should try it. :-)


Are you implying that there are humans involved in all these processes 
and those humans can be trusted (unless proven otherwise)???!???!? 
Impossible! :-P


Disclaimer: the above is humor.




__
OpenStack Development Mailing 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][API] Question about HTTPNotImplementError

[Chen CH Ji]

In reading some API guide line doc [1] seems we should not return 501 to clientbut nova still doing so at API layer [2], any discussion before about this can be referred ? [1]https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#use-of-501---not-implemented[2]https://github.com/openstack/nova/blob/master/nova/api/openstack/common.py#L536


__
OpenStack Development Mailing 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][ec2api] - Official EC2 puppet module repo

[Emilien Macchi]

On 01/29/2016 10:35 AM, Marcos Fermin Lobo wrote:
> Hi,
> 
> Since I finished to "apply" for puppet-ec2api module as official puppet
> module in OpenStack (see https://review.openstack.org/#/c/252959/ and
> https://review.openstack.org/#/c/251857/), I saw that the puppet module
> repository is created https://github.com/openstack/puppet-ec2api
> 
> But the repository is still empty.

Yeah, you have two options:

#1 Import your code

If you do that, please iterate your patches so you'll have reviews more
quickly. You can look how puppet-mistral was created [1], I like the
iterative approach (step by step).

#2 Generate a new module with this procedure [2]

Run the procedure, and follow-up with new patches to add the classes
that you had in our module.

[1] https://review.openstack.org/#/q/project:openstack/puppet-mistral
[2] https://wiki.openstack.org/wiki/Puppet/New_module#On_the_technical_side

> (...)

Both approaches work for us, but please iterate with small chunks, which
is easier to test and review.


Thanks a lot for your efforts, very appreciated.
-- 
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] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

[gordon chung]

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

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

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

cheers,

-- 
gord


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

Re: [openstack-dev] [tripleo] use mitaka CI tested repo

[David Moreau Simard]

+1 for aligning efforts between Triple-O and RDO Manager around CI.

There's been a *lot* of work (trown++) towards RDO Manager CI and it'd
be great if Triple O could benefit from that.
Like Emilien said, our test coverage for promoting a set of packages
to "current-passed-ci" is huge already and will keep on improving.

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]


On Fri, Jan 29, 2016 at 10:42 AM, John Trowbridge  wrote:
>
>
> On 01/29/2016 09:40 AM, Dan Prince wrote:
>> On Fri, 2016-01-29 at 08:17 -0500, Emilien Macchi wrote:
>>> Hi,
>>>
>>> I'm wondering why don't we use Mitaka CI tested repository [1].
>>> IIRC, TripleO is currently using a snapshot which is updated
>>> asynchronously by TripleO CI folks.
>>> The problem is that we're not consistent with what RDO CI is testing.
>>> In
>>> my memory and tell me if I'm wrong but it happens we're using an old
>>> snapshot of packages which is older that is actually tested &
>>> verified
>>> by RDO CI.
>>>
>>> The benefit of using this tested repo would be:
>>> * this repository is already gated by Weirdo [2] which is running the
>>> same jobs as Puppet OpenStack CI.
>>> * you would not have less jobs failures, because RDO CI would have
>>> detected bugs before.
>>> * tripleo folks could focus a bit more on features & bugfixes in
>>> TripleO
>>> itself, rather than debugging CI issues and slowing down the review
>>> process.
>>> * Puppet OpenStack CI became really stable since we're using this
>>> repository. We have a very few number of issues since then.
>>>
>>> Though, something I don't like in my proposal:
>>> * tripleo would not bring short feedback to RDO folks if something is
>>> broken
>>>
>>> But is TripleO supposed to debug other projects in the same time?
>>> Don't
>>> we have enough challenges in our project?
>>>
>>> This would be a temporary solution I think, until TripleO would be
>>> part
>>> of other upstream project gate (nova, etc) maybe one day.
>>> But at this time, I honestly think TripleO (which is an installer)
>>> folks, spend too much time at debugging CI for some reasons that are
>>> related to projects outside tripleo (puppet modules, openstack bugs,
>>> packaging issues, etc).
>>>
>>> This is just a proposal and an idea to help TripleO folks to focus on
>>> their review process, instead of debugging CI failures every week.
>>
>> The problem I think is largly due to the fact that the RDO CI doesn't
>> test the same things we do in the TripleO CI. It is essentially a
>> different CI system.
>>
>> Because the CI systems are different different breakages happen when
>> you try to update one component vs. another. This is why we have to
>> maintain 'current-tripleo' separately between RDO and TripleO.
>>
>> I agree it would be nice if we could consolidate on a single repository
>> across these projects. It would allow us to focus on review more...
>> (less CI fixing).
>>
>> Perhaps a test matrix comparing the two CI systems would help us get
>> them closer to parity with what is covered. Even better would be just
>> simply contributing to the same CI systems and scripts.
>>
>
> I think contributing to the same scripts would be a big win. From the
> 'undercloud install' on, it is totally feasible for both CI systems to
> use the same script right now.
>
> I am working on using tripleo.sh in rdoci, which modulo the different
> environment setups, would get us to the above goal.
>
> If we could then get tripleoci consuming the same pre-built
> undercloud.qcow2 that rdoci is using[1], I think the environment
> differences would be negligible.
>
> [1]
> https://ci.centos.org/artifacts/rdo/images/mitaka/delorean/stable/undercloud.qcow2
>
>> Dan
>>
>>>
>>>
>>> Thanks for reading so far.
>>> Your feedback and comments are more than welcome.
>>>
>>> [1] http://trunk.rdoproject.org/centos7/current-passed-ci/delorean.re
>>> po
>>> [2] https://github.com/redhat-openstack/weirdo
>>> _
>>> _
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
>>> cribe
>>> 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 

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

[Jeremy Stanley]

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

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

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

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

[Jeremy Stanley]

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

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

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

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

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

Re: [openstack-dev] [oslo] nominating Ronald Bradford for oslo-core

[Rochelle Grober]

I'm not a voting member of the Oslo team, but a BIG

+1

>From me.

--Rocky

-Original Message-
From: Joshua Harlow [mailto:harlo...@fastmail.com] 
Sent: Thursday, January 28, 2016 11:38 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [oslo] nominating Ronald Bradford for oslo-core

Let's do it,

+1

-Josh

On 01/28/2016 05:41 PM, Davanum Srinivas wrote:
> +1 from me!
>
> -- Dims
>
> On Thu, Jan 28, 2016 at 4:00 PM, Doug Hellmann  wrote:
>> I am nominating Ronald Bradford (rbradfor) for oslo-core.
>>
>> Ronald has been working this cycle to learn about oslo.context,
>> oslo.log, and oslo.config. He anticipates picking up the much-needed
>> work on the app-agnostic-logging blueprint, and has already started
>> making incremental changes related to that work.  He has also
>> contributed to the documentation generation and sample generator
>> in oslo.config. His understanding of the code, our backwards-compatibility
>> requirements, and the operational needs related to configuration
>> and logging will make him a valuable addition to the team.
>>
>> Please indicate yea or nay with the usual +1/-1 vote here.
>>
>> Doug
>>
>> http://stackalytics.com/?release=all_type=all_id=ronaldbradford
>>
>>
>> __
>> OpenStack Development Mailing 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