date:20161003

On 2016-10-03 12:23:47 -0700 (-0700), Clay Gerrard wrote:
> This was a riveting soapbox missive - and I agree with what you said -
> particularly about the focus on breaking down the barriers to building out
> and supporting the OpenStack contributor base.

Thanks! Rather than talk about myself or recount the same concerns
and goals I've come to expect in others' platform statements, I
wanted to use it as an opportunity to bring some different topics to
the forefront which I feel aren't discussed enough. If it evoked
thought about those particular issues, then I was successful.

> But I don't have a good sense for how you want to apply that focus in
> action on the TC?

I'll be frank. Many people whose opinions I respect deeply
encouraged me to run. The loss of several incumbents and, with them,
their wisdom and history with the project has left many worried
about what would happen if most of the options this term were
relative newcomers to our community or those with limited
involvement and perspective across the breadth of OpenStack. I've
since been relieved to see that we ended up with many great
candidates. I'm still willing to serve on the TC if that is the will
of the electorate, but I'm satisfied that whether or not I'm elected
the future of our technical committee is in good hands.

Issues like those I mentioned in my position statement are, of
course, not easily addressed. They require an effort on the part of
our entire community, and I plan to continue trying to lead by
example in hope that others will join in. Honestly, there's little I
(or anyone for that matter) can accomplish as a member of the TC
that can't be done simply as a concerned member of our community,
and to me that is perhaps OpenStack's greatest strength. We're all
free to convince others to support our solutions, to draft and
propose policy changes and to voice our concerns through numerous
channels of communication to the body of prudent representatives
we've elected. So you ask what I intend to accomplish as a member of
the TC... probably many of the same things I'll attempt to
accomplish regardless, but I'll also be helping to decide where we
as a community will focus our available resources through approval
or rejection of changes to governance policy.

> I went back and looked at a number of mailing list
> threads you participated in - and happily recalled your very matter of fact
> presentation.  Frankly it was quite refreshing to see how often you seemed
> to offer historical context more that your personal opinion (!!!)

A straightforward aggregation and logical analysis of prior events
increases the chance for impartial decisions. While ideals and goals
are important (and I certainly have my fair share of both), I still
prefer a choice based in reason and research over one filled with
emotion and conviction. The latter too often ends deadlocked in a
stalemate of conflicting opinion rather than reaching useful
consensus.

> Is there any *specific* goals you have for a one year term on the TC - or
> do you think more focus on contributors is the most important thing to fix
> first?  Would you perhaps consider to share your thoughts in response to
> Gordon's question [1]?
[...]

Indeed, I've just finished responding to his open question, so I'll
spare our gentle readers a rehashing of the same here.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [all][elections][TC] TC candidacy

2016-10-03 Thread Sean McGinnis

On Mon, Oct 03, 2016 at 10:53:30AM -0700, John Dickinson wrote:
> 
> 
> On 27 Sep 2016, at 9:21, Sean McGinnis wrote:
> 
> > I would like to announce my candidacy for a position on the Technical
> > Committee.
> >
> 
>
> Sean,
> 
> Are there some specific areas of complexity that you would like to change in 
> OpenStack now? How would you change them? Are there things you see happening 
> in OpenStack now that need to be stopped because they will produce too much 
> complexity?
> 
> 
> --John
> 
> 

I wrote a response earlier today, but now I don't see it. Apologies if
this is a second response, but rephrasing are restating never hurts to
communicate ideas. ;)

I think most of us are engineers. It is usually our natural tendency to
over-engineer solutions. I've been down this road far too many times,
and I hope I can help identify when that's happening and help steer
things to a simpler solution.

I will state - I am not coming in to this with a big agenda. I don't
look to pull down any tents or build any coliseums.

I think it's important to have a diverse mix of members on the TC.
Varying view points and good arguments, as long as they are technical
arguments, are import for something like the TC to be effective in
making good long term decisions.

As part of these discussions, I also think it's important to keep in mind
what our real goals are and make sure we are not going down a certain
path just because it's what's considered the "OpenStack way". We also
need to make sure all voices are heard. I think we've seen many cases on
the mailing list where early agreement to an idea has deterred others
from expressing their doubts about it. We need to make sure we're open to
other viewpoints and listening to input.

We need to help make it easy for new contributors to get involved. If
there are 10 steps to go through and two weeks of reading governance
documents and (outdated) wiki instructions, then the only new
contributors we will get are the ones being assigned to OpenStack by
their employers.

I'm really just rambling now. I assure you, my earlier response was much
more eloquent and concise. :)

Sean

__
OpenStack Development Mailing List (not for 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-03 Thread Emilien Macchi

On Mon, Oct 3, 2016 at 5:01 PM, Emilien Macchi  wrote:
> On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard  wrote:
>>
>>
>> On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi  wrote:
>>>
>>>
>>> - Make sure it works outside Devstack.
>>>
>>> There is a huge gap between what is tested by Devstack gate and what
>>> operators
>>> deploy on the field.  This gap tends to stretch the feedback loop between
>>> developers and operators.  As a community, we might want to reduce this
>>> gap
>>> and make OpenStack testing more effective and more realistic.
>>> That's an area of focus I would like to work and spread over OpenStack
>>> projects if I'm elected.
>>>
>>
>> This is a really interesting platform point.  It's been a concern in he
>> community since *at least* Vancouver [1].  We've had lots of different
>> viewpoints towards project install-ability raised this election:
>>
>> John Dickenson says installation of projects should go horizontal [2]
>> Monty Taylor says services oriented deployment teams are the wasteful
>> exception [3]
>> John Griffith says how the TC approaches services oriented OpenStack will be
>> an important factor in the future definition of OpenStack and it's relevancy
>> [4]
>>
>
> Before I start replying to the questions, I would like to note that
> I'm not against Devstack and I still see some value of such a project.
> Devstack has been so far the first deployment tool that is used by
> OpenStack continuous integration, my point is really about adding more
> CI coverage.
>
>> Do you think this is an important topic for OpenStack right now?  I'd be
>> really interested to hear any *new* insights from the previous PTL of *one*
>> of OpenStack's installation automation projects?  What could or should be
>> done to reduce the bias/reliance towards a devstack or an
>> "openstack-all-in-one" deployment model?  Can or should the TC be the
>> champion of the discussion around "how to install" OpenStack?  How much of
>> an impact does choices made in *testing* effect the install-ability and
>> ease-of-use of OpenStack in general?
>
> 1) Do you think this is an important topic for OpenStack right now?
> Yes. Making sure that OpenStack can be installed, upgraded and
> operated outside devstack is in my opinion an important long-term
> topic that needs to be addressed right now.
>
> 2) What could or should be done to reduce the bias/reliance towards a
> devstack or an "openstack-all-in-one" deployment model?
> Some projects (Heat, Ironic, etc) already run non-devstack jobs,
> example given with TripleO.
> I'm not going to make advertising for this project but it's an example
> of installer that deploys a good set of service with uses-cases close
> to production: multinode, SSL, IPv6, upgrade testing, network
> isolation, etc.
> We could see more of it in OpenStack, where projects like TripleO,
> Kolla, Fuel, etc, could run their CI jobs in projects like Nova or
> Swift for example.
> It would reduce the feedback loop between developers and operators
> when something breaks (backward compatibility testing is a good
> use-case), or increase coverage (things that Devstack doesn't test).

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.

> 3) Can or should the TC be the champion of the discussion around "how
> to install" OpenStack?
> I don't think so. To me, it's up to our community to decide how to
> install OpenStack.
> The deployment tool (ansible versus chef versus puppet, etc) is
> something that we can't choose on behalf of our operators, because
> they already have tools to manage their existing infrastructure.
> Where TC could help, is to drive OpenStack deployment tools projects
> to increase their impact in OpenStack testing with a final goal of
> reducing the feedback loop between devs & ops.
>
> 4) How much of an impact does choices made in *testing* effect the
> install-ability and ease-of-use of OpenStack in general?
> - evaluate how a project does respect backward compatibility in
> configuration and APIs.
> - evaluate if projects can actually be upgraded by using operator and
> not something that operators don't use (devstack / grenade).
> That's the two things that directly came into my mind.
>
>> Somewhat unrelated.  Do you have any personal thoughts/insights on how you
>> believe OpenStack should approach potentially disruptive or "competing"
>> design in general - like ansible/puppet or even Kolla?
>
> I don't think Ansible / Puppet OpenStack / Kolla / TripleO / Fuel /
> (...) compete in design, but they rather fit (or match) the needs of
> people who deploy OpenStack in production.
> In my experience of d

[openstack-dev] [puppet] useful logstash queries

2016-10-03 Thread Emilien Macchi

I was looking for a quick way to find Puppet deprecations that we did
in Newton and could clean-up in Ocata.
Also I was searching for OpenStack deprecations.

I found useful to create an etherpad with some logstash queries:
https://etherpad.openstack.org/p/puppet-openstack-ci-logstash-queries

Feel free to add more as you find useful queries (to debug a specific
issue or get some metrics).

Regarding the deprecations themselves, we might want to work on it
during Ocata as well as our consistency work.
It's usually not hard to update options and could be done by newcomers
to get used of contributing in Puppet OpenStack. Feel free to reach us
if you're interested to work on it.
In any case, we'll probably clean-up deprecations during early Ocata
and update deprecated options during the cycle.

Feedback is welcome,
-- 
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] [tc] open question to the candidates

On 2016-10-03 15:30:56 + (+), gordon chung wrote:
[...]
> the TC has historically been a reactive council that lets others ask for
> change and acts as the final approver. do you believe the TC should be a
> proactive committee that initiates change and if yes, to what scope?

I view the TC as both a technical body to which individuals can
request input on OpenStack-wide concerns or appeal decisions made in
an individual project with implications on the community as a whole,
and also a force for change with a tempered view of OpenStack's
overall direction along with perspective on our community's
strengths and weaknesses. The only direct control the TC is able to
exercise in this regard is addition/removal of governance tags and
inclusion/exclusion of official ("big tent") status for teams.
Fortunately, as elected representatives of our community the
opinions of the TC carry weight with decision-makers throughout not
only individual project teams, but also the OpenStack Foundation
Board of Directors and employees in many member companies.

> more generally, what are some specific issues you'd like the TC address
> in the coming year?
[...]

Out of fairness I've avoided reading any other candidates' responses
yet, so forgive me if I end up repeating points they've also made.

Similar to the sitting TC, I agree general leadership tasks such as
improving cross-project collaboration among developers or recording
previous assumptions based on the community's oral tradition (so we
can all reconcile, evaluate and even disagree with and subsequently
improve those) are important, as are specific initiatives like our
much-overdue Py3K support or API consistency. Per my platform
statement, I also believe increasing solidarity between OpenStack
and the rest of the greater free software community is critical, and
so is ensuring ease of involvement and contribution from
unaffiliated volunteers, distro package maintainers and our end
users and operator/deployers. Another thing I'd love to see is the
TC weighing in more actively on software freedom concerns, for
example encouraging driver support in official projects to embody
the spirit of our license choice rather than merely the letter of
that license.
-- 
Jeremy Stanley

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

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

2016-10-03 Thread Morgan Fainberg

On Oct 3, 2016 14:15, "Edward Leafe"  wrote:
>
> On Oct 3, 2016, at 12:18 PM, Clay Gerrard  wrote:
> >
> >> After the nominations close, the election officials will assign each
candidate a non-identifying label, such as a random number, and those
officials will be the only ones who know which candidate is associated with
which number.
> >>
> > I'm really uneasy about this suggestion.  Especially when it comes to
re-election, for the purposes of accountability I think it's really
important that voters be able to identify the candidates.  For some people
there's a difference in what they say and what they end up doing when left
calling shots from the bubble for too long.
>
> This was a concern of mine, too, but IMO there haven't been too many
cases where a TC member has said they would support X and then fail to do
so. They might not prevail, being one of 13, but when that issue came up
they were almost always consistent with what they said.
>
> > As far as the other stuff... idk if familiarity == bias.  I'm sure lots
of occasions people vote for people they know because they *trust* them;
but I don't think that's bias?  I think a more common problem is when
people vote for a *name* they recognize without really knowing that person
or what they're about.  Or perhaps just as bad - *not* voting because they
realize they have on context to consider these candidates beyond name
familiarity and an (optional) email.
>
> I think that with so many candidates for so few seats, most people simply
don't have the time or the interest to look very deeply into things. I know
that that shows up in the voting. Take the election from a year ago: there
were 619 votes cast for 19 candidates. Out of these:
> - 35 ballots only voted for one candidate
> - 102 ballots voted for three or fewer
> - 175 didn't even bother to vote for 6
> - only 159 bothered to rank all the candidates
>

I want to point out that the last statistic is not super useful. The very
nature of CIVS allows for duplicated ranks. I rank folks where I would like
them and explicitly stack the bottom for those not in the top X, as I see
them all as equally viable but lower on my priority. So I am lumped into
that last statistic without it meaning I didn't actively and consciously
choose to do so for ease of voting. The web form on mobile (usually where I
vote) is not as responsive and sometimes might mis-rank folks).

So in short. Don't use the "failed to rank everyone" as a real metric. It
isn't representative  of what you're implying.

> So I think that there is evidence that unless you are already well-known,
most people aren't going to take the time to dig deeper. Maybe anonymous
campaigns aren't the answer, but they certainly would help in this regard.
>
> > I think a campaign period, and especially some effort [1] to have
candidates verbalize their viewpoints on topics that matter to the
constituency could go a long way towards giving people some more context
beyond "i think this name looks familiar; I don't really recognize this
name"
>
> Agreed 100%! It was made worse this year because the nominations closed
on a Saturday, and with the late rush of people declaring their candidacy,
gave no time at all for any sort of campaign discussions before voting
began. There really needs to be a decent period of time allowed for people
to get answers to whatever questions they may have.
>
>
> -- 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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Tony Breeds

On Mon, Oct 03, 2016 at 07:19:46PM +, Jeremy Stanley wrote:
> On 2016-10-03 16:11:25 + (+), Jeremy Stanley wrote:
> [...]
> > I think we can bring this thread to a close now. Upstream deleted
> > the broken wheel from PyPI a little over an hour ago, and within
> > about 5 minutes it disappeared from our CI system mirrors as well
> > (PyPI deletions propagate automatically through our mirroring). At
> > this point things _should_ be back to normal, and projects can
> > probably start working on reverting or abandoning any temporary
> > workarounds.
> 
> I just learned that we (unnecessarily) also copy available wheels
> from PyPI into our separate wheel mirrors when building
> architecture-specific wheels as a side effect of trivially reusing
> the wheel cache to populate it. Since those mirrors are effectively
> append-only we ended up persisting a copy of the broken wheel there
> even after it vanished from our PyPI mirror, and so it continued to
> be found by jobs in our CI system.
> 
> In the past few minutes I've cleared out vestigial copies of it
> there, and we're reflecting on ways we can enhance our wheel
> building jobs to omit duplication of wheels which are already
> present on PyPI (which would be more intuitive and avoid situations
> like this one). As far as I can tell things seem to be working in
> the gate behind the constraints revert[*] now.

So it seems to me that we can revert:
https://review.openstack.org/#/q/status:merged+NOT+branch:master+project:openstack/requirements+topic:bug/1629830
?

Yours Tony.


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] migrate_flavor_data doesn't flavor migrate meta data of VMs spawned during upgrade.

2016-10-03 Thread Suresh Vinapamula

Hi,

I did some investigation last week, why this was happening before I file
the bug. Here are my observations and I would like to work on it. Any
guidance is appreciated.

Upgrade procedure:
In my setup I have openstack controller on one node, neutron on another
node and rest of the nodes are computes. Assume they are running juno. As
the first step,
a) Bringup up a new openstack node in kilo
b) Migrate database from juno to kilo.
c) Run xxx manage db sync commands.
d) Set upgrade levels to juno
e) Migrate neutron and computes to the newer controller.

second step.
a) Upgrade neutron, and then start compute upgrades one at a time.

third step,
a) Finalize the upgrade by clearing upgrade levels and restarting services.
b) Issue migrate flavor data command.

This procedure is openstack side by side upgraded and neutron and computes
inplace upgraded.

Issue:
VMs spawned after step1 and during step2 are not flavor migrated. So,
migration to liberty was failing.

Investigation:
flavor migrate command filters instance uuids in nova.instance_extra table
whose 'flavor' column is NULL and fill in with the necessary flavor
information and delete those respective rows from the
nova.instance_system_metadata associated with that VM.
For the VMs spawned after the first step and before step2, this flavor
information in nova.instance_extra and also respective flavor information
in nova.instance_system_metadata table.
Since the filter looks for 'flavor ' column as NULL, these instances are
not caught to delete entries in nova.instance_system_metadata. And presence
of this data is failing nova db sync while migrating to liberty.

Possible Solutions:
I feel we should broaden the filter so that instances spawned after step1
and during step 2 are also accounted for data translation. As a quick
verification, I tried this by having no filer and it worked. I know filter
give efficiency, but would it matter in this context or should we broaden
the filter?

Please let me know if I am going in the right direction.

thanks

On Thu, Sep 1, 2016 at 10:28 AM, Matt Riedemann 
wrote:

> On 9/1/2016 12:05 PM, Suresh Vinapamula wrote:
>
>> On 8/31/2016 4:17 PM, Dan Smith wrote:
>>
>> Thanks Dan for your response. While I do run that before I start
>> my
>> move to liberty, what I see is that it doesn't seem to flavor
>> migrate
>> meta data for the VMs that are spawned after controller upgrade
>> from
>> juno to kilo and before all computes upgraded from juno to kilo.
>> The
>> current work around is to delete those VMs that are spawned after
>> controller upgrade and before all computes upgrade, and then
>> initiate
>> liberty upgrade. Then it works fine.
>>
>> I can't think of any reason why that would be, or why it would be a
>> problem. Instances created after the controllers are upgraded should
>> not
>> have old-style flavor info, so they need not be touched by the
>> migration
>> code.
>>
>> Maybe filing a bug is in order describing what you see?
>>
>> --Dan
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > >
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> Also, are you running with the latest kilo patch update? There were
>> some bug fixes backported after the release from what I remember.
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>> Hi Matt,
>>
>> Thanks for the response. I am currently using 2015.1.2. From the release
>> notes of 2015.1.4 https://wiki.openstack.org/wiki/ReleaseNotes/2015.1.4,
>> I can't correlate any fixes with this issue. Am I missing something?
>>
>> thanks
>>
>> Suresh
>>
>>
> The things I was looking for look like they are in 2015.1.2 so you should
> be OK there for at least known issues.
>
> --
>
> 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] [tc] open question to the candidates

2016-10-03 Thread Clark Boylan

On Mon, Oct 3, 2016, at 08:30 AM, gordon chung wrote:
> the TC has historically been a reactive council that lets others ask for 
> change and acts as the final approver. do you believe the TC should be a 
> proactive committee that initiates change and if yes, to what scope? 
> more generally, what are some specific issues you'd like the TC address 
> in the coming year?

Yes, I think the TC should be a proactive committee. I think the
OpenStack wide goals work has been a good push towards being more
proactive. As for scope I believe the current process of soliciting
feedback from the community then picking a small number of achievable
goals to focus on per release cycle is a good place to start. Chances
are it won't be perfect, but if we don't try something progress can't be
made. Then in a cycle look back on what worked and what didn't and
refine the process.

Ideally OpenStack wide goals should affect the breadth of our projects
and users. Specifically goals like becoming python 3 compatible and
testing on python 3 are great. CPython 2 has a limited lifetime and
OpenStack (not just Nova, Glance, etc) needs to be planning ahead to
deal with this. It isn't something that can happen overnight and we
should agree on a common plan to address this so that we don't end up
with some projects doing Python 3 and others doing PyPy* to the
detriment of our developers and users.

Another example of a place where project wide goals make sense is in
ensuring that OpenStack runs and is tested on newer distro releases as
they become available. OpenStack isn't deployed in a vacuum and we
should do what we can to make sure that the barriers to deployment don't
begin at "can't deploy OpenStack on the distro most people are trying to
deploy OpenStack on". In the past we have done a reasonable job at
uplifting OpenStack onto new distro releases and making sure the tests
run properly. The recent Trusty to Xenial transition has been somewhat
painful though. Part of that is probably my fault, but we should stop
expecting magical gnomes to do all the work for OpenStack and call it
out as an explicit goal in the future for all of OpenStack.

As a user of OpenStack clouds I would also like to see more push for a
consistent experience as presented to our end users. Tons of work has
been done to make this much better than it was a few years ago, but
there is so much more we can do. It would make me so happy if we could
make OpenStack useable without knowledge of the underlying cloud
implementation choices. This actually ends up being problematic due to
many small issues so I am not sure if this makes sense as an OpenStack
wide goal, but it should illustrate the level at which I think the TC
should be proactive.

* I have nothing against PyPy and this shouldn't be interpreted as an
argument against using it beyond CPython 2's end of life, but I think
that we need to solve large scale problems like this consistently so
that developers, operators, and our users don't have to juggle a half
dozen toolsets to get anything done with OpenStack.

Hope this helps,
Clark

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

Re: [openstack-dev] [all][elections] Voting for the TC Election is now open

2016-10-03 Thread Tony Breeds

On Tue, Oct 04, 2016 at 09:32:54AM +1100, Tony Breeds wrote:
> NOTE: The election officals have been contacted by a number of people stating
> that they have not recieved thier ballot.  In addition the email to
> openstack-dev announcing the opening of the elction did not arrive.  As such
> the election officials are performing the following actions:
> 
>  1. Extending the voting period by adding 24 hours.  The new time for election
> close will be: 23:45 October 9th, 2016 UTC.
>  2. Re-sending this email.  If you see this email but no ballot please contact
> the election officials[5]
>  3. Resending everyone's voter keys.  This last step does NOT allow for
> re-voting or adding additional voters.  Votes already cast are valid and
> will remain so

All ballots have been re-sent.

Yours Tony.


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] [tc] open question to the candidates

Excerpts from John Dickinson's message of 2016-10-03 14:26:00 -0700:
> 
> On 3 Oct 2016, at 12:31, Doug Hellmann wrote:
> >
> > I think that's the balance we want to
> > have: listen to input, collect information, then clearly set the
> > direction without over-prescribing the implementation.
> 
> In light of this statement, would you reevaluate previous decisions you've 
> made regarding implementation details? You've criticized OpenStack projects 
> for not using certain code, you've advocated for openstack-wide goals which 
> are all about implementation[1], and you voted against Swift and other 
> projects using Golang for an internal process[2]. Each of these are quite 
> prescriptive with regards to the implementation. Would you change your vote 
> on any of these decisions if you are reelected?
> 
> [1] https://review.openstack.org/#/c/349068/
> [2] 
> http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html

I said "without *over-prescribing*", not "without prescribing at
all". I generally don't care how the goal is achieved, as long as
it is. That's why the goals framework focuses on describing end-states,
and not procedures or "specs".

Yes, sometimes I will advocate for goals that involve implementation
details of projects.  Probably a lot of the time, actually, since
most of the goals we've discussed so far are related to doing things
consistently (if you're interested in the other goals being discussed,
there's an etherpad [3]). I want projects to use common tools and
implementation patterns as much as possible, because doing so
benefits our users, makes life easier for our contributors, and
enables cross-project efforts like infrastructure, documentation,
and release management. Common tools and patterns also contribute
to our sense of being one community that is working on one over-arching
project.

Taking the two specific goals discussed over the past few months:

The Python 3 goal is about running tests under Python 3 as well as
Python 3. I don't care what order or process projects follow to get
their tests running under Python 3. I do want them to do it, and I
do want them to get *all* of the tests running.

The Oslo cleanup goal is related to dealing with unsupported code
lingering in projects.  Projects should either remove unsupported
code in favor of supported code, or declare that they will support
the "forked" modules themselves by moving them out of a common
directory that implies they are supported by the Oslo team. Either
way we convert to using supported code and satisfy the goal.

Regarding Golang, I tried to explain my position to you at OpenStack
Days East a few weeks ago, but apparently I wasn't as clear as I
thought.  I have to look beyond the Swift team's immediate needs
and consider our entire community.  With that in mind, I did not
reject the use of Golang outright or permanently. I voted against
the Swift team's current request to be the first team to use it,
and in effect establish the standards for its use, based on the
team's continual resistance to adopting community standards.  Anyone
interested in the full statement I made at the time should read the
pastebin [4] as well as the meeting logs.

When the two of us talked about this in person, I tried to express
to you that I will reconsider my vote when the Swift team demonstrates
that it has revised its stance and begins participating in community
standards to the extent that I believe they would be good stewards
of the infrastructure needed to allow teams *besides themselves*
to use Golang.  If I am not mistaken, recently the team has done
some work to start incorporating reno, and I count that as a good
step.

If another team demonstrates a need to use a language other than
Python, I will consider their request separately and on its own
merits, regardless of the language.

Doug

[3] https://etherpad.openstack.org/p/community-goals
[4] http://paste.openstack.org/show/545744/

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

[openstack-dev] [all][elections] Voting for the TC Election is now open

2016-10-03 Thread Tony Breeds

NOTE: The election officals have been contacted by a number of people stating
that they have not recieved thier ballot. In addition the email to
openstack-dev announcing the opening of the elction did not arrive. As such
the election officials are performing the following actions:

1. Extending the voting period by adding 24 hours. The new time for election
close will be: 23:45 October 9th, 2016 UTC.
2. Re-sending this email. If you see this email but no ballot please contact
the election officials[5]
3. Resending everyone's voter keys. This last step does NOT allow for
re-voting or adding additional voters. Votes already cast are valid and
will remain so

Voting for the TC Election is now open and will remain open until 23:45 October
9th, 2016 UTC.

We are selecting 6 TC members, please rank all candidates in your order of
preference.

You are eligible to vote if you are a Foundation individual member[1] that also
has committed to one of the official programs projects[2] over the
Mitaka-Newton timeframe (September 5, 2015 00:00 UTC to September 4, 2016 23:59
UTC) or if you are one of the extra-atcs.[3]

What to do if you don't see the email and have a commit in at least one of the
official programs projects[2]:
* check the trash or spam folder of your gerrit Preferred Email address[4],
in case it went into trash or spam
* wait a bit and check again, in case your email server is a bit slow
* find the sha of at least one commit from the program project repos[2] and
email the election officials[1]. If we can confirm that you are entitled to
vote, we will add you to the voters list and you will be emailed a ballot.

Our democratic process is important to the health of OpenStack, please exercise
your right to vote.

Candidate statements/platforms can be found linked to Candidate names[6].

Happy voting,
Thank you,

[1]: http://www.openstack.org/community/members/
[2]:
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2016-elections
Note the tag for this repo, sept-2016-elections.
[3]: Look for the extra-atcs element in [2]
[4]: Sign into review.openstack.org: Go to Settings > Contact Information. Look
at the email listed as your Preferred Email. That is where the ballot has
been
sent.
[5]: http://governance.openstack.org/election/#election-officials
[6]: http://governance.openstack.org/election/#ocata-tc-candidates

Yours Tony.

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] [tc] open question to the candidates

2016-10-03 Thread Chris Dent


On Mon, 3 Oct 2016, gordon chung wrote:


the TC has historically been a reactive council that lets others ask for
change and acts as the final approver. do you believe the TC should be a
proactive committee that initiates change and if yes, to what scope?
more generally, what are some specific issues you'd like the TC address
in the coming year?


I ended up getting overly excited in my response to Clay and answering
over there. So by the power of hypertext:

http://lists.openstack.org/pipermail/openstack-dev/2016-October/105000.html

--
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] TC candidacy

2016-10-03 Thread Chris Dent


On Mon, 3 Oct 2016, Clay Gerrard wrote:


I just re-read your announcement - and I couldn't be happier you're running
:D


a) Glad to hear it.

b) It's a shame these email threads didn't start last week. I
suspect many of the people reading have already voted. I think the
conversations are still valuable, both for the people who haven't
voted and to shape future discussions. It's making more things more
visible, and that's good.


I was so surprised at the fallout from your suggestion that the TC should
actively engage in more broadcasting of important topics [1] to bring in
more voices from the community early!?  Links to IRC logs and Gerrit commit
history seemed to totally miss the point?


Yes, I found that surprising too. To be fair I think it probably has
a lot to do with different people's different communication styles.
For some people IRC logs and gerrit are great. For others, not so
much. This is one of the reasons for insisting that the TC have a
mixture of voices and opinions. It can be very easy to become
habituated to believing that the norm works for everyone, when it
could just be you for whom it is working.


I'm curious if any other discussions or questions on the mailing list have
excited or frustrated you in the past week?  Is there any specific goals
you have for a one year term on the TC - or do you think more clarity on
past "perceived agreements" and a better focus on visibility and
communication is the more important thing to fix first?


All that is important, and (transferring gordc's question over here)
better communication will certainly enhance the TC's capability as a
responsive (seems a better term than reactive) representative body.
Good communication is effectively a requirement for doing existing
and future work correctly.

Where I want to see the TC be proactive is a long list. A sample is
below. The reason I think the TC should take a lead on these is because
the issues need attention from a group that prioritizes the entire
community, not just one project, and the members of that group must have
the time to give real attention to the issues. Very few people in
the community are licensed to legitimately use time in that fashion.

Some ideas other candidates have already stated:

* Driving community-wide goals (for example Python 3 support sooner than
  later).

* Building bridges with other communities in similar spaces (for
  example our pals in k8s).

I hope that neither of these are controversial. They are fundamental for
the long term health of the community and the project.

Some notions that might be subject to some disagreement:

* Putting some strength in working groups like arch-wg and api-wg so
  we can start modernizing in general and in some cases correcting
  past mistakes.

* Concentrating more on contributor experience. Not at the expense
  of user experience, but in addition to. I think part of the role
  of the TC should be something akin to a union rep. Corporate driven
  open source is weird. We need to acknowledge that it presents some
  challenges. We've seen some discussion dancing around the edges of
  this topic in the review of the principles document linked from [1].

* Balance the needs of existing users against the needs of the users
  we haven't yet acquired somewhat in favor of the many more users yet
  to come. Too often we use existing users as an excuse to not make an
  improvement. This is not to say we should actively punish existing
  users but rather that there a multiple avenues to smooth transitions
  beyond simply avoiding them.

* Put some subjectivity back into the project evaluation process.
  The big tent was designed to make acceptance into the OpenStack
  community more objective. That's admirable in some ways, but has led
  to confusion about the identity of OpenStack. The thing is that
  taste matters. OpenStack needs to have opinions about what
  OpenStack is and does. We need humans to articulate those opinions
  and then act on them by sometimes saying yes and sometimes saying
  no. That's hard work but it pays dividends not just in community
  cohesion but also in product cohesion. This will require (as
  others have stated) making a real effort to set some goals on a 1, 2
  and 5 year timetable. Where do we want to be? How do we get there?
  What are our subjective assertions about how things should be at each
  of those stages.

* And because it needs to be said somewhere: I'm pretty okay with this
  whole golang thing. Requiring homogeneity is a sure fire way to
  limit innovation and kill any spirit of experimentation and
  exploration. We want the OpenStack community to be a place of
  constant learning. People who aren't learning will go elsewhere to
  do so. Do we want to lose them?

While I have opinions on all these things, and I will defend those
opinions with vigor, I want to be actively disagreed with. Active
debate is how we reach strong and reasonable compromises. I don't
want to impose my vision on OpenS

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

On 2016-10-03 16:15:01 -0500 (-0500), Edward Leafe wrote:
[...]
> So I think that there is evidence that unless you are already
> well-known, most people aren't going to take the time to dig
> deeper. Maybe anonymous campaigns aren't the answer, but they
> certainly would help in this regard.
[...]

Becoming well-known, at least within our technical community, tends
to be a mark of connectedness with the TC electorate (generally
through some manner of contribution whether that's serving in other
elected positions or working on cross-project efforts or simply
making excellent observations and suggestions on our mailing lists).
People who are relatively unknown in the community will, on the
whole, lack a breadth of experience outside their niche
cross-sections of OpenStack and so have trouble establishing
credibility with their constituency.

As for the anonymity idea, I rely far more on actions and positions
I've seen from candidates over their years of interactions with me
and the rest of the community. If I were forced to rely solely on
pseudonymous (what you described is not actually anonymous since
there would be a unique ID assigned) position statements, I would
mostly just end up attempting to map them to the candidates I knew
were running based on the opinions I know them to hold.
-- 
Jeremy Stanley

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

Re: [openstack-dev] [Nova] Live migration sub-team lead

2016-10-03 Thread Matt Riedemann


On 10/3/2016 12:31 PM, Timofei Durakov wrote:

Paul,

thanks for leading live migration sub-team. A lot of work were done in
that area for last year!

Best,
Timofey



On Mon, Oct 3, 2016 at 7:22 PM, Murray, Paul (HP Cloud) mailto:pmur...@hpe.com>> wrote:

Hi All,

I have had the pleasure of chairing the live migration sub-team for
the last year. Recently, as some of you will have noticed, my time
has been stretched to the extent that I have started to neglect the
task. Timofei Durakov has stood in for me on several occasions
recently and has now agreed to take over full time. I had planned to
bring this up in the meeting tomorrow, but yet again I am unable to
attend.

So thanks to all in the sub-team for being so self-organising and
making the meetings so easy. Please turn to Timofei as your first
point of contact for all things live migration from now on.

Best regards,
Paul

P.S. I will be in the meetings when I can.




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



Thanks Paul for organizing a lot of the live migration work the past 
couple of releases, and thanks Timofei for stepping up and continuing to 
push this work forward.


--

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] [tc] open question to the candidates

2016-10-03 Thread John Dickinson

On 3 Oct 2016, at 12:31, Doug Hellmann wrote:
>
> I think that's the balance we want to
> have: listen to input, collect information, then clearly set the
> direction without over-prescribing the implementation.

In light of this statement, would you reevaluate previous decisions you've made 
regarding implementation details? You've criticized OpenStack projects for not 
using certain code, you've advocated for openstack-wide goals which are all 
about implementation[1], and you voted against Swift and other projects using 
Golang for an internal process[2]. Each of these are quite prescriptive with 
regards to the implementation. Would you change your vote on any of these 
decisions if you are reelected?

[1] https://review.openstack.org/#/c/349068/
[2] http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html

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

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

On Oct 3, 2016, at 1:39 PM, Clint Byrum  wrote:
> 
> Of course, I read the essays of those who I don't know more carefully, and
> I often go searching through my ML archives to see if we've interacted on
> threads in the past. Still, I'm very unlikely to rank somebody higher than
> a personal acquaintance unless I don't have many personal acquaintances
> that I agree with that are nominated.

I understand, and would be less than honest if I stated that I never do the 
same thing. I'm questioning, though, whether that's a good thing, or part of 
our tribal nature as humans.

> So I get where you're going, but I don't think that can be "the
> election". In addition to not allowing me to judge peoples' character,
> it also introduces a _massive_ fraud incentive. If you are a candidate,
> and you write a paper that is equal to all others, you can gain votes just
> by secretly telling your friends which one is yours, and their implicit
> bias will 1) make many think this is morally ok, because they know you're
> a good candidate, and 2) make them more likely to vote for you.

I suppose that's a possible downside, although I don't know that anyone who 
would do that would have enough people they could call "friends" to get them 
elected. I know that such a tactic would certainly backfire if someone tried to 
get me to vote for them.

> One way to counter the problems associated with the popularity contest
> is to have some appointed members. We can admonish the TC to appoint a
> nominee who did not win the most votes, but who is more likely to break
> a groupthink cycle. This would only work if people paid attention to TC
> voting records, which AFAIK, nobody really does.

Heh, let's change the bylaws so that the top 4 (or 5 in the next cycle) 
vote-getters win, and the other two seats are chosen by lottery from the bottom 
5 vote getters! That's sure to liven things up! 

(kidding, of course!)

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

On Oct 3, 2016, at 12:18 PM, Clay Gerrard  wrote:
> 
>> After the nominations close, the election officials will assign each 
>> candidate a non-identifying label, such as a random number, and those 
>> officials will be the only ones who know which candidate is associated with 
>> which number. 
>> 
> I'm really uneasy about this suggestion.  Especially when it comes to 
> re-election, for the purposes of accountability I think it's really important 
> that voters be able to identify the candidates.  For some people there's a 
> difference in what they say and what they end up doing when left calling 
> shots from the bubble for too long.

This was a concern of mine, too, but IMO there haven't been too many cases 
where a TC member has said they would support X and then fail to do so. They 
might not prevail, being one of 13, but when that issue came up they were 
almost always consistent with what they said.

> As far as the other stuff... idk if familiarity == bias.  I'm sure lots of 
> occasions people vote for people they know because they *trust* them; but I 
> don't think that's bias?  I think a more common problem is when people vote 
> for a *name* they recognize without really knowing that person or what 
> they're about.  Or perhaps just as bad - *not* voting because they realize 
> they have on context to consider these candidates beyond name familiarity and 
> an (optional) email.

I think that with so many candidates for so few seats, most people simply don't 
have the time or the interest to look very deeply into things. I know that that 
shows up in the voting. Take the election from a year ago: there were 619 votes 
cast for 19 candidates. Out of these:
- 35 ballots only voted for one candidate
- 102 ballots voted for three or fewer
- 175 didn't even bother to vote for 6
- only 159 bothered to rank all the candidates

So I think that there is evidence that unless you are already well-known, most 
people aren't going to take the time to dig deeper. Maybe anonymous campaigns 
aren't the answer, but they certainly would help in this regard.

> I think a campaign period, and especially some effort [1] to have candidates 
> verbalize their viewpoints on topics that matter to the constituency could go 
> a long way towards giving people some more context beyond "i think this name 
> looks familiar; I don't really recognize this name"

Agreed 100%! It was made worse this year because the nominations closed on a 
Saturday, and with the late rush of people declaring their candidacy, gave no 
time at all for any sort of campaign discussions before voting began. There 
really needs to be a decent period of time allowed for people to get answers to 
whatever questions they may have.


-- 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] [Mentoring] Call for Mentors for Barcelona events

2016-10-03 Thread Emily K Hugenbruch



Hello,
We have two (2) great mentoring opportunities coming up for the Barcelona
summit.  These are a fairly short time commitment, so please consider
taking a few hours to help out people new to the community.

   Upstream University - Sunday October 23rd, 1:00-5:00PM & Monday, October
   24th, 10:00AM-4:00PM
   Schedule information here -
   
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16638/upstream-university-day-1

   Looking for 5-10 mentors to float around the training rooms, helping
   students who are stuck and offering advice.  Please sign up on the
   mentor signup form -
   
https://openstackfoundation.formstack.com/forms/mentor_mentee_signup_pre_barcelona
   , put "Upstream university only" under "Additional information about
   yourself.  You do *not* need to RSVP to the event on the schedule app if
   you fill out the formstack form.

   Speed Mentoring Breakfast sponsored by Intel - Tuesday, October 25,
   7:30-8:35AM
   Schedule information here -
   
https://www.openstack.org/summit/barcelona-2016/summit-schedule/events/16889/speed-mentoring-organized-by-women-of-openstack-sponsored-by-intel

   We're looking for 10-20 mentors, who are interested in offering either
   technical or career advice.  You'll meet with small groups of mentees in
   15 minute intervals and answer their questions about how to grow in the
   community.  It's a fast paced event and a great way to meet new people
   and introduce them to the summit.  Mentors should plan to arrive at
   7:15AM, although we will provide breakfast and caffeine!
   Please sign up via the schedule and select "mentor".  We will contact
   mentors ahead of time and hold a short call to go over logistics of the
   event shortly before the summit.

Thanks in advance for volunteering!
Sincerely,
Emily Kate Hugenbruch
Women of OpenStack Mentoring
__
OpenStack Development Mailing List (not for 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

On Oct 3, 2016, at 12:51 PM, Doug Hellmann  wrote:

> When I vote, I consider the positions a candidate takes, the ideas
> they propose, and -- equally importantly -- their track record of
> actually getting things done.  Hiding the candidate's identity makes
> it impossible to evaluate that track record and have a sense of
> whether they're likely to make any real progress on their ideas.

That's a very good point, and one I wrestled with. I tried to balance that with 
the desire to see an influx of new ideas; I guess this balance is where we 
differ.

> In the past we experimented with a few formal questions being posed
> to all candidates. I appreciate the fact that Gordon took the
> initiative and started a less formal thread on his own this time.
> I hope that everyone feels able to do the same, whether they have
> questions for specific candidates or for the entire slate.

I agree, and wish that the discussion Gordon started could have happened 
*before* people started voting. 

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

2016-10-03 Thread gordon chung

On 03/10/2016 1:18 PM, Clay Gerrard wrote:
> I think a more common problem is when people vote for a *name* they
> recognize without really knowing that person or what they're about.  Or
> perhaps just as bad - *not* voting because they realize they have on
> context to consider these candidates beyond name familiarity and an
> (optional) email

fully agree with this. this is how i've voted in the past (and to an 
extent, this time as well.). that said, i think it's good to get to know 
the candidates a bit more beyond the initial, often heavily vetted, 
self-nominations. i don't know if this will change anything but 
hopefully it stops the downward trend we have for TC election turnout.

cheers,
-- 
gord

ps. i apologise to the people running who i do know for not telling them 
ahead of time i was going to ask random questions. equal playing field :P

__
OpenStack Development Mailing List (not for 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-03 Thread Emilien Macchi

On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard  wrote:
>
>
> On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi  wrote:
>>
>>
>> - Make sure it works outside Devstack.
>>
>> There is a huge gap between what is tested by Devstack gate and what
>> operators
>> deploy on the field.  This gap tends to stretch the feedback loop between
>> developers and operators.  As a community, we might want to reduce this
>> gap
>> and make OpenStack testing more effective and more realistic.
>> That's an area of focus I would like to work and spread over OpenStack
>> projects if I'm elected.
>>
>
> This is a really interesting platform point.  It's been a concern in he
> community since *at least* Vancouver [1].  We've had lots of different
> viewpoints towards project install-ability raised this election:
>
> John Dickenson says installation of projects should go horizontal [2]
> Monty Taylor says services oriented deployment teams are the wasteful
> exception [3]
> John Griffith says how the TC approaches services oriented OpenStack will be
> an important factor in the future definition of OpenStack and it's relevancy
> [4]
>

Before I start replying to the questions, I would like to note that
I'm not against Devstack and I still see some value of such a project.
Devstack has been so far the first deployment tool that is used by
OpenStack continuous integration, my point is really about adding more
CI coverage.

> Do you think this is an important topic for OpenStack right now?  I'd be
> really interested to hear any *new* insights from the previous PTL of *one*
> of OpenStack's installation automation projects?  What could or should be
> done to reduce the bias/reliance towards a devstack or an
> "openstack-all-in-one" deployment model?  Can or should the TC be the
> champion of the discussion around "how to install" OpenStack?  How much of
> an impact does choices made in *testing* effect the install-ability and
> ease-of-use of OpenStack in general?

1) Do you think this is an important topic for OpenStack right now?
Yes. Making sure that OpenStack can be installed, upgraded and
operated outside devstack is in my opinion an important long-term
topic that needs to be addressed right now.

2) What could or should be done to reduce the bias/reliance towards a
devstack or an "openstack-all-in-one" deployment model?
Some projects (Heat, Ironic, etc) already run non-devstack jobs,
example given with TripleO.
I'm not going to make advertising for this project but it's an example
of installer that deploys a good set of service with uses-cases close
to production: multinode, SSL, IPv6, upgrade testing, network
isolation, etc.
We could see more of it in OpenStack, where projects like TripleO,
Kolla, Fuel, etc, could run their CI jobs in projects like Nova or
Swift for example.
It would reduce the feedback loop between developers and operators
when something breaks (backward compatibility testing is a good
use-case), or increase coverage (things that Devstack doesn't test).

3) Can or should the TC be the champion of the discussion around "how
to install" OpenStack?
I don't think so. To me, it's up to our community to decide how to
install OpenStack.
The deployment tool (ansible versus chef versus puppet, etc) is
something that we can't choose on behalf of our operators, because
they already have tools to manage their existing infrastructure.
Where TC could help, is to drive OpenStack deployment tools projects
to increase their impact in OpenStack testing with a final goal of
reducing the feedback loop between devs & ops.

4) How much of an impact does choices made in *testing* effect the
install-ability and ease-of-use of OpenStack in general?
- evaluate how a project does respect backward compatibility in
configuration and APIs.
- evaluate if projects can actually be upgraded by using operator and
not something that operators don't use (devstack / grenade).
That's the two things that directly came into my mind.

> Somewhat unrelated.  Do you have any personal thoughts/insights on how you
> believe OpenStack should approach potentially disruptive or "competing"
> design in general - like ansible/puppet or even Kolla?

I don't think Ansible / Puppet OpenStack / Kolla / TripleO / Fuel /
(...) compete in design, but they rather fit (or match) the needs of
people who deploy OpenStack in production.
In my experience of deployment, I've seen many cases where a company
already used Ansible (or Puppet or Chef, etc) in their infrastructure,
and picked the same tool to deploy OpenStack, to accelerate their
adoption and facilitate their deployment team.
Such a diversity is in my opinion awesome as long as we directly
consume what is produced by upstream projects and report immediate
feedback with CI and horizontal collaboration.

I hope I answered to the questions, and if not please let me know, I'm
always open for questions and feedback.

Thanks,
-- 
Emilien Macchi

__
Op

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

2016-10-03 Thread Ken Giusti

+1 for Gevorg!

On Mon, Oct 3, 2016 at 2:02 PM, Davanum Srinivas  wrote:
> +1 from me!
>
> On Mon, Oct 3, 2016 at 1: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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Ken Giusti  (kgiu...@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] [oslo] Adding ozamiatin to oslo-core

2016-10-03 Thread Ken Giusti

+1 for sure.

On Mon, Oct 3, 2016 at 1: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



-- 
Ken Giusti  (kgiu...@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] open question to the candidates

2016-10-03 Thread Jim Rollenhagen

On Mon, Oct 3, 2016 at 11:30 AM, gordon chung  wrote:
> hi,
>
> as there are many candidates this TC election, i figured i'd ask a
> question to better understand the candidates from the usual sales pitch
> in self-nominations. hopefully, this will give some insights into the
> candidates for those who haven't voted yet. obviously, the following is
> completely optional. :)
>
> i initially asked this to John Dickinson[1] in his self-nomination. i'd
> like to open this up to everyone. the (re-worded) question is:
>
> the TC has historically been a reactive council that lets others ask for
> change and acts as the final approver. do you believe the TC should be a
> proactive committee that initiates change and if yes, to what scope?
> more generally, what are some specific issues you'd like the TC address
> in the coming year?

I believe I addressed this in my candidacy email, but for posterity I'll
talk about it a bit more here.

I believe that the TC will always need to be reactive to some extent,
however it should also strive to be more proactive than it currently is.

The big tent is a good thing IMO, but needs some work. Many projects
struggle with finding the common ways to do OpenStack-y things
(upgrades, microversions, integration testing, etc), and I think the TC
should work to make that easier. Most (all?) of the current and
nominated TC members know how to code, and (hopefully, heh) all
of them are familiar with how OpenStack works. They should use their
skills and knowledge to help projects become part of a coherent
OpenStack - building common tools and frameworks that projects
can adopt to be more like other projects.

tl;dr we assert OpenStack is "one framework of collaborating components",
and not "a loose connection of disconnected projects".[0] From the outside,
it doesn't always look like that. The TC should work to help fix that.

// jim

[0] http://governance.openstack.org/reference/principles.html#one-openstack

__
OpenStack Development Mailing List (not for 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] open question to the candidates

Excerpts from gordon chung's message of 2016-10-03 15:30:56 +:
> hi,
> 
> as there are many candidates this TC election, i figured i'd ask a 
> question to better understand the candidates from the usual sales pitch 
> in self-nominations. hopefully, this will give some insights into the 
> candidates for those who haven't voted yet. obviously, the following is 
> completely optional. :)
> 
> i initially asked this to John Dickinson[1] in his self-nomination. i'd 
> like to open this up to everyone. the (re-worded) question is:
> 
> the TC has historically been a reactive council that lets others ask for 
> change and acts as the final approver. do you believe the TC should be a 
> proactive committee that initiates change and if yes, to what scope? 
> more generally, what are some specific issues you'd like the TC address 
> in the coming year?
> 
> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-September/104821.html

Thanks for raising this question, Gordon.

I hope it is clear from my pushing the goals initiative [2] this
cycle that I want the TC to be a bit more active than it has been
in encouraging project teams to take specific action so the whole
project is moving in common direction. On the other hand, the process
for selecting those goals is intended to incorporate a lot of input
from the community and it could also characterized as "reactive"
to what the community wants. I think that's the balance we want to
have: listen to input, collect information, then clearly set the
direction without over-prescribing the implementation.

Doug

[2] http://governance.openstack.org/goals/index.html

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

Re: [openstack-dev] TC candidacy

2016-10-03 Thread David Moreau Simard

On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard  wrote:
> Do you think this is an important topic for OpenStack right now?  I'd be
> really interested to hear any *new* insights from the previous PTL of *one*
> of OpenStack's installation automation projects?  What could or should be
> done to reduce the bias/reliance towards a devstack or an
> "openstack-all-in-one" deployment model?  Can or should the TC be the
> champion of the discussion around "how to install" OpenStack?  How much of
> an impact does choices made in *testing* effect the install-ability and
> ease-of-use of OpenStack in general?

I'll bounce on that too.

I think part of the problem is that the OpenStack projects develops
and tests against Devstack and if it works there, they mostly call it
a day.
Sort of exaggerating but I hope you understand.

The reality is that you don't go in production with Devstack.

Users and operators tend to go in production in one of three ways:
1) Manually (ouch) with documentation available on docs.o.o, usually
using packages provided by Debian, Ubuntu or RDO on CentOS
2) Purpose-built "home" made installation layer using high-level
configuration management modules (OSA, Puppet, Chef, etc.), that
install either from source or from distro packages
3) Using actual installers that often wrap around what is provided in
#2 but not exclusively (TripleO, Packstack, Kolla, Fuel, etc.)

The reason why "It worked in Devstack" has become a meme is because
historically, the developer community has not paid a lot of attention
to make sure #1 through #3 still work as a result of their changes.
I've been told numerous times as a maintainer/developer and user of #2
and #3 that I ought to keep up with the release notes if my stuff is
broken.

Thankfully, I think reception to issues/bugs has gotten better over
the course of Newton.
However, it still takes a considerable amount of time to track issues,
sometimes with projects we are not familiar with at all, and get the
required information to file a comprehensible report.

Sometimes the problem is in the project, sometimes in the
configuration management module (i.e, deprecation, non-backwards
compatible change, etc.), sometimes in packaging (RDO/UCA/Debian),
sometimes elsewhere.
This is all very complex.

I like to think we have an excellent test coverage matrix in
puppet-openstack [1] covering both RDO and UCA with multiple projects,
different backends, ipv6, SSL, etc.
We've started levering that coverage in Tempest already where Puppet
has 3 non-voting jobs to help provide input.

I think we could do better and I'm confident we /can/ do better.

[1]: https://github.com/openstack/puppet-openstack-integration#description

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] TC Candidacy

This was a riveting soapbox missive - and I agree with what you said -
particularly about the focus on breaking down the barriers to building out
and supporting the OpenStack contributor base.

But I don't have a good sense for how you want to apply that focus in
action on the TC?  I went back and looked at a number of mailing list
threads you participated in - and happily recalled your very matter of fact
presentation.  Frankly it was quite refreshing to see how often you seemed
to offer historical context more that your personal opinion (!!!)

Is there any *specific* goals you have for a one year term on the TC - or
do you think more focus on contributors is the most important thing to fix
first?  Would you perhaps consider to share your thoughts in response to
Gordon's question [1]?

-Clay

1.
http://lists.openstack.org/pipermail/openstack-dev/2016-October/104953.html


On Thu, Sep 29, 2016 at 4:47 PM, Jeremy Stanley  wrote:

> I guess I'll send a copy of mine to the ML too, since all the cool
> kids seem to be doing it...
>
> Most of you probably know me as "that short dude in the Hawaiian
> shirt and long hair." I'll answer to "Jeremy," "fungi" or even just
> "hey you." I'm starting my third cycle as PTL of the Infrastructure
> team, and have been a core reviewer and root sysadmin for
> OpenStack's community-maintained project infrastructure for the past
> four years. I've also been doing vulnerability management in
> OpenStack for almost as long, chaired conference tracks, and given
> talks to other communities on a variety of OpenStack-related topics.
> I help with elections, attend and participate in TC meetings and
> review proposed changes to governance. I have consistent, strong
> views in favor of free software and open/transparent community
> process.
>
> https://wiki.openstack.org/user:fungi
>
> I see OpenStack not as software, but as a community of people who
> come together to build something for the common good. We've been
> fortunate enough to experience a bubble of corporate interest which
> has provided amazing initial momentum in the form of able software
> developers and generous funding, but that can't last forever. As
> time goes on, we will need to rely increasingly on effort from
> people who contribute to OpenStack because it interests them, rather
> than because some company is paying them to do so. The way I see it,
> we should be preparing now for the future of our project:
> independent, volunteer contributors drawn from the global free
> software community. However, we're not succeeding in attracting them
> the way some other projects do, which brings me to a major
> concern...
>
> OpenStack has a public relations problem we need to solve, and soon.
> I know I'm not the only one who struggles to convince contributors
> in other communities that we're really like them, writing free
> software under transparent processes open to any who wish to help.
> This skepticism comes from many sources, some overt (like our
> massive trade conferences and marketing budget) while others
> seemingly inconsequential (such as our constant influx of new
> community members who are unfamiliar with free software concepts and
> lack traditional netiquette). Overcoming this not-really-free
> perception is something we absolutely must do to be able to attract
> the unaffiliated volunteers who will continue to maintain OpenStack
> through the eventual loss of our current benefactors and well into
> stabilization.
>
> Prior to OpenStack, I worked for longer than I care to remember as
> an "operator" at Internet service, hosting and telecommunications
> providers doing Unix systems administration, network engineering,
> virtualization and information security. When I first started my
> career, you couldn't be a capable systems administrator without a
> firm grasp of programming fundamentals and couldn't be a good
> programmer without understanding the basics of systems
> administration. I'm relieved that, after many years of companies
> trying to tell us otherwise, our industry as a whole is finally
> coming back around to the same realization. Similarly, I don't
> believe we as a community benefit by socializing a separation of
> "operators" from "developers" and feel the role distinction many
> attempt to strike between the two is at best vague, while at its
> worst completely alienating a potential source of current and future
> contributions.
>
> What causes software to succeed in the long run is not hype,
> limitless funding or even technical superiority, it's the size and
> connectedness of its community of volunteers and users who invest
> themselves and their personal time. The work we're doing now is
> great, don't get me wrong, but for it to survive into the next
> decade and beyond we need to focus more on building a close-knit
> community of interested contributors even if it's not in the best
> interests of industry pundits or vendor product roadmaps.
>
> OpenStack is people. If we l

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Davanum Srinivas

Thanks for the prompt follow up Jeremy!

-- Dims

On Mon, Oct 3, 2016 at 3:19 PM, Jeremy Stanley  wrote:
> On 2016-10-03 16:11:25 + (+), Jeremy Stanley wrote:
> [...]
>> I think we can bring this thread to a close now. Upstream deleted
>> the broken wheel from PyPI a little over an hour ago, and within
>> about 5 minutes it disappeared from our CI system mirrors as well
>> (PyPI deletions propagate automatically through our mirroring). At
>> this point things _should_ be back to normal, and projects can
>> probably start working on reverting or abandoning any temporary
>> workarounds.
>
> I just learned that we (unnecessarily) also copy available wheels
> from PyPI into our separate wheel mirrors when building
> architecture-specific wheels as a side effect of trivially reusing
> the wheel cache to populate it. Since those mirrors are effectively
> append-only we ended up persisting a copy of the broken wheel there
> even after it vanished from our PyPI mirror, and so it continued to
> be found by jobs in our CI system.
>
> In the past few minutes I've cleared out vestigial copies of it
> there, and we're reflecting on ways we can enhance our wheel
> building jobs to omit duplication of wheels which are already
> present on PyPI (which would be more intuitive and avoid situations
> like this one). As far as I can tell things seem to be working in
> the gate behind the constraints revert[*] now.
>
> [*] https://review.openstack.org/381192
> --
> 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



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

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

On 2016-10-03 16:11:25 + (+), Jeremy Stanley wrote:
[...]
> I think we can bring this thread to a close now. Upstream deleted
> the broken wheel from PyPI a little over an hour ago, and within
> about 5 minutes it disappeared from our CI system mirrors as well
> (PyPI deletions propagate automatically through our mirroring). At
> this point things _should_ be back to normal, and projects can
> probably start working on reverting or abandoning any temporary
> workarounds.

I just learned that we (unnecessarily) also copy available wheels
from PyPI into our separate wheel mirrors when building
architecture-specific wheels as a side effect of trivially reusing
the wheel cache to populate it. Since those mirrors are effectively
append-only we ended up persisting a copy of the broken wheel there
even after it vanished from our PyPI mirror, and so it continued to
be found by jobs in our CI system.

In the past few minutes I've cleared out vestigial copies of it
there, and we're reflecting on ways we can enhance our wheel
building jobs to omit duplication of wheels which are already
present on PyPI (which would be more intuitive and avoid situations
like this one). As far as I can tell things seem to be working in
the gate behind the constraints revert[*] now.

[*] https://review.openstack.org/381192
-- 
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

[openstack-dev] [ironic] weekly subteam report

2016-10-03 Thread Loo, Ruby

Hi,

Here is this week's subteam report for Ironic. As usual, this is pulled 
directly from the Ironic whiteboard[0] and formatted.

Bugs (dtantsur)
===
- Stats (diff between 26 Sep 2016 and 03 Oct 2016)
- Ironic: 205 bugs (+10) + 212 wishlist items (-4). 6 new (+6), 169 in progress 
(+10), 0 critical, 32 high (+1) and 18 incomplete (+1)
- Inspector: 14 bugs (+3) + 19 wishlist items. 1 new, 13 in progress (+3), 0 
critical, 4 high (+3) and 1 incomplete
- Nova bugs with Ironic tag: 10 (+4). 0 new, 0 critical, 1 high (+1)

Gate improvements (jlvillal, lucasagomes, dtantsur)
===
* trello: 
https://trello.com/c/HWVHhxOj/1-multi-tenant-networking-network-isolation
- no updates from dtantsur
- (lucasagomes) UEFI tests works but currently "blocked" by cirros not 
supporting UEFI in the latest release, see: 
https://bugs.launchpad.net/ironic/+bug/1625616

Generic boot-from-volume (TheJulia, dtantsur, lucasagomes)
==
* trello: https://trello.com/c/UttNjDB7/13-generic-boot-from-volume
- TheJulia will be rebasing/updating revisions this week.

Notifications (mariojv)
===
* trello: https://trello.com/c/MD8HNcwJ/17-notifications
- Power state notifications patch is close: 
https://review.openstack.org/#/c/321865/
- CRUD notification spec needs reviewer attention: 
https://review.openstack.org/#/c/347242/

Serial console (yossy, hshiina, yuikotakadamori)

* trello: https://trello.com/c/nm3I8djr/20-serial-console
- Nova patch: needs review https://review.openstack.org/#/c/328157/
- ironic bug: needs review https://review.openstack.org/#/c/363647/

Enhanced root device hints (lucasagomes)

* trello: https://trello.com/c/f9DTEvDB/21-enhanced-root-device-hints
- Waiting on a ironic-lib release
  (jroll) release team won't do release until next week (after final Newton 
releases this week)

Inspector (dtansur)
===
* trello: https://trello.com/c/PwH1pexJ/23-rescue-mode
- a patch is up to move all inspector tempest jobs to Xenial
- LLDP bits for the python-ironic-inspector-client&CLI: 
https://review.openstack.org/#/c/374381/ (spec)

Bifrost (TheJulia)
==
- Currently working towards support of keystone based authentication.

.

Until next week,
--ruby

[0] https://etherpad.openstack.org/p/IronicWhiteBoard

__
OpenStack Development Mailing List (not for 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, Sep 27, 2016 at 2:52 PM, Emilien Macchi  wrote:

>
> - Make sure it works outside Devstack.
>
> There is a huge gap between what is tested by Devstack gate and what
> operators
> deploy on the field.  This gap tends to stretch the feedback loop between
> developers and operators.  As a community, we might want to reduce this gap
> and make OpenStack testing more effective and more realistic.
> That's an area of focus I would like to work and spread over OpenStack
> projects if I'm elected.
>
>
This is a really interesting platform point.  It's been a concern in he
community since *at least* Vancouver [1].  We've had lots of different
viewpoints towards project install-ability raised this election:

   - John Dickenson says installation of projects should go horizontal [2]
   - Monty Taylor says services oriented deployment teams are the wasteful
   exception [3]
   - John Griffith says how the TC approaches services oriented OpenStack
   will be an important factor in the future definition of OpenStack and it's
   relevancy [4]

Do you think this is an important topic for OpenStack right now?  I'd be
really interested to hear any *new* insights from the previous PTL of *one*
of OpenStack's installation automation projects?  What could or should be
done to reduce the bias/reliance towards a devstack or an
"openstack-all-in-one" deployment model?  Can or should the TC be the
champion of the discussion around "how to install" OpenStack?  How much of
an impact does choices made in *testing* effect the install-ability and
ease-of-use of OpenStack in general?

Somewhat unrelated.  Do you have any personal thoughts/insights on how you
believe OpenStack should approach potentially disruptive or "competing"
design in general - like ansible/puppet or even Kolla?

-Clay

1. https://www.youtube.com/watch?v=ZY8hnMnUDjU&feature=youtu.be&t=379
2.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104815.html
3.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104844.html
4.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104833.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-10-03 Thread Clint Byrum

Excerpts from Edward Leafe's message of 2016-10-03 11:46:41 -0500:
> So the period of self-nominations for the Technical Committee seats has 
> ended, and the voting has begun. I've been a very close observer of this 
> process for several cycles, and I have some ideas I'd like to share. Full 
> disclosure: I am a current candidate for the TC, and have been a candidate 
> several times in the past, all of which were unsuccessful.
> 
> When deciding to run, candidates write a long, thoughtful essay on their 
> reasons for wanting to serve on the TC, and those essays are typically the 
> last you hear from them until the election. It has been rare for anyone to 
> ask follow-up questions, or to challenge the candidates to explain their 
> positions more definitively. I have spoken with many people at the Summits, 
> which always closely followed the TC election (warning: unscientific samples 
> ahead!), and what their selection process mostly boils down to is: they pick 
> the names they are most familiar with. Many people don't read those long 
> candidacy posts, and nearly all couldn't remember a single point that any of 
> the candidates had put forth.
> 
> We are fortunate in that all of the candidates are exceptionally 
> well-qualified, and those elected have put in excellent service while on the 
> TC. But one thing I'm afraid of is that we tend to get into a situation where 
> groupthink [0] is very likely. There are many excellent candidates running in 
> every election, but it is rare for someone who hasn't been a PTL of a large 
> project, and thus very visible, has been selected. Is this really the best 
> approach?
> 

I think you're right, that groupthink is very likely. In so much as, I am
more likely to select people from my own closer peer group who thinks like
me, because I agree with their general way of working and thinking, and
thus, the TC will end up thinking like the largest, most moderate group
of people in OpenStack.

> I wrote a blog post about implicit bias [1], and in that post used the 
> example of blind auditions for musical orchestras radically changing the 
> selection results. Before the introduction of blind auditions, men 
> overwhelmingly comprised orchestras, but once the people judging the 
> auditions had no clue as to whether the musician was male or female, women 
> began to be selected much more in proportion to their numbers in the audition 
> pools. So I'd like to propose something for the next election: have 
> candidates self-nominate as in the past, but instead of writing a big 
> candidacy letter, just state their interest in serving. After the nominations 
> close, the election officials will assign each candidate a non-identifying 
> label, such as a random number, and those officials will be the only ones who 
> know which candidate is associated with which number. The nomination period 
> can be much, much shorter, and then followed by a week of campaigning (the 
> part that's really missing in the cur
>  rent process). Candidates will post their thoughts and positions, and 
> respond to questions from people, and this is how the voters will know who 
> best represents what they want to see in their TC.
> 
> 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. Keeping anonymity will be difficult, and will preclude the use of 
> email for posting positions and responses, since email identifies the sender. 
> So perhaps candidates could forward their posts to the election officials, 
> who will post them for the candidates, identifying them by number only. The 
> voting form will only list the candidate numbers, so the end result will be 
> people casting votes for the candidates whose platform most matches what they 
> want to see in the TC, and who have best answered any questions raised by 
> others.
> 

Character is a massive factor in choosing representatives. The position
essay is just a small reflection to introduce one self to those who
do not know them. But really, I'm going to weigh Josh Harlow's value
as a TC member against Jeremy Stanley's value as a TC member based on
the various conversations we've had at summits, on the ML, and on IRC,
far more heavily than I can using a quick position essay.

Of course, I read the essays of those who I don't know more carefully, and
I often go searching through my ML archives to see if we've interacted on
threads in the past. Still, I'm very unlikely to rank somebody higher than
a personal acquaintance unless I don't have many personal acquaintances
that I agree with that are nominated.

So I get where you're going, but I don't think that can be "the
election". In addition to not allowing me to judge peoples' character,
it also introduces a _massive_ fraud incentive. If you are a candidate,
and you write a paper that is equal to

[openstack-dev] [nova][bugs] Nova Bugs Team Meeting this Tuesday at 1800 UTC

2016-10-03 Thread Augustina Ragwitz

The next Nova Bugs Team meeting will be Tuesday, October 3 at 1800 UTC
in #openstack-meeting-4

http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160920T18

Feel free to add to the meeting agenda: 
https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam

-- 
Augustina Ragwitz
Señora Software Engineer
---
Ask me about contributing to OpenStack Nova!
https://wiki.openstack.org/wiki/Nova/Mentoring

Waiting for your change to get through the gate? Clean up some Nova
bugs!
http://45.55.105.55:8082/bugs-dashboard.html
---
email: aragwitz+n...@pobox.com
irc: auggy

__
OpenStack Development Mailing List (not for 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] open question to the candidates

2016-10-03 Thread Joshua Harlow


gordon chung wrote:

hi,

as there are many candidates this TC election, i figured i'd ask a
question to better understand the candidates from the usual sales pitch
in self-nominations. hopefully, this will give some insights into the
candidates for those who haven't voted yet. obviously, the following is
completely optional. :)

i initially asked this to John Dickinson[1] in his self-nomination. i'd
like to open this up to everyone. the (re-worded) question is:

the TC has historically been a reactive council that lets others ask for
change and acts as the final approver. do you believe the TC should be a
proactive committee that initiates change and if yes, to what scope?
more generally, what are some specific issues you'd like the TC address
in the coming year?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104821.html

thanks,


What a neat question!

So to me there is a middle-ground here between a fully proactive 
committee and a reactive one. I believe it has gone a little to far to 
the reactive side and I would like to have it move more toward the 
proactive side (obviously not all the way to proactive, this isn't a 
dictatorship).


The scope I would like is for the TC to be a body that helps advocate 
the larger picture of where the community wants to be in 2-5 years and 
being proactively trying to help make that happen. That could involve 
reaching out to other communities and working with the technical 
leadership in those other communities (for example the CNCF @ 
http://cncf.io/ who is working with these folks?). It should also 
involve working with-in our own community to try to understand what the 
2-5 year vision really is (because honestly what is it?); and working 
through the writing of that down, the dissemination of it and working 
with folks that don't (or may not) agree with it.


In general I'd really like for folks on the TC to be leaders that can 
help proactively guide the rest of the community forward... I don't 
quite know the full scope of such guidance, but I feel it is a missing 
component the community hasn't ever quite figured out to well (but I 
still have hope!).


-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

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

2016-10-03 Thread Davanum Srinivas

+1 from me!

On Mon, Oct 3, 2016 at 1: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



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

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

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

2016-10-03 Thread Davanum Srinivas

+1 from me!.

On Mon, Oct 3, 2016 at 1: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



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

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

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

Excerpts from Clay Gerrard's message of 2016-10-03 10:18:43 -0700:
> On Mon, Oct 3, 2016 at 9:46 AM, Edward Leafe  wrote:
> 
> > After the nominations close, the election officials will assign each
> > candidate a non-identifying label, such as a random number, and those
> > officials will be the only ones who know which candidate is associated with
> > which number.
> 
> 
> I'm really uneasy about this suggestion.  Especially when it comes to
> re-election, for the purposes of accountability I think it's really
> important that voters be able to identify the candidates.  For some people
> there's a difference in what they say and what they end up doing when left
> calling shots from the bubble for too long.
> 
> As far as the other stuff... idk if familiarity == bias.  I'm sure lots of
> occasions people vote for people they know because they *trust* them; but I
> don't think that's bias?  I think a more common problem is when people vote
> for a *name* they recognize without really knowing that person or what
> they're about.  Or perhaps just as bad - *not* voting because they realize
> they have on context to consider these candidates beyond name familiarity
> and an (optional) email.
> 
> I think a campaign period, and especially some effort [1] to have
> candidates verbalize their viewpoints on topics that matter to the
> constituency could go a long way towards giving people some more context
> beyond "i think this name looks familiar; I don't really recognize this
> name"

I agree, on both counts.

When I vote, I consider the positions a candidate takes, the ideas
they propose, and -- equally importantly -- their track record of
actually getting things done.  Hiding the candidate's identity makes
it impossible to evaluate that track record and have a sense of
whether they're likely to make any real progress on their ideas.

In the past we experimented with a few formal questions being posed
to all candidates. I appreciate the fact that Gordon took the
initiative and started a less formal thread on his own this time.
I hope that everyone feels able to do the same, whether they have
questions for specific candidates or for the entire slate.

I don't want to speak for everyone else, but my self-nomination
email is only intended as a snapshot or summary of my thoughts on
a few issues that I see as important.  If I didn't mention a topic,
it's not necessarily due to lack of interest. I'll be happy to
respond to questions here on the list.

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

Excerpts from Hayes, Graham's message of 2016-10-03 17:35:44 +:
> On 03/10/2016 17:49, Edward Leafe wrote:
> > So the period of self-nominations for the Technical Committee seats has 
> > ended, and the voting has begun. I've been a very close observer of this 
> > process for several cycles, and I have some ideas I'd like to share. Full 
> > disclosure: I am a current candidate for the TC, and have been a candidate 
> > several times in the past, all of which were unsuccessful.
> >
> > When deciding to run, candidates write a long, thoughtful essay on their 
> > reasons for wanting to serve on the TC, and those essays are typically the 
> > last you hear from them until the election. It has been rare for anyone to 
> > ask follow-up questions, or to challenge the candidates to explain their 
> > positions more definitively. I have spoken with many people at the Summits, 
> > which always closely followed the TC election (warning: unscientific 
> > samples ahead!), and what their selection process mostly boils down to is: 
> > they pick the names they are most familiar with. Many people don't read 
> > those long candidacy posts, and nearly all couldn't remember a single point 
> > that any of the candidates had put forth.
> >
> > We are fortunate in that all of the candidates are exceptionally 
> > well-qualified, and those elected have put in excellent service while on 
> > the TC. But one thing I'm afraid of is that we tend to get into a situation 
> > where groupthink [0] is very likely. There are many excellent candidates 
> > running in every election, but it is rare for someone who hasn't been a PTL 
> > of a large project, and thus very visible, has been selected. Is this 
> > really the best approach?
> >
> > I wrote a blog post about implicit bias [1], and in that post used
the example of blind auditions for musical orchestras radically
changing the selection results. Before the introduction of blind
auditions, men overwhelmingly comprised orchestras, but once the people
judging the auditions had no clue as to whether the musician was male
or female, women began to be selected much more in proportion to their
numbers in the audition pools. So I'd like to propose something for the
next election: have candidates self-nominate as in the past, but
instead of writing a big candidacy letter, just state their interest in
serving. After the nominations close, the election officials will
assign each candidate a non-identifying label, such as a random number,
and those officials will be the only ones who know which candidate is
associated with which number. The nomination period can be much, much
shorter, and then followed by a week of campaigning (the part that's
really missing in the current pro
> >  cess). Candidates will post their thoughts and positions, and respond to 
> > questions from people, and this is how the voters will know who best 
> > represents what they want to see in their TC.
> 
> On the topic of implicit bias - I am open to correction on this, but I
> do not think we have had a TC member who was not heavily involved in
> either Cross Project teams, or one of the projects that spun out of
> Nova in the early years.
> 
> Now, is this bias, or a side effect of people on smaller projects not
> necessarily having dedicated upstream time.
> 
> Is this something we are worried about (or should be worried about)?

That's a good question. Leadership sustainability one of the reasons
I hope that the new PTG structure, with separate days for cross-project
meetings, will result in more folks with more time for cross-project
work that will give them the sort of perspective, and interest, to
make them good TC members.

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] [all][elections][TC] TC candidacy

2016-10-03 Thread John Dickinson



On 27 Sep 2016, at 9:21, Sean McGinnis wrote:

> I would like to announce my candidacy for a position on the Technical
> Committee.
>
> I work for Dell EMC with over a decade (quite a bit over, but I don't want to
> think about that) in storage and software development. I have been involved in
> OpenStack since the Icehouse cycle and have served as the Cinder PTL since the
> Mitaka release.
>
> I think it's important to have active PTLs on the TC. TC decisions need to be
> grounded in the reality of day to day project development. I think it will 
> also
> be good for me as a PTL to be forced to take a wider view of things across the
> whole ecosystem.
>
> I think outreach and education is important to spread interest in OpenStack 
> and
> provide awareness to reach new people. I've spoken at several Summits, as well
> as OpenStack Days events and (more pertinent to Cinder) at Storage Network
> Industry Association (SNIA) events.
>
> I think it's important to get feedback from actual operators and end users. I
> have tried to reach out to these users as well as attend the Ops Midcycle in
> order to close that feedback loop.
>
> I would continue to work towards these things and bring that feedback to the
> TC - making sure the decisions we make have the end user in mind.
>
> Another goal for me is simplicity. With the Big Tent, more interacting,
> projects, and lot's of competing interests, things have gotten much more
> complicated over the last several releases.
>
> I say this while acknowledging within Cinder - while I have been PTL - a lot 
> of
> complexity has been added. In most cases there are very valid reasons for 
> these
> changes. So even with a desire to make things as simple as possible, I 
> consider
> myself a pragmatist and recognize that complexity is sometimes unavoidable in
> order to move forward. But one thing I would try to focus on as a TC member
> would be to reduce complexity anywhere it's possible and where it makes sense.

Sean,

Are there some specific areas of complexity that you would like to change in 
OpenStack now? How would you change them? Are there things you see happening in 
OpenStack now that need to be stopped because they will produce too much 
complexity?


--John





>
> It would be an honor to serve as a member of the TC and help do whatever I can
> to help the community continue to succeed and grow.
>
> Thank you for your consideration.
>
> Sean McGinnis (smcginnis)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] TC candidacy

I just re-read your announcement - and I couldn't be happier you're running
:D

I was so surprised at the fallout from your suggestion that the TC should
actively engage in more broadcasting of important topics [1] to bring in
more voices from the community early!?  Links to IRC logs and Gerrit commit
history seemed to totally miss the point?

I'm curious if any other discussions or questions on the mailing list have
excited or frustrated you in the past week?  Is there any specific goals
you have for a one year term on the TC - or do you think more clarity on
past "perceived agreements" and a better focus on visibility and
communication is the more important thing to fix first?

Thanks again,

-Clay

1. This is a great example how much this attitude of "full contact
community engagement" is *needed* and how much it's *lacking* with the
current set of representatives ->
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103223.html -
not surprisingly it took someone from "the outside" to make it happen!

On Wed, Sep 28, 2016 at 9:41 AM, Chris Dent  wrote:

>
> Despite its name, the Technical Committee has become the part of the
> OpenStack contributor community that enshrines, defines, and -- in some
> rare cases -- enforces what it means to be "OpenStack". Meanwhile,
> the community has seen a great deal of growth and change.
>
> Some of these changes have led to progress and clarity, others have left
> people confused about how they can best make a contribution and what
> constraints their contributions must meet (for example, do we all know
> what it means to be an "official" project?).
>
> Much of the confusion, I think, can be traced to two things:
>
> * Information is not always clear nor clearly available, despite
>   valiant efforts to maintain a transparent environment for the
>   discussion of policy and process. There is more that can be done
>   to improve engagement and communication. Maybe the TC needs
>   release notes?
>
> * Agreements are made without the full meaning and implications of those
>   agreements being collectively shared. Most involved think they agree,
>   but there is limited shared understanding, so there is limited
>   effective collaboration. We see this, for example, in the ongoing
>   discussions on "What is OpenStack?". Agreement is claimed without
>   actually existing.
>
> We can fix this, but we need a TC that has a diversity of ideas and
> experiences. Other candidates will have dramatically different opinions
> from me. This is good because we must rigorously and vigorously question
> the status quo and our assumptions. Not to tear things down, but to
> ensure our ideas are based on present day truths and clear visions of
> the future. And we must do this, always, where it can be seen and
> joined and later discovered; gerrit and IRC are not enough.
>
> To have legitimate representation on the Technical Committee we must
> have voices that bring new ideas, are well informed about history, that
> protect the needs of existing users and developers, encourage new users
> and developers, that want to know how, that want to know why. No single
> person can speak with all these voices.
>
> Several people have encouraged me to run for the TC, wanting my
> willingness to ask questions, to challenge the status quo and to drive
> discourse. What I want is to use my voice to bring about frequent and
> positive reevaluation.
>
> We have a lot of challenges ahead. We want to remain a pleasant,
> progressive and relevant place to participate. That will require
> discovering ways to build bridges with other communities and within our
> own. We need to make greater use of technologies which were not invented
> here and be more willing to think about the future users, developers and
> use cases we don't yet have (as there will always be more of those). We
> need to keep looking and pushing forward.
>
> To that end I'm nominating myself to be a member of the Technical
> Committee.
>
> If you have specific questions about my goals, my background or anything
> else, please feel free to ask. I'm on IRC as cdent or send some email.
> Thank you for your consideration.
>
> --
> 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

[openstack-dev] [oslo] Adding ozamiatin to oslo-core

2016-10-03 Thread Joshua Harlow


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

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

2016-10-03 Thread Joshua Harlow


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

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

2016-10-03 Thread Hayes, Graham

On 03/10/2016 17:49, Edward Leafe wrote:
> So the period of self-nominations for the Technical Committee seats has 
> ended, and the voting has begun. I've been a very close observer of this 
> process for several cycles, and I have some ideas I'd like to share. Full 
> disclosure: I am a current candidate for the TC, and have been a candidate 
> several times in the past, all of which were unsuccessful.
>
> When deciding to run, candidates write a long, thoughtful essay on their 
> reasons for wanting to serve on the TC, and those essays are typically the 
> last you hear from them until the election. It has been rare for anyone to 
> ask follow-up questions, or to challenge the candidates to explain their 
> positions more definitively. I have spoken with many people at the Summits, 
> which always closely followed the TC election (warning: unscientific samples 
> ahead!), and what their selection process mostly boils down to is: they pick 
> the names they are most familiar with. Many people don't read those long 
> candidacy posts, and nearly all couldn't remember a single point that any of 
> the candidates had put forth.
>
> We are fortunate in that all of the candidates are exceptionally 
> well-qualified, and those elected have put in excellent service while on the 
> TC. But one thing I'm afraid of is that we tend to get into a situation where 
> groupthink [0] is very likely. There are many excellent candidates running in 
> every election, but it is rare for someone who hasn't been a PTL of a large 
> project, and thus very visible, has been selected. Is this really the best 
> approach?
>
> I wrote a blog post about implicit bias [1], and in that post used the 
> example of blind auditions for musical orchestras radically changing the 
> selection results. Before the introduction of blind auditions, men 
> overwhelmingly comprised orchestras, but once the people judging the 
> auditions had no clue as to whether the musician was male or female, women 
> began to be selected much more in proportion to their numbers in the audition 
> pools. So I'd like to propose something for the next election: have 
> candidates self-nominate as in the past, but instead of writing a big 
> candidacy letter, just state their interest in serving. After the nominations 
> close, the election officials will assign each candidate a non-identifying 
> label, such as a random number, and those officials will be the only ones who 
> know which candidate is associated with which number. The nomination period 
> can be much, much shorter, and then followed by a week of campaigning (the 
> part that's really missing in the current p
 ro
>  cess). Candidates will post their thoughts and positions, and respond to 
> questions from people, and this is how the voters will know who best 
> represents what they want to see in their TC.

On the topic of implicit bias - I am open to correction on this, but I
do not think we have had a TC member who was not heavily involved in
either Cross Project teams, or one of the projects that spun out of
Nova in the early years.

Now, is this bias, or a side effect of people on smaller projects not
necessarily having dedicated upstream time.

Is this something we are worried about (or should be worried about)?

> 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. Keeping anonymity will be difficult, and will preclude the use of 
> email for posting positions and responses, since email identifies the sender. 
> So perhaps candidates could forward their posts to the election officials, 
> who will post them for the candidates, identifying them by number only. The 
> voting form will only list the candidate numbers, so the end result will be 
> people casting votes for the candidates whose platform most matches what they 
> want to see in the TC, and who have best answered any questions raised by 
> others.
>
> My feeling is that the result would be very different than the current 
> process. My question, then, is whether that would be a good thing? It would 
> require more work from the candidates and especially the election officials, 
> so we should make sure that the goal is worth it. Do we want everyone to have 
> an equal chance to serve on the TC, or should those who have earned name 
> recognition by their excellent work in other parts of OpenStack continue to 
> have an advantage?
>
> [0] https://en.wikipedia.org/wiki/Groupthink
> [1] http://blog.leafe.com/bias/
>
> -- 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] TC Candidacy

On Thu, Sep 29, 2016 at 8:34 PM, John Griffith 
wrote:

>
>
> I think what's more important and critical is the future and where
> OpenStack is going over the course of the next few years.
>

I think this is a really important topic right now!  Do you see any
dangerous road blocks coming up!?


>
> Do we want our most popular topic at the key-notes to continue being
> customers telling their story of "how hard" it was to do OpenStack?
>

No ;)


>
> It's my belief that the TC has a great opportunity (with the right people)
> to take input from the "outside world" and drive a meaningful and
> innovative future for OpenStack.  Maybe try and dampen the echo-chamber a
> bit, see if we can identify some real problems that we can help real
> customers solve.
>

I think this is where we *all* should be focused - do you think the TC can
offer specific support to the projects here - or is more about just
removing other roadblocks and keeping the community on target?


> I'd like to see us embracing new technologies and ways of doing things.
> I'd love to have a process where we don't care so much about the check
> boxes of what oslo libs you do or don't use in a project, or how well you
> follow the hacking rules; but instead does your project actually work?  Can
> it actually be deployed by somebody outside of the OpenStack community or
> with minimal OpenStack experience?
>
> It's my belief that Projects should offer real value as stand-alone
> services just as well as they do working with other OpenStack services.
>

Very controversial (surprisingly?)!  Why do you think this is important?
Do you think this is in conflict with the goal of OpenStack as one
community?



>
> Feel free to ask me about my thoughts on anything specific, I'm happy to
> answer any questions that I can as honestly as I can.
>

Don't mind if I do ;)

-Clay
__
OpenStack Development Mailing List (not for 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] Live migration sub-team lead

2016-10-03 Thread Timofei Durakov

Paul,

thanks for leading live migration sub-team. A lot of work were done in that
area for last year!

Best,
Timofey



On Mon, Oct 3, 2016 at 7:22 PM, Murray, Paul (HP Cloud) 
wrote:

> Hi All,
>
> I have had the pleasure of chairing the live migration sub-team for the
> last year. Recently, as some of you will have noticed, my time has been
> stretched to the extent that I have started to neglect the task. Timofei
> Durakov has stood in for me on several occasions recently and has now
> agreed to take over full time. I had planned to bring this up in the
> meeting tomorrow, but yet again I am unable to attend.
>
> So thanks to all in the sub-team for being so self-organising and making
> the meetings so easy. Please turn to Timofei as your first point of contact
> for all things live migration from now on.
>
> Best regards,
> Paul
>
> P.S. I will be in the meetings when I can.
>
__
OpenStack Development Mailing List (not for 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

On Mon, Oct 3, 2016 at 9:46 AM, Edward Leafe  wrote:

> After the nominations close, the election officials will assign each
> candidate a non-identifying label, such as a random number, and those
> officials will be the only ones who know which candidate is associated with
> which number.

I'm really uneasy about this suggestion.  Especially when it comes to
re-election, for the purposes of accountability I think it's really
important that voters be able to identify the candidates.  For some people
there's a difference in what they say and what they end up doing when left
calling shots from the bubble for too long.

As far as the other stuff... idk if familiarity == bias.  I'm sure lots of
occasions people vote for people they know because they *trust* them; but I
don't think that's bias?  I think a more common problem is when people vote
for a *name* they recognize without really knowing that person or what
they're about.  Or perhaps just as bad - *not* voting because they realize
they have on context to consider these candidates beyond name familiarity
and an (optional) email.

I think a campaign period, and especially some effort [1] to have
candidates verbalize their viewpoints on topics that matter to the
constituency could go a long way towards giving people some more context
beyond "i think this name looks familiar; I don't really recognize this
name"

-Clay

1.
http://lists.openstack.org/pipermail/openstack-dev/2016-October/104953.html
<- "role of the TC and your priorities"; seems like a reasonable thing for
someone to be able to answer about folks they're putting in the top six
slots in the voting card!
__
OpenStack Development Mailing 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] email filter for starred changes in Gerrit?

2016-10-03 Thread Kevin Benton

Hi,

Is there a way to identify an email notification from Gerrit that
corresponds to a change you have starred? I'm trying to write an email
filter to give these emails a special tag but I'm not seeing an easy way to
do this.

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

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

So the period of self-nominations for the Technical Committee seats has ended, 
and the voting has begun. I've been a very close observer of this process for 
several cycles, and I have some ideas I'd like to share. Full disclosure: I am 
a current candidate for the TC, and have been a candidate several times in the 
past, all of which were unsuccessful.

When deciding to run, candidates write a long, thoughtful essay on their 
reasons for wanting to serve on the TC, and those essays are typically the last 
you hear from them until the election. It has been rare for anyone to ask 
follow-up questions, or to challenge the candidates to explain their positions 
more definitively. I have spoken with many people at the Summits, which always 
closely followed the TC election (warning: unscientific samples ahead!), and 
what their selection process mostly boils down to is: they pick the names they 
are most familiar with. Many people don't read those long candidacy posts, and 
nearly all couldn't remember a single point that any of the candidates had put 
forth.

We are fortunate in that all of the candidates are exceptionally 
well-qualified, and those elected have put in excellent service while on the 
TC. But one thing I'm afraid of is that we tend to get into a situation where 
groupthink [0] is very likely. There are many excellent candidates running in 
every election, but it is rare for someone who hasn't been a PTL of a large 
project, and thus very visible, has been selected. Is this really the best 
approach?

I wrote a blog post about implicit bias [1], and in that post used the example 
of blind auditions for musical orchestras radically changing the selection 
results. Before the introduction of blind auditions, men overwhelmingly 
comprised orchestras, but once the people judging the auditions had no clue as 
to whether the musician was male or female, women began to be selected much 
more in proportion to their numbers in the audition pools. So I'd like to 
propose something for the next election: have candidates self-nominate as in 
the past, but instead of writing a big candidacy letter, just state their 
interest in serving. After the nominations close, the election officials will 
assign each candidate a non-identifying label, such as a random number, and 
those officials will be the only ones who know which candidate is associated 
with which number. The nomination period can be much, much shorter, and then 
followed by a week of campaigning (the part that's really missing in the 
current pro
 cess). Candidates will post their thoughts and positions, and respond to 
questions from people, and this is how the voters will know who best represents 
what they want to see in their TC.

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. Keeping 
anonymity will be difficult, and will preclude the use of email for posting 
positions and responses, since email identifies the sender. So perhaps 
candidates could forward their posts to the election officials, who will post 
them for the candidates, identifying them by number only. The voting form will 
only list the candidate numbers, so the end result will be people casting votes 
for the candidates whose platform most matches what they want to see in the TC, 
and who have best answered any questions raised by others.

My feeling is that the result would be very different than the current process. 
My question, then, is whether that would be a good thing? It would require more 
work from the candidates and especially the election officials, so we should 
make sure that the goal is worth it. Do we want everyone to have an equal 
chance to serve on the TC, or should those who have earned name recognition by 
their excellent work in other parts of OpenStack continue to have an advantage? 

[0] https://en.wikipedia.org/wiki/Groupthink
[1] http://blog.leafe.com/bias/

-- 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] [tc] open question to the candidates

2016-10-03 Thread Amrith Kumar



> -Original Message-
> From: gordon chung [mailto:g...@live.ca]
> Sent: Monday, October 03, 2016 11:31 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [tc] open question to the candidates
> 
> hi,
> 
> as there are many candidates this TC election, i figured i'd ask a
> question to better understand the candidates from the usual sales pitch
> in self-nominations. hopefully, this will give some insights into the
> candidates for those who haven't voted yet. obviously, the following is
> completely optional. :)
> 
> i initially asked this to John Dickinson[1] in his self-nomination. i'd
> like to open this up to everyone. the (re-worded) question is:
> 
> the TC has historically been a reactive council that lets others ask for
> change and acts as the final approver. do you believe the TC should be a
> proactive committee that initiates change and if yes, to what scope?
> more generally, what are some specific issues you'd like the TC address
> in the coming year?

[amrith] Gordon, great question. Short answer is that I believe that the TC 
should be proactive. All the members in the TC are themselves active 
contributors to different parts of OpenStack and there is a reasonable 
expectation that they are remaining informed about the things that are going on 
in all projects, are aware of what deployers and users are trying to do with 
OpenStack and the problems they are facing.

I believe that this gives them the ideal position to not only react to issues 
that come up, but also in cases take proactive steps to improve things. But, in 
keeping with the openness of OpenStack, I believe that any 'proactive' action 
should be discussed in the open and decided only after this open participatory 
process.

In the future it may be a good idea to have an IRC meeting where all candidates 
attend and members of the community get to participate in a moderated 
discussion. This may mean that the timeline (closing deadline, polling) may 
need to be altered but I think an opportunity for all candidates to discuss 
these kinds of things would be valuable.

Thanks!

> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-
> September/104821.html
> 
> thanks,
> --
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] [neutron] bug deputy report

2016-10-03 Thread Vikram Choudhary

3. https://bugs.launchpad.net/neutron/+bug/1628044 - bgp listener not
> listening on mitaka. Someone should validate the bug in latest code.
>>> Ryu team got to check this issue... Neutron is not responsible for
creating BGP peer...

On Oct 3, 2016 8:26 PM, "Assaf Muller"  wrote:

> On Mon, Oct 3, 2016 at 10:15 AM, Ihar Hrachyshka 
> wrote:
> > Hi all,
> >
> > I was serving as a bug deputy for the last two weeks. (Well, I planned to
> > serve for one week only, but then I forgot to set new deputies in the
> last
> > meeting I chaired, so the 2nd week was my punishment for short memory.)
> >
> > There were several bugs that I did not know how to triage properly, so
> help
> > with that is highly welcome.
> >
> > 1. https://bugs.launchpad.net/neutron/+bug/1625829 - instance shutdown
> > breaks floating ip connectivity, probably a duplicate of
> > https://bugs.launchpad.net/neutron/+bug/1549443. the immediate suspect
> is
> > iptables rules ordering.
> >
> > 2. https://bugs.launchpad.net/neutron/+bug/1627480 - Kevin suspects that
> > IPAM ip allocation code may succeed without allocating an IP address for
> a
> > subnet requested. That one gave us some headache in late RC1-2 time.
> Would
> > be great to see IPAM folks chime in to nail it down.
> >
> > 3. https://bugs.launchpad.net/neutron/+bug/1628044 - bgp listener not
> > listening on mitaka. Someone should validate the bug in latest code.
> >
> > 4. https://bugs.launchpad.net/neutron/+bug/1628385 - router-port-list
> not
> > showing gateway port. I assume it’s as designed because of special
> status of
> > the gateway port, but I would like to confirm with L3 folks before
> setting
> > to Opinion.
> >
> > 5. https://bugs.launchpad.net/neutron/+bug/1629097 - that’s a scary one:
> > rootwrap processes are hanging after ovsdb-client dies, exhausting
> memory.
> > OVS restart exits those processes. A suspicious patch is detected.
>
> Added info here.
>
> >
> > 6. https://bugs.launchpad.net/neutron/+bug/1629539 - dvr not working
> with
> > lbaasv1? Not sure if it’s a valid case now considering the fact we
> dropped
> > lbaasv1, but lbaas folks should chime in.
> >
> > I hope we’ll get new deputies today that will start processing bugs
> starting
> > from the time of writing the email.
> >
> > Cheers.
> > Ihar
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] open question to the candidates

2016-10-03 Thread Sean McGinnis

On Mon, Oct 03, 2016 at 03:30:56PM +, gordon chung wrote:
> 
> 
> the TC has historically been a reactive council that lets others ask for 
> change and acts as the final approver. do you believe the TC should be a 
> proactive committee that initiates change and if yes, to what scope? 
> more generally, what are some specific issues you'd like the TC address 
> in the coming year?
> 

This is an interesting question.

Leadership in an open source project really is a unique and interesting
thing. In a lot of ways you have little control over what is proposed
and focused on other then to suggest things you think are important and
hope that others agree. On the other hand, you need to apply some
control over what is allowed in to make sure it is good and what is
right for the project.

I see the TC, like being a PTL, as needing to straddle this line of
being there to foster and encourage, while also needing to be the final
say and being the enforcer when things that are not seen as right for
OpenStack as a whole.

The "committee" part of the TC is key here I think. This is not a
dictatorship, and no one person should have absolute say over what is
and is not acceptable. We need a diverse group of people, with the best
interests of the project in mind, to be able to discuss issues and
disagreements.

To directly answer the question - both. The TC needs to be looking at
the landscape and getting the bigger picture to help influence where we
are going. But there is also no avoiding being somewhat reactive. There
will always be new things and ideas popping up that will require a
reactive stance. If someone wants to propose using the D language to
implement some new project, the reasons for that choice need to be
evaluated to tell why and determine if it makes sense as far as the
overall project goes.

One thing I would like to see in the coming year is moving beyond the
required reactive aspect and reaching out more to users and operators to
learn more about what they need. What issues are they running into? If
they stopped using OpenStack, why? I think it's important that we
recognize OpenStack-wide what's missing or what's a problem and start
working with the various project teams to get some of these gaps and
shortcomings addressed.

Sean (smcginnis)

> [1] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-September/104821.html
> 
> thanks,
> -- 
> gord
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] Live migration sub-team lead

2016-10-03 Thread Murray, Paul (HP Cloud)

Hi All,

I have had the pleasure of chairing the live migration sub-team for the last 
year. Recently, as some of you will have noticed, my time has been stretched to 
the extent that I have started to neglect the task. Timofei Durakov has stood 
in for me on several occasions recently and has now agreed to take over full 
time. I had planned to bring this up in the meeting tomorrow, but yet again I 
am unable to attend.

So thanks to all in the sub-team for being so self-organising and making the 
meetings so easy. Please turn to Timofei as your first point of contact for all 
things live migration from now on.

Best regards,
Paul

P.S. I will be in the meetings when I can.
__
OpenStack Development Mailing List (not for 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] open question to the candidates

On Oct 3, 2016, at 10:30 AM, gordon chung  wrote:

> the TC has historically been a reactive council that lets others ask for 
> change and acts as the final approver. do you believe the TC should be a 
> proactive committee that initiates change and if yes, to what scope? 
> more generally, what are some specific issues you'd like the TC address 
> in the coming year?

OK, I'm going to start with the standard cop-out answer: "It depends"

What I mean is that one of the duties of the TC is to be reactive: to act as a 
referee when there are issues brought to it. This can't and shouldn't change.

But I *would* like to see some more pro-active work, primarily in the area of 
technical matters. They are the "Technical" committee, after all. So while a 
heavy-handed, top-down approach is never going to work, there are areas where 
the TC must push all OpenStack projects forward. One area that they are already 
doing this is pushing projects to fully support Python 3. This is an essential 
technical matter, as Python 2 will be unsupported by 2020, and it is the TC's 
job to ensure that all of OpenStack is ready.

One other area where I would like to see the TC actively promote is in 
modernizing the architecture of the projects to keep up with the changes in the 
underlying technologies. Having been involved in the initial design decisions 
in 2010, I can state with certainty that had those same discussion been held in 
2016, we would have made very different choices. That's the nature of the world 
we operate in, and while change for the sake of change is a waste of time, 
change to keep OpenStack from becoming a outdated dinosaur is essential.

Tying those two points together brings me to a third: the expansion of 
languages used in OpenStack. We are and always have been a Python project. 
There were newer languages with some support by a few developers in the 
beginning, but as both Nova and Swift were Python, OpenStack was Python. And as 
things change, new languages will always come around that have some benefits 
that developers like. But experience tells me that every time you introduce a 
new language into the mix, you fracture the community. Yes, I know about 
Javascript in Horizon, but that's a particular case, as web browsers do not 
natively support Python. As long as we keep current with Python and its 
evolution, there is no good reason to fracture the development community within 
OpenStack. In the specific case of Swift and the use of Go, I wrote about my 
feelings here: http://blog.leafe.com/on_swift/ 

And thanks for posting this question. There is not nearly enough discussion 
when it comes to TC elections.

-- 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] [tc] open question to the candidates

2016-10-03 Thread Clint Byrum

Excerpts from gordon chung's message of 2016-10-03 15:30:56 +:
> hi,
> 
> as there are many candidates this TC election, i figured i'd ask a 
> question to better understand the candidates from the usual sales pitch 
> in self-nominations. hopefully, this will give some insights into the 
> candidates for those who haven't voted yet. obviously, the following is 
> completely optional. :)
> 
> i initially asked this to John Dickinson[1] in his self-nomination. i'd 
> like to open this up to everyone. the (re-worded) question is:
> 
> the TC has historically been a reactive council that lets others ask for 
> change and acts as the final approver. do you believe the TC should be a 
> proactive committee that initiates change and if yes, to what scope? 
> more generally, what are some specific issues you'd like the TC address 
> in the coming year?
> 

Great question Gordon. I sort of wish there was a little more time
between nomination and polls opening, since I'm sure many (myself
included) have just finished the extremely difficult task of ranking
these 21 fine individuals.

My answer is that purely reactive bodies aren't leaders, they're
roadblocks. You need only look at the current US legislative branch to
see an example of this.

But I would disagree that the group has been purely reactive. The
group has been extremely busy with things brought to them, but in their
responses to these issues, they have empowered and encouraged OpenStack
contributors(including themselves) to go out and start initiatives
outside the framework of TC voting to build consensus and communicate
directly with the rest of OpenStack.

The best example of this is The Big Tent. I don't think that was purely
reactive, and it wasn't just the TC that made it happen. Yes, it was
in response to an untenable TC process, but a purely reactive group
would simply band-aid the problem, or let it wend its way through the
beuracracy. Really at the first sign of trouble, the group's members
drafted proposals, debated the issues wit the community, and enacted a
system that, while certainly flawed, produces better results.

So, it may be a nuance, but I'd say the TC is _responsive_, not
_reactive_, and it will work best that way, because OpenStack is big,
and busy, and that doesn't seem to be changing any time soon.

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

On 2016-10-02 19:54:58 -0500 (-0500), Matt Riedemann wrote:
> There was a pycparser 2.14 package update on pypi today which is making
> cinder-manager db sync fail. This is making all dsvm/grenade jobs fail in
> master and stable/newton.
> 
> The upstream issue being tracked is:
> 
> https://github.com/eliben/pycparser/issues/147

I think we can bring this thread to a close now. Upstream deleted
the broken wheel from PyPI a little over an hour ago, and within
about 5 minutes it disappeared from our CI system mirrors as well
(PyPI deletions propagate automatically through our mirroring). At
this point things _should_ be back to normal, and projects can
probably start working on reverting or abandoning any temporary
workarounds.
-- 
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] [tc] open question to the candidates

2016-10-03 Thread Anita Kuno


On 16-10-03 11:30 AM, gordon chung wrote:

hi,

as there are many candidates this TC election, i figured i'd ask a
question to better understand the candidates from the usual sales pitch
in self-nominations. hopefully, this will give some insights into the
candidates for those who haven't voted yet. obviously, the following is
completely optional. :)

i initially asked this to John Dickinson[1] in his self-nomination. i'd
like to open this up to everyone. the (re-worded) question is:

the TC has historically been a reactive council that lets others ask for
change and acts as the final approver. do you believe the TC should be a
proactive committee that initiates change and if yes, to what scope?
more generally, what are some specific issues you'd like the TC address
in the coming year?

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104821.html

thanks,


Thanks Gord:

My view of the technical committee is that it is in place to solve 
actual problems not to chase after things which may or may not be a 
problem. One of the best ways to identify if some issue is a problem is 
for someone to identify it is a problem for them. Issues have been 
raised by members of the community approaching the technical committee, 
issues have also been raised by technical committee members themselves.


Whether something is considered reactive or proactive is often based on 
their personal perception as events unfold. Sometimes some members feel 
something should be addressed but need the correct alignment of events 
to occur for the community to agree.


I think one of the largest issues we will face in the coming year is 
what does it mean now that the projects will be meeting at the project 
team gathering in Atlanta in February and the Conference will take place 
in Boston later in the spring. These events affect a lot of people and 
many folks will be confused about what can and can't be accomplished in 
the separate spaces and also the symbology of what this means to them, 
their work and their business plans. I think the Foundation has be 
proactive in communicating this. I think the technical committee to date 
has been proactive in recognizing this is a need. I think the next 
technical committee with have to do both proactive communicating and 
reactive redirecting as folks move toward these events, at these events 
and following up these events. I think these events are much on people's 
minds and the technical committee needs to continue to communicate the 
workflow and expectation of these events in concert with the Foundation 
as it has done thus far.


Thank you,
Anita.

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

UPD: some people suggested I should update the thread about the success of  
the fixes. Long story short, affected projects (nova, trove) are fixed, so  
we consider it done.


Ihar Hrachyshka  wrote:


UPD: @dims pushed all four into gate. (Lord be merciful.)

Ihar

Ihar Hrachyshka  wrote:


Long story short, this topic should get us back to normal:

https://review.openstack.org/#/q/topic:bug/1629830

We could probably also ban the version in global-requirements.txt, but I  
am bad at foresight. I will let others to clean it up if needed.


Ihar

Graham  wrote:


Also impacts designate, our dashboard, and our tempest plugin. It will
probably hit our client library as well.

-- Graham


On 03/10/2016 12:49, Amrith Kumar wrote:

Also impacts Trove, see (for example)



http://logs.openstack.org/85/380985/1/check/gate-trove-functional-dsvm-mysql/48ae79c/logs/devstacklog.txt.gz#_2016-10-03_09_04_15_199



I have updated https://bugs.launchpad.net/trove/+bug/1629726 and marked
it as impacting Trove.



-amrith



*From:*Steven Dake (stdake) [mailto:std...@cisco.com]
*Sent:* Monday, October 03, 2016 1:57 AM
*To:* OpenStack Development Mailing List (not for usage questions)

*Subject:* Re: [openstack-dev] FYI - gate completely borked on master
and newton dsvm/grenade jobs



Also impacts Kolla (as in our gates are blocked).  At present we are
using the proposed workaround until the pycparser 2.14 wheel and package
are synced up.



Regards

-steve





*From: *Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>>
*Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" mailto:openstack-dev@lists.openstack.org>>
*Date: *Sunday, October 2, 2016 at 5:54 PM
*To: *"OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
*Subject: *[openstack-dev] FYI - gate completely borked on master
and newton dsvm/grenade jobs



There was a pycparser 2.14 package update on pypi today which is making

cinder-manager db sync fail. This is making all dsvm/grenade jobs fail

in master and stable/newton.



The upstream issue being tracked is:



https://github.com/eliben/pycparser/issues/147



--



Thanks,



Matt Riedemann





__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org
?subject:unsubscribe

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



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

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




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

[openstack-dev] [glance] image import sync - Tuesdays 14:00 UTC

2016-10-03 Thread Brian Rosmaita

The voting has closed.  By acclamation the weekly image import sync will
occur as follows:

when: Tuesdays, 14:00 UTC
where: #openstack-glance
duration: 20 minutes

I realize this time isn't great for everyone.  Since #openstack-glance is
logged, I'll use "#startmeeting image import sync" and "#endmeeting image
import sync" to make it easy for those who may not be able to attend to
locate the meeting conversation in the logs.

cheers,
brian


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

[openstack-dev] [tc] open question to the candidates

2016-10-03 Thread gordon chung

hi,

as there are many candidates this TC election, i figured i'd ask a 
question to better understand the candidates from the usual sales pitch 
in self-nominations. hopefully, this will give some insights into the 
candidates for those who haven't voted yet. obviously, the following is 
completely optional. :)

i initially asked this to John Dickinson[1] in his self-nomination. i'd 
like to open this up to everyone. the (re-worded) question is:

the TC has historically been a reactive council that lets others ask for 
change and acts as the final approver. do you believe the TC should be a 
proactive committee that initiates change and if yes, to what scope? 
more generally, what are some specific issues you'd like the TC address 
in the coming year?

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104821.html

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

[openstack-dev] [networking-cisco] Release Schedule

2016-10-03 Thread Bradley Jones

We're aiming to cut a newton & mitaka release for networking-cisco at the end of
this week on 6th October. So please ensure all patches that need to be merged
before then are up to date so we can review them quickly.

Thanks
Brad

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

Re: [openstack-dev] [Keystone] Project name DB length

2016-10-03 Thread Steve Martinelli

On Mon, Oct 3, 2016 at 10:52 AM, gordon chung  wrote:
>
>
> the original thread died pretty quickly; it didn't seem like an issue to
> anyone or needed fixing... if only there was a global council that
> worked on such technical things :P
>
>
ah great idea, perhaps we should call it a committee :)
__
OpenStack Development Mailing 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] [puppet] weekly meeting #92

2016-10-03 Thread Iury Gregory

Hi Puppeteers!

We'll have our weekly meeting tomorrow at 3pm UTC on #openstack-meeting-4

Here's a first agenda:
https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20161004

Feel free to add topics, and any outstanding bug and patch.

See you tomorrow!
Thanks,

-- 
~


*Att[]'sIury Gregory Melo Ferreira **Master student in Computer Science at
UFCG*
*E-mail:  iurygreg...@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] [Keystone] Project name DB length

2016-10-03 Thread gordon chung

On 28/09/2016 11:52 PM, Adrian Turjak wrote:
>
> Plus although there is no true official standard, most projects in
> OpenStack seem to use 255 as the default for a lot of string fields.
> Weirdly enough, a lot of projects seem to use 255 even for project.id,
> which seeing as it's 64 in keystone, and a uuid4 anyway, seems like a
> bit of a waste.

this was brought up a year ago[1] as a broader issue in OpenStack. 255 
bytes for id is weird especially as you mentioned if it's only a uuid. 
but yeah, Morgan's reply might reflect why you it is a length of 255.

the original thread died pretty quickly; it didn't seem like an issue to 
anyone or needed fixing... if only there was a global council that 
worked on such technical things :P

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068104.html

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] [neutron] bug deputy report

2016-10-03 Thread Assaf Muller

On Mon, Oct 3, 2016 at 10:15 AM, Ihar Hrachyshka  wrote:
> Hi all,
>
> I was serving as a bug deputy for the last two weeks. (Well, I planned to
> serve for one week only, but then I forgot to set new deputies in the last
> meeting I chaired, so the 2nd week was my punishment for short memory.)
>
> There were several bugs that I did not know how to triage properly, so help
> with that is highly welcome.
>
> 1. https://bugs.launchpad.net/neutron/+bug/1625829 - instance shutdown
> breaks floating ip connectivity, probably a duplicate of
> https://bugs.launchpad.net/neutron/+bug/1549443. the immediate suspect is
> iptables rules ordering.
>
> 2. https://bugs.launchpad.net/neutron/+bug/1627480 - Kevin suspects that
> IPAM ip allocation code may succeed without allocating an IP address for a
> subnet requested. That one gave us some headache in late RC1-2 time. Would
> be great to see IPAM folks chime in to nail it down.
>
> 3. https://bugs.launchpad.net/neutron/+bug/1628044 - bgp listener not
> listening on mitaka. Someone should validate the bug in latest code.
>
> 4. https://bugs.launchpad.net/neutron/+bug/1628385 - router-port-list not
> showing gateway port. I assume it’s as designed because of special status of
> the gateway port, but I would like to confirm with L3 folks before setting
> to Opinion.
>
> 5. https://bugs.launchpad.net/neutron/+bug/1629097 - that’s a scary one:
> rootwrap processes are hanging after ovsdb-client dies, exhausting memory.
> OVS restart exits those processes. A suspicious patch is detected.

Added info here.

>
> 6. https://bugs.launchpad.net/neutron/+bug/1629539 - dvr not working with
> lbaasv1? Not sure if it’s a valid case now considering the fact we dropped
> lbaasv1, but lbaas folks should chime in.
>
> I hope we’ll get new deputies today that will start processing bugs starting
> from the time of writing the email.
>
> Cheers.
> Ihar
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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] next notification subteam meeting

2016-10-03 Thread Balázs Gibizer

Hi, 

The next notification subteam meeting will be held on 2016.10.04 17:00 UTC [1] 
on #openstack-meeting-4.

Cheers,
Gibi

[1] https://www.timeanddate.com/worldclock/fixedtime.html?iso=20161004T17

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

[openstack-dev] [neutron] bug deputy report


Hi all,

I was serving as a bug deputy for the last two weeks. (Well, I planned to  
serve for one week only, but then I forgot to set new deputies in the last  
meeting I chaired, so the 2nd week was my punishment for short memory.)


There were several bugs that I did not know how to triage properly, so help  
with that is highly welcome.


1. https://bugs.launchpad.net/neutron/+bug/1625829 - instance shutdown  
breaks floating ip connectivity, probably a duplicate of  
https://bugs.launchpad.net/neutron/+bug/1549443. the immediate suspect is  
iptables rules ordering.


2. https://bugs.launchpad.net/neutron/+bug/1627480 - Kevin suspects that  
IPAM ip allocation code may succeed without allocating an IP address for a  
subnet requested. That one gave us some headache in late RC1-2 time. Would  
be great to see IPAM folks chime in to nail it down.


3. https://bugs.launchpad.net/neutron/+bug/1628044 - bgp listener not  
listening on mitaka. Someone should validate the bug in latest code.


4. https://bugs.launchpad.net/neutron/+bug/1628385 - router-port-list not  
showing gateway port. I assume it’s as designed because of special status  
of the gateway port, but I would like to confirm with L3 folks before  
setting to Opinion.


5. https://bugs.launchpad.net/neutron/+bug/1629097 - that’s a scary one:  
rootwrap processes are hanging after ovsdb-client dies, exhausting memory.  
OVS restart exits those processes. A suspicious patch is detected.


6. https://bugs.launchpad.net/neutron/+bug/1629539 - dvr not working with  
lbaasv1? Not sure if it’s a valid case now considering the fact we dropped  
lbaasv1, but lbaas folks should chime in.


I hope we’ll get new deputies today that will start processing bugs  
starting from the time of writing the email.


Cheers.
Ihar

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

Re: [openstack-dev] [Keystone] Project name DB length

2016-10-03 Thread Dolph Mathews

On Wed, Sep 28, 2016 at 10:55 PM Adrian Turjak 
wrote:

> I think with PKI tokens we had worse to worry about!
>
> At any rate, would be great to know, and if there isn't a strong reason
> against it we can make project name 255 for some more flexibility.
>

It's nice for UI's like horizon and openstackclient to have reasonable
expectations around max length.

AFAIK, 64 characters is arbitrary and intended to cover the 99% use case.
Other than trying to use DN's as user names and such, I believe this is the
first objection I've ever seen to 64 characters.


>
> Plus although there is no true official standard, most projects in
> OpenStack seem to use 255 as the default for a lot of string fields.
> Weirdly enough, a lot of projects seem to use 255 even for project.id,
> which seeing as it's 64 in keystone, and a uuid4 anyway, seems like a bit
> of a waste.
>
>
>
> On 29/09/16 16:19, Steve Martinelli wrote:
>
> We may have to ask Adam or Dolph, or pull out the history textbook for
> this one. I imagine that trying to not bloat the token was definitely a
> concern. IIRC User name was 64 also, but we had to increase to 255 because
> we're not in control of name that comes from external sources (like LDAP).
>
> On Wed, Sep 28, 2016 at 11:06 PM, Adrian Turjak 
> wrote:
>
> Hello Keystone Devs,
>
> Just curious as to the choice to have the project name be only 64
> characters:
>
> https://github.com/openstack/keystone/blob/master/keystone/resource/backends/sql.py#L241
>
> Seems short, and an odd choice when the user.name field is 255 characters:
>
> https://github.com/openstack/keystone/blob/master/keystone/identity/backends/sql_model.py#L216
>
> Is there a good reason for it only being 64 characters, or is this just
> something that was done a long time ago and no one thought about it?
>
> Not hugely important, just seemed odd and may prove limiting for
> something I'm playing with.
>
> Cheers,
> Adrian Turjak
>
>
> __
> OpenStack Development Mailing 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:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
-Dolph
__
OpenStack Development Mailing List (not for 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][i18n] do we need translation mark for strings in tests?

2016-10-03 Thread Dolph Mathews

On Sat, Oct 1, 2016 at 5:24 PM Ihar Hrachyshka  wrote:

> Akihiro Motoki  wrote:
>
> > Hi,
> >
> > I noticed strings in tests (unit tests or others) have translation marks
> > (_, _LE and so on).
> > Do we need translation marks for them?
> >
> > I don't think so for most cases from various reasons below.
> > Only exception is to test translations.
> >
> > From translators:
> > - Effort to translate strings in tests leads is meaningless. Such
> > translations are never used.
> > - Strings from test code drop the translation percentage.
> >   The current translation import script checks the translation percentage
> >   and imports translations with >75% percentage.
> >
> > From developers:
> > - Translation mark is actually unnecessary but developers are requested
> >   to mark them as translatable. It is annoying.
> >
> > Thought?
> >
> > Thanks,
> > Akihiro
>
> I believe we should not only not use marks in tests, but forbid them with a
> hacking check. It’s a waste of translator time.
>

+1 for forbidding i18n in test directories.


>
> 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
>
-- 
-Dolph
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ironic] ironic-inspector-core team update

2016-10-03 Thread milanisko k

Thanks guys! :)

Cheers,
milan

po 3. 10. 2016 v 10:49 odesílatel Dmitry Tantsur 
napsal:

> The change is in effect. Thanks for your hard work Milan!
>
> On 09/26/2016 02:55 PM, milanisko k wrote:
> > Thanks guys! :D
> >
> > --
> > milan
> >
> > po 26. 9. 2016 v 14:46 odesílatel Jim Rollenhagen <
> j...@jimrollenhagen.com
> > > napsal:
> >
> > // jim
> >
> >
> > On Mon, Sep 26, 2016 at 5:24 AM, Dmitry Tantsur  > > wrote:
> > > Hi folks!
> > >
> > > As you probably know, Imre has decided to leave us for other
> challenges, so
> > > our small core team has become even smaller. I'm removing him on
> his
> > > request.
> > >
> > > I suggest adding Milan Kovacik (milan or mkovacik on IRC) to the
> > > ironic-inspector-core team. He's been pretty active on
> ironic-inspector
> > > recently, doing meaningful reviews, and he's driving our HA work
> forward.
> > >
> > > Please vote with +1/-1. If no objections are recorded, the change
> will be in
> > > effect next Monday.
> > >
> > > Thanks!
> >
> > +1, Milan seems to be killing it. :)
> >
> > // jim
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] Roles count and flavors inside Heat environment file

2016-10-03 Thread Steven Hardy

On Mon, Oct 03, 2016 at 02:23:08PM +0200, Marius Cornea wrote:
> Hello everyone,
> 
> In Newton we've deprecated the *-scale and *-flavor deploy command
> arguments in favor of using Heat environment files. In the context of
> testing the composable roles where the custom roles' node count and
> flavor need to be passed inside an environment file I would like to
> build the test plan by using an environment containing all nodes count
> and flavors, including the preexisting roles.
> 
> A deploy command example would look like:
> 
> openstack overcloud deploy --stack cloudy --templates -e nodes.yaml
> 
> where the nodes environment file contains something like:
> 
> parameter_defaults:
>   ControllerCount: 3
>   ComputeCount: 2
>   CephStorageCount: 3
>   ServiceApiCount: 3
> 
>   OvercloudControlFlavor: controller
>   OvercloudComputeFlavor: compute
>   OvercloudCephStorageFlavor: ceph
>   OvercloudServiceApiFlavor: serviceapi
> 
> 
> I would like to get some feedback about this approach. I think it's
> better to keep all the roles count/flavors in the same place for
> consistency reasons.

+1 - I think this is well aligned with the interfaces we want to encourage
(vs the hard-coded CLI options which we want to move away from).

The only disadvantage of this approach is there's a few special-cases where
the parameter name isn't intuitive (OvercloudControlFlavor is an example).

It'd be better if we move to a consistent e.g $roleFlavor interface in due
course), but I still think encouraging this pattern is good, as it'll help
us identify the parameter interfaces which are inconsistent, then we can
fix them (deprecate the old parameter, add new consistent ones).

Thanks,

Steve

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs


UPD: @dims pushed all four into gate. (Lord be merciful.)

Ihar

Ihar Hrachyshka  wrote:


Long story short, this topic should get us back to normal:

https://review.openstack.org/#/q/topic:bug/1629830

We could probably also ban the version in global-requirements.txt, but I  
am bad at foresight. I will let others to clean it up if needed.


Ihar

Graham  wrote:


Also impacts designate, our dashboard, and our tempest plugin. It will
probably hit our client library as well.

-- Graham


On 03/10/2016 12:49, Amrith Kumar wrote:

Also impacts Trove, see (for example)



http://logs.openstack.org/85/380985/1/check/gate-trove-functional-dsvm-mysql/48ae79c/logs/devstacklog.txt.gz#_2016-10-03_09_04_15_199



I have updated https://bugs.launchpad.net/trove/+bug/1629726 and marked
it as impacting Trove.



-amrith



*From:*Steven Dake (stdake) [mailto:std...@cisco.com]
*Sent:* Monday, October 03, 2016 1:57 AM
*To:* OpenStack Development Mailing List (not for usage questions)

*Subject:* Re: [openstack-dev] FYI - gate completely borked on master
and newton dsvm/grenade jobs



Also impacts Kolla (as in our gates are blocked).  At present we are
using the proposed workaround until the pycparser 2.14 wheel and package
are synced up.



Regards

-steve





*From: *Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>>
*Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" mailto:openstack-dev@lists.openstack.org>>
*Date: *Sunday, October 2, 2016 at 5:54 PM
*To: *"OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
*Subject: *[openstack-dev] FYI - gate completely borked on master
and newton dsvm/grenade jobs



There was a pycparser 2.14 package update on pypi today which is making

cinder-manager db sync fail. This is making all dsvm/grenade jobs fail

in master and stable/newton.



The upstream issue being tracked is:



https://github.com/eliben/pycparser/issues/147



--



Thanks,



Matt Riedemann





__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org
?subject:unsubscribe

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



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




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

Re: [openstack-dev] [tripleo] Roles count and flavors inside Heat environment file

2016-10-03 Thread Michele Baldessari

On Mon, Oct 03, 2016 at 02:23:08PM +0200, Marius Cornea wrote:
> Hello everyone,
> 
> In Newton we've deprecated the *-scale and *-flavor deploy command
> arguments in favor of using Heat environment files. In the context of
> testing the composable roles where the custom roles' node count and
> flavor need to be passed inside an environment file I would like to
> build the test plan by using an environment containing all nodes count
> and flavors, including the preexisting roles.
> 
> A deploy command example would look like:
> 
> openstack overcloud deploy --stack cloudy --templates -e nodes.yaml
> 
> where the nodes environment file contains something like:
> 
> parameter_defaults:
>   ControllerCount: 3
>   ComputeCount: 2
>   CephStorageCount: 3
>   ServiceApiCount: 3
> 
>   OvercloudControlFlavor: controller
>   OvercloudComputeFlavor: compute
>   OvercloudCephStorageFlavor: ceph
>   OvercloudServiceApiFlavor: serviceapi
> 
> 
> I would like to get some feedback about this approach. I think it's
> better to keep all the roles count/flavors in the same place for
> consistency reasons.

I fully agree with this approach. I think it is also preferrable to have
a single point where we define this.

cheers,
Michele
-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Hayes, Graham

Added a test commit for Designate -

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

On 03/10/2016 13:31, Amrith Kumar wrote:
> FWIW, this does not appear to work for Trove. To confirm I've pushed up a 
> trial balloon (https://review.openstack.org/#/c/381075/2).
>
> At least on a local sandbox it does not work ...
>
> -amrith
>
>> -Original Message-
>> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
>> Sent: Monday, October 03, 2016 8:17 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> 
>> Subject: Re: [openstack-dev] FYI - gate completely borked on master and
>> newton dsvm/grenade jobs
>>
>> Ihar Hrachyshka  wrote:
>>
>>> Long story short, this topic should get us back to normal:
>>>
>>> https://review.openstack.org/#/q/topic:bug/1629830
>>>
>>> We could probably also ban the version in global-requirements.txt, but I
>>> am bad at foresight. I will let others to clean it up if needed.
>>
>> Oh well, I am now contradicting myself-an-hour-ago who said that the
>> library is not in global-requirements.txt at all, so no need for a
>> cleanup.
>>
>> Ihar
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Amrith Kumar

FWIW, this does not appear to work for Trove. To confirm I've pushed up a trial 
balloon (https://review.openstack.org/#/c/381075/2).

At least on a local sandbox it does not work ...

-amrith

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Monday, October 03, 2016 8:17 AM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] FYI - gate completely borked on master and
> newton dsvm/grenade jobs
> 
> Ihar Hrachyshka  wrote:
> 
> > Long story short, this topic should get us back to normal:
> >
> > https://review.openstack.org/#/q/topic:bug/1629830
> >
> > We could probably also ban the version in global-requirements.txt, but I
> > am bad at foresight. I will let others to clean it up if needed.
> 
> Oh well, I am now contradicting myself-an-hour-ago who said that the
> library is not in global-requirements.txt at all, so no need for a
> cleanup.
> 
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[openstack-dev] [tripleo] Roles count and flavors inside Heat environment file

2016-10-03 Thread Marius Cornea

Hello everyone,

In Newton we've deprecated the *-scale and *-flavor deploy command
arguments in favor of using Heat environment files. In the context of
testing the composable roles where the custom roles' node count and
flavor need to be passed inside an environment file I would like to
build the test plan by using an environment containing all nodes count
and flavors, including the preexisting roles.

A deploy command example would look like:

openstack overcloud deploy --stack cloudy --templates -e nodes.yaml

where the nodes environment file contains something like:

parameter_defaults:
  ControllerCount: 3
  ComputeCount: 2
  CephStorageCount: 3
  ServiceApiCount: 3

  OvercloudControlFlavor: controller
  OvercloudComputeFlavor: compute
  OvercloudCephStorageFlavor: ceph
  OvercloudServiceApiFlavor: serviceapi


I would like to get some feedback about this approach. I think it's
better to keep all the roles count/flavors in the same place for
consistency reasons.

Thank you,
Marius

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs


Ihar Hrachyshka  wrote:


Long story short, this topic should get us back to normal:

https://review.openstack.org/#/q/topic:bug/1629830

We could probably also ban the version in global-requirements.txt, but I  
am bad at foresight. I will let others to clean it up if needed.


Oh well, I am now contradicting myself-an-hour-ago who said that the  
library is not in global-requirements.txt at all, so no need for a cleanup.


Ihar

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs


Long story short, this topic should get us back to normal:

https://review.openstack.org/#/q/topic:bug/1629830

We could probably also ban the version in global-requirements.txt, but I am  
bad at foresight. I will let others to clean it up if needed.


Ihar

Graham  wrote:


Also impacts designate, our dashboard, and our tempest plugin. It will
probably hit our client library as well.

-- Graham


On 03/10/2016 12:49, Amrith Kumar wrote:

Also impacts Trove, see (for example)



http://logs.openstack.org/85/380985/1/check/gate-trove-functional-dsvm-mysql/48ae79c/logs/devstacklog.txt.gz#_2016-10-03_09_04_15_199



I have updated https://bugs.launchpad.net/trove/+bug/1629726 and marked
it as impacting Trove.



-amrith



*From:*Steven Dake (stdake) [mailto:std...@cisco.com]
*Sent:* Monday, October 03, 2016 1:57 AM
*To:* OpenStack Development Mailing List (not for usage questions)

*Subject:* Re: [openstack-dev] FYI - gate completely borked on master
and newton dsvm/grenade jobs



Also impacts Kolla (as in our gates are blocked).  At present we are
using the proposed workaround until the pycparser 2.14 wheel and package
are synced up.



Regards

-steve





*From: *Matt Riedemann mailto:mrie...@linux.vnet.ibm.com>>
*Reply-To: *"OpenStack Development Mailing List (not for usage
questions)" mailto:openstack-dev@lists.openstack.org>>
*Date: *Sunday, October 2, 2016 at 5:54 PM
*To: *"OpenStack Development Mailing List (not for usage questions)"
mailto:openstack-dev@lists.openstack.org>>
*Subject: *[openstack-dev] FYI - gate completely borked on master
and newton dsvm/grenade jobs



There was a pycparser 2.14 package update on pypi today which is making

cinder-manager db sync fail. This is making all dsvm/grenade jobs fail

in master and stable/newton.



The upstream issue being tracked is:



https://github.com/eliben/pycparser/issues/147



--



Thanks,



Matt Riedemann





__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: openstack-dev-requ...@lists.openstack.org
?subject:unsubscribe

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



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




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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Hayes, Graham

Also impacts designate, our dashboard, and our tempest plugin. It will
probably hit our client library as well.

-- Graham


On 03/10/2016 12:49, Amrith Kumar wrote:
> Also impacts Trove, see (for example)
>
>
>
> http://logs.openstack.org/85/380985/1/check/gate-trove-functional-dsvm-mysql/48ae79c/logs/devstacklog.txt.gz#_2016-10-03_09_04_15_199
>
>
>
> I have updated https://bugs.launchpad.net/trove/+bug/1629726 and marked
> it as impacting Trove.
>
>
>
> -amrith
>
>
>
> *From:*Steven Dake (stdake) [mailto:std...@cisco.com]
> *Sent:* Monday, October 03, 2016 1:57 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> 
> *Subject:* Re: [openstack-dev] FYI - gate completely borked on master
> and newton dsvm/grenade jobs
>
>
>
> Also impacts Kolla (as in our gates are blocked).  At present we are
> using the proposed workaround until the pycparser 2.14 wheel and package
> are synced up.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> *From: *Matt Riedemann  >
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)"  >
> *Date: *Sunday, October 2, 2016 at 5:54 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)"
>  >
> *Subject: *[openstack-dev] FYI - gate completely borked on master
> and newton dsvm/grenade jobs
>
>
>
> There was a pycparser 2.14 package update on pypi today which is making
>
> cinder-manager db sync fail. This is making all dsvm/grenade jobs fail
>
> in master and stable/newton.
>
>
>
> The upstream issue being tracked is:
>
>
>
> https://github.com/eliben/pycparser/issues/147
>
>
>
> --
>
>
>
> Thanks,
>
>
>
> Matt Riedemann
>
>
>
>
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
>
> Unsubscribe: openstack-dev-requ...@lists.openstack.org
> ?subject:unsubscribe
>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>


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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Amrith Kumar

Also impacts Trove, see (for example)

http://logs.openstack.org/85/380985/1/check/gate-trove-functional-dsvm-mysql/48ae79c/logs/devstacklog.txt.gz#_2016-10-03_09_04_15_199

I have updated https://bugs.launchpad.net/trove/+bug/1629726 and marked it as 
impacting Trove.

-amrith

From: Steven Dake (stdake) [mailto:std...@cisco.com]
Sent: Monday, October 03, 2016 1:57 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] FYI - gate completely borked on master and newton 
dsvm/grenade jobs

Also impacts Kolla (as in our gates are blocked).  At present we are using the 
proposed workaround until the pycparser 2.14 wheel and package are synced up.

Regards
-steve


From: Matt Riedemann 
mailto:mrie...@linux.vnet.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, October 2, 2016 at 5:54 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] FYI - gate completely borked on master and newton 
dsvm/grenade jobs

There was a pycparser 2.14 package update on pypi today which is making
cinder-manager db sync fail. This is making all dsvm/grenade jobs fail
in master and stable/newton.

The upstream issue being tracked is:

https://github.com/eliben/pycparser/issues/147

--

Thanks,

Matt Riedemann


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

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

Re: [openstack-dev] [magnum] Swarm Mode -- to come?

2016-10-03 Thread Fabrizio Soppelsa

Hi Ton, I filed a high-level blueprint and assigned to you as a manager, if you 
have questions just ask.

Implementing the new Swarm as a COE should be rather straightforward, much more 
than the old Swarm. Details in the BP.

Thanks,
Fabrizio


> On Oct 3, 2016, at 9:12 AM, Ton Ngo  wrote:
> 
> Hi Fabrizio,
> We had a discussion on Docker 1.12 but have not proceeded with any 
> development yet. 
> You are quite welcome to write a blueprint with details on how you envision 
> it should work. 
> This would help move the discussion along.
> Ton Ngo,
> 
> Fabrizio Soppelsa ---10/02/2016 11:26:08 AM---Hello, how about 
> the (newest) Swarm Mode (Docker 1.12+) support in Magnum?
> 
> From: Fabrizio Soppelsa 
> To: "OpenStack Development Mailing List (not for usage questions)" 
> 
> Date: 10/02/2016 11:26 AM
> Subject: [openstack-dev] [magnum] Swarm Mode -- to come?
> 
> 
> 
> 
> Hello,
> how about the (newest) Swarm Mode (Docker 1.12+) support in Magnum?
> I don’t find any blueprint on Launchpad on the matter yet, is this going to 
> be worked?
> 
> Ta,
> Fabrizio.
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Yours Faithfully,
Fabrizio Soppelsa
L2 Escalations Engineer - L2 EU team lead
Mirantis, Inc.

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Sylvain Bauza




Le 03/10/2016 12:27, Sylvain Bauza a écrit :



Le 03/10/2016 12:02, Sylvain Bauza a écrit :



Le 03/10/2016 02:54, Matt Riedemann a écrit :
There was a pycparser 2.14 package update on pypi today which is 
making cinder-manager db sync fail. This is making all dsvm/grenade 
jobs fail in master and stable/newton.


The upstream issue being tracked is:

https://github.com/eliben/pycparser/issues/147



Just to be clear, that's not only impacting our grenade scenarios, 
but also tramples our unittests and our Tempest tests.


http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%20\%22AssertionError:%20sorry,%20but%20this%20version%20only%20supports%20100%20named%20groups\%22&from=24h 



Do we have any open bug against that problem ?



OpenStack projects that are currently impacted by this issue can 
identify themselves in the following bug report :

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



Nevermind, found the original bug report 
https://bugs.launchpad.net/nova/+bug/1629726


Ihar is working on a resolution that probably requires to detangle 
Swift from our upper-constraints job. You can join the discussion in 
#openstack-requirements.


-Sylvain


-Sylvain

__ 


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

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



__ 


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

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



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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Sylvain Bauza




Le 03/10/2016 12:02, Sylvain Bauza a écrit :



Le 03/10/2016 02:54, Matt Riedemann a écrit :
There was a pycparser 2.14 package update on pypi today which is 
making cinder-manager db sync fail. This is making all dsvm/grenade 
jobs fail in master and stable/newton.


The upstream issue being tracked is:

https://github.com/eliben/pycparser/issues/147



Just to be clear, that's not only impacting our grenade scenarios, but 
also tramples our unittests and our Tempest tests.


http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%20\%22AssertionError:%20sorry,%20but%20this%20version%20only%20supports%20100%20named%20groups\%22&from=24h 



Do we have any open bug against that problem ?



OpenStack projects that are currently impacted by this issue can 
identify themselves in the following bug report :

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

Ihar is working on a resolution that probably requires to detangle Swift 
from our upper-constraints job. You can join the discussion in 
#openstack-requirements.


-Sylvain


-Sylvain

__ 


OpenStack Development Mailing 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] FYI - gate completely borked on master and newton dsvm/grenade jobs

2016-10-03 Thread Sylvain Bauza




Le 03/10/2016 02:54, Matt Riedemann a écrit :
There was a pycparser 2.14 package update on pypi today which is 
making cinder-manager db sync fail. This is making all dsvm/grenade 
jobs fail in master and stable/newton.


The upstream issue being tracked is:

https://github.com/eliben/pycparser/issues/147



Just to be clear, that's not only impacting our grenade scenarios, but 
also tramples our unittests and our Tempest tests.


http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%20\%22AssertionError:%20sorry,%20but%20this%20version%20only%20supports%20100%20named%20groups\%22&from=24h

Do we have any open bug against that problem ?

-Sylvain

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

Re: [openstack-dev] [mistral] Cancelling team meeting - 10/03/2016

2016-10-03 Thread Dougal Matthews

On 3 October 2016 at 08:32, Renat Akhmerov  wrote:

> Hi,
>
> We decided to cancel today’s team meeting because most people are either
> busy with release activities or on holidays.
>

Hi,

Thanks for sending this.

I just had a quick idea - maybe when we cancel the weekly meeting we should
move it to email. So rather than a cancellation email you could send you
status or anything you have to say and others could reply with their
contributions. It would be a good way to keep in touch when we don't have
the formal meeting.

Stay tuned, thanks.
>
> Renat Akhmerov
> @Nokia
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tripleo] all OVB jobs failing on stable/newton - neutron fails to sync db


Emilien Macchi  wrote:


A bit of investigation drove me to a new dependency required by
python-networking-cisco.
I proposed the new dependency in RDO:
https://review.rdoproject.org/r/#/c/2889/

"Since https://review.openstack.org/#/c/377937/ has been merged upstream,
we now require python-neutron-tests as a package dependency when
deploying python-networking-cisco or neutron db-sync will fail."

The patch has been merged in master and is being backported.

Until everything is built in RDO, I'm also trying this temporary
workaround in tripleo-ci:
https://review.openstack.org/380870

I'll +2 +A it tonight if I see that it pass all CI jobs, and give a
status update here before end of day.


While I agree with the tripleo workaround, I believe that the right long  
term course of actions would be networking-cisco folks untangling their  
plugin code from test only code. It does not make much sense that their  
plugin pulls lots of test only dependencies that python-neutron-tests RDO  
package has.


Ihar

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

Re: [openstack-dev] FYI - gate completely borked on master and newton dsvm/grenade jobs