date:20161004

Excerpts from Ed Leafe's message of 2016-10-04 16:38:50 -0500:
> On Oct 4, 2016, at 4:21 PM, Doug Hellmann  wrote:
> 
> >> 1) Allow time between the nominations and the voting. Half of the 
> >> candidates don’t announce until the last day or two, and that doesn’t 
> >> leave very much time to get to know them.
> > 
> > It seems like a reasonable idea, but why limit the period where we
> > discuss these "big issues" to a week or so every 6 months?
> 
> Well, we can (and should) certainly discuss issues as they arise. But the 
> nature of electing a representative is periodic, so that you can get back to 
> your job, and let those who are elected do the actual work. If the 
> conversations aren’t happening when the people who are voting are most likely 
> to be paying attention, then it’s just a small group talking amongst 
> themselves. And those elected may not represent the voters as well as they 
> might.

It's definitely a tough thing to balance. I can understand that not
everyone has the same amount of time (or interest) to spend on the
issues, of course.  So far the TC has avoided rushing any given
decision to give space for discussion and input from as many sources
as possible.  I'm not opposed to a focused period of time for
discussions around elections, but I guess I hope for folks to be a
little more engaged throughout the cycle.

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] [telemetry] Deprecating the Ceilometer API

2016-10-04 Thread Mehdi Abaakouk




Le 2016-10-04 18:09, gordon chung a écrit :

On 04/10/2016 11:58 AM, Tim Bell wrote:
What would be the impact for Heat users who are using the Ceilometer 
scaling in their templates?


Tim


pretty big. :/


The use-case itself is still supported.

Using Ceilometer alarming or Aodh alarming is transparent from the Heat 
template point of view, Heat already does the API calls to endpoint 
found in Keystone.


For the storage, Heat users can move their storage to Gnocchi and 
updates their templates to create in Aodh, Gnocchi alarms instead of 
legacy Ceilometer alarms.


I agree with gordc, this is not a light change. But well the old 
Ceilometer storage don't work at scale, each alarm evaluation take a lot 
of times and CPU to retrieve statistics from the old storage, while it's 
very quick when Gnocchi is used.


Keeping the old storage system for the autoscaling use-case doesn't make 
sense to me.


Also we have a integration gating job that tests the 
Heat+Ceilometer+Aodh+Gnocchi since two cycles. While the previous/legacy 
Ceilometer scaling system never had functional/integration tests.



--
Mehdi Abaakouk
mail: sil...@sileht.net
irc: sileht

__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread Ed Leafe

On Oct 4, 2016, at 4:21 PM, Doug Hellmann  wrote:

>> 1) Allow time between the nominations and the voting. Half of the candidates 
>> don’t announce until the last day or two, and that doesn’t leave very much 
>> time to get to know them.
> 
> It seems like a reasonable idea, but why limit the period where we
> discuss these "big issues" to a week or so every 6 months?

Well, we can (and should) certainly discuss issues as they arise. But the 
nature of electing a representative is periodic, so that you can get back to 
your job, and let those who are elected do the actual work. If the 
conversations aren’t happening when the people who are voting are most likely 
to be paying attention, then it’s just a small group talking amongst 
themselves. And those elected may not represent the voters as well as they 
might.

-- Ed Leafe

__
OpenStack Development Mailing 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] Deprecating the Ceilometer API

On 04/10/2016 12:35 PM, Julien Danjou wrote:
> On Tue, Oct 04 2016, gordon chung wrote:
>
>> so one thing we probably do need to keep is the ability push samples
>> (and events?). i know previously people were actually using this feature.
>
> That's debatable.
>
> Pushing events is IMHO out of scope of Ceilometer – it's related to
> oslo.messaging notification at this point. So if we want to allow that
> via an API endpoint, we should build one in OpenStack over
> oslo.messaging. Good idea or not, I don't know.
>
> Pushing samples is probably doable with some kind of small API, but I am
> not sure it's worth anything. You could still directly push the data to
> Gnocchi and save some you some load. Unless you have transformers to
> apply, but… really?

i don't know reasoning but agreed, it's more useful if available 
generically from something else.

i'll throw another idea out there, this relates to what stevelle 
suggested (i think it was him). an api to see live view of services: 
amount of messages it's processing at moment, queue sizes, what 
pollsters are enabled, maybe be able to dynamically load/remove 
pollsters, agent state. if i was not lazy i would look at other pipeline 
services right to see what they provide as 'API'.

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] Removing required port-id from classifier

2016-10-04 Thread Cathy Zhang

Hi Tim,

Please see inline. 

Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 04, 2016 1:29 PM
To: Cathy Zhang
Cc: OpenStack Development Mailing List (not for usage questions); Sridhar 
Ramaswamy; Sripriya Seetharam; Anil Vishnoi
Subject: Re: Removing required port-id from classifier

Responses inline.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Cathy Zhang" 
To: "Tim Rozet" , "OpenStack Development Mailing List (not 
for usage questions)" 
Cc: "Sridhar Ramaswamy" , "Sripriya Seetharam" 

Sent: Tuesday, October 4, 2016 1:54:04 PM
Subject: RE: Removing required port-id from classifier

Hi Tim,

Please see inline.

Thanks,
Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 04, 2016 10:07 AM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Cc: Sridhar Ramaswamy; Sripriya Seetharam
Subject: [tacker] [networking-sfc] Removing required port-id from classifier

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  

Cathy> Do you mean logical source port here?
trozet> yeah the neutron_source_port seems required.

Cathy> This is only required if the backend is OVS SFC driver (not required if 
it is ODL SFC driver or other drivers). There are several reasons for this. For 
example, without neutron source port being specified, we have to install flow 
classification rules on every compute node to catch the traffic flow from the 
source and scalability will be a big issue if there are thousands of compute 
nodes. Another example is that if two tenants use a shared network and each has 
its flow originating from different source VMs and going through its own SFC in 
the shared network, OVS needs different logical source ports to distinguish 
different tenants' traffic flow. Is there any reason why you can not specify a 
neutron source port? 

We just finished up implementing VNFFG in Tacker and are hitting this while 
testing.  What is the plan to remove this requirement?  Also, how are IETF 
SFC/NSH related API/plugin changes going?  Can we expect to have attributes 
like path-id, encap type soon?  

Cathy> The API already provides a way for specifying "path-id" and encap type 
(currently only MPLS encap type is supported since OVS does not support NSH 
yet). As to NSH support, the code patch is being worked on, not completed yet. 
We are also tracking the NSH work in OVS and hope OVS will support NSH soon so 
that when networking-sfc integrates with that new version of OVS, NSH can be 
supported properly.  
trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl driver 
for networking-sfc that supports NSH.  
Can you link the patches or point me to who is working on the NSH support for 
the API/plugin DB layer?

Cathy> Here is the patch link https://review.openstack.org/#/c/373465/

Thanks,

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

[openstack-dev] [nova] [tripleo] new non-devstack experimental CI job

I'm happy to announce a new experimental CI job in Nova's gate.

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


== What is this new CI job?

The job is called: gate-tripleo-ci-centos-7-nonha-multinode
It's non-voting, and only run at demand, using "check experimental".

It's deploying 2 nodes:
- undercloud [1]: OpenStack cloud used to deploy overcloud(s)
- overcloud: OpenStack cloud used to create resources consumed by end-users.
If you want to know more about TripleO architecture:
http://docs.openstack.org/developer/tripleo-docs/introduction/architecture.html#tripleo

The job aims to be stable, but we often have downtimes when something
breaks in packaging or infrastructure. It's very possible that you'll
see the job red but has nothing to do with your patch.


== When to run the CI job?

As a Nova developer, when deprecating a feature or some options, or
even removing it, I want to test if it breaks systems outside
devstack.
We are documenting it in Nova developer doc:
https://review.openstack.org/#/c/381838/ - Feel free to comment and
review!


== What to do if TripleO CI job is red?

It would not be fair to ask Nova team to debug TripleO jobs, their
time is precious and that's not the goal here. Though if something is
red, please let us know!
Jump on #tripleo channel or ping me on #openstack-nova (or any TripleO
folks connected on this channel) and we'll have a look as soon as we
can to figure what happens.


== CI job is red, but a valid reason. Are we going to block my patch in Nova?

The goal here is to report short feedback from deployment tools used
in production to projects like Nova. If TripleO job is red because
backward compatibility is broken and was not intended to be broken, I
think it's fair to block the Nova patch as we might break other users.
If TripleO CI job is red because we didn't update our configuration
and still use deprecated parameters, it's our responsibility to update
TripleO and the patch should not be blocked in Nova.



I hope this proposal is fair for everyone, any feedback is welcome here.

Thanks for your openness, very appreciated here.
-- 
Emilien Macchi

__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread Chris Dent


On Tue, 4 Oct 2016, Doug Hellmann wrote:


It seems like a reasonable idea, but why limit the period where we
discuss these "big issues" to a week or so every 6 months?


Exactly this. If TC elections are the catalyst for having the kinds
of discussions that we've had this week then we should either have
TC elections every week or come up with some other catalysts.

--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

Excerpts from Ed Leafe's message of 2016-10-04 14:31:45 -0500:
> On Oct 4, 2016, at 11:54 AM, Thierry Carrez  wrote:
> 
> >> In French, "prétendre" has a connotation of "profess" or simply
> >> "say", which is very different from the more negative connotation
> >> of "pretend" in English where common use implies some false intent.
> >> Knowing Thierry and his past contributions well enough to trust his
> >> good intentions, I was able to look past the awkward phrasing to
> >> ask what message he was trying to convey.
> > 
> > Yeah, sorry for the poor choice of words, I didn't mean that candidates
> > are trying to deceive anyone. I only meant that in my experience, past
> > members of the TC were overly optimistic in their campaign emails about
> > how much they thought they would be able to achieve. So looking at the
> > past track record is important.
> 
> A great example of knowing the person. It sounded harsh to me when I read it, 
> too, but knowing Thierry so well, I understood the intent. Had that been an 
> anonymous comment, I wouldn’t have made that mental adjustment.
> 
> So maybe anonymous isn’t the way to go. But we really do need to do several 
> things:
> 
> 1) Allow time between the nominations and the voting. Half of the candidates 
> don’t announce until the last day or two, and that doesn’t leave very much 
> time to get to know them.

It seems like a reasonable idea, but why limit the period where we
discuss these "big issues" to a week or so every 6 months?

> 2) I like the idea of identifying the issues that the people of OpenStack 
> care about, and having every candidate give their answers. One thing I worry 
> about, though, is the time zone difference. Candidate A publishes their 
> answers early, and gets a lot of reaction. Candidate Z, in a later timezone, 
> publishes their answers after the discussions have played out already. Let’s 
> release the answers all at once.

I think I understand the goal of doing that, but it doesn't lend
itself very well to having a conversation about the topics and I
tend to think a conversation is more enlightening than a position
paper.

I quite like Gordon's approach to this problem. He had a question,
and he asked it on the ML. I would have liked it if it was asked
earlier, but I'm extremely happy that it was asked at all so I'm
not going to complain about the timing.

> 3) We need to find a way to at least *reduce* the effect of incumbency. Not 
> that I have any particular incumbent in mind, of course, but any group of 
> people gets set in their ways unless the membership changes regularly.
> 
> And let me reiterate: I’m a candidate for the TC, and not an incumbent. So of 
> course this seems a bit self-serving, especially to an outsider who might not 
> know me very well. But I’m sure that Thierry and Doug and others, who have 
> known me for many years, understand my intent: to keep improving OpenStack.

Definitely. I appreciate your willingness to explore options, even if I
don't necessarily agree with the proposals.

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] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread John Griffith

On Tue, Oct 4, 2016 at 1:31 PM, Ed Leafe  wrote:

> On Oct 4, 2016, at 11:54 AM, Thierry Carrez  wrote:
>
> >> In French, "prétendre" has a connotation of "profess" or simply
> >> "say", which is very different from the more negative connotation
> >> of "pretend" in English where common use implies some false intent.
> >> Knowing Thierry and his past contributions well enough to trust his
> >> good intentions, I was able to look past the awkward phrasing to
> >> ask what message he was trying to convey.
> >
> > Yeah, sorry for the poor choice of words, I didn't mean that candidates
> > are trying to deceive anyone. I only meant that in my experience, past
> > members of the TC were overly optimistic in their campaign emails about
> > how much they thought they would be able to achieve. So looking at the
> > past track record is important.
>
> A great example of knowing the person. It sounded harsh to me when I read
> it, too, but knowing Thierry so well, I understood the intent. Had that
> been an anonymous comment, I wouldn’t have made that mental adjustment.
>
> So maybe anonymous isn’t the way to go. But we really do need to do
> several things:
>
> 1) Allow time between the nominations and the voting. Half of the
> candidates don’t announce until the last day or two, and that doesn’t leave
> very much time to get to know them.
>
> 2) I like the idea of identifying the issues that the people of OpenStack
> care about, and having every candidate give their answers. One thing I
> worry about, though, is the time zone difference. Candidate A publishes
> their answers early, and gets a lot of reaction. Candidate Z, in a later
> timezone, publishes their answers after the discussions have played out
> already. Let’s release the answers all at once.
>
> 3) We need to find a way to at least *reduce* the effect of incumbency.
> Not that I have any particular incumbent in mind, of course, but any group
> of people gets set in their ways unless the membership changes regularly.
>
> And let me reiterate: I’m a candidate for the TC, and not an incumbent. So
> of course this seems a bit self-serving, especially to an outsider who
> might not know me very well. But I’m sure that Thierry and Doug and others,
> who have known me for many years, understand my intent: to keep improving
> OpenStack.
>
>
> -- Ed Leafe
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
Just to be "that person", that choice of words in no way seemed harsh or
offensive to me at all.  It's a fact, people can write an email professing
anything they want.  They can even do so without even really having an
understanding of what they may or may not actually be able to do within the
confines of the community and the boundaries that we have to work in out of
necessity and reality.  So nobody wants to offend anyone or say anything
construed as negative or pessimistic... ok; but personally I think that if
your vote is based solely on a candidate's email (stump speech) with no
background on who they actually are, what level of involvement, commitment
or capability they possess I think you have a recipe for disaster.  I don't
think that people realize that being a TC member is actually a lot of hard
and not so fun work.

Additionally along those lines, I personally would not be involved or
participate in an election where I was presented with just a candidate's
proposal and responses to email all shielded under anonymity.

Finally, given that Thierry is perhaps the most pragmatic, level headed and
welcoming person that I've encountered in my five years of participating in
OpenStack, I fear that must appear to be a complete Ogre if his statements
were interpreted as harsh or distrusting of people.

Thanks,
John
__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread Anita Kuno


On 16-10-04 12:54 PM, Thierry Carrez wrote:

Doug Hellmann wrote:

John Davidge wrote:

Thierry, I'm surprised by your open hostility towards candidates.
Accusing
people of 'pretending' to care about things that they've taken the
time to

This is an excellent example of needing to know the speaker, as
well as their words, and why anonymous elections for leaders
are a bad idea generally and favor native English speakers over
other members of our community.

In this case, I know that Thierry is French and, while his English
is better than I could ever hope my French to be, he sometimes makes
"interesting" word choices, especially where the French and English
words are close in spelling or pronunciation, if not quite so close in
meaning.

In French, "prétendre" has a connotation of "profess" or simply
"say", which is very different from the more negative connotation
of "pretend" in English where common use implies some false intent.
Knowing Thierry and his past contributions well enough to trust his
good intentions, I was able to look past the awkward phrasing to
ask what message he was trying to convey.

Yeah, sorry for the poor choice of words, I didn't mean that candidates
are trying to deceive anyone. I only meant that in my experience, past
members of the TC were overly optimistic in their campaign emails about
how much they thought they would be able to achieve. So looking at the
past track record is important.


A poll in the weeks leading to the self-nomination period could
be used to identify the issues people are most concerned about, and
candidates could be encouraged to address those issues directly in their
self-nominations. This would reduce the reliance on a potentially messy
question and answer period by pre-empting the greatest concerns.

If my memory serves well, I think Anita (anteaya) drove such a
structured discussion in a past election (identify key issues and ask
candidates to address those questions in their candidacy email). Maybe
she can give us a summary of how well that went.




I had hoped to stay out of this discussion since I consider it poor form 
to discuss the way a race is run whilst the race is being run, however 
here we are.


tl;dr the idea seems sound, my method doesn't scale, other tooling needs 
to be considered if this is something folks want in future


Indeed when I was an election official in the past one of the items that 
both myself and my co-election official identified was the difficulty 
the electorate was having identifying the differences between the 
candidates (some of whom they did not know, since we were and have 
scaled so much in such a short period of time). We felt that it was 
important to do the best we could to give the electorate an opportunity 
(so hard to find a window of time to consume information and contemplate 
it anymore) to compare candidates in a neutral and equal way.


The wikipage for the TC election for 2014 has the information: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014
I also would suggest looking at the history of edits to the page to get 
a sense of the work involved in offering this information in this way.


I came up with the questions myself: 
https://wiki.openstack.org/wiki/TC_Elections_October_2014#TC_Election_Questions 
Tristan signed off on them but he didn't have as much knowledge of the 
community as I did at the time so I composed them. We debated on asking 
the mailing list for input but since I knew I would be doing the lions 
share of the work on this one I didn't want to have to filter through 
questions and then appear to either pick favourites or snub someone 
should I select or not select their offered question. I felt I had 
enough pressure on myself already taking this on, I didn't want to dig 
myself a deeper hole.


As you can see from the edits to the wikipage (I basically spent 4 
straight days adding answers and reordering existing answers on the 
wikipage - I had a bowl of names in my home and every time a new 
response came in I shook the names and selected them out of the bowl to 
create an order and then did it again for the next question - it was 
time consuming but I felt it was worth it in terms of serving the 
community's interests) I reordered the responses often to ensure that 
preference in response order was moved around. I value the opportunity 
for people to make their own decision very highly and didn't want my 
choices in terms of how the information was presented to play a role in 
how they perceived the information. So I shuffled the answers a lot.


Now in the post mortem of the election tooling discussion in the infra 
meeting we did discuss options for tooling to ensure the responses are 
shuffled when rendered in subsequent elections (I think that may have 
been the time I also presented the idea of moving to a git repo, I can't 
remember) but it wasn't picked up on and I decided in fairness to let 
others take a turn running elections and didn't pursue it.


I

[openstack-dev] [osc] [openstackclient] No stable branch backports/releases ?

2016-10-04 Thread David Moreau Simard

Hi,

Some puppet modules and by extension TripleO currently have a Newton
release critical issue [1] in the latest release of OSC, 3.2.0 as per
upper-constraints of stable/newton [2].

This problem was fixed in master [3] and at this time, OSC has not had
a tagged release with this fix in.
When attempting to backport the fix to stable/newton [4] in hope of
seeing it released (in 3.2.1 or something), we were told the
following:

> The stable branches exist as a requirement of the release process, not 
> because we want them.
> We have never had a policy of backporting bug fixes, it has always been 
> critical security fixes only.

What does this mean ?
Pretend a 3.2.1 is tagged from the tip of the master branch with the
fix included, is that expected to be tested and released in U-C of
both master and stable branches?
If the new release isn't bumped in upper-constraints of stable
branches, are projects and distributions expected to go beyond what is
tested with U-C at their own risks ?

Is OSC somewhat meant to be branchless and work with every release a
bit like Tempest ?

Would appreciate some input so we know what to do.

Thanks,

[1]: https://bugs.launchpad.net/python-openstackclient/+bug/1619274
[2]: 
https://github.com/openstack/requirements/blob/93d32db347b07a973d9fd8ddc648c7469eae23bc/upper-constraints.txt#L303
[3]: https://review.openstack.org/#/c/364518/
[4]: https://review.openstack.org/#/c/372712/

David Moreau Simard
Senior Software Engineer | Openstack RDO

dmsimard = [irc, github, twitter]

__
OpenStack Development Mailing 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] Removing required port-id from classifier

2016-10-04 Thread Tim Rozet

Responses inline.

Thanks,

Tim Rozet
Red Hat SDN Team

- Original Message -
From: "Cathy Zhang" 
To: "Tim Rozet" , "OpenStack Development Mailing List (not 
for usage questions)" 
Cc: "Sridhar Ramaswamy" , "Sripriya Seetharam" 

Sent: Tuesday, October 4, 2016 1:54:04 PM
Subject: RE: Removing required port-id from classifier

Hi Tim,

Please see inline.

Thanks,
Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 04, 2016 10:07 AM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Cc: Sridhar Ramaswamy; Sripriya Seetharam
Subject: [tacker] [networking-sfc] Removing required port-id from classifier

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  

Cathy> Do you mean logical source port here?
trozet> yeah the neutron_source_port seems required.

We just finished up implementing VNFFG in Tacker and are hitting this while 
testing.  What is the plan to remove this requirement?  Also, how are IETF 
SFC/NSH related API/plugin changes going?  Can we expect to have attributes 
like path-id, encap type soon?  

Cathy> The API already provides a way for specifying "path-id" and encap type 
(currently only MPLS encap type is supported since OVS does not support NSH 
yet). As to NSH support, the code patch is being worked on, not completed yet. 
We are also tracking the NSH work in OVS and hope OVS will support NSH soon so 
that when networking-sfc integrates with that new version of OVS, NSH can be 
supported properly.  
trozet> OK good. Anil is close (demoed at ODL summit) a networking-odl driver 
for networking-sfc that supports NSH.  Can you link the patches or point me to 
who is working on the NSH support for the API/plugin DB layer?

Thanks,

Tim Rozet
Red Hat SDN Team

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

[openstack-dev] [tacker] Newton retrospective - notes

2016-10-04 Thread Sridhar Ramaswamy

Tackers -

I've captured the notes from newton retrospective topic from last week's
meeting,

https://etherpad.openstack.org/p/tacker-newton-retrospective

Let's make Ocata dev cycle even better!
__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread Ed Leafe

On Oct 4, 2016, at 11:54 AM, Thierry Carrez  wrote:

>> In French, "prétendre" has a connotation of "profess" or simply
>> "say", which is very different from the more negative connotation
>> of "pretend" in English where common use implies some false intent.
>> Knowing Thierry and his past contributions well enough to trust his
>> good intentions, I was able to look past the awkward phrasing to
>> ask what message he was trying to convey.
> 
> Yeah, sorry for the poor choice of words, I didn't mean that candidates
> are trying to deceive anyone. I only meant that in my experience, past
> members of the TC were overly optimistic in their campaign emails about
> how much they thought they would be able to achieve. So looking at the
> past track record is important.

A great example of knowing the person. It sounded harsh to me when I read it, 
too, but knowing Thierry so well, I understood the intent. Had that been an 
anonymous comment, I wouldn’t have made that mental adjustment.

So maybe anonymous isn’t the way to go. But we really do need to do several 
things:

1) Allow time between the nominations and the voting. Half of the candidates 
don’t announce until the last day or two, and that doesn’t leave very much time 
to get to know them.

2) I like the idea of identifying the issues that the people of OpenStack care 
about, and having every candidate give their answers. One thing I worry about, 
though, is the time zone difference. Candidate A publishes their answers early, 
and gets a lot of reaction. Candidate Z, in a later timezone, publishes their 
answers after the discussions have played out already. Let’s release the 
answers all at once.

3) We need to find a way to at least *reduce* the effect of incumbency. Not 
that I have any particular incumbent in mind, of course, but any group of 
people gets set in their ways unless the membership changes regularly.

And let me reiterate: I’m a candidate for the TC, and not an incumbent. So of 
course this seems a bit self-serving, especially to an outsider who might not 
know me very well. But I’m sure that Thierry and Doug and others, who have 
known me for many years, understand my intent: to keep improving OpenStack.

-- Ed Leafe

__
OpenStack Development Mailing 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] [Architecture] APAC friendly meeting time for Architecture Working Group proposed

2016-10-04 Thread Clint Byrum

Hello, we want to get as much broad participation as possible with the
Architecture Working Group, so I've proposed an alternating odd/even
schedule change here:

https://review.openstack.org/379768

I'm hoping the proposed time is convenient and can be attended by those
in time zones very far ahead of UTC, such as India, China, Japan, Korea,
Australia and New Zealand. The proposed time, 0100 UTC Thursdays, is
a time that I should be able to attend as well, so that I can serve as
chair, though it would be helpful if someone from the timezone stepped
up just in case I'm not able to make it, since this is a bit after my
normal EOD.

So please, if you're not able to attend our current meetings [1], but
you'd like to help with the working group, go +1 or -1 that review to
let us know if that time will help.

Thanks!

[1] https://wiki.openstack.org/wiki/Meetings/Arch-WG

__
OpenStack Development Mailing 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] VIF plugin issue _get_neutron_events

2016-10-04 Thread Ajay Kalambur (akalambu)

Hi
When booting Vms with 3 interfaces and when port binding happens quick enough I 
sometimes see that the first VM booted on a compute node gets stuck waiting for 
VIF plugging event but looking at the neutron logs the notification is sent and 
also nova responded with a 200 OK.

When looking at the code in nova/virt/libvirt/driver.py we see in spawn() there 
is a call to _create_domain_and_network which calls _get_neutron_events

So in what scenarios can this notification happen to soon or is there a race 
condition somewhere in this code wherby even though neutron sends the 
notification and nova responds the code here blocks for 300 seconds since it 
missed the event.

Any clues on what maybe going on here. Its almost like the neutron notification 
happened too quickly while nova code was busy performing create_image

This happens only with the first VM on a compute node

Any ideas on how to fix this

Ajay

__
OpenStack Development Mailing 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] Removing required port-id from classifier

2016-10-04 Thread Cathy Zhang

Hi Tim,

Please see inline.

Thanks,
Cathy

-Original Message-
From: Tim Rozet [mailto:tro...@redhat.com] 
Sent: Tuesday, October 04, 2016 10:07 AM
To: OpenStack Development Mailing List (not for usage questions); Cathy Zhang
Cc: Sridhar Ramaswamy; Sripriya Seetharam
Subject: [tacker] [networking-sfc] Removing required port-id from classifier

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  

Cathy> Do you mean logical source port here?


We just finished up implementing VNFFG in Tacker and are hitting this while 
testing.  What is the plan to remove this requirement?  Also, how are IETF 
SFC/NSH related API/plugin changes going?  Can we expect to have attributes 
like path-id, encap type soon?  

Cathy> The API already provides a way for specifying "path-id" and encap type 
(currently only MPLS encap type is supported since OVS does not support NSH 
yet). As to NSH support, the code patch is being worked on, not completed yet. 
We are also tracking the NSH work in OVS and hope OVS will support NSH soon so 
that when networking-sfc integrates with that new version of OVS, NSH can be 
supported properly.  




Thanks,

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

Re: [openstack-dev] [QA] The end-user test suite for OpenStack clusters

2016-10-04 Thread Yaroslav Lobankov

Hi Ken,

OS-Faults doesn't have any scenarios in the tree yet (the project is two
months old), but you can find some examples of the use in the
os-faults/examples directory.

Regards,
Yaroslav Lobankov.

On Tue, Oct 4, 2016 at 8:02 PM, Ken'ichi Ohmichi 
wrote:

> Hi Timur,
>
> Thanks for your explanation.
>
> 2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov :
> >
> >> I am guessing the above "restart nodes" is for verifying each
> >> OpenStack service restarts successfully, right?
> >
> > Yes, this is right. And we also will check that HA logic for these
> > services works correctly (for example, rescheduling of L3 Neutron
> > agents for networks).
> >
> >> But these service scripts are provided by distributors, and Devstack
> >> itself doesn't contain service scripts IIUC.
> >> So I'd like to know how to verify it on Devstack clouds.
> >
> > Yes, DevStack doesn't support many scenarios which are actual
> > and should be supported on the production clouds.
> > It will be not possible to run all advanced test scenarios for DevStack
> > clouds,
> > just because DevStack can't deploy OpenStack cloud with 3 controllers
> > now (so, probably it will be possible in the future).
> >
> > Of course, some advanced scenarios will support DevStack clouds,
> > for example, some test scenarios which are based on customer-found
> > issues from the real production clouds, like upload of the large images
> > (100+ Gb)
> > to Glance with Swift backend. Such cases are important for verification
> of
> > pre-production environments, but not very important for CI gate jobs.
> >
> > It is also important to note that in these advanced cases we are
> targeting
> > to check not only the logic of Python code, but also the correct
> > configuration
> > of all OpenStack components on some pre-production OpenStack clusters.
>
> I guessed some part of os-faults can be moved to Tempest if os-faults
> contains API tests for enabling/disabling OpenStack services.
> Then, os-faults would be able to concentrate on more destructive tests
> like rebooting physical nodes, etc.
> However, I could not find any actual scenarios on current os-faults
> (https://github.com/openstack/os-faults).
> That seems to just contain some abstraction layers and unit tests. Can
> we see actual test scenarios of os-faults ?
> Maybe I missed something.
>
> Thanks
> Ken Ohmichi
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [new][sahara] sahara-tests 0.3.0 release

2016-10-04 Thread no-reply

We are amped to announce the release of:

sahara-tests 0.3.0: Sahara tests

With source available at:

https://git.openstack.org/cgit/openstack/sahara-tests

For more details, please see below.

0.3.0
^

Added ability to use clouds.yaml with scenario tests

Client tests have been imported from the Sahara repository.

Migrate sahara cli tests from saharaclient to sahara-tests

Yaml-files for deprecated plugins was removed

Tests no longer depend on fake plugin to run

Sahara Tests plugin now uses tempest stable interface


New Features


* User can now use clouds.yaml in the format defined by os-client-
  config to specify the auth values wanted on a scenario test.

* The tests for the official Python clients have been moved here
  from the Sahara repository. They are based on the Tempest libraries
  even they do not follow the Tempest guidelines (as they need to test
  the Python clients, they do not use the native Tempest clients).


Upgrade Notes
*

* Migration from novaclient.v2.images to glanceclient


Bug Fixes
*

* Removed yaml-files for Kilo release

* Removed unused yaml-files for master branch


Other Notes
***

* Adapt Sahara Tests code to stop relying only on the fake plugin
  and use the default plugin available. However, it's worth noting
  that - if available - the fake plugin will be used.

* Sahara Tests plugin is adapted to use in-tree client, which was
  migrated from Tempest code. Also, there's a new stable interface for
  Service Clients in Tempest, so this change adapts the code to use
  it.

Changes in sahara-tests 0.2.0..0.3.0


4ebba66 Added folder with defaults for newton
44a4503 Temporarily skip test_cluster_cli to avoid timeouts
026e612 Fix creation of ng with proxy node
883a09f Fix the network settings of the templates
1670a25 Fixed unit tests in sahara scenario
d70d4cc Use default plugin instead of fake
f844235 define output datasource for spark wordcount
a0314ad Trivial: delete openstack/common in flake8 exclude list
e91f1f2 Moving hdfs_username to cluster configuration
881409e add impl of SparkWordCount example
b25514b Added cli-tests for job template
2378cae Add image clean up to test_cluster_cli
9a93de6 Added verification of cluster to scenario-framework
5ed393d Added cli tests for data sources
eee440c Fix using additional parameters in 'credentials'
ed3a540 Added cli tests for job binary
4accb7d Remove hardcoded config values in CLI tests
60d35c6 Test fix for CLI tests
6459b15 Update home-page
4f320f6 Added tests for job types
59ae23b Adding link on documentation in README
c614216 TrivialFix: Remove logging import unused
0d41475 Add MapR 520 test
6a2b026 Adapt plugin to use new tempest stable interface
501c3ed Use session to create Sahara Client in tests
288d963 Update tests for plugin, cluster and image
0169a4f Trivial: Replace 'assertTrue(a in b)' with 'assertIn(a, b)'
560c3c5 Add Spark WordCount job for Vanilla Plugin
0d4db58 fix bug: skipException() instead of SkipException()
f32eb1e Fix tempest.conf generation
8fd39dc Remove the deprecated access to Exception message
a38f750 Removed 'scenario' section from ambari scenarios
66dc1c0 Migrate the imported client tests to the Tempest plugin
77fa63e New Pig example with a User Defined Function
d5e565d Correct place for the imported Tempest client
bc969cd Added the possibility to set auto_security_group par to False
4d5cb98 Service client modules in various services  __init__
dd7d457 Make data_processing/baremetal use rest_client
8d91e32 Fix H404/405 violations for service clients
49c6c59 Full response for DataProcessingClient methods
e354df9 Switch all uses of json to oslo_serialization
b473dce Remove CONF values from data_processing client
8eb3310 Rename data_processing client
e7bef91 Change data_processing client to return one value and update tests
e5b5321 Remove all CONF values from RestClient
c651538 Move _get_region() to NegativeRestClient
d853750 Remove _get_endpoint_type() from RestClient
3a64b4e Separate build_interval/timeout from RestClient
0e283b5 Sahara: preparations for job tests
2cc7cfd Add client response checking for data processing service
894ded5 Sahara: preparations for job binary tests
8485358 Sahara: add API tests for job binary internals
fbe51d0 Sahara: preparations for job binary internal tests
f2c685a Sahara: editing licenses
407a266 Sahara: preparations for data source tests
07825b7 Sahara: preparations for new tests
9c3f914 Savanna: add API client and tests for plugins
9c940b0 Multiversion authentication part1
4f32f83 Convert all service clients to global CONF object
395d077 Add Savanna client for node group templates
d01f168 Check if resources are really deleted in api tests
dfbe9f9 Fix CDH 5.7.0 template
62d8842 Strengthen the permission for the generated ssh key
57a6616 embedded jars: replace spark-example.jar
35173b3 Added ability to use clouds.yaml with scenario tests
12872a5 Move CLI tests under

Re: [openstack-dev] [oslo] Adding gdavoian to oslo-core

2016-10-04 Thread Brant Knudson

On Mon, Oct 3, 2016 at 12:40 PM, Joshua Harlow 
wrote:

> Greetings all stackers,
>
> I propose that we add Gevorg Davoian[1] to the oslo-core[2] team.
>
> Gevorg has been actively contributing to oslo for a while now, both in
> helping make oslo better via code contribution(s) and by helping with the
> review load when he can. He has provided quality reviews and is doing an
> awesome job with the various oslo concepts and helping make oslo the best
> it can be!
>
> Overall I think he would make a great addition to the core review team.
>
> Please respond with +1/-1.
>
> Thanks much!
>
> - Joshua Harlow
>
> [1] https://launchpad.net/~gdavoian
> [2] https://launchpad.net/oslo
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

+1

-- 
- Brant
__
OpenStack Development Mailing 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] Adding ozamiatin to oslo-core

2016-10-04 Thread Brant Knudson

On Mon, Oct 3, 2016 at 12:42 PM, Joshua Harlow 
wrote:

> Greetings all stackers,
>
> I propose that we add Oleksii Zamiatin[1] to the oslo-core[2] team.
>
> Oleksii has been actively contributing to oslo for a while now, both in
> helping make oslo better via code contribution(s) and by helping with the
> review load when he can. He has provided quality reviews and is doing an
> awesome job with the various oslo concepts and helping make oslo the best
> it can be!
>
> Overall I think he would make a great addition to the core review team.
>
> Please respond with +1/-1.
>
> Thanks much!
>
> - Joshua Harlow
>
> [1] https://launchpad.net/~ozamiatin
> [2] https://launchpad.net/oslo
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

+1

-- 
- Brant
__
OpenStack Development Mailing 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] IRC Meeting time suggestion

2016-10-04 Thread Serg Melikyan

Omar,

time works for me!

On Thu, Sep 29, 2016 at 7:39 AM, aaronzhu1121 
wrote:

> Good news for contributor from China, will attend the meeting.
>
>
> Thanks,
>
> Zhu Rong
>
> __
> OpenStack Development Mailing 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, Development Manager at Mirantis, Inc.
http://mirantis.com | smelik...@mirantis.com | +1 (650) 440-8979
__
OpenStack Development Mailing 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] [tacker] [networking-sfc] Removing required port-id from classifier

2016-10-04 Thread Tim Rozet

Hi Cathy,
I recall a while back discussing removing the required neutron port-id from the 
classifier.  We just finished up implementing VNFFG in Tacker and are hitting 
this while testing.  What is the plan to remove this requirement?  Also, how 
are IETF SFC/NSH related API/plugin changes going?  Can we expect to have 
attributes like path-id, encap type soon?  

Thanks,

Tim Rozet
Red Hat SDN Team

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

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

2016-10-04 Thread Jeremy Stanley

On 2016-10-04 18:22:10 +0200 (+0200), Ihar Hrachyshka wrote:
[...]
> When I execute 'bindep test’ locally, I get the following error on centos7.2
> which is expected:
> 
> Bad versions of installed packages:
> sqlite version 3.7.17-8.el7 does not match >=3.8
> 
> I would think that this output is passed to apt-get in the gate. But then I
> see the following failure in gate:
> 
> http://logs.openstack.org/06/381906/3/check/gate-neutron-pep8-ubuntu-xenial/148dcd8/console.html#_2016-10-04_15_57_36_846699
[...]

We hashed this out just now in #openstack-infra, but the quick
summary is that version specifiers with bindep are sort of
experimental. They were added as part of its initial design but the
first implementation was dpkg-only and made some assumptions about
how distros track available vs installed package versions that
couldn't easily be extended to other platforms. As a result, when we
started adding rpm (and then later emerge) support, we pretty much
just punted on version handling until someone actually turned up who
needed it and was willing to do the work to add it in a useful
cross-platform manner. For now at least, version specifiers have
poor coverage in bindep's unit tests and no coverage in its
functional tests and have probably bit-rotted on us.

It's on me that I forgot we actually mention version constraints in
the bindep documentation, with no indication that they aren't a
first-class feature at the moment. Anyway, it sounds like you may
have time and interest to help us get this supported properly (at
least for rpm-based platforms), so I'm thrilled and looking forward
to working with you toward that goal. Thanks again!
-- 
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] [QA] The end-user test suite for OpenStack clusters

2016-10-04 Thread Ken'ichi Ohmichi

Hi Timur,

Thanks for your explanation.

2016-09-29 6:22 GMT-07:00 Timur Nurlygayanov :
>
>> I am guessing the above "restart nodes" is for verifying each
>> OpenStack service restarts successfully, right?
>
> Yes, this is right. And we also will check that HA logic for these
> services works correctly (for example, rescheduling of L3 Neutron
> agents for networks).
>
>> But these service scripts are provided by distributors, and Devstack
>> itself doesn't contain service scripts IIUC.
>> So I'd like to know how to verify it on Devstack clouds.
>
> Yes, DevStack doesn't support many scenarios which are actual
> and should be supported on the production clouds.
> It will be not possible to run all advanced test scenarios for DevStack
> clouds,
> just because DevStack can't deploy OpenStack cloud with 3 controllers
> now (so, probably it will be possible in the future).
>
> Of course, some advanced scenarios will support DevStack clouds,
> for example, some test scenarios which are based on customer-found
> issues from the real production clouds, like upload of the large images
> (100+ Gb)
> to Glance with Swift backend. Such cases are important for verification of
> pre-production environments, but not very important for CI gate jobs.
>
> It is also important to note that in these advanced cases we are targeting
> to check not only the logic of Python code, but also the correct
> configuration
> of all OpenStack components on some pre-production OpenStack clusters.

I guessed some part of os-faults can be moved to Tempest if os-faults
contains API tests for enabling/disabling OpenStack services.
Then, os-faults would be able to concentrate on more destructive tests
like rebooting physical nodes, etc.
However, I could not find any actual scenarios on current os-faults
(https://github.com/openstack/os-faults).
That seems to just contain some abstraction layers and unit tests. Can
we see actual test scenarios of os-faults ?
Maybe I missed something.

Thanks
Ken Ohmichi

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread Thierry Carrez

Doug Hellmann wrote:
> John Davidge wrote:
>> Thierry, I'm surprised by your open hostility towards candidates.
>> Accusing
>> people of 'pretending' to care about things that they've taken the
>> time to
> 
> This is an excellent example of needing to know the speaker, as
> well as their words, and why anonymous elections for leaders
> are a bad idea generally and favor native English speakers over
> other members of our community.
> 
> In this case, I know that Thierry is French and, while his English
> is better than I could ever hope my French to be, he sometimes makes
> "interesting" word choices, especially where the French and English
> words are close in spelling or pronunciation, if not quite so close in
> meaning.
> 
> In French, "prétendre" has a connotation of "profess" or simply
> "say", which is very different from the more negative connotation
> of "pretend" in English where common use implies some false intent.
> Knowing Thierry and his past contributions well enough to trust his
> good intentions, I was able to look past the awkward phrasing to
> ask what message he was trying to convey.

Yeah, sorry for the poor choice of words, I didn't mean that candidates
are trying to deceive anyone. I only meant that in my experience, past
members of the TC were overly optimistic in their campaign emails about
how much they thought they would be able to achieve. So looking at the
past track record is important.

>> A poll in the weeks leading to the self-nomination period could
>> be used to identify the issues people are most concerned about, and
>> candidates could be encouraged to address those issues directly in their
>> self-nominations. This would reduce the reliance on a potentially messy
>> question and answer period by pre-empting the greatest concerns.

If my memory serves well, I think Anita (anteaya) drove such a
structured discussion in a past election (identify key issues and ask
candidates to address those questions in their candidacy email). Maybe
she can give us a summary of how well that went.

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] [telemetry] Deprecating the Ceilometer API

2016-10-04 Thread Hague, Darren

https://github.com/sapcc/openstack-kube - Ceilometer is not yet mentioned in 
the README but it's in there.

Bear in mind this is currently work in progress, and is our team sharing the 
work we are doing in building up OpenStack on Kubernetes - it's not intended to 
be a fully-documented or supported release of any kind, but it serves as a 
real-world implementation that others can use as a starting point.

Here's my boss talking about it and showing a demo: 
https://www.youtube.com/watch?v=4gyeixJLabo 

Cheers,
Darren

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: 04 October 2016 17:12
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [telemetry] Deprecating the Ceilometer API

> we removed the API and storage containers from our Kubernetes deployment of 
> Ceilometer some time ago.
> We use the collector's HTTP Dispatcher to send events and metrics to our 
> billing database.

Cool. Are you going to share the code for your k8s deployment of Ceilometer?

Best,
-jay

__
OpenStack Development Mailing 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] [elections][tc]Thoughts on the TC election process

Excerpts from John Davidge's message of 2016-10-04 14:44:00 +:
> Thierry Carrez wrote:
>
> >Edward Leafe wrote:
> >> [...]
> >> The current candidacy essay would now be posted in the campaign
> >> period,
> >>rather than at the time of nomination, and should exclude the sort
> >>of
> >>biographical information that is currently the most important piece
> >>for
> >>many people. [...]
> >
> >As other mentioned, this is unlikely to give good results -- the
> >track
> >record of the person is much more important than what they pretend to
> >care about in campaign emails (or their mastery of written English).
>

[...]

> Thierry, I'm surprised by your open hostility towards candidates.
> Accusing
> people of 'pretending' to care about things that they've taken the
> time to

This is an excellent example of needing to know the speaker, as
well as their words, and why anonymous elections for leaders
are a bad idea generally and favor native English speakers over
other members of our community.

In this case, I know that Thierry is French and, while his English
is better than I could ever hope my French to be, he sometimes makes
"interesting" word choices, especially where the French and English
words are close in spelling or pronunciation, if not quite so close in
meaning.

In French, "prétendre" has a connotation of "profess" or simply
"say", which is very different from the more negative connotation
of "pretend" in English where common use implies some false intent.
Knowing Thierry and his past contributions well enough to trust his
good intentions, I was able to look past the awkward phrasing to
ask what message he was trying to convey.

Removing the information about who is making a statement eliminates
that sort of context, and means that any history we have of working
together as individual humans can't be used to help our judgment when
we're communicating with each other.

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] [telemetry] Deprecating the Ceilometer API

2016-10-04 Thread Julien Danjou

On Tue, Oct 04 2016, gordon chung wrote:

> so one thing we probably do need to keep is the ability push samples 
> (and events?). i know previously people were actually using this feature.

That's debatable.

Pushing events is IMHO out of scope of Ceilometer – it's related to
oslo.messaging notification at this point. So if we want to allow that
via an API endpoint, we should build one in OpenStack over
oslo.messaging. Good idea or not, I don't know.

Pushing samples is probably doable with some kind of small API, but I am
not sure it's worth anything. You could still directly push the data to
Gnocchi and save some you some load. Unless you have transformers to
apply, but… really?

-- 
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] [telemetry] Deprecating the Ceilometer API

2016-10-04 Thread Julien Danjou

On Tue, Oct 04 2016, gordon chung wrote:

> i think the main issue right now is, no one is maintaining the storage 
> solutions (for a while now if we're talking about metric storage) but 
> people are using it. many people have figured it out and bailed on the 
> storage for their own solutions or Gnocchi. now how do we deal with 
> those who haven't? we definitely don't want to handle any new people on 
> this API.
>
> maybe we can start with just deleting the API and storage install docs.

Yes, I already proposed a patch that does not set the default to
anything with Ocata:

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

So that helps not having "wrong" default, at least.

-- 
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] [telemetry] Deprecating the Ceilometer API

On 04/10/2016 12:04 PM, Yarko Tymciurak wrote:
> I won't be at Barcelona, but would like to participate in the telemetry
> sessions, and particularly this one.
> Are there plans to enable remote participants (beyond just etherpad),
>  i.e. hangouts or skype, or something similar?

we can try this. i know some other projects have done this. hangouts 
probably easiest choice (assuming we don't have more than 10 people)?

i would definitely raise topics beforehand though. especially if we have 
morning sessions. i tried waking up for Europe time last year for 
virtual midcycle -- it sucks waking up at 3am.

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] [all][infra] Binary Package Dependencies - not only for Python

2016-10-04 Thread Ihar Hrachyshka

Andreas Jaeger wrote:

TL;DR: Projects can use bindep.txt to document in a programmatic way
their binary dependencies

Python developers record their dependencies on other Python packages in
requirements.txt and test-requirements.txt. But some packages
havedependencies outside of python and we should document
thesedependencies as well so that operators, developers, and CI systems
know what needs to be available for their programs.

Bindep is a solution to this, it allows a repo to document
binarydependencies in a single file. It even enablies specification of
which distribution the package belongs to - Debian, Fedora, Gentoo,
openSUSE, RHEL, SLES and Ubuntu have different package names - and
allows profiles, like a test profile.

Bindep is one of the tools the OpenStack Infrastructure team has written
and maintains. It is in use by already over 130 repositories.

For better bindep adoption, in the just released bindep 2.1.0 we have
changed the name of the default file used by bindep from
other-requirements.txt to bindep.txt and have pushed changes [3] to
master branches of repositories for this.

Projects are encouraged to create their own bindep files. Besides
documenting what is required, it also gives a speedup in running tests
since you install only what you need and not all packages that some
other project might need and are installed by default. Each test system
comes with a basic installation and then we either add the repo defined
package list or the large default list.

In the OpenStack CI infrastructure, we use the "test" profile for
installation of packages. This allows projects to document their run
time dependencies - the default packages - and the additional packages
needed for testing.

Be aware that bindep is not used by devstack based tests, those have
their own way to document dependencies.

A side effect is that your tests run faster, they have less packages to
install. A Ubuntu Xenial test node installs 140 packages and that can
take between 2 and 5 minutes. With a smaller bindep file, this can change.

Let's look at the log file for a normal installation with using the
default dependencies:
2 upgraded, 139 newly installed, 0 to remove and 41 not upgraded
Need to get 148 MB of archives.
After this operation, 665 MB of additional disk space will be used.

Compare this with the openstack-manuals repostiry that uses bindep -
this example was 20 seconds and not minutes:
0 upgraded, 17 newly installed, 0 to remove and 43 not upgraded.
Need to get 35.8 MB of archives.
After this operation, 128 MB of additional disk space will be used.

If you want to learn more about bindep, read the Infra Manual on package
requirements [1] or the bindep manual [2].

If you have further questions about bindep, feel free to ask the Infra
team on #openstack-infra.

Thanks to Anita for reviewing and improving this blog post and to the
OpenStack Infra team that maintains bindep, especially to Jeremy Stanley
and Robert Collins.

Note I'm sending this out while not all our test clouds have images that
know about bindep.txt (they only handle other-requirements.txt). The
infra team is in the process of ensuring updated images in all our test
clouds for later today. Thanks, Paul!

Andreas

References:
[1]
http://docs.openstack.org/infra/manual/drivers.html#package-requirements

[2] http://docs.openstack.org/infra/bindep/
[3] https://review.openstack.org/#/q/branch:master+topic:bindep-mv
—

I went and sent a strawman patch for neutron to adopt bindep.txt:

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

When I execute 'bindep test’ locally, I get the following error on
centos7.2 which is expected:

Bad versions of installed packages:
sqlite version 3.7.17-8.el7 does not match >=3.8

I would think that this output is passed to apt-get in the gate. But then I
see the following failure in gate:

http://logs.openstack.org/06/381906/3/check/gate-neutron-pep8-ubuntu-xenial/148dcd8/console.html#_2016-10-04_15_57_36_846699

Apparently, bindep tool failed to parse the file on that other platform?

Can anyone help me to understand what I’m missing?

Ihar

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

[openstack-dev] [App-Catalog][Glare][Infra] Vm for app-catalog

2016-10-04 Thread Mikhail Fedosin

Hello folks!

Last week we released glare 0.1 and today they built a deb package for us -
now it's located in unstable repo https://packages.debian.
org/source/sid/glare with several dependencies from experimental.

Currently we can't deploy it on ubuntu, because 14.04 doesn't have all
required packages (like 'microversion-parse') and for 16.04 they are not
built yet. James Page promised everything will be available in 2-3 weeks,
but we can't wait for so long.

Now all other activities are done: we have working puppets, packages and
app-catalog code on review. For this reason I suggest to deploy staging vm
on debian sid, managed by openstack-infra, and let people test and play
with it. When ubuntu packages appear we will able to deploy ubuntu 16.04
immediately.

Best regards,
Mikhail Fedosin
__
OpenStack Development Mailing 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] Deprecating the Ceilometer API

so one thing we probably do need to keep is the ability push samples 
(and events?). i know previously people were actually using this feature.

On 04/10/2016 11:27 AM, Julien Danjou wrote:
> Hi,
>
> Considering the split of Ceilometer in subprojects (Aodh and Panko)
> during those last cycles, and the increasing usage of Gnocchi, I am
> starting to wonder if it makes sense to maintain the legacy Ceilometer
> API.
>
> As of today, it's still barely useful, unusable at large scale, and
> barely maintained.
>
> I've proposed a session¹ about that for the next Barcelona summit, but
> feel free to share your thoughts on this thread before.
>
> Cheers,
>
> ¹  https://etherpad.openstack.org/p/ocata-telemetry-summit-planning
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
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] Deprecating the Ceilometer API

2016-10-04 Thread Jay Pipes


On 10/04/2016 11:53 AM, Hague, Darren wrote:

On Tue, 4 Oct 2016, Chris Dent wrote:
On Tue, 4 Oct 2016, Julien Danjou wrote:



Considering the split of Ceilometer in subprojects (Aodh and Panko)
during those last cycles, and the increasing usage of Gnocchi, I am
starting to wonder if it makes sense to maintain the legacy Ceilometer
API.


No surprise, as I've been saying this for a long time, but yeah, I think
the API and storage should be deprecated.

The data gathering (and to some extent transforming) parts are the only
parts of ceilometer that are particularly unique so it would be good
for those to be preserved.


That works for me - we removed the API and storage containers from our 
Kubernetes deployment of Ceilometer some time ago.
We use the collector's HTTP Dispatcher to send events and metrics to our 
billing database.


Cool. Are you going to share the code for your k8s deployment of Ceilometer?

Best,
-jay

__
OpenStack Development Mailing 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] Deprecating the Ceilometer API

On 04/10/2016 11:58 AM, Tim Bell wrote:
> What would be the impact for Heat users who are using the Ceilometer scaling 
> in their templates?
>
> Tim

pretty big. :/

i don't really have anything else to add to this answer. jd__, add it to 
discussion :P

i think the main issue right now is, no one is maintaining the storage 
solutions (for a while now if we're talking about metric storage) but 
people are using it. many people have figured it out and bailed on the 
storage for their own solutions or Gnocchi. now how do we deal with 
those who haven't? we definitely don't want to handle any new people on 
this API.

maybe we can start with just deleting the API and storage install docs.

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] Deprecating the Ceilometer API

2016-10-04 Thread Yarko Tymciurak

On Tue, Oct 4, 2016 at 10:27 AM, Julien Danjou  wrote:

> Hi,
>
> Considering the split of Ceilometer in subprojects (Aodh and Panko)
> during those last cycles, and the increasing usage of Gnocchi, I am
> starting to wonder if it makes sense to maintain the legacy Ceilometer
> API.
>
> As of today, it's still barely useful, unusable at large scale, and
> barely maintained.
>
> I've proposed a session¹ about that for the next Barcelona summit, but
> feel free to share your thoughts on this thread before.
>

Hi,

I think this is inline with what I intuitively suggested at Austin Summit
(ie. about ceilometer doing too much, should be just a queue or transport
channel manager).

I won't be at Barcelona, but would like to participate in the telemetry
sessions, and particularly this one.
Are there plans to enable remote participants (beyond just etherpad),  i.e.
hangouts or skype, or something similar?

Thanks,
Yarko


>
> Cheers,
>
> ¹  https://etherpad.openstack.org/p/ocata-telemetry-summit-planning
>
> --
> 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] [telemetry] Deprecating the Ceilometer API

2016-10-04 Thread Tim Bell


> On 4 Oct 2016, at 17:36, Chris Dent  wrote:
> 
> On Tue, 4 Oct 2016, Julien Danjou wrote:
> 
>> Considering the split of Ceilometer in subprojects (Aodh and Panko)
>> during those last cycles, and the increasing usage of Gnocchi, I am
>> starting to wonder if it makes sense to maintain the legacy Ceilometer
>> API.
> 
> No surprise, as I've been saying this for a long time, but yeah, I think
> the API and storage should be deprecated. I think at some of the mid-
> cycles and summits we've had discussions about the parts of ceilometer
> that should be preserved, including any pollsters for which a
> notification does not or cannot exist.
> 
> The data gathering (and to some extent transforming) parts are the only
> parts of ceilometer that are particularly unique so it would be good
> for those to be preserved.
> 
> 

What would be the impact for Heat users who are using the Ceilometer scaling in 
their templates?

Tim

> -- 
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: 
> @anticdent__
> OpenStack Development Mailing 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] Deprecating the Ceilometer API

2016-10-04 Thread Hague, Darren

On Tue, 4 Oct 2016, Chris Dent wrote:
On Tue, 4 Oct 2016, Julien Danjou wrote:
> 
> > Considering the split of Ceilometer in subprojects (Aodh and Panko)
> > during those last cycles, and the increasing usage of Gnocchi, I am
> > starting to wonder if it makes sense to maintain the legacy Ceilometer
> > API.
> 
> No surprise, as I've been saying this for a long time, but yeah, I think
> the API and storage should be deprecated. 
> 
> The data gathering (and to some extent transforming) parts are the only
> parts of ceilometer that are particularly unique so it would be good
> for those to be preserved.

That works for me - we removed the API and storage containers from our 
Kubernetes deployment of Ceilometer some time ago.
We use the collector's HTTP Dispatcher to send events and metrics to our 
billing database.
__
OpenStack Development Mailing 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] Deprecating the Ceilometer API

2016-10-04 Thread Chris Dent


On Tue, 4 Oct 2016, Julien Danjou wrote:


Considering the split of Ceilometer in subprojects (Aodh and Panko)
during those last cycles, and the increasing usage of Gnocchi, I am
starting to wonder if it makes sense to maintain the legacy Ceilometer
API.


No surprise, as I've been saying this for a long time, but yeah, I think
the API and storage should be deprecated. I think at some of the mid-
cycles and summits we've had discussions about the parts of ceilometer
that should be preserved, including any pollsters for which a
notification does not or cannot exist.

The data gathering (and to some extent transforming) parts are the only
parts of ceilometer that are particularly unique so it would be good
for those to be preserved.


--
Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing 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] Adding ozamiatin to oslo-core

Excerpts from Joshua Harlow's message of 2016-10-03 10:42:49 -0700:
> Greetings all stackers,
> 
> I propose that we add Oleksii Zamiatin[1] to the oslo-core[2] team.
> 
> Oleksii has been actively contributing to oslo for a while now, both in
> helping make oslo better via code contribution(s) and by helping with 
> the review load when he can. He has provided quality reviews and is 
> doing an awesome job with the various oslo concepts and helping make 
> oslo the best it can be!
> 
> Overall I think he would make a great addition to the core review team.
> 
> Please respond with +1/-1.
> 
> Thanks much!
> 
> - Joshua Harlow
> 
> [1] https://launchpad.net/~ozamiatin
> [2] https://launchpad.net/oslo
> 

+1

__
OpenStack Development Mailing 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] Adding gdavoian to oslo-core

Excerpts from Joshua Harlow's message of 2016-10-03 10:40:46 -0700:
> Greetings all stackers,
> 
> I propose that we add Gevorg Davoian[1] to the oslo-core[2] team.
> 
> Gevorg has been actively contributing to oslo for a while now, both in
> helping make oslo better via code contribution(s) and by helping with 
> the review load when he can. He has provided quality reviews and is 
> doing an awesome job with the various oslo concepts and helping make 
> oslo the best it can be!
> 
> Overall I think he would make a great addition to the core review team.
> 
> Please respond with +1/-1.
> 
> Thanks much!
> 
> - Joshua Harlow
> 
> [1] https://launchpad.net/~gdavoian
> [2] https://launchpad.net/oslo
> 

+1

__
OpenStack Development Mailing 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] [tacker][ptl] Leave of Absence

Excerpts from Sridhar Ramaswamy's message of 2016-10-03 23:26:16 -0700:
> Tackers,
> 
> I'd like to inform I'll be away from work / the community for about 4 - 6
> weeks to attend to an urgent medical need.  This also means I won't be able
> to attend the upcoming Barcelona summit. I'll terribly miss the event,
> particularly meeting some of the new faces in the Tacker community.
> 
> I'm happy that the Newton release is behind us, and Ocata summit planning
> is well underway [1]. I'd like to nominate tacker core Sripriya Seetharam
> (irc: sripriya) as the acting PTL to continue the work forward in my
> absence .
> 
> thanks,
> Sridhar
> 
> [1] https://etherpad.openstack.org/p/tacker-ocata-summit

Thank you for ensuring there is someone filling the PTL role in your
absence, Sridhar, and good luck with your medical situation. I'm sure
the whole team wishes you a quick recovery.

Doug

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

[openstack-dev] [telemetry] Deprecating the Ceilometer API

2016-10-04 Thread Julien Danjou

Hi,

Considering the split of Ceilometer in subprojects (Aodh and Panko)
during those last cycles, and the increasing usage of Gnocchi, I am
starting to wonder if it makes sense to maintain the legacy Ceilometer
API.

As of today, it's still barely useful, unusable at large scale, and
barely maintained.

I've proposed a session¹ about that for the next Barcelona summit, but
feel free to share your thoughts on this thread before.

Cheers,

¹  https://etherpad.openstack.org/p/ocata-telemetry-summit-planning

-- 
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] [elections][tc]Thoughts on the TC election process

2016-10-04 Thread John Davidge

Thierry Carrez wrote:

>Edward Leafe wrote:
>> [...]
>> The current candidacy essay would now be posted in the campaign period,
>>rather than at the time of nomination, and should exclude the sort of
>>biographical information that is currently the most important piece for
>>many people. [...]
>
>As other mentioned, this is unlikely to give good results -- the track
>record of the person is much more important than what they pretend to
>care about in campaign emails (or their mastery of written English).

Is it, though? A person's track record might help to show how likely they
are to stick to their stated goals, but it's the goals themselves that are
actually going to shape the future of OpenStack. Ed quite rightly points
out that our current election system puts almost no focus on the agenda of
each candidate, in favor of how well their name is recognized by a wide
base of contributors. I do agree that name recognition in itself can be an
indication that the person has contributed and will continue to contribute
positively to the community, but it shouldn't be the primary metric.

On balance, I think that the community would benefit from an effort to
shift the focus more onto the issues than the individuals. The TC would
also benefit by receiving a greater mandate to accomplish the goals that
were voted for.

We'll need to acknowledge that the more well known names in the community
you would stand to lose a large advantage with the change Ed is proposing.
If we're going to seriously consider some level of electoral reform - and
I think we should - then it needs to be discussed and refined in the open,
and decided by community vote. The TC cannot be the ones to decide this,
as no matter how much we trust them, we cannot ignore the conflict of
interests it raises.

Thierry, I'm surprised by your open hostility towards candidates. Accusing
people of 'pretending' to care about things that they've taken the time to
write about is exactly the kind of bad-faith assumption that puts people
off from getting involved. This leads to self-censorship of dissent,
without which it is impossible to have any meaningful debate. I wish we
could disagree without resorting to personal attacks.

>In campaign emails, people always promise they have a lot of time on their
>hands, or they will change everything (or "be proactive"). But when the
>rubber hits the road, some vote one hour before the meeting, and some
>others don't show up at all. Campaign emails only bind those who believe
>in them. In my voting I prefer to consider the past availability and
>interest in those issues, the positions held on various threads and
>reviews, and the cooperative behavior (or absence thereof) exhibited in
>those discussions.

All valuable methods for weighing candidates against each other, which is
why I don't think dropping names completely is the right way to go. Again
though, let's not encourage the assumption that all candidates are lazy
con-artists until proven otherwise.

>Now, it's true that a lot of people vote on names, and don't take the
>time to dig into meeting logs and governance reviews. I'm not sure it's
>easy to fix though... you can't force people to spend time researching
>candidates.

And I don't think we have to. Something as simple as a few bullet points
about each candidate's intentions on the voting page would be a hugely
beneficial first step. If the current voting infrastructure doesn't
support that for whatever reason, then we should consider a different one.

>We could reduce the electorate to people more likely to have
>time to do that research (raise the bar in number of patches you have to
>contribute before you can vote) -- but that would require significant
>changes in the Foundation bylaws (where the "1 contributor = 1 vote"
>principle in carved in protected sections).

No, absolutely not. We went over this on the 'Write down OpenStack
principles' review[1]. The fact that the required research is so time
consuming is the problem. We should be making every effort to present the
relevant information at the time of voting. Of course this is easier said
than done, but if we don't help newer contributors feel like they're
making informed voting decisions, we're going to lose out on the
opportunity for our ever-changing demographics to inform our direction.

>Another path would be to facilitate that research. We could publish
>meeting presence metrics, but that would only encourage people to make
>random noise at meetings. We could ask incumbents to post a "here is
>what I did over the last year at the TC" as part of their platform
>email. Other ideas ?

I think a beneficial step would be to include the community earlier in the
process. A poll in the weeks leading to the self-nomination period could
be used to identify the issues people are most concerned about, and
candidates could be encouraged to address those issues directly in their
self-nominations. This would reduce the reliance on a potentially messy

[openstack-dev] [ceilometer] ceilometer liberty detect instance creation

2016-10-04 Thread Yue Xin

Hi all,

I have installed the ceilometer liberty version. but when i use the command
"ceilometer meter-list" there is no "instance.creation" "network.creation"
appears(which can be detected on mitaka version), may i ask is this because
of the version limit? Or there is some configuration file should be
modified in order to be able to detect?

Thanks a lot.

*Regards,*
*Yue*
__
OpenStack Development Mailing 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] Future of turbo-hipster CI

2016-10-04 Thread Dan Smith

> Having said that, I think Dan Smith came across a fairly large
> production DB dataset recently which he was using for testing some
> archive changes, maybe Dan will become our new Johannes, but grumpier of
> course. :)

That's quite an insult to Johannes :)

While working on the db archiving thing recently I was thinking about
how it would be great to get t-h to run this process on one of its
large/real datasets. Then I started to wonder when was the last time I
actually saw it comment.

I feel like these days Nova, by policy, isn't doing any database
migrations that can really take a long time for a variety of reasons
(i.e. expand-only schema migrations, no data migrations). That means the
original thing t-h set out to prevent is not really much of a risk anymore.

I surely think it's valuable, but I understand if the benefit does not
outweigh the cost at this point.

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

[openstack-dev] [Performance] No Performance Team meeting today

2016-10-04 Thread Dina Belova

Folks,

due to the internal training big part of Mirantis won't be able to attend
the meeting. Let's skip this for today.

Sorry for inconvenience.

Cheers,
Dina

-- 
*Dina Belova*
*Senior Software Engineer*
Mirantis, Inc.
525 Almanor Avenue, 4th Floor
Sunnyvale, CA 94085

*Phone: 650-772-8418Email: dbel...@mirantis.com *
www.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] TC candidacy

On Tue, Oct 4, 2016 at 8:59 AM, Matt Riedemann
 wrote:
> On 10/3/2016 10:03 PM, Emilien Macchi wrote:
>>
>>
>> I'm actually proposing to run TripleO multinode job in Nova experimental
>> jobs:
>> https://review.openstack.org/#/c/381322/
>> It's non-voting and run at demand, so we're not breaking anything.
>>
>> tripleo-ci-centos-7-nonha-multinode is a CI job that takes ~40-60
>> minutes (we're working on reducing its runtime) and deploy TripleO in
>> multinode environment.
>> I think it would be a good start to see if non-devstack jobs would
>> bring useful feedback.
>>
>
> I'll repeat here what I asked in the review above: on what kinds of changes
> should nova developers and reviewers think to run the experimental queue job
> for tripleo? Since the experimental queue is on-demand we generally only run
> it for specific changes that aren't tested by our normal check/gate jobs.
> Like we have an lxc job in the experimental queue and that's fairly
> straight-forward on when to run it, similar with neutron + dvr + multinode.
>
> But what would prompt me to run the tripleo job on a nova change? Things
> that impact upgrades? Configuration option changes, like dropping deprecated
> configuration options or changing their default behavior?

I haven't exactly answered to the question.
I guess a Nova developer would run the job when making changes such as
removing an option or a feature.
Also it would be useful when deprecating something widely used, and
make sure it still works outside Devstack.

Thanks,

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



-- 
Emilien Macchi

__
OpenStack Development Mailing 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] [Vitrage] Installation

2016-10-04 Thread Paul Vaduva

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment


Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4 021 311 43 00
Fax +4 021 311 43 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

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

Re: [openstack-dev] TC candidacy

On Tue, Oct 4, 2016 at 8:59 AM, Matt Riedemann
 wrote:
> On 10/3/2016 10:03 PM, Emilien Macchi wrote:
>>
>>
>> I'm actually proposing to run TripleO multinode job in Nova experimental
>> jobs:
>> https://review.openstack.org/#/c/381322/
>> It's non-voting and run at demand, so we're not breaking anything.
>>
>> tripleo-ci-centos-7-nonha-multinode is a CI job that takes ~40-60
>> minutes (we're working on reducing its runtime) and deploy TripleO in
>> multinode environment.
>> I think it would be a good start to see if non-devstack jobs would
>> bring useful feedback.
>>
>
> I'll repeat here what I asked in the review above: on what kinds of changes
> should nova developers and reviewers think to run the experimental queue job
> for tripleo? Since the experimental queue is on-demand we generally only run
> it for specific changes that aren't tested by our normal check/gate jobs.
> Like we have an lxc job in the experimental queue and that's fairly
> straight-forward on when to run it, similar with neutron + dvr + multinode.
>
> But what would prompt me to run the tripleo job on a nova change? Things
> that impact upgrades? Configuration option changes, like dropping deprecated
> configuration options or changing their default behavior?

Generally speaking, making sure it works fine outside the gate is in
my opinion an interesting information, as we know developers tend to
take care of devstack only (and I understand why).
But yes, things like:
- making sure a change is backward compatible outside devstack
(configuration or behaviors): using TripleO job now, but why not Kolla
or another tool in the Big Tent?
- test real upgrades, looking at sdake's reply it seems like Kolla has
a bunch of jobs for that.

Also I proposed to use the experimental pipeline right now because I
like to iterate. If we see some benefits and results, I would be in
favor of moving the jobs to the check pipeline, as non-voting.

Thanks Matt for being open of such a change,
-- 
Emilien Macchi

__
OpenStack Development Mailing 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] Future of turbo-hipster CI

2016-10-04 Thread Dean Troyer

On Mon, Oct 3, 2016 at 11:29 PM, Joshua Hesketh 
wrote:

> The question now is whether or not to continue running. Is there still
> value in running turbo-hipster? It uses significant resources and it feels
> that developers have learned the lessons it was designed to teach.
>

Is there any value in running turbo-hipster as a periodic job across
multiple releases?  One common request from operators is to be able to
upgrade directly from, say, kilo to mitaka or newton.  I know there are
other factors involved in that (APIs, objects, etc), the question is if
this is a necessary/useful component of testing that upgrade path?

dt

-- 

Dean Troyer
dtro...@gmail.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] TC candidacy

2016-10-04 Thread Matt Riedemann


On 10/3/2016 10:03 PM, Emilien Macchi wrote:


I'm actually proposing to run TripleO multinode job in Nova experimental jobs:
https://review.openstack.org/#/c/381322/
It's non-voting and run at demand, so we're not breaking anything.

tripleo-ci-centos-7-nonha-multinode is a CI job that takes ~40-60
minutes (we're working on reducing its runtime) and deploy TripleO in
multinode environment.
I think it would be a good start to see if non-devstack jobs would
bring useful feedback.



I'll repeat here what I asked in the review above: on what kinds of 
changes should nova developers and reviewers think to run the 
experimental queue job for tripleo? Since the experimental queue is 
on-demand we generally only run it for specific changes that aren't 
tested by our normal check/gate jobs. Like we have an lxc job in the 
experimental queue and that's fairly straight-forward on when to run it, 
similar with neutron + dvr + multinode.


But what would prompt me to run the tripleo job on a nova change? Things 
that impact upgrades? Configuration option changes, like dropping 
deprecated configuration options or changing their default behavior?


--

Thanks,

Matt Riedemann


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

[openstack-dev] {Vitrage} Installation

2016-10-04 Thread Paul Vaduva

Hi everybody,

I am writing you to ask for guidance with the installation of Vitrage.
I have a deployed opnfv environment based on openstack mitaka release and I 
want to ask you how I would go about installing vitrage (with horizon) on this 
existing environment

Paul Ionut Vaduva
Software Engineer
Linux Team

Email  paul.vad...@enea.com

Enea R
319 Splaiul Independentei, OB403A
Bucharest, 060044
Phone  +4 021 311 43 00
Fax +4 021 311 43 01


www.enea.com

[cid:image002.png@01D00576.7D651240]
This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake please let 
us know by reply and then delete it from your system; you should not copy it or 
disclose its contents to anyone. All messages sent to and from Enea may be 
monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, a mended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.

__
OpenStack Development Mailing 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] Future of turbo-hipster CI

2016-10-04 Thread Matt Riedemann


On 10/3/2016 11:29 PM, Joshua Hesketh wrote:

Howdy,

Quick bit of background. Turbo-hipster is a 3rd party CI system that
runs nova's database migrations against real datasets to try and catch
real-world problems.

When it was initially written the state of migrations in nova would
cause a lot of pain for deployers (such as very long downtimes while
upgrades were performed or just not working at all). Since then nova has
made conscious efforts to minimise this time and are generally aware
when implementing a necessary migration may cause large downtimes and
attempt to work around it where possible.

turbo-hipster used to run against every change in nova. This was to
catch changes that may have affected migration performance as a side
effect. However for the last few months turbo-hipster has only been
running against changes modifying files in nova/db/*. Any changes
outside of there that causes pain can likely be reverted.

As a note, turbo-hipster is currently not running due
to https://review.openstack.org/#/c/374307/ until I have time to update
the datasets used.

The question now is whether or not to continue running. Is there still
value in running turbo-hipster? It uses significant resources and it
feels that developers have learned the lessons it was designed to teach.

Not running it increases the risk a migration will fail or take a very
long time for a real user, but turbo-hipster is far from perfect anyway
and only tests a couple of datasets so that risk is still there.

Are nova developers still getting value out of turbo-hipster or has it
achieved its goal and is it time for it to retire?

Thanks,
Josh


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



I honestly forgot it existed. We have had some proposed database 
migrations come up which were a bit controversial, e.g.:


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

So it would be nice to have something big to test these out while 
considering them. We used to have Johannes for manual test runs on 
migration changes but he's no longer around.


So I guess I'm fine with not having t-h anymore since I didn't even 
notice the absence for the last couple of releases, but I worry a bit 
about not having a large test dataset for manual runs.


Having said that, I think Dan Smith came across a fairly large 
production DB dataset recently which he was using for testing some 
archive changes, maybe Dan will become our new Johannes, but grumpier of 
course. :)


--

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] [all][oslo] Parse ISO8601 (open) time intervals

2016-10-04 Thread milanisko k

Guys,

thanks for the input!
I've just reported an rfe-issue on dateutils[1]. I'm proposing an
"?finished_at=ISO/ISO" format of time interval for the Inspector[2], let's
see where the reviews are going to get us.

Thanks again!
milan

[1] https://github.com/dateutil/dateutil/issues/295
[2]
https://review.openstack.org/#/c/375045/5/specs/list-introspection-statuses.rst@69

čt 29. 9. 2016 v 19:05 odesílatel Julien Danjou  napsal:

On Tue, Sep 27 2016, milanisko k wrote:

> I'd like to ask whether other projects need to parse time intervals and/or
> how do they achieve that.

We kind of do that in Gnocchi, but we do with 2 fields: one ISO8601
timestamp and a timestamp field, which we parse using pytimeparse, you
(can check gnocchi.utils.to_timespan).

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

Re: [openstack-dev] TC candidacy