Re: [openstack-dev] TC candidacy

[Ihar Hrachyshka]

Joshua Harlow  wrote:


Flavio Percoco wrote:

On 03/10/16 23:25 +0100, Chris Dent wrote:

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.


FWIW, I think it's better to start these discussions when the candidacy
period
is over. As a voter, I always ask questions (or read other voter's
questions
before casting my vote). This might not be true for everyone, though.

Asking questions during the candidacy period might affect other
candidates too
(in a good or bad way), I believe.

That said, I'd like to also thank Clay for asking all the questions this
time
around. :D

Flavio


I for one think we should do 'live' televised debates, perhaps on CNN??

Maybe then not televised but in a IRC channel? Or on google hangouts or  
zoom (or other similar technology).


The idea seems to work for US presidential candidates so seems like it  
could work for the community here to (only sort of kidding).


Right. I think it’s obvious to everyone that the system narrows the list to  
the best candidates ever. /s


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

[Joshua Harlow]

Flavio Percoco wrote:

On 03/10/16 23:25 +0100, Chris Dent wrote:

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.


FWIW, I think it's better to start these discussions when the candidacy
period
is over. As a voter, I always ask questions (or read other voter's
questions
before casting my vote). This might not be true for everyone, though.

Asking questions during the candidacy period might affect other
candidates too
(in a good or bad way), I believe.

That said, I'd like to also thank Clay for asking all the questions this
time
around. :D

Flavio



I for one think we should do 'live' televised debates, perhaps on CNN??

Maybe then not televised but in a IRC channel? Or on google hangouts or 
zoom (or other similar technology).


The idea seems to work for US presidential candidates so seems like it 
could work for the community here to (only sort of kidding).


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

[Flavio Percoco]

On 03/10/16 23:25 +0100, Chris Dent wrote:

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.


FWIW, I think it's better to start these discussions when the candidacy period
is over. As a voter, I always ask questions (or read other voter's questions
before casting my vote). This might not be true for everyone, though.

Asking questions during the candidacy period might affect other candidates too
(in a good or bad way), I believe.

That said, I'd like to also thank Clay for asking all the questions this time
around. :D

Flavio


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
 

Re: [openstack-dev] TC candidacy

[Steven Dake (stdake)]

Emilien,

Understood  and thanks for the clarification; looks like mail threading problem 
with lookout.  This outlook client is not very good for mailing lists.

Regards
-steve


From: Emilien Macchi <emil...@redhat.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, October 4, 2016 at 4:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] TC candidacy

On Tue, Oct 4, 2016 at 4:01 AM, Steven Dake (stdake) 
<std...@cisco.com<mailto:std...@cisco.com>> wrote:
Emilen,

You say "the previous *PTL* of an OpenStack installation automation project" as 
if there were only one previous PTL :)  There are many previous PTLs of 
OpenStack automation projects.  I feel the question was directed at me, so I'll 
answer.

( I didn't ask for it but Clay Gerrard did. I also gave my insights,
waiting for others previous PTL, like you, to give thoughts too. )


From: Emilien Macchi <emil...@redhat.com<mailto:emil...@redhat.com>>
Sent: Monday, October 3, 2016 8:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] TC candidacy

On Mon, Oct 3, 2016 at 5:01 PM, Emilien Macchi 
<emil...@redhat.com<mailto:emil...@redhat.com>> wrote:
On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard 
<clay.gerr...@gmail.com<mailto:clay.gerr...@gmail.com>> wrote:


On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi 
<emil...@redhat.com<mailto:emil...@redhat.com>> 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?


In my early history as a leader prior to OpenStack, I believed exceptions were 
the norm.  I then read Clayton Christensen's Harvard Business Review article 
"How will you measure your life?"[1] and it fundamentally changed my thinking 
on exceptions.  (Full disclosure, I graduated from Northern Arizona University 
in 1998, not Harvard in 2010).  I would encourage everyone first to read the 
article "How will you measure your life?" and vote afterwards.  Please do vote 
- without your vote, your voice isn't heard on how you want the OpenStack TC to 
function.  The short version of Christensen's theory is exceptions lead to more 
exceptions lead to more exceptions leads to an untenable situation with all 
sorts of negative outcomes.  I was actually suffering through this exact 
scenario in my early career and one of my greatest mentors pointed me at this 
article which put me on the right track.

Now I give awareness of it to you.

Kolla has been led exception free since day 0.  I have hope this continues into 
the future since I have elected not to run to serve as PTL of Kolla and instead 
focus on serving as a TC member if elected.

Unfortunately answering your questions is an exception in and to itself.  
However, I also believe in being direct and honest with individuals as you can 
see in my self-nomination to the TC and have a strong disdain for individuals 
that waste time by avoiding questions, so I'll answer.

What should be done about 

Re: [openstack-dev] TC candidacy

[Emilien Macchi]

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

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

Thanks,

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



-- 
Emilien Macchi

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

Re: [openstack-dev] TC candidacy

[Emilien Macchi]

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

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

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

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

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

Re: [openstack-dev] TC candidacy

[Matt Riedemann]

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


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

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



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


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


--

Thanks,

Matt Riedemann


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

Re: [openstack-dev] TC candidacy

[Emilien Macchi]

On Tue, Oct 4, 2016 at 4:01 AM, Steven Dake (stdake) <std...@cisco.com> wrote:
> Emilen,
>
> You say "the previous *PTL* of an OpenStack installation automation project" 
> as if there were only one previous PTL :)  There are many previous PTLs of 
> OpenStack automation projects.  I feel the question was directed at me, so 
> I'll answer.

( I didn't ask for it but Clay Gerrard did. I also gave my insights,
waiting for others previous PTL, like you, to give thoughts too. )

> 
> From: Emilien Macchi <emil...@redhat.com>
> Sent: Monday, October 3, 2016 8:03 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] TC candidacy
>
> On Mon, Oct 3, 2016 at 5:01 PM, Emilien Macchi <emil...@redhat.com> wrote:
>> On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <clay.gerr...@gmail.com> wrote:
>>>
>>>
>>> On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi <emil...@redhat.com> 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?
>>
>
> In my early history as a leader prior to OpenStack, I believed exceptions 
> were the norm.  I then read Clayton Christensen's Harvard Business Review 
> article "How will you measure your life?"[1] and it fundamentally changed my 
> thinking on exceptions.  (Full disclosure, I graduated from Northern Arizona 
> University in 1998, not Harvard in 2010).  I would encourage everyone first 
> to read the article "How will you measure your life?" and vote afterwards.  
> Please do vote - without your vote, your voice isn't heard on how you want 
> the OpenStack TC to function.  The short version of Christensen's theory is 
> exceptions lead to more exceptions lead to more exceptions leads to an 
> untenable situation with all sorts of negative outcomes.  I was actually 
> suffering through this exact scenario in my early career and one of my 
> greatest mentors pointed me at this article which put me on the right track.
>
> Now I give awareness of it to you.
>
> Kolla has been led exception free since day 0.  I have hope this continues 
> into the future since I have elected not to run to serve as PTL of Kolla and 
> instead focus on serving as a TC member if elected.
>
> Unfortunately answering your questions is an exception in and to itself.  
> However, I also believe in being direct and honest with individuals as you 
> can see in my self-nomination to the TC and have a strong disdain for 
> individuals that waste time by avoiding questions, so I'll an

Re: [openstack-dev] TC candidacy

[Steven Dake (stdake)]

Emilen,

You say "the previous *PTL* of an OpenStack installation automation project" as 
if there were only one previous PTL :)  There are many previous PTLs of 
OpenStack automation projects.  I feel the question was directed at me, so I'll 
answer.

From: Emilien Macchi <emil...@redhat.com>
Sent: Monday, October 3, 2016 8:03 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] TC candidacy

On Mon, Oct 3, 2016 at 5:01 PM, Emilien Macchi <emil...@redhat.com> wrote:
> On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard <clay.gerr...@gmail.com> wrote:
>>
>>
>> On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi <emil...@redhat.com> 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?
>

In my early history as a leader prior to OpenStack, I believed exceptions were 
the norm.  I then read Clayton Christensen's Harvard Business Review article 
"How will you measure your life?"[1] and it fundamentally changed my thinking 
on exceptions.  (Full disclosure, I graduated from Northern Arizona University 
in 1998, not Harvard in 2010).  I would encourage everyone first to read the 
article "How will you measure your life?" and vote afterwards.  Please do vote 
- without your vote, your voice isn't heard on how you want the OpenStack TC to 
function.  The short version of Christensen's theory is exceptions lead to more 
exceptions lead to more exceptions leads to an untenable situation with all 
sorts of negative outcomes.  I was actually suffering through this exact 
scenario in my early career and one of my greatest mentors pointed me at this 
article which put me on the right track.

Now I give awareness of it to you.

Kolla has been led exception free since day 0.  I have hope this continues into 
the future since I have elected not to run to serve as PTL of Kolla and instead 
focus on serving as a TC member if elected.

Unfortunately answering your questions is an exception in and to itself.  
However, I also believe in being direct and honest with individuals as you can 
see in my self-nomination to the TC and have a strong disdain for individuals 
that waste time by avoiding questions, so I'll answer.

What should be done about the reliance as devstack as gating mechanism for all 
OpenStack software?  I proposed an answer here [2] essentially asking core 
reviewers and PTLs of projects interested in being consumed by various 
individuals interested in using the software these projects produced to 
contribute to Kolla (or pick your operational deployment manager of choice) to 
fill out the big tent.  That thread had a wildly successful outcome for Kolla - 
15 new services implemented in Newton!  The obvious next step is now to gate on 
these services in various service def

Re: [openstack-dev] TC Candidacy

[John Griffith]

On Mon, Oct 3, 2016 at 11:33 AM, Clay Gerrard 
wrote:

>
>
> 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!?
>
​I don't know if I'd call them "road blocks", what I do worry about though
is becoming irrelevant (ok maybe that's harsh), but I do think stagnation
is a potential.  It's a great big world out there and there are other Open
Source efforts out there moving really fast and doing some pretty cool
stuff.  More importantly they're creating things that are ACTUALLY
CONSUMABLE by mere mortals!  Some are solving real problems in a novel way,
and they're doing it in a way that people can actually use them as a
foundation and build value on top of them.  That's what I always envisioned
happening with OpenStack.  The fact is though if you're not offering
something unique and providing the ability for people to easily solve
problems, then they'll move on to the next solution.

​To be clear, I'm not discrediting OpenStack, the community or any of the
folks that have led efforts in the past.  I am saying that time is
changing, we have to grow up at some point and that things either evolve or
die.​

>
>
>>
>> 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?
>
​The problem currently in my view is not whether the TC offers this support
or not, but rather I don't think it's currently intended or viewed as
fulfilling this obligation.  I think it should though, the trick is that
it's not something that just one or two newly elected members of the TC can
do.  This is something that really needs significant mind-share, and of
course has to find a way to balance the needs and wishes of the community
at the same time.

Really above all, I've had this feeling the past few years that the
OpenStack development community served itself, that being the vendors that
sponsor the developers, or even in some cases just groups of developers
inside the community itself.  If that's the way things go, then that's
fine, but I'd really like to see a true shift towards a focus on solving
new problems for actual users.​


>
>
>> 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?
>
​Which soap box should I get on top of here :)
​* New technologies

Same thing I mentioned before, evolve or die.  If there are better tools
that are easier, better, more advanced that can be used to solve a problem
then by all means they should be used.  Frankly I don't care so much if a
project uses oslo's version of XYZ vs implementing their own thing so long
as what they implement works and people can consume it.  I'm not saying
anything negative about oslo or any libraries that exist under that
project, just saying that maybe the lowest common denominator, one size
fits all lib isn't always the best or only answer.  If folks feel strongly
and have what for them is a better implementation, good for them.  At the
same time I'd hope we're all professionals and build a new wheel for
everything just because it's the cool thing to do.

* Real value as stand-alone services

This one is really interesting to me, and really until recently there's
only been on OpenStack project (I'm looking at you Swift) that's managed to
do that.  As a result I think that Swift is better for it.  More
importantly however, I think OpenStack is better for it as well.  I've
noticed other projects starting to try and shift that direction, Neutron,
Ironic and of course Cinder.  I don't 

Re: [openstack-dev] TC Candidacy

[Jeremy Stanley]

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

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

Re: [openstack-dev] TC candidacy

[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 

Re: [openstack-dev] TC candidacy

[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

Re: [openstack-dev] TC candidacy

[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

[Clay Gerrard]

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

Re: [openstack-dev] TC candidacy

[Clay Gerrard]

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=youtu.be=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] TC candidacy

[Clay Gerrard]

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

Re: [openstack-dev] TC Candidacy

[Clay Gerrard]

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

[openstack-dev] TC Candidacy - amrith

[Amrith Kumar]

I would like to announce my candidacy for election to the OpenStack
Technical Committee.

By way of introduction, I[1] have been working primarily on Trove 
since just before Icehouse. I was the PTL of the project for the
Newton cycle, and was recently elected to a second term as the 
PTL for the Ocata cycle. I am also active in the Stewardship
Working Group (SWG)[2].

I believe that a place on the TC is an opportunity to serve the
OpenStack community. An important aspect of leadership is something
called 'servant leadership', the notion that leaders are there to
serve the rest of their constituents. This is also a concept central
to the SWG which I am a part of. If elected to the TC, it would be my
privilege to serve all of you.

What does that mean?

The charter of the OpenStack Technical Committee[3] charges the TC
with providing 'technical leadership'.

There are however a number of questions that must be answered such as
"What is OpenStack", and I submit to you that these are not
necessarily just 'technical'. The TC has been spending a lot of time
trying to answer some of these.

Some of this makes total sense, but then there are are questions about
what 'maturity' is, and who an 'active reviewer' is. The TC has been
spending an inordinate of time trying to decide what metrics or
attributes of a contributor it can measure, and then proceeding to
define activity and maturity in terms of those things.

I submit to you that these latter things are a huge distraction.

In the process, I believe that there are significant 'technical'
issues that have paid the penalty, for example the notion of cross
project goals (series goals [4]), one that I strongly believe are
meaningful and within the scope of the TC.

If elected to the TC, I would like to use my position to urge the TC
to spend more time on the important things like "How do we make
OpenStack better for users", and "How can we make a cross-project goal
for python3 work", and less of its time on the distractions that have
been numerous of late.

In a nutshell, I'd like to put more of the "technical" back into the
"Technical Committee", and re-focus it on serving the OpenStack
community, the very essence of Stewardship.

Thank you for your reading, and I appreciate your support, and giving
me the opportunity to SERVE YOU on the Technical Committee.

-amrith

[1] http://www.openstack.org/community/members/profile/15733
[2] https://governance.openstack.org/resolutions/20160705-stewardship.html
[3] https://governance.openstack.org/reference/charter.html
[4] https://review.openstack.org/#/c/349068/

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

[Brad Topol]

I have known Mr. Taylor for many years and I would like to come out as his
first endorser for his big league thoughts and recommendations below.


Brad Topol, Ph.D.
IBM Distinguished Engineer
OpenStack
(919) 543-0646
Internet:  bto...@us.ibm.com
Assistant: Kendra Witherspoon (919) 254-0680



From:   Monty Taylor <mord...@inaugust.com>
To: openstack-dev@lists.openstack.org
Date:   09/29/2016 07:29 PM
Subject:    Re: [openstack-dev] TC candidacy



On 09/29/2016 06:14 PM, Clint Byrum wrote:
> https://review.openstack.org/379850
>
> Let's make OpenStack great again.
>
> If you don't know me, I'm very good. The code and designs I make
> are tremendous, and I intend to contribute to the TC bigly. The other
> candidates are sad, and they want OpenStack to be a third world project,
> no good.
>
> OpenStack, could be the greatest cloud in the history of clouds, but to
> get there, you need me, to make sure our clouds are the greatest. We
> need to test the clouds, I'm talking about EXTREME cloud vetting,
> EXTREME cloud vetting. You know the other TC's are laughing at us,
> because we don't have such a great TC.
>
> The biggest problem we have is people rewriting parts of OpenStack in Go.
> They're bringing threads, they're compiled, with errors handled at the
> point of return, and some of them, I assume, are good programmers. So
> when I'm elected to the TC, I will build a wall, and make Go pay for it.
>
> ...
>
> Ok if you're still reading and you don't take things too seriously,
> then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
> serve you on the OpenStack Technical Committee. You may recognize me
> from various scalability and deployment discussions.
>
> OpenStack has a number of challenges that face it in the immediate. There
> is a crisis of identity that we're only just now wrapping our arms
> around, and a question about whether or not this should be something
> decided at a centralized level by the TC or not. Are we a toobox? Are
> we a product? Can we be both?  These are real things, and the TC should
> debate them. However, I don't think the TC should force the community to
> do anything it doesn't want to do as a whole. If the community really
> wants to end the big tent, we should listen, inform, and debate, and
> decide whether or not we think it is in the best interest to do so based
> on our own expertise, the experience thus far, and a plan to go forward.
>
> It is my personal belief that the big tent has largely been a success
> for OpenStack project teams, but created a problem of confusion that we
> should resolve. The recent efforts to more clearly define OpenStack have
> been positive, and I would like to help the TC continue down that road.
>
> In fact, I have recently started an Architecture Working Group to help
> define and shape what OpenStack is at a technical design level. Whether
> pieces have been evolved apart from one another, or specifically designed
> and built to spec, OpenStack hasn't done a good job of writing some
> of those things down. I believe the Architecture Working Group will
> be capable of improving that, and I want the TC to have some of that
> influence built in.
>
> So, if you want to see more design, consensus building, and an eye for
> scaling on the TC, then please consider casting a vote for me.

I nominate this email to be the best email ever sent to an OpenStack
list. In fact, I think we should replace the entire TC with this email.
This email shall be our leader and I, for one, welcome it gladly.

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

[Monty Taylor]

I would like to serve the community on the Technical Committee again.

For those of you who don't know me:

* I've served on the TC since it was the PPB.

* I founded and am past-PTL of OpenStack Infra.

* I also serve on the OpenStack Board of Directors as an Individual
Member, which is a position I've held since the formation of the Foundation.

Our culture and our commonality define us and draw us together, and
that's a good thing. We are one of the world's most successful Open
Source projects. The reason we're so successful is that we've always
valued the we over the I. We've always made choices that maxmize our
ability to work with each other, even if those choices might dimish the
ability of some 'Brilliant Jerk' to amaze us with their brilliance and
just how big of a jerk they can be.

We should continue to hold strong to our idea of an environment where
we're all equal, where we can all work together regardless of background
and where collaboration is valued in its own right.

** OpenStack is One Project. **

Together we are much greater than the sum of our parts. It's vital that
we all understand that and actively look for ways to work together. It's
hard, of course. It's much easier to hunker down with a few close
friends and shut out all the noise as distraction. However, our primary
advantage is that there are a lot of us, and that we work together. The
world is replete with projects that are tightly controlled by a single
person or a single company. We're different, and it can give us
strength. But it will only be a strength when we all pull together and
actively look for ways in which we can align with each other, rather
than looking for legalistic lists of ways in which we are required to.

As our community is one of our greatest strengths, we need to become
better at being steadfast in our adherence to each other. When our
friends get tired and decide that all of this community crap is too
hard, we need to provide them support and help them to understand that
not only is the community part not a waste of time, it is, in fact, one
of the most important aspects of who we are.

** OpenStack delivers computers via an API, not VMs. **

Any positioning that our primary unit of operation is a VM is antiquated
and wrong. Bare metal, VMs and Containers are all essential building
blocks - and more importantly each of those being able to exist in a
shared networking context able to access the same storage resources is
the ballgame. Any time any part of our community wants to suggest that
one of the three have primacy over the others, we need to lovingly but
firmly put our foot down and stand up for our users.

We are not in competition with Kubernetes, Mesos or Docker. They're all
wonderful projects that solve problems for their users. All three of
them need to run on an Infrastructure. We should be the friendliest
Infrastructure for them.

** Success is defined by empowering our Users to solve their problems. **

OpenStack has IPv6 support. None of the closed-source Public Clouds do.
We should be more proud of that. OpenStack can give you a direct L2 IP
that isn't forced to pass through a NAT layer. None of the closed-source
Public Clouds can do that. Oracle just announced that as an "exciting"
thing that would set their new Public Cloud apart. It's not exciting,
it's basic functionality that the other clouds lack, and they're late to
the party. We've had it for years, and we should be proud of that. We
should not chase mediocrity by accepting the premise that the feature
definitions in a set of existing closed-source Public Clouds are the
gospel. We should instead empower our end-users by putting the tools of
computing that they actually want in their hands, not just the tools
someone else thinks they should want.

NAT is a hack, it's not a feature. We should treat it as the lame
second-class citizen it truly is, and we should make all the other
clouds who are not us ashamed that it's the only crappy networking they
give their users. We should continue to love our users.

** The world is a really big place with a bunch of really wonderful
people. **

We have OpenStack Public Clouds all over the world, in more geographical
locations than any of the closed-source Public Clouds. We should all be
proud of that. There is not a US-centric single giant OpenStack Public
Cloud ... but that's a good thing, not a failure. Single clouds are
single points of failure, both from a technology standpoint and from a
'random executive has an agenda' standpoint. An ecosystem of clouds
running the same software but run by different operators with different
needs and goals is an ecosystem we should all be proud of - and we can
be proud of that today.

We have grassroots OpenStack communities world-wide full of amazing
people. We have people all over the world who are solving problems with
OpenStack. We should all be proud of that.

** There are still plenty of challenges ahead of us. **

The end user experience with 

[openstack-dev] TC Candidacy

[John Griffith]

Hey Everyone,

Some of you may know me, I've been around the OpenStack community for a
while (longer than some, shorter than others).  I'm not an "uber hipster",
or a "super cool bro-grammer", or even a "mega hacker" trying to write the
most clever code possible to impress everyone.

I am however someone that has been contributing to OpenStack for about five
years now.  Not only via code contributions, but services, support and
evangelism.  I started the Cinder project with some great help from a few
other folks and did the best I could with that while forging ahead into
unknown territory.  I use OpenStack on a daily basis in a number of private
clouds, have helped several average sized companies deploy and maintain
OpenStack clouds and have spent countless hours helping people get their
heads wrapped around the whole OpenStack Platform thing and how it might be
able solve some of their problems.

I'm not going to try and claim that I have all the answers related to
OpenStack and the TC, in fact, I'm not even going to pretend to know what
all the questions are.  I'm not going to tell you what a great person I am,
or all of my "great achievements" over the years.  As we all know, people
can write up whatever wonderful things.  People can say or write up just
about anything and promise the world without really having any idea what
they're talking about.

What I will say however, is that I believe OpenStack has changed
dramatically over the last few years.  Some things for the better, some
things... not so much.  While I think the past is extremely important for
the experience it gives, I think what's more important and critical is the
future and where OpenStack is going over the course of the next few years.

OpenStack is a bit ambiguous for a lot of people that I talk to (both
inside and outside of the community).  Even more unclear is what do we want
to be in another two years, three or even five?  Do we want to just
continue being a platform that kinda looks like AWS or a "free" version of
VMware?  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?

I think we're at an important cross-roads with respect to the future of
OpenStack.  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'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.  I
should be able to use them equally as well outside the eco-system as in
side of it.  I believe the TC should consider driving issues like these and
help guide the future of OpenStack.

If you like my philosophy (really that's all it is), or agree with it; I'd
love the opportunity to try and make some of this a reality.  I can't
promise anything, except that I'll try to do what I believe is good for the
community (especially deployers and end-users).

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.

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

Re: [openstack-dev] TC Candidacy

[Qiming Teng]

I believe this is the voice we really need in the TC.
THANK YOU.

- Qiming

On Thu, Sep 29, 2016 at 11:47:12PM +, 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 lose sight of that, it's over.
> -- 
> 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 candidacy

[John Dickinson]

On 29 Sep 2016, at 16:00, gordon chung wrote:

>
> On 29/09/16 04:35 PM, John Dickinson wrote:
>>
>> I am concerned that there is a current focus on preserving the status
>> quo. There's focus on policies and rules instead of use cases; there's
>> focus on conformity instead of innovation; there's focus on forced
>> prioritization instead of inclusivity.
>
> i fully agree with this pov. there's a sentiment among certain members
> that if you choose a path different from the norm, you are not
> "following the OpenStack way".
>
> my question is (i guess this in theory could be ask to everyone), the
> the TC has historically been a reactive council that lets others ask for
> change and acts as the final approver (arguably, just my opinion). do
> you believe the TC should be a proactive committee that drives change?
> and if yes, to what scope? i realise the follow up is very open-end and
> vague and i apologise for this.

The TC is not small enough, and OpenStack is too big, for the TC to proactively 
drive and manage change across all OpenStack projects. In fact, I think 
OpenStack is too big for any one group to try to manage a task for all 
projects. I like how the docs team has been pushing docs into each project 
repository. That distributes the load and solves a scaling problem.

In my experience as a PTL for a single OpenStack project, I've learned that I 
can influence by suggestion, but I cannot mandate anything. In a large part, my 
role has been to respond to what the community is doing by removing any 
barriers that exist, monitoring the status of the team, connecting people 
working on similar tasks, and providing a general vision of where we're going 
as a project.

I see the role of the TC in much the same way. The TC should not be the 
high-priesthood of OpenStack where we go to present our supplications before 
we're allowed to do something. Individual projects should default to "doing" 
and the TC's role there is to make sure barriers for "doing" are removed. The 
individual projects are what initial and drive change in OpenStack, based on 
the needs of their specific users, and the TC aggregates those changes across 
projects to facilitate communication with the broader ecosystem about OpenStack 
in general.

I'm sure I could go on for quite a while about specifics I'd like to see. 
Here's a short list of bullets of things I'd love to see the TC take on:

 * Every project installable in 10 minutes or less.
 * Most projects independently installable to solve a specific use case for a 
deployer.
 * Track contributor activity to identify when and why people contribute. Is 
there some pattern that can be used to identify when someone might leave the 
community? Is there a pattern of how long-term contributors start? What are the 
major barriers for new contributors?
 * How do we reduce the average time a patch spends in review?
 * Why are people adopting OpenStack? If people move away from OpenStack (in 
whole or in part), what was missing in OpenStack?
 * What improvements can we make to facilitate team communication across time 
zones and across cultural lines?
 * How do we provide our corporate sponsors with a reasonably-accurate view of 
future development work?
 * How do we support new languages and deployment tools in OpenStack projects?
 * What improvements can we make to integrate proprietary software and hardware 
into our projects?
 * How does OpenStack work in a world where "cloud" is dominated by AWS, 
Google, and Microsoft?

etc.



--John



>
>>
>> If I am elected to the TC, I will look at every decision in the light
>> of these two needs. I will not focus on codifying rules, and I will
>> not focus on keeping OpenStack small and homogeneous. I will do what I
>> can to help the OpenStack community increase adoption today and remain
>> relevant as the industry changes.
>>
>
> yay to less codifying rules!
>
> 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


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

[openstack-dev] TC Candidacy

[Jeremy Stanley]

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 lose sight of that, it's over.
-- 
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

[openstack-dev] TC Candidacy

[Clark Boylan]

I am standing as a candidate for a seat on the OpenStack Technical
Committee.

I have worked with OpenStack since the Diablo days and have done it full
time since joining the OpenStack Infrastructure team during the Folsom
cycle. During this time I have been an OpenStack developer, operator,
and user.

During the Newton cycle the TC began to work on community wide goals. I
agree with Doug and others that this is a very important step for the TC
and OpenStack to take. We should be able to collaborate on and solve
large scale issues that affect our community.

That said, I recognize that at the end of the day someone has to be
making these changes. I have previously been involved in many community
wide changes including parallelized unittesting, ElasticSearch and
elastic-recheck, multinode testing, and most recently running our tests
with TLS enabled. I know how difficult changes like this can be. Getting
the critical mass of interest needed for reviews to happen and debugging
when things go wrong can be very difficult. If I am elected to the TC my
mission will be to ensure these goals get the visibility required to be
successful, and that we actually work together to achieve these goals as
a community.

As an individual one of the best things about OpenStack for me is that I
get to develop and use Free Software that solves real world problems for
both myself and others. I think the best way for us to continue to do
this is by working together to solve the hard technical problems we
face. Let's make it happen.

Thank you,
Clark

https://review.openstack.org/379853

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

[Monty Taylor]

On 09/29/2016 06:14 PM, Clint Byrum wrote:
> https://review.openstack.org/379850
> 
> Let's make OpenStack great again.
> 
> If you don't know me, I'm very good. The code and designs I make
> are tremendous, and I intend to contribute to the TC bigly. The other
> candidates are sad, and they want OpenStack to be a third world project,
> no good.
> 
> OpenStack, could be the greatest cloud in the history of clouds, but to
> get there, you need me, to make sure our clouds are the greatest. We
> need to test the clouds, I'm talking about EXTREME cloud vetting,
> EXTREME cloud vetting. You know the other TC's are laughing at us,
> because we don't have such a great TC.
> 
> The biggest problem we have is people rewriting parts of OpenStack in Go.
> They're bringing threads, they're compiled, with errors handled at the
> point of return, and some of them, I assume, are good programmers. So
> when I'm elected to the TC, I will build a wall, and make Go pay for it.
> 
> ...
> 
> Ok if you're still reading and you don't take things too seriously,
> then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
> serve you on the OpenStack Technical Committee. You may recognize me
> from various scalability and deployment discussions.
> 
> OpenStack has a number of challenges that face it in the immediate. There
> is a crisis of identity that we're only just now wrapping our arms
> around, and a question about whether or not this should be something
> decided at a centralized level by the TC or not. Are we a toobox? Are
> we a product? Can we be both?  These are real things, and the TC should
> debate them. However, I don't think the TC should force the community to
> do anything it doesn't want to do as a whole. If the community really
> wants to end the big tent, we should listen, inform, and debate, and
> decide whether or not we think it is in the best interest to do so based
> on our own expertise, the experience thus far, and a plan to go forward.
> 
> It is my personal belief that the big tent has largely been a success
> for OpenStack project teams, but created a problem of confusion that we
> should resolve. The recent efforts to more clearly define OpenStack have
> been positive, and I would like to help the TC continue down that road.
> 
> In fact, I have recently started an Architecture Working Group to help
> define and shape what OpenStack is at a technical design level. Whether
> pieces have been evolved apart from one another, or specifically designed
> and built to spec, OpenStack hasn't done a good job of writing some
> of those things down. I believe the Architecture Working Group will
> be capable of improving that, and I want the TC to have some of that
> influence built in.
> 
> So, if you want to see more design, consensus building, and an eye for
> scaling on the TC, then please consider casting a vote for me.

I nominate this email to be the best email ever sent to an OpenStack
list. In fact, I think we should replace the entire TC with this email.
This email shall be our leader and I, for one, welcome it gladly.

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

[Clint Byrum]

https://review.openstack.org/379850

Let's make OpenStack great again.

If you don't know me, I'm very good. The code and designs I make
are tremendous, and I intend to contribute to the TC bigly. The other
candidates are sad, and they want OpenStack to be a third world project,
no good.

OpenStack, could be the greatest cloud in the history of clouds, but to
get there, you need me, to make sure our clouds are the greatest. We
need to test the clouds, I'm talking about EXTREME cloud vetting,
EXTREME cloud vetting. You know the other TC's are laughing at us,
because we don't have such a great TC.

The biggest problem we have is people rewriting parts of OpenStack in Go.
They're bringing threads, they're compiled, with errors handled at the
point of return, and some of them, I assume, are good programmers. So
when I'm elected to the TC, I will build a wall, and make Go pay for it.

...

Ok if you're still reading and you don't take things too seriously,
then hello. I'm Clint Byrum, known as "SpamapS" on IRC, and I want to
serve you on the OpenStack Technical Committee. You may recognize me
from various scalability and deployment discussions.

OpenStack has a number of challenges that face it in the immediate. There
is a crisis of identity that we're only just now wrapping our arms
around, and a question about whether or not this should be something
decided at a centralized level by the TC or not. Are we a toobox? Are
we a product? Can we be both?  These are real things, and the TC should
debate them. However, I don't think the TC should force the community to
do anything it doesn't want to do as a whole. If the community really
wants to end the big tent, we should listen, inform, and debate, and
decide whether or not we think it is in the best interest to do so based
on our own expertise, the experience thus far, and a plan to go forward.

It is my personal belief that the big tent has largely been a success
for OpenStack project teams, but created a problem of confusion that we
should resolve. The recent efforts to more clearly define OpenStack have
been positive, and I would like to help the TC continue down that road.

In fact, I have recently started an Architecture Working Group to help
define and shape what OpenStack is at a technical design level. Whether
pieces have been evolved apart from one another, or specifically designed
and built to spec, OpenStack hasn't done a good job of writing some
of those things down. I believe the Architecture Working Group will
be capable of improving that, and I want the TC to have some of that
influence built in.

So, if you want to see more design, consensus building, and an eye for
scaling on the TC, then please consider casting a vote for me.

Thank you.

https://review.openstack.org/379850

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

[gordon chung]

On 29/09/16 04:35 PM, John Dickinson wrote:
>
> I am concerned that there is a current focus on preserving the status
> quo. There's focus on policies and rules instead of use cases; there's
> focus on conformity instead of innovation; there's focus on forced
> prioritization instead of inclusivity.

i fully agree with this pov. there's a sentiment among certain members 
that if you choose a path different from the norm, you are not 
"following the OpenStack way".

my question is (i guess this in theory could be ask to everyone), the 
the TC has historically been a reactive council that lets others ask for 
change and acts as the final approver (arguably, just my opinion). do 
you believe the TC should be a proactive committee that drives change? 
and if yes, to what scope? i realise the follow up is very open-end and 
vague and i apologise for this.

>
> If I am elected to the TC, I will look at every decision in the light
> of these two needs. I will not focus on codifying rules, and I will
> not focus on keeping OpenStack small and homogeneous. I will do what I
> can to help the OpenStack community increase adoption today and remain
> relevant as the industry changes.
>

yay to less codifying rules!


cheers,
-- 
gord

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

[openstack-dev] TC candidacy

[Joshua Harlow]

Howdy folks,

I'd like to submit myself as a candidate for the OpenStack TC,

The reasons why are varied (and longer than I can list here) but it
really comes to my desire to see OpenStack succeed and prosper and
exist (in whatever shape and form) going forward in a way that is
sustainable for the companies consuming *and* contributing to
OpenStack. I believe the TC as it exists helps (or can help) act as a
guiding force that ensures that sustainable future (along with
everyone involved in OpenStack).

In my honest opinion times ahead are going to be a little ‘scary'
for some as alternative tooling (such as containers and container
services) come into existence that offer similar (and yes sometimes
more uniform and better) functionality than what we have via the
diverse set of OpenStack components. I personally don't see that as
bad, but what I do see it being is a thing called 'evolution' and we
need to ensure we have a strong set of leaders that is helping ensure
our relevance (whatever it may be) going forward.

I feel we need to ask the 'hard' questions like:

- Where does the diverse set of OpenStack projects & components have
  value in this evolution?
- Is it better to align with some other community and create alliances
  (a *united* cloud nation for example) that work well for both/all?
  - Why have we been resistant to such things before? What can
we do better going forward...
- Are we learning from from operator difficulties, distributed system
  best practices (and other successful large scale distributed systems)
  so that we can architect and develop smart & sustainable solutions
  that *out of  the box* have zero to no operational difficulties?
- How do we get there (while still keeping our own ship afloat)?
- And more...

This may involve some changes in how our community operates and the
outreach to other communities that are becoming more popular and
widely used (and yes we may even need to slim down a little). I
personally feel it is the job of TC leadership to help guide our
community in this regard (and to make it a goal of *all* folks in our
community to do outreach, to produce great & innovative code and
products and projects that can be valuable beyond 'just being useful
in OpenStack').

Because one thing evolution has shown is that if we don't try to
evolve (and this evolution may be uncomfortable for some) that we
*may* (there's no fate but what we make) quickly become obsolete. So
instead we probably need to do some really deep thinking around
various questions like 'where does the community see itself in 3-5
years'?

TLDR; I'm hoping that being on the TC with others that I can help raise
  these kinds of questions and encourage the discussion (along with
  others) that starts to ask these hard and likely uncomfortable
  questions (and hopefully we can offer a clear(er) path for the
  general community as a result). Overall I hope we as a community
  try to rally behind a sustainable future where the majority
  understands our future evolution and the majority can get behind
  it and help *all* of us get there (it’s highly likely there will
  be a minority who will likely not be in agreement, that
  IMHO is ok and natural).

Thanks for my consideration,

FYI, harlowja on IRC, feel free to find and chat with me if you want :)

-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

[openstack-dev] TC candidacy

[John Dickinson]

I am throwing my hat into the ring for the TC election.

I've been a part of OpenStack since it started. I've seen it grow from
a few dozen people into the very large community we have today. During
the past 6 years, I've seen controversial topics come and go and the
community grow and adapt. I've also seen OpenStack respond in knee-
jerk fashion to new ideas that challenge the status quo.

I am concerned that there is a current focus on preserving the status
quo. There's focus on policies and rules instead of use cases; there's
focus on conformity instead of innovation; there's focus on forced
prioritization instead of inclusivity.

The primary things OpenStack should be focused on are increased
adoption today and continued relevance in the next five years.

We have a lovely community today, and we attract thousands to our
semi-annual conference. I love seeing companies, big and small, come
share their stories of how they're using OpenStack. It's great to hear
from them over time and see how their use of OpenStack changes and
grows. However, I'm concerned that we keep seeing mostly the same
people, the same companies, and the same sponsors show up to each
event. I'm concerned that, outside of our community bubble, OpenStack
is still largely unknown and little-used. In order to increase
adoption, the TC must look at the use cases we are serving. We must
realize where we are falling short in solving for current use cases,
and we must encourage growth in new use cases which we don't yet
support. To better-solve current use cases, I would like to see more
emphasis on SDK development (across many languages) and the creation
of governance tags identifying projects that are independently
deployable for specific use cases. To encourage solving more use cases
within OpenStack, I would like to see less requirements placed on new
projects and more clear communication about the various ways new
projects can join OpenStack.

In order to stay relevant in the technical world, the OpenStack TC
must figure out how the community itself can foster new ideas and grow
them within OpenStack. We should not ask new projects to split into
OpenStack and non-OpenStack pieces before joining. We should not ask
existing OpenStack contributors to go elsewhere to develop their
ideas. We must inclusively welcome new contributors, new projects, and
new ideas. Sometimes these new ideas require significant effort to
adopt, but I will encourage the TC to take on the challenge.

If I am elected to the TC, I will look at every decision in the light
of these two needs. I will not focus on codifying rules, and I will
not focus on keeping OpenStack small and homogeneous. I will do what I
can to help the OpenStack community increase adoption today and remain
relevant as the industry changes.

I appreciate your vote for me to the TC in this election.

--John

notmyname on IRC

elections patch: https://review.openstack.org/379814




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

[openstack-dev] TC candidacy

[Steve Martinelli]

I’d like to also toss my name into the ring. I’m announcing my candidacy
for a
position on the OpenStack Technical Committee.

-- About me
I have served as the Keystone PTL for the Mitaka and Newton cycles, and will
again serve as the PTL for the Ocata cycle. I’ve also contributed heavily to
python-openstackclient in it’s early days, where I am remain an active
core-reviewer. I am also a core member in a few Oslo projects (oslo.cache
and
oslo.policy) and OpenStackClient projects (os-client-config and cliff). I’ve
contributed reviews and patches to many repos over my time -- ranging from
devstack, infra, python-*client, openstack-manuals, you name it!

I’ve been contributing to OpenStack since early 2013, as part of a small
group
of IBMers dedicated to working entirely upstream. I can happily say that I
continue this same role today. Most of my work on OpenStack has been focused
on making Keystone and OpenStack more enterprise ready while trying to
improve
usability and manageability of OpenStack.

-- Bracing for the Big Crunch
The explosive growth that occurred as a result of the Big Tent was expected
and
phenomenal. I believe the decision brought great innovation, accelerated
adoption at a time when it was needed, and allowed competing projects to
co-exist. A natural reaction to such growth is unfortunately, a leveling
off or
contraction phase. We already saw hints of this in the last round of PTL
elections [1] . I believe this trend will continue. This is OK and
completely
natural, the strongest projects will continue to survive. We have seen this
pattern in many other technologies. The TC should be prepared for this
eventuality, and set minimum standards that projects should meet (not unlike
what is proposed by the OpenStack-wide goals).

-- Organizing the Big Tent
The big tent lumped all the projects together in an unorganized way, take a
quick look at the list [2]. I believe this has been a large source of
confusion
to the end consumer. There are projects that a consumer would never deploy
(docs, infra, etc), there are projects that a consumer will use one of
(openstack-ansible, puppet, chef, etc), these logical groupings go on. We
don't
provide enough guidance on which sets of projects are good groupings to
consider using together. It is critical for the OpenStack community to
reduce
the adoption pains experienced by our consumers. Everything can live in the
big tent, but let’s make the big tent a bit more organized.

-- Let’s get Opinionated
I also believe OpenStack needs to be a bit more opinionated. We have a bad
habit of trying to please everyone, and I’d like for that to stop. We’ll
end up
pleasing nobody at all. We don’t need more optional features, we need to pay
down technical debt. We need to focus on OpenStack-wide goals that create a
more consistent project that is focused and more consumable; improving the
quality of OpenStack as a whole. This is something I will be enforcing in
the
Ocata cycle for Keystone, and I encourage others to do the same.

-- Creating OpenStack-wide goals
OpenStack is mature, it’s now 6 years old. It’s (past?) time we tackle the
hard
issues at an OpenStack-wide level. I'd like to see the TC focus on goals
that
not only increase adoption of OpenStack but also make OpenStack easier to
manage and help to improve our ability to have new consumers of OpenStack
stick
with OpenStack. I believe the key to this success is to work closely with
our
operator friends. Having the Project Team Gathering (PTG) [3] will help get
the
right folks in the room to talk about the important issues.

Working on OpenStack has brought me a great deal of fun and joy. I look
forward
to working on OpenStack in any capacity and would be honored to be on the
TC.

Thanks for reading,
Steve

Stackalytics: http://stackalytics.com/?user_id=stevemar
Foundation Profile: https://www.openstack.org/community/members/profile/8430
Freenode: stevemar
Twitter: https://twitter.com/stevebot

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104170.html
[1] https://governance.openstack.org/reference/projects/index.html
[2] https://www.openstack.org/ptg/

I've also submitted the required patch to the election repo:
https://review.openstack.org/#/c/379799/
__
OpenStack Development Mailing 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

[Chris Dent]

On Thu, 29 Sep 2016, Flavio Percoco wrote:


I'm not saying it wouldn't be useful at all. What I'm saying is that
the format, and more importantly, the content will have to be studied.
I'll likely start working on this and I could use your help whether or
not you'll win the election
:)


Yeah, that sounds good. Please keep me involved.

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

[Flavio Percoco]

On 28/09/16 20:59 +0100, Chris Dent wrote:

On Wed, 28 Sep 2016, Jim Rollenhagen wrote:


+1 to release notes or something of that like. i was asked to give an
update on the TC internally and it seems the only information out there
is to read through backlog of meeting logs or track the items that do
get raised to ML. even then, it's hard to define what deliverables were
achieved in the cycle.



FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/


And the git tree, with a changelog, is here:
http://git.openstack.org/cgit/openstack/governance/


I assume, but I'd prefer if he confirm, that the point gordc was
trying to make was that there's more to what the TC gets up to than
merging changes to governance. That's certainly a major aspect and
one can track those changes by tracking both of those resources.

Part of the point I was trying to make in the message to which gordc was
responding is that whereas a git tree can allow someone to dig through
and acquire details, a thing that is more like release notes[1] is far
more human oriented and more likely to operate as a consumable digest of
what has happened. Notably a git log will not reflect important
conversations that did not result in a governance change nor activity
that could have led to a governance change but was rejected. Certainly
where a community says "no" is just as important as where it says "yes"?
Further, merged changes are changes that have already been decided. We
need more engagement, more broadly, while decisions are being
considered. That means being more verbose, sooner.

[1] Note that I don't actually think that release notes is the proper
form for some extra communication from the TC. Rather the justifications
that lead some projects to add release notes, in addition to the git
log, are something to consider for TC activity.


One thing that's been baking in the back of my head is to produce some sort of
summary of what the TC has done during the cycle. One reason I've not brought
this up is that I believe the information provided through the communication
subteam is probably more useful than a final write up and the end of the cycle.
In addition to this, the TC positions are 1 year long.

I'm not saying it wouldn't be useful at all. What I'm saying is that the format,
and more importantly, the content will have to be studied. I'll likely start
working on this and I could use your help whether or not you'll win the election
:)

Flavio

--
@flaper87
Flavio Percoco


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

Re: [openstack-dev] TC candidacy

[gordon chung]

On 28/09/2016 4:27 PM, Jeremy Stanley wrote:
> As was pointed out elsewhere in the thread, the TC has been trying
> to do something along these lines at
> http://www.openstack.org/blog/category/technical-committee-updates/
> but even with a dedicated communication subteam (see the May 13,
> 2015 entry) attempting to summarize important decisions, it's often
> a struggle to determine which items are important enough to include
> in a periodic high-level summary and which are administrivia better
> left buried in meeting minutes and review comments. All in all I
> think Anne and Flavio have done an awesome job with it.

agreed! thanks to all who did this. definitely useful for me rather than 
having to sift through meeting logs which often lack some context from 
discussions outside logs.

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

[gordon chung]

On 28/09/2016 3:59 PM, Chris Dent wrote:
> On Wed, 28 Sep 2016, Jim Rollenhagen wrote:
>
>> And the git tree, with a changelog, is here:
>> http://git.openstack.org/cgit/openstack/governance/
>
> I assume, but I'd prefer if he confirm, that the point gordc was
> trying to make was that there's more to what the TC gets up to than
> merging changes to governance. That's certainly a major aspect and
> one can track those changes by tracking both of those resources.
>
> Part of the point I was trying to make in the message to which gordc was
> responding is that whereas a git tree can allow someone to dig through
> and acquire details, a thing that is more like release notes[1] is far
> more human oriented and more likely to operate as a consumable digest of
> what has happened. Notably a git log will not reflect important
> conversations that did not result in a governance change nor activity
> that could have led to a governance change but was rejected. Certainly
> where a community says "no" is just as important as where it says "yes"?
> Further, merged changes are changes that have already been decided. We
> need more engagement, more broadly, while decisions are being
> considered. That means being more verbose, sooner.

Chris, i should let you speak for me. much more concise. :)

i wasn't really looking to track conflicts but that is definitely an 
interesting metric. more often than not, stuff happens without many eyes 
even seeing it.

personally, i was wondering if there was more beyond governance repo but 
it seems like that is workflow: propose patch, discuss at meeting, merge.

>
> [1] Note that I don't actually think that release notes is the proper
> form for some extra communication from the TC. Rather the justifications
> that lead some projects to add release notes, in addition to the git
> log, are something to consider for TC activity.
>

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

[Jeremy Stanley]

On 2016-09-28 20:59:09 +0100 (+0100), Chris Dent wrote:
> Part of the point I was trying to make in the message to which gordc was
> responding is that whereas a git tree can allow someone to dig through
> and acquire details, a thing that is more like release notes[1] is far
> more human oriented and more likely to operate as a consumable digest of
> what has happened. Notably a git log will not reflect important
> conversations that did not result in a governance change nor activity
> that could have led to a governance change but was rejected. Certainly
> where a community says "no" is just as important as where it says "yes"?
> Further, merged changes are changes that have already been decided. We
> need more engagement, more broadly, while decisions are being
> considered. That means being more verbose, sooner.
[...]

As was pointed out elsewhere in the thread, the TC has been trying
to do something along these lines at
http://www.openstack.org/blog/category/technical-committee-updates/
but even with a dedicated communication subteam (see the May 13,
2015 entry) attempting to summarize important decisions, it's often
a struggle to determine which items are important enough to include
in a periodic high-level summary and which are administrivia better
left buried in meeting minutes and review comments. All in all I
think Anne and Flavio have done an awesome job with it.

Also, as you say, this mostly just covers decisions made and
discussions concluded rather than bringing attention to upcoming
topics or those for which deliberation was arrested pending
subsequent input. It's probably not the answer you're looking for,
but https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee and
https://review.openstack.org/#/q/project:openstack/governance+is:open
are remarkably effective to that end.
-- 
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 candidacy

[Doug Wiegley]

> On Sep 28, 2016, at 1:59 PM, Chris Dent  wrote:
> 
> On Wed, 28 Sep 2016, Jim Rollenhagen wrote:
> 
 +1 to release notes or something of that like. i was asked to give an
 update on the TC internally and it seems the only information out there
 is to read through backlog of meeting logs or track the items that do
 get raised to ML. even then, it's hard to define what deliverables were
 achieved in the cycle.
 
>>> 
>>> FWIW, the resolutions that passed are listed here:
>>> https://governance.openstack.org/
>> 
>> And the git tree, with a changelog, is here:
>> http://git.openstack.org/cgit/openstack/governance/
> 
> I assume, but I'd prefer if he confirm, that the point gordc was
> trying to make was that there's more to what the TC gets up to than
> merging changes to governance. That's certainly a major aspect and
> one can track those changes by tracking both of those resources.
> 
> Part of the point I was trying to make in the message to which gordc was
> responding is that whereas a git tree can allow someone to dig through
> and acquire details, a thing that is more like release notes[1] is far
> more human oriented and more likely to operate as a consumable digest of

The minutes and logs exist.

http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.html 


http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-09-27-20.01.log.html 


http://eavesdrop.openstack.org/meetings/tc/2016/ 




> what has happened. Notably a git log will not reflect important
> conversations that did not result in a governance change nor activity
> that could have led to a governance change but was rejected. Certainly
> where a community says "no" is just as important as where it says "yes"?
> Further, merged changes are changes that have already been decided. We
> need more engagement, more broadly, while decisions are being
> considered. That means being more verbose, sooner.
> 
> [1] Note that I don't actually think that release notes is the proper
> form for some extra communication from the TC. Rather the justifications
> that lead some projects to add release notes, in addition to the git
> log, are something to consider for TC activity.
> 
> -- 
> Chris Dent   ┬─┬ノ( º _ ºノ)https://anticdent.org/
> freenode: cdent tw: 
> @anticdent__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] TC candidacy

[Chris Dent]

On Wed, 28 Sep 2016, Jim Rollenhagen wrote:


+1 to release notes or something of that like. i was asked to give an
update on the TC internally and it seems the only information out there
is to read through backlog of meeting logs or track the items that do
get raised to ML. even then, it's hard to define what deliverables were
achieved in the cycle.



FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/


And the git tree, with a changelog, is here:
http://git.openstack.org/cgit/openstack/governance/


I assume, but I'd prefer if he confirm, that the point gordc was
trying to make was that there's more to what the TC gets up to than
merging changes to governance. That's certainly a major aspect and
one can track those changes by tracking both of those resources.

Part of the point I was trying to make in the message to which gordc was
responding is that whereas a git tree can allow someone to dig through
and acquire details, a thing that is more like release notes[1] is far
more human oriented and more likely to operate as a consumable digest of
what has happened. Notably a git log will not reflect important
conversations that did not result in a governance change nor activity
that could have led to a governance change but was rejected. Certainly
where a community says "no" is just as important as where it says "yes"?
Further, merged changes are changes that have already been decided. We
need more engagement, more broadly, while decisions are being
considered. That means being more verbose, sooner.

[1] Note that I don't actually think that release notes is the proper
form for some extra communication from the TC. Rather the justifications
that lead some projects to add release notes, in addition to the git
log, are something to consider for TC activity.

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

[Jim Rollenhagen]

>> +1 to release notes or something of that like. i was asked to give an
>> update on the TC internally and it seems the only information out there
>> is to read through backlog of meeting logs or track the items that do
>> get raised to ML. even then, it's hard to define what deliverables were
>> achieved in the cycle.
>>
>
> FWIW, the resolutions that passed are listed here:
> https://governance.openstack.org/

And the git tree, with a changelog, is here:
http://git.openstack.org/cgit/openstack/governance/

// jim

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

Re: [openstack-dev] TC candidacy

[Steve Martinelli]

On Wed, Sep 28, 2016 at 2:49 PM, gordon chung  wrote:

>
>
> On 28/09/2016 12:41 PM, Chris Dent wrote:
> >
> > * 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?
>
> +1 to release notes or something of that like. i was asked to give an
> update on the TC internally and it seems the only information out there
> is to read through backlog of meeting logs or track the items that do
> get raised to ML. even then, it's hard to define what deliverables were
> achieved in the cycle.
>
>
FWIW, the resolutions that passed are listed here:
https://governance.openstack.org/



> i found this updates page[1] but it seemed a little sparse so i imagine
> other stuff happened. i think more of this would help explain what the
> TC does and where it hopes to go because to be frank, i'm not sure what
> is in the scope of TC and what is not and i've been following the list
> and meetings for a while.
>
> [1] http://www.openstack.org/blog/category/technical-committee-updates/
>
> cheers,
>
> --
> gord
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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

[gordon chung]

On 28/09/2016 12:41 PM, Chris Dent wrote:
>
> * 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?

+1 to release notes or something of that like. i was asked to give an 
update on the TC internally and it seems the only information out there 
is to read through backlog of meeting logs or track the items that do 
get raised to ML. even then, it's hard to define what deliverables were 
achieved in the cycle.

i found this updates page[1] but it seemed a little sparse so i imagine 
other stuff happened. i think more of this would help explain what the 
TC does and where it hopes to go because to be frank, i'm not sure what 
is in the scope of TC and what is not and i've been following the list 
and meetings for a while.

[1] http://www.openstack.org/blog/category/technical-committee-updates/

cheers,

-- 
gord

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

[openstack-dev] TC candidacy

[Chris Dent]

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

[Ed Leafe]

Hello! I am announcing my candidacy for a position on the OpenStack Technical
Committee.

For those who do not know me, I have been involved with OpenStack since the
very beginning, working for Rackspace as a core member of the Nova team. An
internal job change took me away from active development after Essex, but since
being hired by IBM, I've been back working on Nova since Kilo. As a result of
this long involvement, I have always had a strong interest in helping to shape
the direction of OpenStack, and if there is one thing people will agree about
me, is that I'm never shy about voicing my opinion, whether the majority agree
with me or not. Many of the earliest design decisions were very contentious,
and while I didn't always prevail in those discussions, I felt that I helped
move the conversation forward. More recently, I have participated in nearly all
TC meetings for the last two years, and now would like to join the TC as a
member.

There seems to be a lot of concern about the impact of the Big Tent, and how
all these new projects are diluting OpenStack, or somehow leading us astray
from what we should be doing. In my opinion, this is all a distraction.
Determining whether a project is "official" is simply a matter of controlling
the branding of OpenStack, and not changing what OpenStack is. If there is room
for improvement, it is in communicating what this means so that we eliminate
the confusion for those who are coming to OpenStack without this historical
knowledge.

One thing I feel strongly about is that since the Mission Statement for
OpenStack is "to produce the ubiquitous Open Source Cloud Computing
platform...", that what we do should always advance cloud *computing*. So while
I applaud the work being done by many of the telecommunication companies to
push the limits of network virtualization, unless it is useful to making
virtual machines communicate better, it really should be outside of OpenStack.
I do recognize that this is not a clear distinction, since someone can always
come up with a remote edge case where it could possibly be used, but we cannot
be all things to all people (or all companies). Having a clear focus is
important to success.

OpenStack is now over 6 years old, and that is forever in technology terms. And
while it has been continuously updated, these updates are restricted by the
requirement that they remain compatible with previous versions, and,
increasingly, that the updates are made with zero downtime. These are important
goals, and some very amazing work has been done to make them a reality. But one
of the consequences of this focus is that there is little serious discussion
about potential architectural changes that would greatly improve OpenStack, if
it requires downtime or breaking backwards compatibility. Suggestions for
experiments along these lines are usually met with the (very valid, in my
opinion) statement that we already have more development work than we can
handle, so diverting some of our resources to explore other possibilities would
set us further back. Unfortunately, this is the same argument that is used to
justify the build-up of technical debt. I would like to see us begin to think
about this, and have the TC direct this conversation, with input from
operators, the recently-formed Architecture Working Group, developers from the
various OpenStack projects, and any other interested parties. Yes, this is a
"moonshot" idea [0], but I believe that it is essential for the long-term
technical viability of OpenStack that we never stop looking ahead.

I have a great deal of respect for the other candidates who are seeking a
position on the TC, and thus understand that you, as a voter, have a difficult
job in selecting only six. I would indeed be honored if you would support me.

Thank you,
Ed

Email: e...@leafe.com
Foundation Profile: http://www.openstack.org/community/members/profile/280
Freenode: edleafe
Website: https://blog.leafe.com
Twitter: @edleafe

[0] https://en.wiktionary.org/wiki/moon_shot (definition 3)


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

[Jim Rollenhagen]

I'd like to throw in my hat to serve the community as a TC member.

My name is Jim Rollenhagen, but I'm better known in the community as jroll.
I've worked in many environments, from 20-person startup to massive
corporations. For the past three years, I've been working on OpenStack at
Rackspace. I primarily work on ironic (where I just started my third term as
PTL), but also dabble heavily in Nova, and try to contribute to cross-project
teams (mostly infra, QA, and Oslo) when I can.

I believe the primary objective of the TC should be to serve the community.
There's a few things we can immediately do to improve. First is the ongoing
effort to document principles and expectations. There's a massive amount of
shared understanding among the leaders in our community (and especially the
current TC) that isn't necessarily known or shared by the rest of the
community. We need to write down the current state of that. The principles
document does this well; but that's only the start. We need to continue to
document expectations for projects in the big tent, expectations for PTLs and
liaisons, and where we want OpenStack to be long term. We often focus on the
short term without thinking about how things support our longer-term goals, and
I'd like to fix that by writing down our vision for the future.

Over the last year, folks keep talking about the big tent, and how it has
watered down the meaning or focus of OpenStack. This is true today, at some
level. However, I believe this is short-term pain while we are moving to a
better place. I don't believe the solution is to go back to the old way of
life. Rather, we should roll forward and help to make the big tent better.
Going back will only create more confusion, and will bring the TC back to the
days of evaluating the usefulness and technical excellence of projects - which
we already have found is untenable. We have common ways of doing many things,
but those aren't well-documented and so newer projects simply do things the way
they think is best, or fastest, or the way it's done in the first project they
look to source ideas from. For example, I know of at least two or three ways
that microversioning is implemented.  There are two ways projects are
implementing rolling upgrades. And that might be okay; but they need to be
documented somewhere that all projects can benefit from. We should even go
further, and build frameworks for common things like these that OpenStack
projects tend to value. I believe the TC (working with folks like the
architecture WG, etc) could (and should!) be the body to help implement and
drive this sort of work. The new goals process is one step toward this, and I
think it's a great start. If we can truly make the big tent a more coherent set
of projects, I think it will be a huge win for everyone - not just developers
that need a home for their project.

The ironic project went through incubation just before the big tent went into
effect, and as such was one of the first projects to need to work with some of
the constraints (i.e., not be a first-class member of many of the cross-project
teams). We've implemented devstack and tempest plugins, in-tree API reference,
and in-tree install guide. To accomplish some of these, we needed to contribute
both code and documentation into these projects. I think my experience there
helps me relate to newer big tent projects that struggle with some of these
initiatives. I look forward to leading efforts to make this less of a burden on
projects.

I would be honored to serve the community from a TC seat, if elected. Whether
or not I am elected, I hope to work on some or all of these items over the next
two cycles, but I believe I will be in a better position to get these done from
within the TC.


// jim

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

[openstack-dev] TC candidacy

[Emilien Macchi]

This is my candidacy for a position on the OpenStack Technical
Committee.

https://review.openstack.org/378054

For those who don't know me, it has been 4 years that I have been
consistently working on OpenStack to make deployments production-ready:

- Puppet OpenStack core contributor, and ex-PTL (18 months).

Writing Puppet modules that allow operators to deploy OpenStack in production.

- TripleO core contributor, and current PTL.

Contribute to TripleO which is an OpenStack installer used by operators to
deploy and operate OpenStack.

- OpenStack Infrastructure contributor.

Improving Continuous Integration for different projects in OpenStack.


Here are some aspects that motivate me to be part of TC:

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


- Keep horizontal collaboration.

While our technical areas of focus might be different, our main goal is to
make OpenStack better and it's important our governance reflects it.
I believe that collaboration works [1] and we have seen positive results over
the last cycles.  I would like TC to keep supporting such efforts and
continue to
make OpenStack a great forum to work.


- Share my experience with Technical Committee.

Being PTL during 18 months, I contributed to drive Puppet OpenStack project to
success [2] and I learned so much about communication and technical leadership.
If I'm elected I'll do my best to re-use this experience from my
previous roles in
OpenStack.  I've been learning on the go and plan to continue that way by
keeping my mind open to feedback.


- Represent all family members.

Because I've worked on different areas of OpenStack (CI, deployments, testing,
etc), I'll represent the voice of any community member: developers, deployers,
operators and users.  I believe in making decisions by wearing
different hats and
find the best solution for everyone.



Over the last years, I've helped into building communities of people who
aim to make OpenStack better.  I would be honored to serve as a TC member.

Thank you for your consideration,


[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066544.html
[2] 
http://lists.openstack.org/pipermail/openstack-dev/2016-September/103372.html
-- 
Emilien Macchi

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

[openstack-dev] TC Candidacy

[Sean Dague]

I'd like to throw my hat into the ring for the TC. I've been involved
in OpenStack since 2012. We may have interacted when working on Nova,
Devstack, Grenade, debugging the gate, or other areas of the broader
OpenStack project.

Upgrades are one of the things I'm passionate about in
OpenStack. The kinds of places OpenStack gets installed into don't
always have a change window. Making upgrades painless and boring are
a precondition for anything else OpenStack wants to do, because if
operators don't upgrade their OpenStack environments, they'll never
get any of the new enhancements we are building as a community.

I really want the end user experience with OpenStack to be better. In
the last cycle I helped spear head the api-ref effort. In a single
cycle our API docs jumped forward to an accuracy level we haven't seen
in years. This was a great community win. I've been championing
getting rid of the extensions mechanism inside Nova, to make it clear
that there is a single compute API, which we expect to see
everywhere.

Having worked on many efforts within projects, and across projects, I
think I bring a perspective to the TC about where process meets
reality in getting things accomplished. We always need to take steps
forward to advance the agenda, but if we make the steps too high, we
can set folks up for failure. Attainable forward progress creates
success, success creates momentum, and momentum makes more progress
possible.

I would be honored to serve on the TC again if chosen.

-Sean

-- 
Sean Dague
http://dague.net

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

Re: [openstack-dev] TC Candidacy

[Qiao, Liyong]

+1

BR, Eli(Li Yong)Qiao

From: David Lyle [mailto:dkly...@gmail.com]
Sent: Thursday, April 23, 2015 8:57 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] TC Candidacy

I'm announcing my candidacy for the Technical Committee elections.

I have been contributing to OpenStack since Grizzly primarily in Horizon. I 
have also had the privilege to serve as Horizon PTL since Icehouse.

Why I'm running:

I believe there should be broader representation on the TC. We are growing the 
OpenStack ecosystem. Let's make sure horizontal teams and diverse parts of the 
ecosystem are represented more directly. I understand concerns of scaling were 
the reason for moving from the TC made up of all PTLs (I question that 
assertion), but the sacrifice so far has been diversity. I feel current TC 
members are exceptionally capable and take a broad viewpoint, but there are 
limits of how well that works. Let's represent broader swaths of our ecosystem 
in the technical leadership.

I think growing the OpenStack ecosystem is fantastic. As a developer and the 
PTL of a project that tries to span across most of that ecosystem it also 
worries me a bit too. I think we need to focus on how the newer and older parts 
of our ecosystem work together. How do we manage all the horizontal needs this 
introduces without going to the extremes of just scaling existing horizontal 
efforts because that won't work. And pushing all horizontal work on the 
individual projects is not appropriate because that yields chaos.

Finally, I believe the TC needs to be more active in guiding overall direction 
of OpenStack and problem resolution. I'm not suggesting a dictatorship of 
course. But let's set a direction, overall release goals for OpenStack and help 
enable and drive them.

I'm really proud to be a part of the OpenStack developer community, but I think 
we're facing some real challenges. We need to address some primary issues or 
this community will struggle to remain the vibrant, supportive place it is now.

Thank you,
David

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

[Edgar Magana]

OpenStack Members,

I would like to announce my candidacy to serve for first time on the Technical 
Committee.

Objective:

I want to be part of the Technical Committee (TC) because I have all the 
passion in the world for OpenStack and I want to keep dedicating my energy and 
love to the most revolutionary opensource project of the last decade. I want to 
make OpenStack the best platform from the software perspective but also from 
the interconnectivity and operability sides as well.

Experience:

I have been member of OpenStack since April 2011, when I attended my first 
summit in Santa Clara and since then I haven't missed one of them and I do not 
want to do it! I am also part of the Neutron core team since 2012, currently 
focus on getting ready the first OpenStack Networking Guide! Thanks to all the 
support from the members of the Docs, Neutron and other teams. I like to 
document everything about OpenStack deployments and best practices for 
operability, some of my guides are referenced even by big companies like Red 
Hat: https://www.rdoproject.org/Install#Installation

Vision:

I have spent many hours operating and developing OpenStack and I think it can 
be better and better. It needs the right direction and the right support 
without having vendor-specific interest impacting the future of the platform. I 
want to bring the view of the operators to the TC. I want to give all this 
passion and energy to this committee to ensure that we all going to keep having 
all those great discussions every six months and many companies will keep 
transitioning their Data Centers ADNs to be powered by OpenStack.

Leading one of the most challenging OpenStack adoption in the Operators side 
has given me the experience to guide the TC and the Foundation to the most 
demanding areas in order to guarantee the growing of the teams and our 
community.

Sincerely,

Edgar Magana
-
IRC: emagana
Mail: emag...@gmail.com
Github: https://github.com/emagana
__
OpenStack Development Mailing 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

[Luke Gorrie]

On 23 April 2015 at 01:17, Maru Newby ma...@redhat.com wrote:

 My name is Maru Newby, and I am announcing my candidacy for the
 Technical Committee (TC) election.


Cool!

** Growing our contributors


Question regarding your candidacy:

If I recall correctly you have spoken in favor of face to face discussions
at mid-cycle meetings as a practical way to set priorities and move things
forward. What are your current thoughts on the costs and benefits of this?

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

[Tristan Cacqueray]

Hi Edgar,

To make it clear, this candidacy can not be confirmed as it was received
after the deadline (April 23, 05:59 UTC).

Regards,
Tristan

On 04/24/2015 02:55 AM, Edgar Magana wrote:
 OpenStack Members,
 
 I would like to announce my candidacy to serve for first time on the 
 Technical Committee.
 
 Objective:
 
 I want to be part of the Technical Committee (TC) because I have all the 
 passion in the world for OpenStack and I want to keep dedicating my energy 
 and love to the most revolutionary opensource project of the last decade. I 
 want to make OpenStack the best platform from the software perspective but 
 also from the interconnectivity and operability sides as well.
 
 Experience:
 
 I have been member of OpenStack since April 2011, when I attended my first 
 summit in Santa Clara and since then I haven't missed one of them and I do 
 not want to do it! I am also part of the Neutron core team since 2012, 
 currently focus on getting ready the first OpenStack Networking Guide! Thanks 
 to all the support from the members of the Docs, Neutron and other teams. I 
 like to document everything about OpenStack deployments and best practices 
 for operability, some of my guides are referenced even by big companies like 
 Red Hat: https://www.rdoproject.org/Install#Installation
 
 Vision:
 
 I have spent many hours operating and developing OpenStack and I think it can 
 be better and better. It needs the right direction and the right support 
 without having vendor-specific interest impacting the future of the platform. 
 I want to bring the view of the operators to the TC. I want to give all this 
 passion and energy to this committee to ensure that we all going to keep 
 having all those great discussions every six months and many companies will 
 keep transitioning their Data Centers ADNs to be powered by OpenStack.
 
 Leading one of the most challenging OpenStack adoption in the Operators side 
 has given me the experience to guide the TC and the Foundation to the most 
 demanding areas in order to guarantee the growing of the teams and our 
 community.
 
 Sincerely,
 
 Edgar Magana
 -
 IRC: emagana
 Mail: emag...@gmail.com
 Github: https://github.com/emagana
 
 
 
 __
 OpenStack Development Mailing 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

[Maru Newby]

 On Apr 24, 2015, at 6:17 AM, Luke Gorrie l...@tail-f.com wrote:
 
 Question regarding your candidacy:
 
 If I recall correctly you have spoken in favor of face to face discussions at 
 mid-cycle meetings as a practical way to set priorities and move things 
 forward. What are your current thoughts on the costs and benefits of this?
 

I don't think our TC should be involved in a project's decision to hold a
mid-cycle unless legitimate complaints about the openness of the mid-cycle
remain unaddressed by the project's leadership.

My experience is that face-to-face communication can aid in building the
relationships and technical understanding essential to writing good software.
The drawbacks are that proximity can be both expensive and exclusionary.  I
think it's up to each project community to decide whether a mid-cycle is
justified, and if so, work hard to minimize the downsides.  Foundation support
is often available for those that can't afford to attend for financial reasons.
For those that otherwise can't attend, there is the option of encouraging
designation of a representative, ensuring that the mid-cycle is recorded or
logged, and deferring decision-making on explored options to the wider community
after the mid-cycle.


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

[Tristan Cacqueray]

confirmed

On 04/22/2015 09:32 PM, Michael Krotscheck wrote:
 Hi everyone!
 
 I'd like to announce my own candidacy for the OpenStack Technical
 Committee. My TL/DR platform is: Represent Front-End Engineering. It's
 what I do, it's what I love, it's what I've been doing for the last 15
 years, and it's what I want to keep doing for years to come.
 
 Would you like some details? Of course you would!
 
 *First: Represent Front-End Engineering on the TC.*
 
 To me, this means being an advocate to everyone who touches the things
 which people use to interact with OpenStack; CLI, Web UI, etc. From the
 engineers working on upstream projects such as Fuel, Refstack, Ironic-UI,
 Horizon, and StoryBoard, to the UI Developers downstream who are developing
 their own tools, I strongly feel this branch of our profession should be
 represented, and I would like to be that representative.
 
 *Second: Advocate ease-of-use across OpenStack.*
 
 I don't only mean pretty buttons - I also mean how easy the CLI clients
 are, how intuitive the API's are, and how easy it is to onboard and/or
 support your own engineering efforts. You can have all the feature support
 in the world, but if it's not easy to use, you're doomed out of the gate.
 
 *Third: Make JavaScript a first-class citizen.*
 
 Yep, _this_ can of worms! Between the projects mentioned above, it's pretty
 clear that JavaScript is here to stay. With that in mind there remain many
 problems with the tooling, and we need to be conscious of those
 shortcomings as we start to draft policies that support the needs of all
 stakeholders: OpenStack's components, Engineers both downstream and
 upstream, Package Maintainers, and most importantly Operators and their
 Customers.
 
 *My qualifications:*
 
 I've been active in the OpenStack community for about 18 months now,
 working on Monty Taylor's team here at HP on trying to get StoryBoard to
 the point where it can replace Launchpad. I'm more-or-less responsible for
 all things NodeJS, NPM, Selenium, and Browser on infra, basically
 everything you need to build and test a Web UI. I've recently landed
 supporting technologies (such as CORS) that will greatly assist in
 unleashing downstream UI developers post-liberty, and am trying to teach
 Infra how to publish javascript libraries much like it does for python.
 Also, I've got 15 years of experience as a UI engineer, and a scant year of
 experience as a UX researcher.
 
 Michael Krotscheck
 
 
 
 __
 OpenStack Development Mailing 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

[Tristan Cacqueray]

confirmed

On 04/22/2015 09:52 PM, Mark McClain wrote:
 All-
 
 I'd like to announce my candidacy to continue serving on the Technical 
 Committee.
 
 
 Platform
 —
 OpenStack is a growing community comprised of many parts and we we must view 
 ourselves as one unit. As a TC member, I will continue to place the interests 
 of the larger community over those of those of individual projects.
 
 There are several key areas I'd like to see the TC focus:
 
 Development
   The Technical Committee should serve as a high level forum to facilitate 
 defining cross project technical and procedural requirements. While many of 
 our programs share commonalities, there are still too many differences in 
 policies and technical decisions. The addition of cross project 
 specifications is a step towards unifying the development process and design 
 standards within our community.  As we accept more projects under the new 
 governance model, the TC should work to facilitate developer mobility across 
 projects by promoting best practices.  Increased mobility will strengthen our 
 community as it helps to prevent silos. Reviews are an another area the TC 
 should focus on during the upcoming cycle. The TC should review and work with 
 projects to improve the contributor and reviewer experience when contributing 
 to projects both big and small.
 
 Cross Project Communication
   Our codebase has grown significantly over the years and a contributor must 
 invest significant time to understand and follow every project; however many 
 contributors have limited time must choose a subset of projects to direct 
 their focus.  As a result, it becomes important to employ cross project 
 communication to explain major technical decisions, share solutions to 
 project challenges that might be widely applicable, and leverage our 
 collective experience.  The TC should seek new ways to facilitate cross 
 project communication that will enable the community to craft improvements to 
 the interfaces between projects as there will be greater familiarity between 
 across the boundary.
 
 Unified Experience
   For OpenStack to be successful we must strive to provide a unified 
 experience for both users and deployers. During the previous cycles we have 
 made progress in this area, but there is still work to be completed. When 
 visiting user groups, a common thread during discussion is the installation 
 experience. The TC should identify common installation configurations and 
 work with projects to optimize installation and upgrades.  Equally important 
 is the users. The TC should work to promote and support projects such the 
 OpenStack client and SDK which aim to provide users with tools that are well 
 maintained, documented and easy to use. Our community has invested 
 significant effort to improve this experience and this should remain a focus 
 going forward.
 
 
 About Me
 ——
 I have served on the Technical Committee for last two years and I am a former 
 PTL. Believing that OpenStack is a unified community, I have contributed code 
 and reviews to many of our projects since Sent from my iPad
 
 We have built a very special open community through the contributions of 
 many.  These contributions have powered our phenomenal growth and I'm excited 
 about our future!
 
 Thanks,
 mark
 
 __
 OpenStack Development Mailing 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

[Tristan Cacqueray]

confirmed

On 04/23/2015 12:26 AM, David Medberry wrote:
 Announcing my candidacy for the TC.
 
 I would bring an operator's perspective (ie, operator, user, super-user and
 dev) to the Technical Committee.
 
 I've been involved in OpenStack for four years. I gave talks at San Diego,
 Atlanta, Paris, and soon Vancouver as a contributor, community organizer,
 and operator.
 
 I would consent to serve a single term.
 
 -dave
 
 
 
 __
 OpenStack Development Mailing 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

[Tristan Cacqueray]

confirmed

On 04/23/2015 12:56 AM, Maish Saidel-Keesing wrote:
 I would like to announce my candidacy for the OpenStack Technical Committee
 
 Many of you many not know me, because I am not a very active contributor.
 
 First a bit about myself. I am a Platform Architect working for Cisco in
 Israel and have been involved with OpenStack for the past two years. I
 was and (and still am a very active member of the virtualization
 community [1] and have been for a good number of years.
 
 I was honored to contribute and participate in the OpenStack
 Architecture Design Guide [2]. I am not new to writing but this was a
 new experience for me. One that I thoroughly enjoyed and would love to
 do again, if presented with the opportunity.
 
 These are the following reasons I think I can make a difference as part
 of the TC
 
 #1 Diversity
 
 The vast majority of the TC members are all long standing and well known
 members of the OpenStack community. Many of them have been
 core-developers, PTL's, reviewers. All of them have one thing in common
 they are developers and people who take pride and joy in contributing
 code to the OpenStack projects.
 
 I too have contributed code to the OpenStack projects - but not on the
 scale that any of the other candidates have. nowhere near close.
 And I am not ashamed of that fact.
 I am not a developer. Yes, I dabble in code (not as much as I would
 like), but I am deep down in my heart, an Operations guy.  I like to get
 things to work, but not only that they work, but that they are stable,
 robust, and will provide a sound infrastructure (so that I do not get
 paged at 03.00 every night because something fell over and died).
 When all of the members of a committee are from a single 'stream' then
 it is natural to look at things in a certain way. But that is not the
 only way to look at things, there are other perspectives that need to be
 considered and that perspective (in my humble opinion) is missing.
 
 
 #2 Focus
 
 There has been a lengthy discussion over the past few months about what
 OpenStack is and what it is not. What should be part of OpenStack and
 again what should not. I cannot say that I fully agree with all the
 decisions that have been made, although I do fully agree with the
 direction in which OpenStack is going and how the TC has been driving that.
 
 I feel that the as part of the TC I will help the community focus on
 building a tightly integrated suite of software (there is no way you can
 call OpenStack a product) that will work, and work well [3].
 
 
 #3 Acceptance of others
 
 It is no secret that i think that I have spoken my mind[4], more than
 once on how I find it extremely hard for someone who is not a developer
 to help and make OpenStack better. I have tried to lower that hurdle in
 a number of ways [5] to make it easier for 'non-dev's' to starting
 'chipping in'. But it seems that I was not successful. Even with regards
 to myself.
 
 We are all members of the community. But there are several levels. Even
 in this election only ''Individual Members who committed a change to a
 repository under ’any’ of the official OpenStack Project Teams (as
 defined above) over the last two 6-month release cycles are
 automatically considered ATC'' and they are the only ones that can vote.
 
 There are other ways to contribute.
 People that report bugs contribute.
 People that write blog posts contribute.
 People that evangelize in User groups and speak at conferences, meetings
 etc. - they also contribute.
 
 It is not all about code.
 Yes it is hard to quantify. Yes it is hard to measure. But that does not
 mean it should not be considered.
 
 If elected to serve as part of the TC - this is something I would like
 pursue - something that can make the OpenStack community not only a
 developer community - but a community of all those who care about it.
 
 I would like to leave you with one last thought.
 I thought long and hard about putting up myself as a candidate. I do
 think that I have a fresh perspective to bring to the table, a different
 way of looking at things and a lot of passion that can help OpenStack
 achieve what it set out to do.
 
 ``Our goal is to produce the ubiquitous Open Source cloud computing
 platform that will meet the needs of public and private cloud providers
 regardless of size, by being simple to implement and massively scalable.``
 
 I would like to wish all the candidates the best of luck.
 




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

[openstack-dev] TC candidacy

[Dean Troyer]

Hello OpenStack world! My name is Dean Troyer and I am running for the
OpenStack Technical Committee.

I have been part of the OpenStack community for a long time and heavily
involved in three projects: I was an early contributor to DevStack and
served as its PTL during its short tenure as a stand-alone program, I
started Grenade to use DevStack as the basis for upgrade testing. I also am
the PTL of the OpenStackClient project that recently became the first
project brought into the expanded official project definition.

The common thread of my work in OpenStack has been with things that cross
the traditional vertical service projects. This has highlighted the scope
and consequences of differences between projects for me. Differences that
affect project developers is one thing, and sometimes a good thing even,
but differences that adversely affect deployers and consumers of OpenStack
clouds is another thing altogether. I believe this is where the focus of
encouraging projects to converge should be placed. Efforts like the API
Working Group and the Log Working Group need to be encouraged where they
improve the experiences of our customers (where 'our' == 'OpenStack' and
'customers' == 'everyone downstream from OpenStack').

I believe the TC has a good bit of work ahead to follow through
implementing the vision of inclusiveness. Communicating the state of
projects is a huge part of this. We should set up the goals and see who can
score. Those projects that do score will be the ones rewarded not by the TC
but by the rest of the community. One specific example that I think the TC
should facilitate is describing the technical relationships between
projects. The TC should bless, if not create, a common vocabulary to
describe the groups of projects and their relationships. While this may be
expressed in 'tags', it is more than just tag definitions.

The Technical Committee is unique in that in some way it touches every
aspect of OpenStack: projects and project developers, application
developers, distributors and VARs, cloud deployers and operators, end
users, and the OpenStack Board of Directors (DefCore!). The TC is the duct
tape of OpenStack! No, it is better than that, it is by design the group
that oversees enabling everything else to succeed.

I believe that TC members must have a broad vision and insight into many
parts of OpenStack and depth into at least a couple of areas. And I believe
that I have both of those attributes. I would appreciate your consideration
and vote.

As I mentioned above, I have been part of the OpenStack community since
before there was one, working on the original Nova deployment at NASA. That
was followed by a stint at Rackspace where DevStack and OSC were born, and
on to Nebula where we tossed Grenade into the world. After the recent
events at Nebula I will be joining Intel soon and again be focused on
upstream OpenStack projects.

Thanks again for your time and consideration
dt

-- 

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

[openstack-dev] TC candidacy

[Anita Kuno]

Please consider my candidacy for membership on the technical committee.

My name is Anita Kuno. I consider my home project to be Infra but I tend
to move around wherever I feel the need is greatest.

I have worked on OpenStack since mid-grizzly starting as an intern with
the GNOME Outreach Program for Women (which is now known as Outreachy)
with my mentor Iccha Sethi. I moved around until I found Infra and have
considered that my home base ever since, mostly because Infra, and my
job, allows me so much flexibility.

During the Hong Kong summit I launched myself into Neutron to see if
there was anything I could do to support improvement, not because I knew
anything about Neutron but because I live by the axiom don't ask anyone
to do anything you wouldn't be prepared to do yourself. I realized that
Neutron developers couldn't even find each other to talk to each other
due to the crowd and organized a Neutron Tempest code sprint in Montreal
in January 2014.

Coming out of that, I have been involved with the third party ci space
ever since, a difficult and demanding space and those involved with have
many opinions on whether I have done and am doing a good job or a poor job.

I split the project-config repo out of what was the Infra config repo
(and is now system-config) at the end of Juno and have been a core
reviewer on the project ever since. I was able to help Neutron split out
their 'as a service' repos at the Sprint in Lehi in December last year
due to having repo-split experience myself.

I had known that the Nova-net to Neutron migration work was/is important
and had attended the Paris summit session on the issue, which had some
people indicate they would drive the work so stepped back believing it
was taken care of. Until December when I saw that not enough work had
taken place for anything to happen in Kilo. I got involved to support
Oleg Bondarev's work and help find more people to provide design
direction and feedback. We had a design and got some code written (way
to go group) however the feedback from the ops summit was such that it
became evident that the current solution even if finished would be
insufficient to address the issue. I curtailed our work (with agreement
of those at the meeting) in favour of opening a larger discussion on the
mailing list. I consider the work those involved put in to be valuable,
as it is possible we might not have gotten the level of detail in the
feedback we currently have without the code, thank you to all who
participated.

At present I have agreed to chair the discussion in Vancouver for the
session addressing Nova-net and Neutron. I ask that those involved and
affected by this work find it in their hearts to bring a positive
outlook to this issue. I'm grateful for your support.

Last cycle I attended the Neutron, Keystone, Nova and Cinder mid-cycles,
to help with third party work, the nova-net to neutron migration as well
as helping project devs better understand how infra works and how to
maximize efficient use of infra tools such as gerrit as well as how to
offer an elastic-recheck fingerprint.

I tend to gravitate towards work that needs to get done but which noone
else wants to do. I have been operating from the belief that this is for
the benefit of OpenStack. I will admit the big tent movement has thrown
me off in regards to what is beneficial for OpenStack. Thierry's blog
post helps in that regard. I would like to look and work on issues that
affect the health of OpenStack long term including our vision of our
targeted user.

I am an astrologer at heart and as such look at large patterns and
cycles of activity as well at their results. OpenStack is in a unique
position to redefine software creation as a process that has outcomes
that can be negotiated as beneficial for all concerned. The way it does
so is by incorporating unlimited freedom with careful evaluation of
structure and limits of resources by balancing culture and social
responsibility to seeing and respecting both ends of the spectrum in
actions. When we do this (and we have been able to) then everyone wins
and feels nourished as a result. When one side of OpenStack (the freedom
side, for instance) needs to accomplish its goal at the expense of the
other side (careful evaluation of structure and limits of resources)
then we all lose. It is a powerful energy structure and requires balance.

I also served the technical committee as election official for 4
election seasons. I want to thank you co-election officials for your
guidance and support in that process, Monty Taylor, Thierry Carrez and
Tristan Cacqueray (who is currently serving as an election official). I
would also like to acknowledge Elizabeth K. Joseph who has replaced me,
thank you to you as well, Elizabeth.

Please feel free to ask me any questions if my post has failed to
present my perspective and position. I will continue to serve OpenStack
to the best of my ability regardless of what position the community
chooses to bestow 

Re: [openstack-dev] TC candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 9:46 AM, Anita Kuno ante...@anteaya.info wrote:
 Please consider my candidacy for membership on the technical committee.

 My name is Anita Kuno. I consider my home project to be Infra but I tend
 to move around wherever I feel the need is greatest.

 I have worked on OpenStack since mid-grizzly starting as an intern with
 the GNOME Outreach Program for Women (which is now known as Outreachy)
 with my mentor Iccha Sethi. I moved around until I found Infra and have
 considered that my home base ever since, mostly because Infra, and my
 job, allows me so much flexibility.

 During the Hong Kong summit I launched myself into Neutron to see if
 there was anything I could do to support improvement, not because I knew
 anything about Neutron but because I live by the axiom don't ask anyone
 to do anything you wouldn't be prepared to do yourself. I realized that
 Neutron developers couldn't even find each other to talk to each other
 due to the crowd and organized a Neutron Tempest code sprint in Montreal
 in January 2014.

 Coming out of that, I have been involved with the third party ci space
 ever since, a difficult and demanding space and those involved with have
 many opinions on whether I have done and am doing a good job or a poor job.

 I split the project-config repo out of what was the Infra config repo
 (and is now system-config) at the end of Juno and have been a core
 reviewer on the project ever since. I was able to help Neutron split out
 their 'as a service' repos at the Sprint in Lehi in December last year
 due to having repo-split experience myself.

 I had known that the Nova-net to Neutron migration work was/is important
 and had attended the Paris summit session on the issue, which had some
 people indicate they would drive the work so stepped back believing it
 was taken care of. Until December when I saw that not enough work had
 taken place for anything to happen in Kilo. I got involved to support
 Oleg Bondarev's work and help find more people to provide design
 direction and feedback. We had a design and got some code written (way
 to go group) however the feedback from the ops summit was such that it
 became evident that the current solution even if finished would be
 insufficient to address the issue. I curtailed our work (with agreement
 of those at the meeting) in favour of opening a larger discussion on the
 mailing list. I consider the work those involved put in to be valuable,
 as it is possible we might not have gotten the level of detail in the
 feedback we currently have without the code, thank you to all who
 participated.

 At present I have agreed to chair the discussion in Vancouver for the
 session addressing Nova-net and Neutron. I ask that those involved and
 affected by this work find it in their hearts to bring a positive
 outlook to this issue. I'm grateful for your support.

 Last cycle I attended the Neutron, Keystone, Nova and Cinder mid-cycles,
 to help with third party work, the nova-net to neutron migration as well
 as helping project devs better understand how infra works and how to
 maximize efficient use of infra tools such as gerrit as well as how to
 offer an elastic-recheck fingerprint.

 I tend to gravitate towards work that needs to get done but which noone
 else wants to do. I have been operating from the belief that this is for
 the benefit of OpenStack. I will admit the big tent movement has thrown
 me off in regards to what is beneficial for OpenStack. Thierry's blog
 post helps in that regard. I would like to look and work on issues that
 affect the health of OpenStack long term including our vision of our
 targeted user.

 I am an astrologer at heart and as such look at large patterns and
 cycles of activity as well at their results. OpenStack is in a unique
 position to redefine software creation as a process that has outcomes
 that can be negotiated as beneficial for all concerned. The way it does
 so is by incorporating unlimited freedom with careful evaluation of
 structure and limits of resources by balancing culture and social
 responsibility to seeing and respecting both ends of the spectrum in
 actions. When we do this (and we have been able to) then everyone wins
 and feels nourished as a result. When one side of OpenStack (the freedom
 side, for instance) needs to accomplish its goal at the expense of the
 other side (careful evaluation of structure and limits of resources)
 then we all lose. It is a powerful energy structure and requires balance.

 I also served the technical committee as election official for 4
 election seasons. I want to thank you co-election officials for your
 guidance and support in that process, Monty Taylor, Thierry Carrez and
 Tristan Cacqueray (who is currently serving as an election official). I
 would also like to acknowledge Elizabeth K. Joseph who has replaced me,
 thank you to you as well, Elizabeth.

 Please feel free to ask me any questions if my post has failed to
 

Re: [openstack-dev] TC candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 9:43 AM, Dean Troyer dtro...@gmail.com wrote:
 Hello OpenStack world! My name is Dean Troyer and I am running for the
 OpenStack Technical Committee.

 I have been part of the OpenStack community for a long time and heavily
 involved in three projects: I was an early contributor to DevStack and
 served as its PTL during its short tenure as a stand-alone program, I
 started Grenade to use DevStack as the basis for upgrade testing. I also am
 the PTL of the OpenStackClient project that recently became the first
 project brought into the expanded official project definition.

 The common thread of my work in OpenStack has been with things that cross
 the traditional vertical service projects. This has highlighted the scope
 and consequences of differences between projects for me. Differences that
 affect project developers is one thing, and sometimes a good thing even, but
 differences that adversely affect deployers and consumers of OpenStack
 clouds is another thing altogether. I believe this is where the focus of
 encouraging projects to converge should be placed. Efforts like the API
 Working Group and the Log Working Group need to be encouraged where they
 improve the experiences of our customers (where 'our' == 'OpenStack' and
 'customers' == 'everyone downstream from OpenStack').

 I believe the TC has a good bit of work ahead to follow through implementing
 the vision of inclusiveness. Communicating the state of projects is a huge
 part of this. We should set up the goals and see who can score. Those
 projects that do score will be the ones rewarded not by the TC but by the
 rest of the community. One specific example that I think the TC should
 facilitate is describing the technical relationships between projects. The
 TC should bless, if not create, a common vocabulary to describe the groups
 of projects and their relationships. While this may be expressed in 'tags',
 it is more than just tag definitions.

 The Technical Committee is unique in that in some way it touches every
 aspect of OpenStack: projects and project developers, application
 developers, distributors and VARs, cloud deployers and operators, end users,
 and the OpenStack Board of Directors (DefCore!). The TC is the duct tape of
 OpenStack! No, it is better than that, it is by design the group that
 oversees enabling everything else to succeed.

 I believe that TC members must have a broad vision and insight into many
 parts of OpenStack and depth into at least a couple of areas. And I believe
 that I have both of those attributes. I would appreciate your consideration
 and vote.

 As I mentioned above, I have been part of the OpenStack community since
 before there was one, working on the original Nova deployment at NASA. That
 was followed by a stint at Rackspace where DevStack and OSC were born, and
 on to Nebula where we tossed Grenade into the world. After the recent events
 at Nebula I will be joining Intel soon and again be focused on upstream
 OpenStack projects.

 Thanks again for your time and consideration
 dt

 --

 Dean Troyer
 dtro...@gmail.com

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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 5:24 AM, Ed Leafe e...@leafe.com wrote:
 Greetings Stackers!

 I'm announcing my candidacy for the Technical Comitee Elections.

 Those of you who have been around OpenStack for a while know me, as I was one 
 of the original developers involved since the inception of OpenStack back in 
 2010, when I worked for Rackspace's Cloud Server team. I was a contributor 
 and core reviewer for Nova until a job change at Rackspace removed me from 
 direct OpenStack development around the Essex release. I was still 
 peripherally involved, though, as my work as a Developer Advocate involved 
 creating the first Python SDK for OpenStack [0], which gave me a great 
 education on how frustrating inconsistent APIs can be! In order to help 
 improve the experience of developers building apps with OpenStack, I 
 wholeheartedly support the efforts of the API Working Group to reduce this 
 problem in the future.

 [0] https://github.com/rackspace/pyrax

 Fast-forward to last September, when I joined IBM with one mandate: work 
 full-time on OpenStack by contributing as much as possible to upstream 
 OpenStack, and becoming involved in the community. Since then I've 
 re-immersed myself in Nova, focusing mainly on the effort to clean up the 
 Scheduler interfaces. So I believe that this history gives me a unique 
 perspective on OpenStack development: where it came from, and where it needs 
 to go to move forward.

 I mentioned improving the experience of developers working *with* OpenStack; 
 I'd also like to improve the experience of developers working *on* OpenStack. 
 To that end, I agree wholeheartedly with Thierry's call to step out of the 
 way [1]. There is a lot of energy across the many projects, and the TC 
 should do everything it can to help make that energy effective without 
 stifling it. I spoke about the potential for OpenStack to change the world 
 in an interview I gave for Rackspace last year [2], and the last thing I 
 would want to see is someone with an idea get discouraged because there were 
 too many hoops to jump through to make it happen on OpenStack.

 [1] http://ttx.re/stepping-out-of-the-way.html
 [2] https://youtu.be/0QRkzMW3OdA?t=115

 One place, though, where I think the TC can inject itself is to help 
 alleviate the lack of core reviewers, particularly in Nova, which I discussed 
 in [3]. Having so few cores for the number of patches being created is simply 
 not sustainable, and just wishing for things to get better isn't cutting it. 
 And I do consider it a technical problem, since the main barrier isn't lack 
 of interested people; it's that it's currently too difficult for most people 
 to learn enough about all the various parts of the project necessary to 
 achieve core status.

 [3] http://blog.leafe.com/the-core-deficiency

 I sort of wish that there was the questionnaire format like we had in the 
 last TC election, so I could be sure to give everyone a clear view on where I 
 see things on different issues. If you have any such concerns, please feel 
 free to respond to this email (and to those of the other candidates!), and I 
 will be happy to answer any questions.

 Thanks for your consideration,

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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 11:19 AM, Zane Bitter zbit...@redhat.com wrote:
 Hello Stackists,
 I'd like to announce my candidacy for the OpenStack Technical Committee.

 I'm running because I don't think that the diversity of perspectives amongst
 TC members reflects the diversity of our community. We're fortunate to have
 a few people whose brilliance often transcends the scope of their day-to-day
 focus, but I don't think that can outweigh the fact that (by my, arguable,
 count) 12 out of 13 are focused primarily on Nova and the projects
 (including cross-project efforts) that evolved directly out of it.

 When a group of people share a common vision and goal, they can pretty much
 always figure out a way to work together toward it. When they don't, they
 have to invent rules and structure and bureaucracy to keep everyone in
 line.[1] I... think we need to work more on the vision thing ;) Thierry
 calls it 'stepping out of the way', but I think of it as stepping up, out of
 the weeds, to look at the bigger picture.

 My hope is that in a decade or two, developers will prefer to write their
 new applications against Open Source implementations of open APIs - and not
 just to avoid lock-in, but because they'll be as good or better than
 proprietary alternatives. Linux has already made that a reality at the level
 of individual servers - and while offering refuge from proprietary Unixes
 (Unices?) for legacy applications was no doubt a critical (and lucrative)
 part of getting there, it's much more important in the long run that it's
 also the preferred platform for new development. Today a growing fraction of
 applications are bigger than a single server, and I believe that OpenStack
 represents our best opportunity to make sure that in the future open source
 cloud APIs will be the preferred choice too.

 The big tent is a great start - it allows a project to assure contributors
 that they are committed to truly open[2] governance long before it matures
 to the point where it could have been incubated under the previous process.
 And after all, the most powerful technologies we've developed are social,
 and we shouldn't be reluctant to use them. However, if only a small section
 in the middle of the tent is waterproof, then the big tent exists in name
 only. We have to make sure we continue to help and guide all of the projects
 as they grow and mature - getting them in the tent is only the first step. I
 am strongly opposed to the TC using the tagging system to identify use cases
 it thinks are important - the community can and will decide for itself what
 is important. (Of course I support using the tagging system to provide more
 information that the community can use to evaluate projects for themselves,
 and more long-form documentation of use cases where that is lacking.) I
 believe in abundance, not scarcity: when our community provides space for
 participants to work on problems they care about we don't weaken the
 existing projects, we actually strengthen the community by increasing its
 critical mass. (In other words, we may have a task-allocation problem, but
 we shouldn't mistake it for a project-allocation problem since it will
 require different solutions.)

 Right now we're missing a lot of fundamental building blocks - like
 user-configurable authorisation, and public-facing asynchronous messaging -
 that we need to allow workloads running in a cloud to interact with it. As a
 result, a lot of projects that should be tightly (small-i) integrated (but
 loosely coupled!) with each other are developing in an ad hoc manner, and a
 lot of technical problems are being solved over and over, often badly. The
 pre-big-tent regime gave an incentive to new projects not to work together,
 and we need to reverse that effect. The TC needs to boost the confidence of
 OpenStack developers to simplify things by taking dependencies on other
 projects where appropriate, and I think the best way to do that is to kick
 off an ongoing discussion about the vision for and design of OpenStack at a
 level above that of indivudual projects. (We've made a good start on
 cross-project co-ordination at a _lower_ level, like the API working group,
 but to do so at a higher level will require the TC's blessing.)


 In case you don't know me, I'm a core developer of Heat and I've been
 involved in OpenStack since the Heat project kicked off about 3 years ago.
 I'm also a former elected PTL, and I've been working closely with the TC
 since Heat applied for incubation back around the time of the Grizzly
 summit. I've attended most TC meetings for at least the past 18 months, so
 I'm already up to speed with what has been happening. Finally, I currently
 lead a team at Red Hat developing (upstream!) tools for updating OpenStack
 deployments - which is another way of saying that few people are more
 motivated to make deployment easier than I ;)

 Thanks for reading this far. Please make time to read the other 

[openstack-dev] TC Candidacy

[Zane Bitter]

Hello Stackists,
I'd like to announce my candidacy for the OpenStack Technical Committee.

I'm running because I don't think that the diversity of perspectives 
amongst TC members reflects the diversity of our community. We're 
fortunate to have a few people whose brilliance often transcends the 
scope of their day-to-day focus, but I don't think that can outweigh the 
fact that (by my, arguable, count) 12 out of 13 are focused primarily on 
Nova and the projects (including cross-project efforts) that evolved 
directly out of it.


When a group of people share a common vision and goal, they can pretty 
much always figure out a way to work together toward it. When they 
don't, they have to invent rules and structure and bureaucracy to keep 
everyone in line.[1] I... think we need to work more on the vision thing 
;) Thierry calls it 'stepping out of the way', but I think of it as 
stepping up, out of the weeds, to look at the bigger picture.


My hope is that in a decade or two, developers will prefer to write 
their new applications against Open Source implementations of open APIs 
- and not just to avoid lock-in, but because they'll be as good or 
better than proprietary alternatives. Linux has already made that a 
reality at the level of individual servers - and while offering refuge 
from proprietary Unixes (Unices?) for legacy applications was no doubt a 
critical (and lucrative) part of getting there, it's much more important 
in the long run that it's also the preferred platform for new 
development. Today a growing fraction of applications are bigger than a 
single server, and I believe that OpenStack represents our best 
opportunity to make sure that in the future open source cloud APIs will 
be the preferred choice too.


The big tent is a great start - it allows a project to assure 
contributors that they are committed to truly open[2] governance long 
before it matures to the point where it could have been incubated under 
the previous process. And after all, the most powerful technologies 
we've developed are social, and we shouldn't be reluctant to use them. 
However, if only a small section in the middle of the tent is 
waterproof, then the big tent exists in name only. We have to make sure 
we continue to help and guide all of the projects as they grow and 
mature - getting them in the tent is only the first step. I am strongly 
opposed to the TC using the tagging system to identify use cases it 
thinks are important - the community can and will decide for itself what 
is important. (Of course I support using the tagging system to provide 
more information that the community can use to evaluate projects for 
themselves, and more long-form documentation of use cases where that is 
lacking.) I believe in abundance, not scarcity: when our community 
provides space for participants to work on problems they care about we 
don't weaken the existing projects, we actually strengthen the community 
by increasing its critical mass. (In other words, we may have a 
task-allocation problem, but we shouldn't mistake it for a 
project-allocation problem since it will require different solutions.)


Right now we're missing a lot of fundamental building blocks - like 
user-configurable authorisation, and public-facing asynchronous 
messaging - that we need to allow workloads running in a cloud to 
interact with it. As a result, a lot of projects that should be tightly 
(small-i) integrated (but loosely coupled!) with each other are 
developing in an ad hoc manner, and a lot of technical problems are 
being solved over and over, often badly. The pre-big-tent regime gave an 
incentive to new projects not to work together, and we need to reverse 
that effect. The TC needs to boost the confidence of OpenStack 
developers to simplify things by taking dependencies on other projects 
where appropriate, and I think the best way to do that is to kick off an 
ongoing discussion about the vision for and design of OpenStack at a 
level above that of indivudual projects. (We've made a good start on 
cross-project co-ordination at a _lower_ level, like the API working 
group, but to do so at a higher level will require the TC's blessing.)



In case you don't know me, I'm a core developer of Heat and I've been 
involved in OpenStack since the Heat project kicked off about 3 years 
ago. I'm also a former elected PTL, and I've been working closely with 
the TC since Heat applied for incubation back around the time of the 
Grizzly summit. I've attended most TC meetings for at least the past 18 
months, so I'm already up to speed with what has been happening. 
Finally, I currently lead a team at Red Hat developing (upstream!) tools 
for updating OpenStack deployments - which is another way of saying that 
few people are more motivated to make deployment easier than I ;)


Thanks for reading this far. Please make time to read the other 
candidate bios (especially Jay's), think about _your_ vision for 
OpenStack, engage with 

[openstack-dev] TC Candidacy

[Maru Newby]

My name is Maru Newby, and I am announcing my candidacy for the
Technical Committee (TC) election.

tl;dr;

I'm a relative unknown outside of Neutron, but I've been helping to drive
high-level change in that project. I would welcome the opportunity to bring my
energy and dedication to OpenStack-wide concerns as a member of our TC.

If you're willing to read any part of this email, I hope it would be 'Why vote
for me?'.

If not, and you are as frustrated with the status quo as I am, I hope you will
consider voting for candidates that support the goal of building a more engaged
TC focused on ensuring that participation in OpenStack becomes more enjoyable
and sustainable.

Thank you for reading, and make sure to vote!


* Why vote for me?

If elected, I'm going to be a squeaky wheel advocating for anything and
everything that empowers our development community to deliver useful software
into the hands of users.  If this puts me at odds with those that want to focus
on issues like 'What is OpenStack' or 'How can we systematize project culture to
make it easier to communicate?', good!  I believe that you, as a technical
contributor to OpenStack, need stronger representation of your viewpoints on our
TC, and I'm one of the strongest advocates you're likely to find in this
community.  I am currently employed full time upstream, and I am willing and
able to devote the resources necessary to do justice to the role.

I also intend to advocate for focusing the OpenStack community on ambitious, but
achievable, goals.  I believe this will require making hard choices about which
use cases we can reasonably expect to support.  To me, the idea that OpenStack
can be all things to all people is dangerous.  It's just as likely that in
trying to do it all, we do little of it well, and risk irrelevance.  I think our
primary competition is and will continue to be proprietary cloud, and my biggest
fear is that we become unable to compete on cost due to the operational
complexity required to make everyone happy.  We need to keep our collective eyes
on the ball!

To be clear, I want to be a part of a TC with as diverse a group of viewpoints
as possible to ensure that we have to work hard to achieve consensus.  If
agreement is reached too easily, there is probably something wrong.  My wanting
to push a developer-centric agenda doesn't mean that I don't respect the need to
address other issues.  My voice would be one of many, and I recognize that
consensus requires compromise.


* Why not vote for me?

There are candidates more deserving of your vote if you think our TC shouldn't
have a role in providing leadership to the OpenStack community.  If you believe
that our TC is already sufficiently developer-focused, then I also don't deserve
your vote.

This is in no way to suggest that I want to see our TC become a top-down
decision-making body. This is still an open source project, after all, and I
know first-hand the complexities of the culture involved.  I do think it
appropriate, though, for an elected body with as much visibility as our TC to
participate more actively in addressing the challenges we face.


* Key concerns

There are any number of issues facing OpenStack today, but the items on the
shortlist that follows are the concerns that I would like to see the TC
champion in the near-term:

** Scaling our development effort

The stated goal of our TC of late has been to 'get out of the way'.  I
wholeheartedly support this intention, and would like to see it extended to how
our TC approaches governance beyond project evaluation.  I think our TC should
be responsible for proposing what we want to achieve rather than in how we
should achieve it.  Outcomes, rather than process.  I think project-level
contributors are best equipped to solve the problems of implementation.  Our TC
can take responsibility for setting OpenStack-wide expectations and in
facilitating - rather than managing - cross-project advancement towards these
goals.  More than ever, we need to be pulling in the same direction, and I think
our TC is an obvious candidate to rally ourselves around.

I hope we all recognize that we can't scale OpenStack if decisions are
constantly gated on a small group of 'tastemakers'.  Delegation of trust is
required, whether at the level of our TC or the individual projects.  I think we
need to take our TC's recent momentum to the project level and find ways to
increase delegation of responsibility.  Nova and Neutron, for example, have had
to face ever-increasing demands with the same small pool of core reviewers, and
many of you know all-too-well the pain that has resulted.  Core reviewers - like
the pre-big tent TC - have inadvertently become micromanagers as their
responsibilities have evolved beyond their capacity to meet them.  The model of
direct trust - in which each core needs to trust every other core - doesn't
scale due to fundamental human limits.  This is at odds with OpenStack's need to
grow, and I want our TC to 

[openstack-dev] TC Candidacy

[Michael Krotscheck]

Hi everyone!

I'd like to announce my own candidacy for the OpenStack Technical
Committee. My TL/DR platform is: Represent Front-End Engineering. It's
what I do, it's what I love, it's what I've been doing for the last 15
years, and it's what I want to keep doing for years to come.

Would you like some details? Of course you would!

*First: Represent Front-End Engineering on the TC.*

To me, this means being an advocate to everyone who touches the things
which people use to interact with OpenStack; CLI, Web UI, etc. From the
engineers working on upstream projects such as Fuel, Refstack, Ironic-UI,
Horizon, and StoryBoard, to the UI Developers downstream who are developing
their own tools, I strongly feel this branch of our profession should be
represented, and I would like to be that representative.

*Second: Advocate ease-of-use across OpenStack.*

I don't only mean pretty buttons - I also mean how easy the CLI clients
are, how intuitive the API's are, and how easy it is to onboard and/or
support your own engineering efforts. You can have all the feature support
in the world, but if it's not easy to use, you're doomed out of the gate.

*Third: Make JavaScript a first-class citizen.*

Yep, _this_ can of worms! Between the projects mentioned above, it's pretty
clear that JavaScript is here to stay. With that in mind there remain many
problems with the tooling, and we need to be conscious of those
shortcomings as we start to draft policies that support the needs of all
stakeholders: OpenStack's components, Engineers both downstream and
upstream, Package Maintainers, and most importantly Operators and their
Customers.

*My qualifications:*

I've been active in the OpenStack community for about 18 months now,
working on Monty Taylor's team here at HP on trying to get StoryBoard to
the point where it can replace Launchpad. I'm more-or-less responsible for
all things NodeJS, NPM, Selenium, and Browser on infra, basically
everything you need to build and test a Web UI. I've recently landed
supporting technologies (such as CORS) that will greatly assist in
unleashing downstream UI developers post-liberty, and am trying to teach
Infra how to publish javascript libraries much like it does for python.
Also, I've got 15 years of experience as a UI engineer, and a scant year of
experience as a UX researcher.

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

[Sergey Lukjanov]

Hi folks,

I’d like to announce my candidacy for the TC elections.

Here is a list of the main directions I would like to concentrate on as a
TC member:

* Continue to grow the OpenStack long-term vision and inclusive approach
that comes with The Big Tent. We should not just be more inclusive, but
also provide new OpenStack projects with fine-grained directions for
improvements, recommendations and cross-project coordination.

* Strengthen the voice of the platform projects (Heat, Sahara, Murano, etc)
on the Technical Committee.

* Bring additional focus and attention to OpenStack end users of all
levels, especially application developers who are the most active cloud
users.

* Help OpenStack community newcomers better understand the process of
contributing, learning the upstream tooling, and finding answers to their
common questions.

* Allow more self-governance and automation of common tasks like adding new
source repositories without TC pre-approval.

A few words about me. I have been actively involved in OpenStack community
for the last 2.5 years. I’m PTL of OpenStack Data Processing service
(“Sahara”) from its very beginning and a core team member of the OpenStack
Infrastructure team. Before OpenStack, I was involved in other open source
projects including Apache/Twitter Storm, Kotlin and Big Data solutions. I’m
currently leading the Sahara team and an internal OpenStack Infra clone
initiative at Mirantis.

Thanks.


-- 
Sincerely yours,
Sergey Lukjanov
Sahara Technical Lead
(OpenStack Data Processing)
Principal Software Engineer
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] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 5:05 PM, Sergey Lukjanov slukja...@mirantis.com wrote:
 Hi folks,

 I'd like to announce my candidacy for the TC elections.

 Here is a list of the main directions I would like to concentrate on as a TC
 member:

 * Continue to grow the OpenStack long-term vision and inclusive approach
 that comes with The Big Tent. We should not just be more inclusive, but
 also provide new OpenStack projects with fine-grained directions for
 improvements, recommendations and cross-project coordination.

 * Strengthen the voice of the platform projects (Heat, Sahara, Murano, etc)
 on the Technical Committee.

 * Bring additional focus and attention to OpenStack end users of all levels,
 especially application developers who are the most active cloud users.

 * Help OpenStack community newcomers better understand the process of
 contributing, learning the upstream tooling, and finding answers to their
 common questions.

 * Allow more self-governance and automation of common tasks like adding new
 source repositories without TC pre-approval.

 A few words about me. I have been actively involved in OpenStack community
 for the last 2.5 years. I'm PTL of OpenStack Data Processing service
 (Sahara) from its very beginning and a core team member of the OpenStack
 Infrastructure team. Before OpenStack, I was involved in other open source
 projects including Apache/Twitter Storm, Kotlin and Big Data solutions. I'm
 currently leading the Sahara team and an internal OpenStack Infra clone
 initiative at Mirantis.

 Thanks.


 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 4:17 PM, Maru Newby ma...@redhat.com wrote:
 My name is Maru Newby, and I am announcing my candidacy for the
 Technical Committee (TC) election.

 tl;dr;

 I'm a relative unknown outside of Neutron, but I've been helping to drive
 high-level change in that project. I would welcome the opportunity to bring my
 energy and dedication to OpenStack-wide concerns as a member of our TC.

 If you're willing to read any part of this email, I hope it would be 'Why vote
 for me?'.

 If not, and you are as frustrated with the status quo as I am, I hope you will
 consider voting for candidates that support the goal of building a more 
 engaged
 TC focused on ensuring that participation in OpenStack becomes more enjoyable
 and sustainable.

 Thank you for reading, and make sure to vote!


 * Why vote for me?

 If elected, I'm going to be a squeaky wheel advocating for anything and
 everything that empowers our development community to deliver useful software
 into the hands of users.  If this puts me at odds with those that want to 
 focus
 on issues like 'What is OpenStack' or 'How can we systematize project culture 
 to
 make it easier to communicate?', good!  I believe that you, as a technical
 contributor to OpenStack, need stronger representation of your viewpoints on 
 our
 TC, and I'm one of the strongest advocates you're likely to find in this
 community.  I am currently employed full time upstream, and I am willing and
 able to devote the resources necessary to do justice to the role.

 I also intend to advocate for focusing the OpenStack community on ambitious, 
 but
 achievable, goals.  I believe this will require making hard choices about 
 which
 use cases we can reasonably expect to support.  To me, the idea that OpenStack
 can be all things to all people is dangerous.  It's just as likely that in
 trying to do it all, we do little of it well, and risk irrelevance.  I think 
 our
 primary competition is and will continue to be proprietary cloud, and my 
 biggest
 fear is that we become unable to compete on cost due to the operational
 complexity required to make everyone happy.  We need to keep our collective 
 eyes
 on the ball!

 To be clear, I want to be a part of a TC with as diverse a group of viewpoints
 as possible to ensure that we have to work hard to achieve consensus.  If
 agreement is reached too easily, there is probably something wrong.  My 
 wanting
 to push a developer-centric agenda doesn't mean that I don't respect the need 
 to
 address other issues.  My voice would be one of many, and I recognize that
 consensus requires compromise.


 * Why not vote for me?

 There are candidates more deserving of your vote if you think our TC shouldn't
 have a role in providing leadership to the OpenStack community.  If you 
 believe
 that our TC is already sufficiently developer-focused, then I also don't 
 deserve
 your vote.

 This is in no way to suggest that I want to see our TC become a top-down
 decision-making body. This is still an open source project, after all, and I
 know first-hand the complexities of the culture involved.  I do think it
 appropriate, though, for an elected body with as much visibility as our TC to
 participate more actively in addressing the challenges we face.


 * Key concerns

 There are any number of issues facing OpenStack today, but the items on the
 shortlist that follows are the concerns that I would like to see the TC
 champion in the near-term:

 ** Scaling our development effort

 The stated goal of our TC of late has been to 'get out of the way'.  I
 wholeheartedly support this intention, and would like to see it extended to 
 how
 our TC approaches governance beyond project evaluation.  I think our TC should
 be responsible for proposing what we want to achieve rather than in how we
 should achieve it.  Outcomes, rather than process.  I think project-level
 contributors are best equipped to solve the problems of implementation.  Our 
 TC
 can take responsibility for setting OpenStack-wide expectations and in
 facilitating - rather than managing - cross-project advancement towards these
 goals.  More than ever, we need to be pulling in the same direction, and I 
 think
 our TC is an obvious candidate to rally ourselves around.

 I hope we all recognize that we can't scale OpenStack if decisions are
 constantly gated on a small group of 'tastemakers'.  Delegation of trust is
 required, whether at the level of our TC or the individual projects.  I think 
 we
 need to take our TC's recent momentum to the project level and find ways to
 increase delegation of responsibility.  Nova and Neutron, for example, have 
 had
 to face ever-increasing demands with the same small pool of core reviewers, 
 and
 many of you know all-too-well the pain that has resulted.  Core reviewers - 
 like
 the pre-big tent TC - have inadvertently become micromanagers as their
 responsibilities have evolved beyond their capacity to meet them.  The 

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 5:56 PM, David Lyle dkly...@gmail.com wrote:
 I'm announcing my candidacy for the Technical Committee elections.

 I have been contributing to OpenStack since Grizzly primarily in Horizon. I
 have also had the privilege to serve as Horizon PTL since Icehouse.

 Why I'm running:

 I believe there should be broader representation on the TC. We are growing
 the OpenStack ecosystem. Let's make sure horizontal teams and diverse parts
 of the ecosystem are represented more directly. I understand concerns of
 scaling were the reason for moving from the TC made up of all PTLs (I
 question that assertion), but the sacrifice so far has been diversity. I
 feel current TC members are exceptionally capable and take a broad
 viewpoint, but there are limits of how well that works. Let's represent
 broader swaths of our ecosystem in the technical leadership.

 I think growing the OpenStack ecosystem is fantastic. As a developer and the
 PTL of a project that tries to span across most of that ecosystem it also
 worries me a bit too. I think we need to focus on how the newer and older
 parts of our ecosystem work together. How do we manage all the horizontal
 needs this introduces without going to the extremes of just scaling existing
 horizontal efforts because that won't work. And pushing all horizontal work
 on the individual projects is not appropriate because that yields chaos.

 Finally, I believe the TC needs to be more active in guiding overall
 direction of OpenStack and problem resolution. I'm not suggesting a
 dictatorship of course. But let's set a direction, overall release goals for
 OpenStack and help enable and drive them.

 I'm really proud to be a part of the OpenStack developer community, but I
 think we're facing some real challenges. We need to address some primary
 issues or this community will struggle to remain the vibrant, supportive
 place it is now.

 Thank you,
 David


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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[David Lyle]

I'm announcing my candidacy for the Technical Committee elections.

I have been contributing to OpenStack since Grizzly primarily in Horizon. I
have also had the privilege to serve as Horizon PTL since Icehouse.

Why I'm running:

I believe there should be broader representation on the TC. We are growing
the OpenStack ecosystem. Let's make sure horizontal teams and diverse parts
of the ecosystem are represented more directly. I understand concerns of
scaling were the reason for moving from the TC made up of all PTLs (I
question that assertion), but the sacrifice so far has been diversity. I
feel current TC members are exceptionally capable and take a broad
viewpoint, but there are limits of how well that works. Let's represent
broader swaths of our ecosystem in the technical leadership.

I think growing the OpenStack ecosystem is fantastic. As a developer and
the PTL of a project that tries to span across most of that ecosystem it
also worries me a bit too. I think we need to focus on how the newer and
older parts of our ecosystem work together. How do we manage all the
horizontal needs this introduces without going to the extremes of just
scaling existing horizontal efforts because that won't work. And pushing
all horizontal work on the individual projects is not appropriate because
that yields chaos.

Finally, I believe the TC needs to be more active in guiding overall
direction of OpenStack and problem resolution. I'm not suggesting a
dictatorship of course. But let's set a direction, overall release goals
for OpenStack and help enable and drive them.

I'm really proud to be a part of the OpenStack developer community, but I
think we're facing some real challenges. We need to address some primary
issues or this community will struggle to remain the vibrant, supportive
place it is now.

Thank you,
David
__
OpenStack Development Mailing 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 candidacy

[Mark McClain]

All-

I'd like to announce my candidacy to continue serving on the Technical 
Committee.


Platform
—
OpenStack is a growing community comprised of many parts and we we must view 
ourselves as one unit. As a TC member, I will continue to place the interests 
of the larger community over those of those of individual projects.

There are several key areas I'd like to see the TC focus:

Development
  The Technical Committee should serve as a high level forum to facilitate 
defining cross project technical and procedural requirements. While many of our 
programs share commonalities, there are still too many differences in policies 
and technical decisions. The addition of cross project specifications is a step 
towards unifying the development process and design standards within our 
community.  As we accept more projects under the new governance model, the TC 
should work to facilitate developer mobility across projects by promoting best 
practices.  Increased mobility will strengthen our community as it helps to 
prevent silos. Reviews are an another area the TC should focus on during the 
upcoming cycle. The TC should review and work with projects to improve the 
contributor and reviewer experience when contributing to projects both big and 
small.

Cross Project Communication
  Our codebase has grown significantly over the years and a contributor must 
invest significant time to understand and follow every project; however many 
contributors have limited time must choose a subset of projects to direct their 
focus.  As a result, it becomes important to employ cross project communication 
to explain major technical decisions, share solutions to project challenges 
that might be widely applicable, and leverage our collective experience.  The 
TC should seek new ways to facilitate cross project communication that will 
enable the community to craft improvements to the interfaces between projects 
as there will be greater familiarity between across the boundary.

Unified Experience
  For OpenStack to be successful we must strive to provide a unified experience 
for both users and deployers. During the previous cycles we have made progress 
in this area, but there is still work to be completed. When visiting user 
groups, a common thread during discussion is the installation experience. The 
TC should identify common installation configurations and work with projects to 
optimize installation and upgrades.  Equally important is the users. The TC 
should work to promote and support projects such the OpenStack client and SDK 
which aim to provide users with tools that are well maintained, documented and 
easy to use. Our community has invested significant effort to improve this 
experience and this should remain a focus going forward.


About Me
——
I have served on the Technical Committee for last two years and I am a former 
PTL. Believing that OpenStack is a unified community, I have contributed code 
and reviews to many of our projects since Sent from my iPad

We have built a very special open community through the contributions of many.  
These contributions have powered our phenomenal growth and I'm excited about 
our future!

Thanks,
mark

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

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 1:13 PM, Armando M. arma...@gmail.com wrote:
 I would like to announce my candidacy for the OpenStack Technical Committee.

 I will try to be brief and to the point: I have been involved in OpenStack
 since the early days of the Austin release; I have worked on (perhaps) the
 two most prolific projects in OpenStack (Nova, and Neutron) and a few others
 aimed at ensuring their quality (Tempest, DevStack, and the infra ones). I
 have been mainly a developer, but also a deployer, distributor, user, tech
 writer, you name it.

 Under these points of views I have seen friction in dealing with OpenStack
 increase over time, and I want to do something about it. I have never run
 for the TC before, or any other position of 'influence'.  I came to the
 realization that doing something about it by being on the fringes could only
 get me so far.

 My main goal is to empower the developer, allowing him/her to go at the pace
 he/she is comfortable with, whilst preserving the quality of software being
 produced: I believe we have many bottlenecks and inefficiencies in the way
 we develop and consume OpenStack technologies. In Neutron I, with the help
 of others, have tried to identify these and proactively did something about
 it: decomposing the codebase in core vs plugins and moving away from the
 project reliance on Tempest to ensure stability are examples to name a few.

 At the same time decentralizing and increasing speed of development can
 impair coherence and cohesion of the overall solution and that is why I
 think a seat in the TC would give me enough exposure to help preserve, and
 strive to achieve these qualities in the software we build. The OpenStack
 ecosystem is incredibly diverse and yet we need each technology developed
 under its umbrella to share a lot more than the four Opens. The definition
 of shared methodologies, practices and guidelines can help us achieve that,
 but most importantly a shared roadmap that can let us peek into the future
 of OpenStack as a whole rather than a fragmented collection of services that
 work poorly together.

 Thanks for reading.

 Regards,
 Armando

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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[David Medberry]

Announcing my candidacy for the TC.

I would bring an operator's perspective (ie, operator, user, super-user and
dev) to the Technical Committee.

I've been involved in OpenStack for four years. I gave talks at San Diego,
Atlanta, Paris, and soon Vancouver as a contributor, community organizer,
and operator.

I would consent to serve a single term.

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

[Maish Saidel-Keesing]

I would like to announce my candidacy for the OpenStack Technical Committee

Many of you many not know me, because I am not a very active contributor.

First a bit about myself. I am a Platform Architect working for Cisco in 
Israel and have been involved with OpenStack for the past two years. I 
was and (and still am a very active member of the virtualization 
community [1] and have been for a good number of years.


I was honored to contribute and participate in the OpenStack 
Architecture Design Guide [2]. I am not new to writing but this was a 
new experience for me. One that I thoroughly enjoyed and would love to 
do again, if presented with the opportunity.


These are the following reasons I think I can make a difference as part 
of the TC


#1 Diversity

The vast majority of the TC members are all long standing and well known 
members of the OpenStack community. Many of them have been 
core-developers, PTL's, reviewers. All of them have one thing in common 
they are developers and people who take pride and joy in contributing 
code to the OpenStack projects.


I too have contributed code to the OpenStack projects - but not on the 
scale that any of the other candidates have. nowhere near close.

And I am not ashamed of that fact.
I am not a developer. Yes, I dabble in code (not as much as I would 
like), but I am deep down in my heart, an Operations guy.  I like to get 
things to work, but not only that they work, but that they are stable, 
robust, and will provide a sound infrastructure (so that I do not get 
paged at 03.00 every night because something fell over and died).
When all of the members of a committee are from a single 'stream' then 
it is natural to look at things in a certain way. But that is not the 
only way to look at things, there are other perspectives that need to be 
considered and that perspective (in my humble opinion) is missing.



#2 Focus

There has been a lengthy discussion over the past few months about what 
OpenStack is and what it is not. What should be part of OpenStack and 
again what should not. I cannot say that I fully agree with all the 
decisions that have been made, although I do fully agree with the 
direction in which OpenStack is going and how the TC has been driving that.


I feel that the as part of the TC I will help the community focus on 
building a tightly integrated suite of software (there is no way you can 
call OpenStack a product) that will work, and work well [3].



#3 Acceptance of others

It is no secret that i think that I have spoken my mind[4], more than 
once on how I find it extremely hard for someone who is not a developer 
to help and make OpenStack better. I have tried to lower that hurdle in 
a number of ways [5] to make it easier for 'non-dev's' to starting 
'chipping in'. But it seems that I was not successful. Even with regards 
to myself.


We are all members of the community. But there are several levels. Even 
in this election only ''Individual Members who committed a change to a 
repository under ’any’ of the official OpenStack Project Teams (as 
defined above) over the last two 6-month release cycles are 
automatically considered ATC'' and they are the only ones that can vote.


There are other ways to contribute.
People that report bugs contribute.
People that write blog posts contribute.
People that evangelize in User groups and speak at conferences, meetings 
etc. - they also contribute.


It is not all about code.
Yes it is hard to quantify. Yes it is hard to measure. But that does not 
mean it should not be considered.


If elected to serve as part of the TC - this is something I would like 
pursue - something that can make the OpenStack community not only a 
developer community - but a community of all those who care about it.


I would like to leave you with one last thought.
I thought long and hard about putting up myself as a candidate. I do 
think that I have a fresh perspective to bring to the table, a different 
way of looking at things and a lot of passion that can help OpenStack 
achieve what it set out to do.


``Our goal is to produce the ubiquitous Open Source cloud computing 
platform that will meet the needs of public and private cloud providers 
regardless of size, by being simple to implement and massively scalable.``


I would like to wish all the candidates the best of luck.

--
Best Regards, Maish Saidel-Keesing


[1] http://vsphere-land.com/news/top-vblog-2015-full-results.html
[2] 
http://technodrone.blogspot.com/2014/08/the-openstack-architecture-design-guide.html
[3] 
http://technodrone.blogspot.com/2014/08/to-innovate-or-to-stabilize-that-is.html
[4] 
http://technodrone.blogspot.com/2014/09/an-open-letter-to-openstack-foundation.html
[5] 
http://technodrone.blogspot.com/2014/11/start-contributing-to-openstack-easy.html



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

[openstack-dev] TC candidacy

[Armando M.]

I would like to announce my candidacy for the OpenStack Technical Committee.

I will try to be brief and to the point: I have been involved in OpenStack
since the early days of the Austin release; I have worked on (perhaps) the
two most prolific projects in OpenStack (Nova, and Neutron) and a few
others aimed at ensuring their quality (Tempest, DevStack, and the infra
ones). I have been mainly a developer, but also a deployer, distributor,
user, tech writer, you name it.

Under these points of views I have seen friction in dealing with OpenStack
increase over time, and I want to do something about it. I have never run
for the TC before, or any other position of 'influence'.  I came to the
realization that doing something about it by being on the fringes could
only get me so far.

My main goal is to empower the developer, allowing him/her to go at the
pace he/she is comfortable with, whilst preserving the quality of software
being produced: I believe we have many bottlenecks and inefficiencies in
the way we develop and consume OpenStack technologies. In Neutron I, with
the help of others, have tried to identify these and proactively did
something about it: decomposing the codebase in core vs plugins and moving
away from the project reliance on Tempest to ensure stability are examples
to name a few.

At the same time decentralizing and increasing speed of development can
impair coherence and cohesion of the overall solution and that is why I
think a seat in the TC would give me enough exposure to help preserve, and
strive to achieve these qualities in the software we build. The OpenStack
ecosystem is incredibly diverse and yet we need each technology developed
under its umbrella to share a lot more than the four Opens. The definition
of shared methodologies, practices and guidelines can help us achieve that,
but most importantly a shared roadmap that can let us peek into the future
of OpenStack as a whole rather than a fragmented collection of services
that work poorly together.

Thanks for reading.

Regards,
Armando
__
OpenStack Development Mailing 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 Candidacy

[James E. Blair]

Hi,

I'd like to announce my candidacy for re-election to the TC.

About Me


I am the PTL for the OpenStack Infrastructure Program, which I have
been helping to build for nearly four years.  I have also served on
the TC since the Icehouse cycle.

I am responsible for a significant portion of our project
infrastructure and developer workflow including setting up gerrit and
helping to write git-review.  All of that is to say that I've given a
lot of thought and action to helping scale OpenStack to the number of
projects and developers it has today.

I also wrote zuul, nodepool, and devstack-gate to make sure that we
are able to test that the different componensts of OpenStack work
together as a cohesive whole.  A good deal of my technical work is
focused on achieving that and ensuring that all of the projects that
make up OpenStack have the ability to test themselves in such a
complex system.

Throughout my time working on OpenStack I have always put the needs of
the whole project first, above those of any individual contributor,
organization, or program.  I also believe in the values we have
established as a project: open source, design, development, and
community.  To that end, I have worked hard to ensure that the project
infrastructure is run just like an OpenStack project, using the same
tools and processes, and I think we've succeeding in creating one of
the most open operational project infrastructures ever.

My Platform
===

I am very excited about the big tent.  The infrastructure team has
been involved in operating stackforge for some time, and so the big
tent idea seems like a natural progression to me.  We have a lot of
folks who are participating in our community and it is time that we
accept them in.  At the same time we can strengthen the core of our
project by acknowledging that there are a lot of components that can
be a part of OpenStack, but not all of them need to be deployed in
every installation.  And so the layered approach helps us make sense
of how a system should be constructed.

As part of the move into the big tent, all of the cross-project
efforts will need to change the way they operate to accomodate the
scale we are dealing with.  Most of that work is well underway, but
the TC itself will need to change as well.  Just as any other
horizontal effort, the TC will need to provide the tools and processes
for projects to be effective members of our community on their own.
Part of the motivation for adopting the big tent strategy is to get
the TC out of the business of doing detailed review of projects so
that it can provide technical leadership for OpenStack as a whole.

I believe we have made a great start on the work that is needed to
build the big tent.  There is still more work that needs to be done, I
would like to continue to help the TC evolve into its new role and so
I would appreciate your vote.

Thanks for your consideration,

Jim

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

[openstack-dev] TC candidacy

[Julien Danjou]

Hey fellow developers,

I'd like to announce my candidacy for the Technical Committee election
that's happening.


TL;DR: Vote for me to bring back the fun and raise the bar! :)


As you might know, I've been a member of the OpenStack community for
several years now, and I actually already seated at the TC, back when
PTL had a seat. I've been leading Ceilometer for a while, and I'm still
active in this project, as I recently started and pushed Gnocchi¹ in
OpenStack. I contribute also to Oslo and other OpenStack projects for a
very long time now.

Let's jump to the hot topics.

The TC decided to open the gates for what goes into OpenStack, and
that's great, as trying to control that was totally failing.
Now there's a work ongoing about classifying projects under tags, and
I've absolutely no idea why the TC should be responsible for this
ultimately. This really looks like something that could be built and
decided by the entire community. I don't think I want to spend too much
time on this anyway.

I think OpenStack has way too much bureaucracy. The whole project is
glued in tons of processes that slows everything down for little value.
I see people writing code that is refused because there's no spec, specs
not reviewed because there's no code, and people frustrated because they
have to wait 3 months to have a brain-dead one-liner fix to get merged.
While I recognized there are some upside to this processes, this has
gone too far and I want OpenStack to become more agile (there, I said
it).

I've pushed the idea recently in Gnocchi that the bar should be raised
about documentation. We've set the same rule for documentation that we
had for unit and functional testing: a patch with no documentation or no
unit tests or no functional tests is refused. This allowed us to build a
complete and (almost) properly documented and fully tested project from
scratch in less than a year. That's an idea I'd like to push further in
other OpenStack projects.

I hope and I think I'm continually striving to make OpenStack better as
a whole and I want to push that further in all projects so that we can
go faster to push our vision out.

It seems to me that the TC had a very small power so far to influence
the community and projects, though I hope we'll anyway be able to reach
out to the projects in an efficient way to communicate our ideas!


Happy hacking!


¹  http://launchpad.net/gnocchi

-- 
Julien Danjou
;; Free Software hacker
;; http://julien.danjou.info


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

Re: [openstack-dev] TC candidacy

[Tristan Cacqueray]

confirmed

On 04/22/2015 05:26 AM, Julien Danjou wrote:
 Hey fellow developers,
 
 I'd like to announce my candidacy for the Technical Committee election
 that's happening.
 
 
 TL;DR: Vote for me to bring back the fun and raise the bar! :)
 
 
 As you might know, I've been a member of the OpenStack community for
 several years now, and I actually already seated at the TC, back when
 PTL had a seat. I've been leading Ceilometer for a while, and I'm still
 active in this project, as I recently started and pushed Gnocchi¹ in
 OpenStack. I contribute also to Oslo and other OpenStack projects for a
 very long time now.
 
 Let's jump to the hot topics.
 
 The TC decided to open the gates for what goes into OpenStack, and
 that's great, as trying to control that was totally failing.
 Now there's a work ongoing about classifying projects under tags, and
 I've absolutely no idea why the TC should be responsible for this
 ultimately. This really looks like something that could be built and
 decided by the entire community. I don't think I want to spend too much
 time on this anyway.
 
 I think OpenStack has way too much bureaucracy. The whole project is
 glued in tons of processes that slows everything down for little value.
 I see people writing code that is refused because there's no spec, specs
 not reviewed because there's no code, and people frustrated because they
 have to wait 3 months to have a brain-dead one-liner fix to get merged.
 While I recognized there are some upside to this processes, this has
 gone too far and I want OpenStack to become more agile (there, I said
 it).
 
 I've pushed the idea recently in Gnocchi that the bar should be raised
 about documentation. We've set the same rule for documentation that we
 had for unit and functional testing: a patch with no documentation or no
 unit tests or no functional tests is refused. This allowed us to build a
 complete and (almost) properly documented and fully tested project from
 scratch in less than a year. That's an idea I'd like to push further in
 other OpenStack projects.
 
 I hope and I think I'm continually striving to make OpenStack better as
 a whole and I want to push that further in all projects so that we can
 go faster to push our vision out.
 
 It seems to me that the TC had a very small power so far to influence
 the community and projects, though I hope we'll anyway be able to reach
 out to the projects in an efficient way to communicate our ideas!
 
 
 Happy hacking!
 
 
 ¹  http://launchpad.net/gnocchi
 
 
 
 __
 OpenStack Development Mailing 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

[Tristan Cacqueray]

confirmed

On 04/22/2015 03:52 AM, James E. Blair wrote:
 Hi,
 
 I'd like to announce my candidacy for re-election to the TC.
 
 About Me
 
 
 I am the PTL for the OpenStack Infrastructure Program, which I have
 been helping to build for nearly four years.  I have also served on
 the TC since the Icehouse cycle.
 
 I am responsible for a significant portion of our project
 infrastructure and developer workflow including setting up gerrit and
 helping to write git-review.  All of that is to say that I've given a
 lot of thought and action to helping scale OpenStack to the number of
 projects and developers it has today.
 
 I also wrote zuul, nodepool, and devstack-gate to make sure that we
 are able to test that the different componensts of OpenStack work
 together as a cohesive whole.  A good deal of my technical work is
 focused on achieving that and ensuring that all of the projects that
 make up OpenStack have the ability to test themselves in such a
 complex system.
 
 Throughout my time working on OpenStack I have always put the needs of
 the whole project first, above those of any individual contributor,
 organization, or program.  I also believe in the values we have
 established as a project: open source, design, development, and
 community.  To that end, I have worked hard to ensure that the project
 infrastructure is run just like an OpenStack project, using the same
 tools and processes, and I think we've succeeding in creating one of
 the most open operational project infrastructures ever.
 
 My Platform
 ===
 
 I am very excited about the big tent.  The infrastructure team has
 been involved in operating stackforge for some time, and so the big
 tent idea seems like a natural progression to me.  We have a lot of
 folks who are participating in our community and it is time that we
 accept them in.  At the same time we can strengthen the core of our
 project by acknowledging that there are a lot of components that can
 be a part of OpenStack, but not all of them need to be deployed in
 every installation.  And so the layered approach helps us make sense
 of how a system should be constructed.
 
 As part of the move into the big tent, all of the cross-project
 efforts will need to change the way they operate to accomodate the
 scale we are dealing with.  Most of that work is well underway, but
 the TC itself will need to change as well.  Just as any other
 horizontal effort, the TC will need to provide the tools and processes
 for projects to be effective members of our community on their own.
 Part of the motivation for adopting the big tent strategy is to get
 the TC out of the business of doing detailed review of projects so
 that it can provide technical leadership for OpenStack as a whole.
 
 I believe we have made a great start on the work that is needed to
 build the big tent.  There is still more work that needs to be done, I
 would like to continue to help the TC evolve into its new role and so
 I would appreciate your vote.
 
 Thanks for your consideration,
 
 Jim
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 




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

[openstack-dev] TC Candidacy

[Ed Leafe]

Greetings Stackers!

I'm announcing my candidacy for the Technical Comitee Elections.

Those of you who have been around OpenStack for a while know me, as I was one 
of the original developers involved since the inception of OpenStack back in 
2010, when I worked for Rackspace's Cloud Server team. I was a contributor and 
core reviewer for Nova until a job change at Rackspace removed me from direct 
OpenStack development around the Essex release. I was still peripherally 
involved, though, as my work as a Developer Advocate involved creating the 
first Python SDK for OpenStack [0], which gave me a great education on how 
frustrating inconsistent APIs can be! In order to help improve the experience 
of developers building apps with OpenStack, I wholeheartedly support the 
efforts of the API Working Group to reduce this problem in the future.

[0] https://github.com/rackspace/pyrax

Fast-forward to last September, when I joined IBM with one mandate: work 
full-time on OpenStack by contributing as much as possible to upstream 
OpenStack, and becoming involved in the community. Since then I've re-immersed 
myself in Nova, focusing mainly on the effort to clean up the Scheduler 
interfaces. So I believe that this history gives me a unique perspective on 
OpenStack development: where it came from, and where it needs to go to move 
forward.

I mentioned improving the experience of developers working *with* OpenStack; 
I'd also like to improve the experience of developers working *on* OpenStack. 
To that end, I agree wholeheartedly with Thierry's call to step out of the 
way [1]. There is a lot of energy across the many projects, and the TC should 
do everything it can to help make that energy effective without stifling it. I 
spoke about the potential for OpenStack to change the world in an interview I 
gave for Rackspace last year [2], and the last thing I would want to see is 
someone with an idea get discouraged because there were too many hoops to jump 
through to make it happen on OpenStack.

[1] http://ttx.re/stepping-out-of-the-way.html
[2] https://youtu.be/0QRkzMW3OdA?t=115

One place, though, where I think the TC can inject itself is to help alleviate 
the lack of core reviewers, particularly in Nova, which I discussed in [3]. 
Having so few cores for the number of patches being created is simply not 
sustainable, and just wishing for things to get better isn't cutting it. And I 
do consider it a technical problem, since the main barrier isn't lack of 
interested people; it's that it's currently too difficult for most people to 
learn enough about all the various parts of the project necessary to achieve 
core status.

[3] http://blog.leafe.com/the-core-deficiency

I sort of wish that there was the questionnaire format like we had in the last 
TC election, so I could be sure to give everyone a clear view on where I see 
things on different issues. If you have any such concerns, please feel free to 
respond to this email (and to those of the other candidates!), and I will be 
happy to answer any questions.

Thanks for your consideration,

-- Ed Leafe







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

Re: [openstack-dev] TC Candidacy

[Tristan Cacqueray]

confirmed

On 04/21/2015 04:47 AM, Flavio Percoco wrote:
 Greetings,
 
 I'm announcing my candidacy for the Technical Comitee Elections.
 
 I wish I could say I've served as a TC member before but I haven't.
 However, there's always a first time for everything, isn't there? I'd
 like for Liberty to be that chance for me to be honored with a seat in
 OpenStack's Technical Comitee.
 
 I believe I've been part of OpenStack's community long enough to know
 how it works, the mechanisms behind it and I believe I have a good
 feeling of where it should be headed. Here are some things that I'd
 love to help achieving as part of my work as a TC member:
 
 # Paradise's doors have been opened but no maps of it have been drawn:
 
 During the last cycles, the TC members have done an amazing job on
 helping make our community more welcoming. The bar for inclusion has
 be lowered to the point where projects are welcomed to join it as long
 as they meet the minimum requirements established in our governance
 repo.
 
 I believe this is an amazing step for our community but we're not
 there yet. Unfortunately, opening our doors does not do the trick. In
 order to keep this openness honest, we also need to provide a better
 support for the projects that are joining our community.
 
 Therefore, I'd like to help moving the big tent effort forward and
 start laying down the bases that will help providing support to
 projects and guide them especially in moments where decisions like
 this[0] need to be taken.
 
 [0]
 http://lists.openstack.org/pipermail/openstack-dev/2015-April/061967.html
 
 # Help with clearing the path where OpenStack is headed
 
 For better or for worse, one of the question I've been asked more
 often, in the last couple of months, is: Is OpenStack there yet?
 What's next?
 
 OpenStack is a cloud provider and as such it should strive to cover
 enough use-cases to make cloud consumers'/providers' lives simpler.
 There's more to a cloud than just compute, storage and networking.
 There's more to cloud than just orchestration and meetering. As part
 of my role as a TC member, I'd like to help our community grow in
 other areas that might not be considered required but that are still
 important for our mission.
 
 # Deployments / Ops
 
 OpenStack has come a long way on making deployments easier but again,
 we're not there yet. With the new governance model, we won't just see
 new *aaS services joining but also new tools[0] that are meant to help
 with OpenStack's installation and maintenance.
 
 Along the lines of what I said in my point #2, I believe having tools
 to install OpenStack is great but there's more to an OpenStack
 deployment than just that. There's monitoring, upgrades, migrations,
 etc.
 
 As part of my journey as a TC member (hopefully), I'd like to help
 these projects by exploring and gathering the needs and feedback from
 our community so we can guide these amazing efforts towards the right
 solution that OpenStack needs.
 
 I believe OpenStack is taking giant steps towards a great success but
 we need to be careful not to skip important things in between those
 steps. I'd like to use my knowledge from my involvement in several
 areas throughout OpenStack (and outside it) to help OpenStack moving
 forward at the same - or at a better - pace.
 
 Thanks for your consideration,
 Flavio
 
 P.S: If you're thinking. Wait, this guy is nuts. He ran for 2 PTL
 positions and he now wants to run for a TC position. Is he crazy? One
 answer to that could be, Yes. However, just to make sure it's clear to
 everyone my current time situation, I'd like to share that I'm
 just Zaqar's PTL - Nikhil is Glance's PTL - and my current
 commitments allow me for dedicating to this position the time it
 requires.
 
 
 
 __
 OpenStack Development Mailing 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

[openstack-dev] TC Candidacy

[Flavio Percoco]

Greetings,

I'm announcing my candidacy for the Technical Comitee Elections.

I wish I could say I've served as a TC member before but I haven't.
However, there's always a first time for everything, isn't there? I'd
like for Liberty to be that chance for me to be honored with a seat in
OpenStack's Technical Comitee.

I believe I've been part of OpenStack's community long enough to know
how it works, the mechanisms behind it and I believe I have a good
feeling of where it should be headed. Here are some things that I'd
love to help achieving as part of my work as a TC member:

# Paradise's doors have been opened but no maps of it have been drawn:

During the last cycles, the TC members have done an amazing job on
helping make our community more welcoming. The bar for inclusion has
be lowered to the point where projects are welcomed to join it as long
as they meet the minimum requirements established in our governance
repo.

I believe this is an amazing step for our community but we're not
there yet. Unfortunately, opening our doors does not do the trick. In
order to keep this openness honest, we also need to provide a better
support for the projects that are joining our community.

Therefore, I'd like to help moving the big tent effort forward and
start laying down the bases that will help providing support to
projects and guide them especially in moments where decisions like
this[0] need to be taken.

[0] http://lists.openstack.org/pipermail/openstack-dev/2015-April/061967.html

# Help with clearing the path where OpenStack is headed

For better or for worse, one of the question I've been asked more
often, in the last couple of months, is: Is OpenStack there yet?
What's next?

OpenStack is a cloud provider and as such it should strive to cover
enough use-cases to make cloud consumers'/providers' lives simpler.
There's more to a cloud than just compute, storage and networking.
There's more to cloud than just orchestration and meetering. As part
of my role as a TC member, I'd like to help our community grow in
other areas that might not be considered required but that are still
important for our mission.

# Deployments / Ops

OpenStack has come a long way on making deployments easier but again,
we're not there yet. With the new governance model, we won't just see
new *aaS services joining but also new tools[0] that are meant to help
with OpenStack's installation and maintenance.

Along the lines of what I said in my point #2, I believe having tools
to install OpenStack is great but there's more to an OpenStack
deployment than just that. There's monitoring, upgrades, migrations,
etc.

As part of my journey as a TC member (hopefully), I'd like to help
these projects by exploring and gathering the needs and feedback from
our community so we can guide these amazing efforts towards the right
solution that OpenStack needs.

I believe OpenStack is taking giant steps towards a great success but
we need to be careful not to skip important things in between those
steps. I'd like to use my knowledge from my involvement in several
areas throughout OpenStack (and outside it) to help OpenStack moving
forward at the same - or at a better - pace.

Thanks for your consideration,
Flavio

P.S: If you're thinking. Wait, this guy is nuts. He ran for 2 PTL
positions and he now wants to run for a TC position. Is he crazy? One
answer to that could be, Yes. However, just to make sure it's clear to
everyone my current time situation, I'd like to share that I'm
just Zaqar's PTL - Nikhil is Glance's PTL - and my current
commitments allow me for dedicating to this position the time it
requires.

--
@flaper87
Flavio Percoco


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

[openstack-dev] TC candidacy

[Angus Salkeld]

I'd like to announce my candidacy for the Technical Committee elections.


This last (Kilo) cycle I have been the PTL for Heat, but will not be for
Liberty.

Because of this, if I get elected to the TC, I can dedicate a significant
amount of time to TC duties.

I have an interest in projects that exist in the upper layers in OpenStack
(Heat, Murano, Mistral, Ceilometer/Monasca, Zaqar), so this gives me a
slightly different viewpoint than the existing TC members (I hope this will
be complementary).


Topics that I am interested in pursuing:


1. How can the TC/PTL's better influence what developers work on?

We currently have working groups and project tags, but are there other ways
that we can encourage developers to work on global issues that users and
operators are asking for?

So if the TC came up with say 2 global themes every cycle, let's say
ease of upgrades and scale, what can we use as a carrot to encourage a
developer to work on these topics rather than something else. Clearly this
has limits, but if the user survey is screaming we need X, it would be
great to have a tool to help focus developers onto this.

One idea might be to use stackalytics main page to show the work done on TC
selected blueprints/bugs. We could tag particular blueprints/bugs and
highlight the developers that have worked on these (i.e. can we use
stackalytics as a tool to motivate developers to work on
TC supported themes).

A note on this (some motivation for taking advantage of stackalytics):
It looks like this commit changed the default view on stackalytics from
commits to reviews
https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c
(14 Apr 2014)
http://stackalytics.com/?release=allmetric=commits
http://stackalytics.com/?release=all

See the sudden plateau of commits and increase in reviews after that time
on the top graph (I am sure there are other factors at play too).


2. How can we better support new foundational projects that we expect other
projects to consume.

Under the new big tent model, we are welcoming more projects into the
openstack/ code namespace while simultaneously shifting the determination
of production-worthiness to distributors and operators. This poses a
problem for projects like Zaqar, Mistral, and even Heat, as these projects
may be consumed/used by other upper-layer projects. Consuming projects end
up with lots of conditional code as they must take into account that the
deployed cloud may not have these dependent projects installed.

How can we make the end user (and inter-project) experience richer and
friendlier with a consistent method of negotiating and discovering the
underlying features a deployed cloud offers?

Could tenant-based services/endpoints be helpful in allowing end users to
install optional projects?


3. Getting notification messages to the end user.

Based on this:
http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html

Other clouds provide better messaging feedback on what the infrastructure
is doing. We are really missing this and I'd like to help to get us to the
point where the user (that doesn't have access to the logs) can understand
what has happened to their resources.


I'm interested in either leading or participating in working groups from
within the TC to address these issues.


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

[Elizabeth K. Joseph]

confirmed


On Tue, Apr 21, 2015 at 5:29 PM, Jay Pipes jaypi...@gmail.com wrote:
 Hey Stackers,

 I'd like to continue serving on the Technical Committee, and I'm asking for
 your votes in the upcoming elections.

 Here's my ask of you, dear voter:

 #1.

 Please do NOT vote for me just because you may recognize my name being
 around the OpenStack community for a long time. Being a long-time member of
 something does not make me any more able to offer creative solutions to our
 problems than someone who's been in our community for a year or so.

 #2.

 Please do NOT vote for me just because I'm currently on the Technical
 Committee and have served on the TC in the past. There is no carry-over
 power that someone that has served on the TC in the past brings with them to
 bear on future TCs. Ideas and a person's ability to debate the issues fairly
 and concisely are what determines the effectiveness of a TC member, not the
 length of time they have served on the TC.

 #3.

 Please do NOT vote for me because you think I am (often unduly) outspoken or
 critical about certain particular issues that you find dear. Even if you
 hate XML as much as I do or would love to see API extensions die in a fire,
 you shouldn't vote for me just because you happen to agree with me on those
 particulars. The TC is not about squabbling and religious wars. It's about
 BIG ideas and listening to the viewpoints of others and seeing how the
 OpenStack contributor ecosystem can be shaped by those ideas in meaningful
 ways.

 #4.

 Please DO vote for me because you think I will fairly consider the
 viewpoints of the other TC members -- whomever they happen to be.

 #5.

 Please DO vote for me because you think I will be diligent in gathering the
 feedback of our disparate and excellent contributor teams, and critically,
 use that feedback to make our OpenStack community better for us all.

 #6.

 Please DO vote for me if you believe I will be an advocate for OpenStack's
 contributor community in the broader open source ecosystem, and continue to
 further the ideals of our four Opens [1].

 Thanks much,
 -jay

 [1] https://wiki.openstack.org/wiki/Open

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



-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[Robert Collins]

Hello everybody, I'm announcing my candidacy for the TC.

I loved Jay's list of reasons [not ]to vote for him - and I'd like you
to apply those to me too :).
[http://lists.openstack.org/pipermail/openstack-dev/2015-April/062234.html]

I think OpenStack is facing several key challenges at the moment.

We've scaled our community but progress on scaling individual projects
is slower. This is a complicated, thorny project, with many
contributing factors. Everything from the basic primitives we make
consistently available (such as exposing notifications to API clients,
or what our RPC layer can do) through social factors (who can review,
what reviews are for) and the sheer technical complexity involved in
our CI system. The IT world hasn't slowed down since OpenStack was
founded, and there is more and more need for us to move fast and
execute well on the desires of our contributors - because those
desires are driven by a need to solve real problems they [or their
users/customers] are facing.

Our product (OpenStack) is becoming balkanized. Operations that should
be easy and consistent across many clouds are not, and it is becoming
harder. Again there are many contributing factors: each service has
its own domain with gnarly backends, different things that are slow or
fast or flaky, and a different group of engineers discussing what the
API should look like, how it should behave, and what is or isn't in
scope. OpenStackClient as a consistent Python API to such things is a
good step, but the heart of the problem lies in how we're defining the
interface users use. We need to find some way to bring together the
folk building the individual services to provide a consistent
experience for users. Our APIs need to be predictable, simple and easy
to work with.

And these join together to form the third challenge: delivering on our
vision: to produce the ubiquitous Open Source Cloud Computing
platform that will meet the needs of public and private clouds
regardless of size, by being simple to implement and massively
scalable''. Thierry put it well when he said we had been caught in the
middle tier - neither very small nor very large clouds are a good fit
for OpenStack. We're failing many potential users because of this.

Last time I was on the TC I felt I helped OpenStack, but I did not run
for re-election because I knew I had not helped as much as I could,
and I wanted to avoid trying to eek out enough time to do so. My lack
of time was due to being a PTL at the same time. I am not a PTL - and
won't run for PTL in any project if I'm on the TC; I no longer believe
there is enough time in a week to do justice to both the PTL and TC
offices. If elected I'll be able to devote the majority of my time to
the TC and related issues - making me much more effective - so I can
help shift the dial on all the challenges we face.

-Rob


-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

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

Re: [openstack-dev] TC candidacy

[Elizabeth K. Joseph]

confirmed


On Tue, Apr 21, 2015 at 4:02 PM, Angus Salkeld asalk...@mirantis.com wrote:
 I'd like to announce my candidacy for the Technical Committee elections.


 This last (Kilo) cycle I have been the PTL for Heat, but will not be for
 Liberty.

 Because of this, if I get elected to the TC, I can dedicate a significant
 amount of time to TC duties.

 I have an interest in projects that exist in the upper layers in OpenStack
 (Heat, Murano, Mistral, Ceilometer/Monasca, Zaqar), so this gives me a
 slightly different viewpoint than the existing TC members (I hope this will
 be complementary).


 Topics that I am interested in pursuing:


 1. How can the TC/PTL's better influence what developers work on?

 We currently have working groups and project tags, but are there other ways
 that we can encourage developers to work on global issues that users and
 operators are asking for?

 So if the TC came up with say 2 global themes every cycle, let's say ease
 of upgrades and scale, what can we use as a carrot to encourage a
 developer to work on these topics rather than something else. Clearly this
 has limits, but if the user survey is screaming we need X, it would be
 great to have a tool to help focus developers onto this.

 One idea might be to use stackalytics main page to show the work done on TC
 selected blueprints/bugs. We could tag particular blueprints/bugs and
 highlight the developers that have worked on these (i.e. can we use
 stackalytics as a tool to motivate developers to work on
 TC supported themes).

 A note on this (some motivation for taking advantage of stackalytics):
 It looks like this commit changed the default view on stackalytics from
 commits to reviews
 https://github.com/stackforge/stackalytics/commit/eb3bebbaa66a718e284d3095dfa8f496bb1d298c
 (14 Apr 2014)
 http://stackalytics.com/?release=allmetric=commits
 http://stackalytics.com/?release=all

 See the sudden plateau of commits and increase in reviews after that time on
 the top graph (I am sure there are other factors at play too).


 2. How can we better support new foundational projects that we expect other
 projects to consume.

 Under the new big tent model, we are welcoming more projects into the
 openstack/ code namespace while simultaneously shifting the determination of
 production-worthiness to distributors and operators. This poses a problem
 for projects like Zaqar, Mistral, and even Heat, as these projects may be
 consumed/used by other upper-layer projects. Consuming projects end up with
 lots of conditional code as they must take into account that the deployed
 cloud may not have these dependent projects installed.

 How can we make the end user (and inter-project) experience richer and
 friendlier with a consistent method of negotiating and discovering the
 underlying features a deployed cloud offers?

 Could tenant-based services/endpoints be helpful in allowing end users to
 install optional projects?


 3. Getting notification messages to the end user.

 Based on this:
 http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html

 Other clouds provide better messaging feedback on what the infrastructure is
 doing. We are really missing this and I'd like to help to get us to the
 point where the user (that doesn't have access to the logs) can understand
 what has happened to their resources.


 I'm interested in either leading or participating in working groups from
 within the TC to address these issues.


 Thanks
 Angus Salkeld

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




-- 
Elizabeth Krumbach Joseph || Lyz || pleia2

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

[Jay Pipes]

Hey Stackers,

I'd like to continue serving on the Technical Committee, and I'm asking 
for your votes in the upcoming elections.


Here's my ask of you, dear voter:

#1.

Please do NOT vote for me just because you may recognize my name being 
around the OpenStack community for a long time. Being a long-time member 
of something does not make me any more able to offer creative solutions 
to our problems than someone who's been in our community for a year or so.


#2.

Please do NOT vote for me just because I'm currently on the Technical 
Committee and have served on the TC in the past. There is no 
carry-over power that someone that has served on the TC in the past 
brings with them to bear on future TCs. Ideas and a person's ability to 
debate the issues fairly and concisely are what determines the 
effectiveness of a TC member, not the length of time they have served on 
the TC.


#3.

Please do NOT vote for me because you think I am (often unduly) 
outspoken or critical about certain particular issues that you find 
dear. Even if you hate XML as much as I do or would love to see API 
extensions die in a fire, you shouldn't vote for me just because you 
happen to agree with me on those particulars. The TC is not about 
squabbling and religious wars. It's about BIG ideas and listening to the 
viewpoints of others and seeing how the OpenStack contributor ecosystem 
can be shaped by those ideas in meaningful ways.


#4.

Please DO vote for me because you think I will fairly consider the 
viewpoints of the other TC members -- whomever they happen to be.


#5.

Please DO vote for me because you think I will be diligent in gathering 
the feedback of our disparate and excellent contributor teams, and 
critically, use that feedback to make our OpenStack community better for 
us all.


#6.

Please DO vote for me if you believe I will be an advocate for 
OpenStack's contributor community in the broader open source ecosystem, 
and continue to further the ideals of our four Opens [1].


Thanks much,
-jay

[1] https://wiki.openstack.org/wiki/Open

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

[Tristan Cacqueray]

confirmed

On 04/20/2015 05:56 AM, Thierry Carrez wrote:
 Hello list,
 
 I'm announcing my candidacy for the Technical Committee elections.
 
 I have been serving as the chair of the Technical Committee since its
 inception, but I think we are at a critical point in the evolution of
 the role of the Technical Committee, and if you allow it, I'd like to be
 around to help drive us through this transition.
 
 In particular, I'd like the Technical Committee to push in 3 new
 directions during the Liberty cycle:
 
 
 1. Step out of the way
 
 As I explained on [1], I think over the last cycles the TC pushed the
 regulation and ask for permission cursor so far we actually start
 preventing things from happening. I'd like us to come back to a point
 where our community is more trusted by default, where it asks more for
 forgiveness and less for permission. So I'd like the Technical Committee
 to look into its processes and see where it can remove itself from the
 action pipeline, and retreat back to being an appeals board should a
 problem arise.
 
 [1] http://ttx.re/stepping-out-of-the-way.html
 
 
 2. Start addressing real issues
 
 I think it is part of the role of the Technical Committee members to
 detect, investigate and help solving issues in our development
 community. As we grow, we can't expect every member to know everything
 about every project in OpenStack. But each member should be able to dive
 into specific project(s) and report issues to the group. Subgroups of
 members should be able to work together on proposing plans to solve
 long-standing issues. That means spending more than one hour per week on
 TC matters, which is why I'd like us to give preference in TC elections
 to candidates who have enough time on their hands, as explained on [2].
 
 [2] http://ttx.re/tech-committee-candidates.html
 
 
 3. Push toward both ends of the scale space
 
 Taking a step back on those last 5 years, I think the natural forces
 behind OpenStack development made us cover the middle-tier of usage
 quite well: reasonably large private IaaS systems (~10k VMs) with a need
 for extra features and accepting the resulting complexity. They did not
 make us cover the hyper-scale end (public clouds with millions of VMs in
 a very active usage pattern) that well, because that end
 is a specific use case that needs specific trade-offs, and not so many
 users need/push those. And it did not make us cover the basic system
 end, where people want to deploy a base IaaS compute system without
 bells and whistles, and without a team of 100 admins, most of them SDN
 specialists.
 
 Our development ecosystem won't naturally go and cover those use cases
 (lack of business and/or market), but those are essential long-term. We
 all need extremely-large OpenStack public clouds to burst hybrid
 workloads to. And we all need people to be able to experiment with
 OpenStack in POCs, labs and universities. This is the two directions I
 want to encourage in the near future.
 
 
 More generally, I think it is the role of the Technical Committee
 members to provide a long-term vision. To influence where we are going,
 beyond where the market forces push us. To inspire our developers to
 work (or support work) to cover areas that their employer might not
 immediately care about in the short term. To make OpenStack better and
 more universal in the long run.
 
 Thanks for your consideration,
 




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

[openstack-dev] TC candidacy

[Thierry Carrez]

Hello list,

I'm announcing my candidacy for the Technical Committee elections.

I have been serving as the chair of the Technical Committee since its
inception, but I think we are at a critical point in the evolution of
the role of the Technical Committee, and if you allow it, I'd like to be
around to help drive us through this transition.

In particular, I'd like the Technical Committee to push in 3 new
directions during the Liberty cycle:


1. Step out of the way

As I explained on [1], I think over the last cycles the TC pushed the
regulation and ask for permission cursor so far we actually start
preventing things from happening. I'd like us to come back to a point
where our community is more trusted by default, where it asks more for
forgiveness and less for permission. So I'd like the Technical Committee
to look into its processes and see where it can remove itself from the
action pipeline, and retreat back to being an appeals board should a
problem arise.

[1] http://ttx.re/stepping-out-of-the-way.html


2. Start addressing real issues

I think it is part of the role of the Technical Committee members to
detect, investigate and help solving issues in our development
community. As we grow, we can't expect every member to know everything
about every project in OpenStack. But each member should be able to dive
into specific project(s) and report issues to the group. Subgroups of
members should be able to work together on proposing plans to solve
long-standing issues. That means spending more than one hour per week on
TC matters, which is why I'd like us to give preference in TC elections
to candidates who have enough time on their hands, as explained on [2].

[2] http://ttx.re/tech-committee-candidates.html


3. Push toward both ends of the scale space

Taking a step back on those last 5 years, I think the natural forces
behind OpenStack development made us cover the middle-tier of usage
quite well: reasonably large private IaaS systems (~10k VMs) with a need
for extra features and accepting the resulting complexity. They did not
make us cover the hyper-scale end (public clouds with millions of VMs in
a very active usage pattern) that well, because that end
is a specific use case that needs specific trade-offs, and not so many
users need/push those. And it did not make us cover the basic system
end, where people want to deploy a base IaaS compute system without
bells and whistles, and without a team of 100 admins, most of them SDN
specialists.

Our development ecosystem won't naturally go and cover those use cases
(lack of business and/or market), but those are essential long-term. We
all need extremely-large OpenStack public clouds to burst hybrid
workloads to. And we all need people to be able to experiment with
OpenStack in POCs, labs and universities. This is the two directions I
want to encourage in the near future.


More generally, I think it is the role of the Technical Committee
members to provide a long-term vision. To influence where we are going,
beyond where the market forces push us. To inspire our developers to
work (or support work) to cover areas that their employer might not
immediately care about in the short term. To make OpenStack better and
more universal in the long run.

Thanks for your consideration,

-- 
Thierry Carrez (ttx)

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

Re: [openstack-dev] TC Candidacy

[Anita Kuno]

confirmed

On 10/10/2014 01:52 AM, David Lyle wrote:
 I would like to announce my candidacy for the Technical Committee.
 
 I have been working on OpenStack since the beginning of the Grizzly cycle.
 I started working on OpenStack as part of HP's Public Cloud effort. I spent
 two years working to make Horizon work in that scale of environment and
 making Horizon the user facing interface of HP's Public Cloud. I have
 served as a Horizon core reviewer since the Havana cycle and I am starting
 my third release as Horizon PTL. Currently, I am employed by Intel in their
 Open Source Technology Center.
 
 I have been a regular observer of the Technical Committee during my time as
 PTL. The role of the TC is large and difficult. I appreciate the efforts of
 all those that have served during that time and I would like to thank them
 for their dedication. One takeaway from those observations in the very
 heavy representation on the TC by infrastructure and core services. I think
 the TC would be benefit from more representation higher up the stack. I
 think Heat, Horizon, Solum, TripleO have a unique perspective into
 cross-project issues and the TC would benefit from such representation.
 
 In my opinion, the fundamental problems the TC needs to address in the Kilo
 cycle are handling growth and cross-project alignment. I'll be honest, I
 don't have a master plan to address these, but I think I'm well equipped
 and motivated to help develop that plan with other members of the TC.
 
 Thanks for your consideration,
 David Lyle
 
 
 Topic: OpenStack Mission: How do you feel the technical community is doing
 in meeting the OpenStack Mission?
 
 
 To produce the ubiquitous OpenSource Cloud Computing platform that will
 meet the needs of public and private clouds regardless of size, by being
 simple to implement and massively scalable.
 
 I think this is a very broad mission. Breadth is not a problem, but there
 are a few implications in here. One OpenStack needs to be inclusive, to
 accomplish ubiquity we need to strive to allow deployers to meet their
 widely varied needs. So we need to support a large ecosystem. The ecosystem
 around OpenStack is certainly large, but there is a fairly sharp dichotomy
 between OpenStack and not OpenStack, recognizing larger parts of the
 ecosystem is important for ecosystem health. As to public vs private and
 massively scalable aspects, I think we have room for growth. Running a
 public cloud on OpenStack requires not insignificant changes, and OpenStack
 has room for improvement on the scalability front. We need greater feedback
 from the very large deployers to make sure we meet those scalability needs.
 
 Topic: Technical Committee Mission: How do you feel the technical committee
 is doing in meeting the technical committee mission?
 
 
 The Technical Committee (TC) is tasked with providing the technical
 leadership for OpenStack as a whole (all official programs, as defined
 below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
 Integration, Quality...), decides on issues affecting multiple programs,
 forms an ultimate appeals board for technical decisions, and generally has
 oversight over all the OpenStack project.
 
 The technical committee has spent much of the last cycle acting as gate
 keeper. I would like to see it take a larger role in overall architectural
 direction in OpenStack. I believe one of the greatest challenges we face is
 coherency of vision and direction. I think this should be the province of
 the technical committee to act as an arbitrar and architectural board. I
 don't hold that overall technical direction is to be dictated by the TC,
 rather the TC merely helps unify that direction and insures consistency.
 Obviously this is a herculean task, but I believe OpenStack needs more
 clearness in direction.
 
 Topic: Contributor Motivation: How would you characterize the various
 facets of contributor motivation?
 
 
 Contributors are motivated to contribute for various reasons. People
 contribute for personal interest, corporate interest, academic interest,
 and any mix of all three. Corporate interest covers a lot, from users to
 operators, vendors to consumers. Many ideas from our great community of
 diverse contributors helps drive us forward and keeps us honest and
 progressing.
 
 At the end of the day, OpenStack is cloud software that should be usable.
 We do need to temper the wouldn't it be neat if, with how will this work in
 real world application ranging from small test clouds to large public
 clouds. Services should strive 

[openstack-dev] TC Candidacy

[John Garbutt]

Hi,

I would like to run for a seat on the Technical Committee, to help
serve the whole OpenStack community during this time of change.

I am employed by Rackspace, working on their public cloud. I am
currently focus mostly on Nova. I am nova-core, and currently nova's
blueprint czar. I am johnthetubaguy on IRC.

I started contributing to OpenStack, working as a researcher at Citrix
in December 2010. I helped create Citrix's Project Olympus packaging
of OpenStack (nova, swift and glance). After a change in strategy I
started working more on making OpenStack work with XenServer, setting
up one of the first Nova sub groups. After my move to Rackspace in
February 2013, I was able to work on all parts of Nova, and quickly
got more involved with a wider range of upstream activities.

I find the work of building a consensus really rewarding. I don't
claim to have all the answers, but I know we need change, so we can
scale out the community, while at the same time we preserving the true
nature of this awesome community.


** Topic: OpenStack Mission
** How do you feel the technical community is doing in meeting the
OpenStack Mission?

Its a bold mission, and I think it is still the right one.

serve developers, users, and the entire ecosystem
I think we need to be better at the serving the entire ecosystem.

Look at Vi vs Emacs. StachTach vs Celiometer? We are a big community,
we should learn to embrace the diversity, where goals don't quite
align. But we still want it to be easy for anyone to join in with any
exiting effort people are working on. People invest in competing
startups.

On the other side of the coin, its hard for our users to know what
combinations of drivers give you are working system, and a system that
solves the problems the user wants to solve. Distros and consultants
are helping fix that. But I am not sure the Vendors always know what
they need to participate in the most useful ways.

We need to better understand what interoperability means with this
broader scope. But making it easy for people to use multiple different
OpenStack implementations is important. Nova API should always behave
like Nova API, Cinder API should always behave like Cinder API, etc.


** Topic: Technical Committee Mission
** How do you feel the technical committee is doing in meeting the
technical committee mission?

TC is clearly aways striving to do better, and trying out new ideas,
which is great.

Evolving the concept of the integrated release is clearly key to
making the system scale. There seems to have been much friction over
the incubation process.

Helping share what has worked well between all the projects, seems key
to providing technical leadership at large scale. Thats starting to
happen, which is cool.

Should the TC reduce its scope to some small number of projects? I am
not sure. Maybe there needs to be a different group setup to deal with
the specifics related to that group of projects? Maybe ttx's cross
project meeting is already the beginnings of that group?


** Topic: Contributor Motivation
** How would you characterise the various facets of contributor motivation?

I feel we are a community of problem solvers, and wanting to
collaborate and make an impact.

Many of us do this work as (some or all) for our full time jobs. That
leads to people being put into a position where the problems they are
able to work on can be constrained by their employer.

We need to get better at educating those who employ people working on
OpenStack, on how they can get the best out of their investment. For
example, not testing things upstream, is really going to hurt.


** Topic: Rate of Growth
** There is no argument the OpenStack technical community has a
substantial rate of growth. What are some of the consequences of this
rate?

Yes, its hurting, and it touches everything. But thats fun, and brings
new ideas, and challenges, which keeps us evolving and adapting. We
need to take care to unlearn things that get in the way too.


** Topic: New Contributor Experience
** How would you characterize the experience new contributors have currently?

I enjoyed how I was welcomed into the OpenStack community. But it was
scary then, and it has to be worse now. We all need to do our part to
be open and welcoming to people.

But we should probably look at who is leaving our community. I
certainly see people step back due to frustrated with the contribution
process. Sometimes burning out after feeling like their ideas are
torn to shreds or feel like the are battling pointless bureaucracy.
The solutions are hard, but it feels like getting better at
documenting the intent of a process, would help, better setting of
expectations around how debates will work, would help. I find rather
than trying to merge my patch, its better to collaborate in solving
my problem.


** Topic: Communication
** How would you describe our current state of communication in the
OpenStack community?

Its not terrible. I think we could do better at on 

Re: [openstack-dev] TC Candidacy

[Tristan Cacqueray]

confirmed

On 09/10/14 09:07 AM, John Garbutt wrote:
 Hi,
 
 I would like to run for a seat on the Technical Committee, to help
 serve the whole OpenStack community during this time of change.
 
 I am employed by Rackspace, working on their public cloud. I am
 currently focus mostly on Nova. I am nova-core, and currently nova's
 blueprint czar. I am johnthetubaguy on IRC.
 
 I started contributing to OpenStack, working as a researcher at Citrix
 in December 2010. I helped create Citrix's Project Olympus packaging
 of OpenStack (nova, swift and glance). After a change in strategy I
 started working more on making OpenStack work with XenServer, setting
 up one of the first Nova sub groups. After my move to Rackspace in
 February 2013, I was able to work on all parts of Nova, and quickly
 got more involved with a wider range of upstream activities.
 
 I find the work of building a consensus really rewarding. I don't
 claim to have all the answers, but I know we need change, so we can
 scale out the community, while at the same time we preserving the true
 nature of this awesome community.
 
 
 ** Topic: OpenStack Mission
 ** How do you feel the technical community is doing in meeting the
 OpenStack Mission?
 
 Its a bold mission, and I think it is still the right one.
 
 serve developers, users, and the entire ecosystem
 I think we need to be better at the serving the entire ecosystem.
 
 Look at Vi vs Emacs. StachTach vs Celiometer? We are a big community,
 we should learn to embrace the diversity, where goals don't quite
 align. But we still want it to be easy for anyone to join in with any
 exiting effort people are working on. People invest in competing
 startups.
 
 On the other side of the coin, its hard for our users to know what
 combinations of drivers give you are working system, and a system that
 solves the problems the user wants to solve. Distros and consultants
 are helping fix that. But I am not sure the Vendors always know what
 they need to participate in the most useful ways.
 
 We need to better understand what interoperability means with this
 broader scope. But making it easy for people to use multiple different
 OpenStack implementations is important. Nova API should always behave
 like Nova API, Cinder API should always behave like Cinder API, etc.
 
 
 ** Topic: Technical Committee Mission
 ** How do you feel the technical committee is doing in meeting the
 technical committee mission?
 
 TC is clearly aways striving to do better, and trying out new ideas,
 which is great.
 
 Evolving the concept of the integrated release is clearly key to
 making the system scale. There seems to have been much friction over
 the incubation process.
 
 Helping share what has worked well between all the projects, seems key
 to providing technical leadership at large scale. Thats starting to
 happen, which is cool.
 
 Should the TC reduce its scope to some small number of projects? I am
 not sure. Maybe there needs to be a different group setup to deal with
 the specifics related to that group of projects? Maybe ttx's cross
 project meeting is already the beginnings of that group?
 
 
 ** Topic: Contributor Motivation
 ** How would you characterise the various facets of contributor motivation?
 
 I feel we are a community of problem solvers, and wanting to
 collaborate and make an impact.
 
 Many of us do this work as (some or all) for our full time jobs. That
 leads to people being put into a position where the problems they are
 able to work on can be constrained by their employer.
 
 We need to get better at educating those who employ people working on
 OpenStack, on how they can get the best out of their investment. For
 example, not testing things upstream, is really going to hurt.
 
 
 ** Topic: Rate of Growth
 ** There is no argument the OpenStack technical community has a
 substantial rate of growth. What are some of the consequences of this
 rate?
 
 Yes, its hurting, and it touches everything. But thats fun, and brings
 new ideas, and challenges, which keeps us evolving and adapting. We
 need to take care to unlearn things that get in the way too.
 
 
 ** Topic: New Contributor Experience
 ** How would you characterize the experience new contributors have currently?
 
 I enjoyed how I was welcomed into the OpenStack community. But it was
 scary then, and it has to be worse now. We all need to do our part to
 be open and welcoming to people.
 
 But we should probably look at who is leaving our community. I
 certainly see people step back due to frustrated with the contribution
 process. Sometimes burning out after feeling like their ideas are
 torn to shreds or feel like the are battling pointless bureaucracy.
 The solutions are hard, but it feels like getting better at
 documenting the intent of a process, would help, better setting of
 expectations around how debates will work, would help. I find rather
 than trying to merge my patch, its better to collaborate in solving
 my problem.
 
 
 ** 

[openstack-dev] TC Candidacy

[John Griffith]

I'd like to announce my candidacy for the OpenStack Technical Committee
Fall 2014 elections.

I've been contributing to OpenStack for almost three years now (this months
my anniversary) and up until this election cycle have served as PTL for the
Cinder Project.  Over the years I've had the opportunity to be on the TC
both as a result of PTL (back when PTL's were reserved seats) as well as by
election.  Last spring however I chose not to run for a seat, for a number
of reasons.  For one I didn't feel as though I had the bandwidth to really
dedicate as much as I should but more importantly I didn't necessarily feel
that what I was doing was really that worthwhile.

Since then there's been a number of ideas proposed about changing some of
our models including the role of the TC.  I really believe that this is
something that we need to do and am excited about the potential
opportunity.  I think there's a lot that needs to be done here, I also
think it's going to be a learning experience and something that's needed is
an open mind.

After the Juno cycle I decided not to seek another term as PTL partly
because I didn't feel that I would be able to effectively fulfill the role
of PTL and serve as a member of the TC.  So I decided that for me, I'd like
the opportunity (if elected) to focus on contributing more broadly to
OpenStack with a focus on service on the Technical Committee.

Answers to the candidacy questions are below.

Thanks,
John



Topic: OpenStack Mission
How do you feel the technical community is doing in meeting the OpenStack
Mission?

Just as a refresh: To produce the ubiquitous OpenSource Cloud Computing
platform that will meet the needs of public and private clouds regardless
of size, by being simple to implement and massively scalable.

So I always find this one a bit challenging to digest to be honest.  I
think the ubiquitous part is coming along and is becoming a reality and I
also think that there's a decent balance between public and private clouds
and that the relative term size could be interpreted as something that's
being addressed fairly well thus far.

Those are the good now for the not so good; simple to implement; I
don't think deployment is  quite as bad as it's made out to be at times,
but it certainly leaves a bit to be desired.  One thing that's always
bothered me here is that it's always been left to the distros to provide
their custom deployment tools and we've never been able to even provide a
common deployment foundation as a community.  I really think that's too
bad, you can build the greatest software project there is, but if people
can't comprehend all the pieces let alone install and configure it fairly
easily it's really not living up to it's potential.

From the perspective of the TC, I'm really not sure what role the TC is
playing in the overall mission to be honest.  In my opinion the TC has
really become mostly a committee relegated to voting on project incubation
and proposals for things like project mission statements.  It's really not
very technical in my opinion and it's also not overly effective either.

In my opinion the TC needs to undergo some changes, it would be great as
others mentioned to move away from just voting on incubation motions and
mission statements or gap analysis efforts and actually focus more on
technical decisions that impact OpenStack as a whole.  For example I think
it would be great for the TC to take a more active role in really having a
deep understanding of how all of the various OpenStack projects are
actually coming together, what they're doing that works, what they're doing
that's not and perhaps provide some guidance and input as well as technical
leadership and direction.  I'm certainly not saying they should be an all
powerful oversight group, but I do think the focus as it stands currently
is wrong.


Topic: Technical Committee Mission
How do you feel the technical committee is doing in meeting the technical
committee mission?
(Reading from the Mission Statement here: [2])

I'm not sure that given the current state of OpenStack and the number of
projects and proposed projects the TC can be faulted for anything here.
The fact is that it's become a full time job to just try and keep up to
date on all the constantly changing projects in the ecosystem, not to
mention all the newly proposed projects.  I do think that it would be
helpful if the TC was able to be adjusted and tweaked a bit such that it
had a more active engagement in technical direction of the project; say for
example driving things like making installation more of a community effort,
providing HA options that really work and most of all pushing every project
in OpenStack to be responsible for making the upgrade process better.  I
also think that the TC needs to make some really hard decisions about
things; like projects that have been started, approved for incubation but
maybe aren't really turning out as was hoped.  In my opinion there are a
number of projects 

[openstack-dev] TC Candidacy

[David Lyle]

I would like to announce my candidacy for the Technical Committee.

I have been working on OpenStack since the beginning of the Grizzly cycle.
I started working on OpenStack as part of HP's Public Cloud effort. I spent
two years working to make Horizon work in that scale of environment and
making Horizon the user facing interface of HP's Public Cloud. I have
served as a Horizon core reviewer since the Havana cycle and I am starting
my third release as Horizon PTL. Currently, I am employed by Intel in their
Open Source Technology Center.

I have been a regular observer of the Technical Committee during my time as
PTL. The role of the TC is large and difficult. I appreciate the efforts of
all those that have served during that time and I would like to thank them
for their dedication. One takeaway from those observations in the very
heavy representation on the TC by infrastructure and core services. I think
the TC would be benefit from more representation higher up the stack. I
think Heat, Horizon, Solum, TripleO have a unique perspective into
cross-project issues and the TC would benefit from such representation.

In my opinion, the fundamental problems the TC needs to address in the Kilo
cycle are handling growth and cross-project alignment. I'll be honest, I
don't have a master plan to address these, but I think I'm well equipped
and motivated to help develop that plan with other members of the TC.

Thanks for your consideration,
David Lyle


Topic: OpenStack Mission: How do you feel the technical community is doing
in meeting the OpenStack Mission?


To produce the ubiquitous OpenSource Cloud Computing platform that will
meet the needs of public and private clouds regardless of size, by being
simple to implement and massively scalable.

I think this is a very broad mission. Breadth is not a problem, but there
are a few implications in here. One OpenStack needs to be inclusive, to
accomplish ubiquity we need to strive to allow deployers to meet their
widely varied needs. So we need to support a large ecosystem. The ecosystem
around OpenStack is certainly large, but there is a fairly sharp dichotomy
between OpenStack and not OpenStack, recognizing larger parts of the
ecosystem is important for ecosystem health. As to public vs private and
massively scalable aspects, I think we have room for growth. Running a
public cloud on OpenStack requires not insignificant changes, and OpenStack
has room for improvement on the scalability front. We need greater feedback
from the very large deployers to make sure we meet those scalability needs.

Topic: Technical Committee Mission: How do you feel the technical committee
is doing in meeting the technical committee mission?


The Technical Committee (TC) is tasked with providing the technical
leadership for OpenStack as a whole (all official programs, as defined
below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
Integration, Quality...), decides on issues affecting multiple programs,
forms an ultimate appeals board for technical decisions, and generally has
oversight over all the OpenStack project.

The technical committee has spent much of the last cycle acting as gate
keeper. I would like to see it take a larger role in overall architectural
direction in OpenStack. I believe one of the greatest challenges we face is
coherency of vision and direction. I think this should be the province of
the technical committee to act as an arbitrar and architectural board. I
don't hold that overall technical direction is to be dictated by the TC,
rather the TC merely helps unify that direction and insures consistency.
Obviously this is a herculean task, but I believe OpenStack needs more
clearness in direction.

Topic: Contributor Motivation: How would you characterize the various
facets of contributor motivation?


Contributors are motivated to contribute for various reasons. People
contribute for personal interest, corporate interest, academic interest,
and any mix of all three. Corporate interest covers a lot, from users to
operators, vendors to consumers. Many ideas from our great community of
diverse contributors helps drive us forward and keeps us honest and
progressing.

At the end of the day, OpenStack is cloud software that should be usable.
We do need to temper the wouldn't it be neat if, with how will this work in
real world application ranging from small test clouds to large public
clouds. Services should strive to work across this spectrum. The difficulty
is focusing these disparate motivations into a cohesive effort.

Topic: Rate of Growth: There 

Re: [openstack-dev] TC Candidacy

[Anita Kuno]

confirmed

On 10/10/2014 01:22 AM, John Griffith wrote:
 I'd like to announce my candidacy for the OpenStack Technical Committee
 Fall 2014 elections.
 
 I've been contributing to OpenStack for almost three years now (this months
 my anniversary) and up until this election cycle have served as PTL for the
 Cinder Project.  Over the years I've had the opportunity to be on the TC
 both as a result of PTL (back when PTL's were reserved seats) as well as by
 election.  Last spring however I chose not to run for a seat, for a number
 of reasons.  For one I didn't feel as though I had the bandwidth to really
 dedicate as much as I should but more importantly I didn't necessarily feel
 that what I was doing was really that worthwhile.
 
 Since then there's been a number of ideas proposed about changing some of
 our models including the role of the TC.  I really believe that this is
 something that we need to do and am excited about the potential
 opportunity.  I think there's a lot that needs to be done here, I also
 think it's going to be a learning experience and something that's needed is
 an open mind.
 
 After the Juno cycle I decided not to seek another term as PTL partly
 because I didn't feel that I would be able to effectively fulfill the role
 of PTL and serve as a member of the TC.  So I decided that for me, I'd like
 the opportunity (if elected) to focus on contributing more broadly to
 OpenStack with a focus on service on the Technical Committee.
 
 Answers to the candidacy questions are below.
 
 Thanks,
 John
 
 
 
 Topic: OpenStack Mission
 How do you feel the technical community is doing in meeting the OpenStack
 Mission?
 
 Just as a refresh: To produce the ubiquitous OpenSource Cloud Computing
 platform that will meet the needs of public and private clouds regardless
 of size, by being simple to implement and massively scalable.
 
 So I always find this one a bit challenging to digest to be honest.  I
 think the ubiquitous part is coming along and is becoming a reality and I
 also think that there's a decent balance between public and private clouds
 and that the relative term size could be interpreted as something that's
 being addressed fairly well thus far.
 
 Those are the good now for the not so good; simple to implement; I
 don't think deployment is  quite as bad as it's made out to be at times,
 but it certainly leaves a bit to be desired.  One thing that's always
 bothered me here is that it's always been left to the distros to provide
 their custom deployment tools and we've never been able to even provide a
 common deployment foundation as a community.  I really think that's too
 bad, you can build the greatest software project there is, but if people
 can't comprehend all the pieces let alone install and configure it fairly
 easily it's really not living up to it's potential.
 
 From the perspective of the TC, I'm really not sure what role the TC is
 playing in the overall mission to be honest.  In my opinion the TC has
 really become mostly a committee relegated to voting on project incubation
 and proposals for things like project mission statements.  It's really not
 very technical in my opinion and it's also not overly effective either.
 
 In my opinion the TC needs to undergo some changes, it would be great as
 others mentioned to move away from just voting on incubation motions and
 mission statements or gap analysis efforts and actually focus more on
 technical decisions that impact OpenStack as a whole.  For example I think
 it would be great for the TC to take a more active role in really having a
 deep understanding of how all of the various OpenStack projects are
 actually coming together, what they're doing that works, what they're doing
 that's not and perhaps provide some guidance and input as well as technical
 leadership and direction.  I'm certainly not saying they should be an all
 powerful oversight group, but I do think the focus as it stands currently
 is wrong.
 
 
 Topic: Technical Committee Mission
 How do you feel the technical committee is doing in meeting the technical
 committee mission?
 (Reading from the Mission Statement here: [2])
 
 I'm not sure that given the current state of OpenStack and the number of
 projects and proposed projects the TC can be faulted for anything here.
 The fact is that it's become a full time job to just try and keep up to
 date on all the constantly changing projects in the ecosystem, not to
 mention all the newly proposed projects.  I do think that it would be
 helpful if the TC was able to be adjusted and tweaked a bit such that it
 had a more active engagement in technical direction of the project; say for
 example driving things like making installation more of a community effort,
 providing HA options that really work and most of all pushing every project
 in OpenStack to be responsible for making the upgrade process better.  I
 also think that the TC needs to make some really hard decisions about
 things; like 

[openstack-dev] TC Candidacy

[Eoghan Glynn]

Folks,

I would like to throw my hat into the ring for the upcoming Technical
Committee election.

I've been involved in the OpenStack community for nearly three years,
starting off by becoming core on glance, before moving my focus mainly
onto the ceilometer project. Along the way I've landed a smattering of
commits across nova, heat, cinder, horizon, neutron, oslo, devstack,
and openstack-manuals, while contributing to the stable-maint effort
over multiple cycles.

More recently, I've served the ceilometer project as PTL over the Juno
cycle, and will be doing so again for Kilo.

I'm employed by Red Hat to work primarily upstream, but I also have
some perspective on the sausage machine that operates downstream in
order to put the technology we produce into the hands of users.

My motivation in running is to bring more perspective from a smaller
project to the deliberations of the TC, which I think already has a
tonne of large-project and cross-project perspective to draw on.
Balance is a good and healthy thing :)

As a community we have a big challenge ahead of us to figure out how
we respond to the growing pains that been felt in our governance
structure and cross-project resources. This has crystallized around
the recent layering and big tent discussions. My own feeling has
always been in favor of a big welcoming tent, but I'm less convinced
that a small blessed core is necessarily a corollary of such
inclusiveness. Before we radically alter the release cycle model
that's served us relatively well thus far, I think a critical eye
should be brought to the proposals; in particular we really need to
clearly identify the core problems that these proposed changes are
intended to solve.

And so, onwards to the stock questions ...

Topic: OpenStack Mission


How do you feel the technical community is doing in meeting the
OpenStack Mission?

In all honesty, I would give us an A+ for effort, but more like a B-
for execution. In our excitement and enthusiasm to add shiny new
features, we sometimes take our eye off the ball in terms of what's
needed to make the lives of our users easier. I'm as guilty of this as
anyone else, perhaps even more so. But I think at this stage, it would
be of much benefit to our user community if we swung the pendulum
somewhat in the other direction, and shifted some focus onto easing
the practical challenges of operating our stuff at scale.

Topic: Technical Committee Mission
==

How do you feel the technical committee is doing in meeting the
technical committee mission?

Well, to be honest, if I thought this couldn't be improved, I wouldn't
be running for election.

On the one hand, I felt the gap analysis for already-integrated
projects was a good and healthy thing, and certainly assisted in
focusing resources over Juno on the areas where the TC saw
deficiencies.

On the other hand, I was quite disheartened by how some of the TC
discussions around project status played out. IMO there was a failure
of due diligence and mentoring. If we continue to have the TC making
important determinations about the future of projects (whether it be
their integrated status or their production readiness), then I think
we need to ensure that the TC keeps itself fully appraised from an
earlier stage about the direction that the project is taking, and
gives fair warning when it feels that a project needs a
course-correction.

Topic: Contributor Motivation
=

How would you characterize the various facets of contributor
motivation?

Most of my prior opensource experience was on various Apache projects
and in contrast it's striking that the OpenStack contributor community
is on the whole more skewed away from pure volunteerism, and towards
corporate contributors. By that, I mean contributors who are employed
by major operators and distributors of OpenStack, where their day-job
is to go forth and make it better. On balance, this is actually a
strength in our community. It certainly aids in the continuity and
sustainability of effort. It also helps ensure that less glamorous,
but ultra-important, efforts such as stable-maint and vulnerability
management get the attention they deserve.

However, despite this skew, I'm well aware that we're building a
broad church here. I think we all benefit from active efforts to
build diversity in our contributor community and harness the energy of
contributors with all kinds of motivations. Not just because it's the
right-on thing to do, but because it's the *smart* thing to do
... ensuring that we get access to all of the talents, especially from
previously under-represented groups. Towards this end, I continue to
support the efforts of programs such as the GNOME OPW and their recent
moves towards extending their reach to a wider set of contributor
backgrounds.

Topic: Rate of Growth
=

There is no argument the OpenStack technical community has a
substantial rate of 

Re: [openstack-dev] TC Candidacy

[Tristan Cacqueray]

confirmed

On 08/10/14 05:51 AM, Eoghan Glynn wrote:
 
 
 Folks,
 
 I would like to throw my hat into the ring for the upcoming Technical
 Committee election.
 
 I've been involved in the OpenStack community for nearly three years,
 starting off by becoming core on glance, before moving my focus mainly
 onto the ceilometer project. Along the way I've landed a smattering of
 commits across nova, heat, cinder, horizon, neutron, oslo, devstack,
 and openstack-manuals, while contributing to the stable-maint effort
 over multiple cycles.
 
 More recently, I've served the ceilometer project as PTL over the Juno
 cycle, and will be doing so again for Kilo.
 
 I'm employed by Red Hat to work primarily upstream, but I also have
 some perspective on the sausage machine that operates downstream in
 order to put the technology we produce into the hands of users.
 
 My motivation in running is to bring more perspective from a smaller
 project to the deliberations of the TC, which I think already has a
 tonne of large-project and cross-project perspective to draw on.
 Balance is a good and healthy thing :)
 
 As a community we have a big challenge ahead of us to figure out how
 we respond to the growing pains that been felt in our governance
 structure and cross-project resources. This has crystallized around
 the recent layering and big tent discussions. My own feeling has
 always been in favor of a big welcoming tent, but I'm less convinced
 that a small blessed core is necessarily a corollary of such
 inclusiveness. Before we radically alter the release cycle model
 that's served us relatively well thus far, I think a critical eye
 should be brought to the proposals; in particular we really need to
 clearly identify the core problems that these proposed changes are
 intended to solve.
 
 And so, onwards to the stock questions ...
 
 Topic: OpenStack Mission
 
 
 How do you feel the technical community is doing in meeting the
 OpenStack Mission?
 
 In all honesty, I would give us an A+ for effort, but more like a B-
 for execution. In our excitement and enthusiasm to add shiny new
 features, we sometimes take our eye off the ball in terms of what's
 needed to make the lives of our users easier. I'm as guilty of this as
 anyone else, perhaps even more so. But I think at this stage, it would
 be of much benefit to our user community if we swung the pendulum
 somewhat in the other direction, and shifted some focus onto easing
 the practical challenges of operating our stuff at scale.
 
 Topic: Technical Committee Mission
 ==
 
 How do you feel the technical committee is doing in meeting the
 technical committee mission?
 
 Well, to be honest, if I thought this couldn't be improved, I wouldn't
 be running for election.
 
 On the one hand, I felt the gap analysis for already-integrated
 projects was a good and healthy thing, and certainly assisted in
 focusing resources over Juno on the areas where the TC saw
 deficiencies.
 
 On the other hand, I was quite disheartened by how some of the TC
 discussions around project status played out. IMO there was a failure
 of due diligence and mentoring. If we continue to have the TC making
 important determinations about the future of projects (whether it be
 their integrated status or their production readiness), then I think
 we need to ensure that the TC keeps itself fully appraised from an
 earlier stage about the direction that the project is taking, and
 gives fair warning when it feels that a project needs a
 course-correction.
 
 Topic: Contributor Motivation
 =
 
 How would you characterize the various facets of contributor
 motivation?
 
 Most of my prior opensource experience was on various Apache projects
 and in contrast it's striking that the OpenStack contributor community
 is on the whole more skewed away from pure volunteerism, and towards
 corporate contributors. By that, I mean contributors who are employed
 by major operators and distributors of OpenStack, where their day-job
 is to go forth and make it better. On balance, this is actually a
 strength in our community. It certainly aids in the continuity and
 sustainability of effort. It also helps ensure that less glamorous,
 but ultra-important, efforts such as stable-maint and vulnerability
 management get the attention they deserve.
 
 However, despite this skew, I'm well aware that we're building a
 broad church here. I think we all benefit from active efforts to
 build diversity in our contributor community and harness the energy of
 contributors with all kinds of motivations. Not just because it's the
 right-on thing to do, but because it's the *smart* thing to do
 ... ensuring that we get access to all of the talents, especially from
 previously under-represented groups. Towards this end, I continue to
 support the efforts of programs such as the GNOME OPW and their recent
 moves towards extending their reach to a wider 

Re: [openstack-dev] TC candidacy

[Tristan Cacqueray]

confirmed

On 07/10/14 10:06 PM, Adam Lawson wrote:
 Hello everyone!
 
 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I hate the spotlight. But the importance of
 Openstack in the cloud marketplace is increasingly important as is the
 integrity of its technical direction. So I'm going to step on a limb here
 and enter the circle.
 
 My involvement has been primarily focused on large designs and deployments
 of custom automated Openstack clouds. And while I am more than proficient
 in Python and numerous other languages including .NET/J2EE and others, my
 greatest pleasure has been architecting solutions that are powered by
 Openstack. Focusing on that has really given me a unique perspective. Not
 just on individual components and how they interact with each other, but
 also how they collectively perform within the context of a heterogenous
 hybrid cloud solution while adhering to industry best practices. This
 perspective is one that I hope to bring to the technical committee if the
 Openstack community is so inclined. Not only to shepherd how Openstack is
 put together but to help enable an easier and more seamless adoption cycle
 within the enterprise.
 
 Lastly in the spirit of full disclosure, I am the principal architect for
 an Openstack consulting company I founded which strives for an accelerated
 enterprise adoption of the open cloud through, in part, the successes of
 Openstack. So one could say I am vested in Openstack in a pretty unique way
 compared to most others. So where technical direction is concerned, I
 believe I have a deep well of experience from which to draw via designing
 and developing production Openstack clouds in the real world - day in and
 day out - which I believe would be of immense value to the TC and the
 community supporting the project itself.
 
 I know there are some really smart people who want to also serve on the TC
 with focuses on various areas of Openstack and thankfully the committee was
 designed to accommodate multiple unique perspectives for that very reason.
 My hope is that the community chooses to include my program-agnostic
 architectural influence to the TC while maintaining the same work ethic and
 unyielding commitment to efforts that will deliver excellence to and within
 the Openstack platform.
 
 So without any further adieu, below are my thoughts re the requested
 questions and thanks for your consideration!
 
 *My name is Adam Lawson, running for election to the Openstack Technical
 Committee, and I approve this message.* ; )
 
 *Topic: OpenStack Mission*
 *How do you feel the technical community is doing in meeting the OpenStack
 Mission?*
 
 *“To produce the ubiquitous Open Source Cloud Computing platform that will
 meet the needs of public and private clouds regardless of size, by being
 simple to implement and massively scalable.”*
 
 The whole point of mission statements is merely to identify what we are
 striving to achieve or accomplish within the organization. With that said,
 I feel that technical leadership is the first step to accomplishing a
 technical goal. So to that end, the existence of the TC is a positive first
 step. But it's just one step or many more to come.
  Within this particular TC cycle, I'd like to see the TC demonstrate
 leadership to drive a reduction of lingering technical debt and address API
 and module standardization. Openstack in its current form has a number of
 challenges that are affecting our ability to scale and while some of this
 can be solved organizationally, technical debt and standardization are
 challenges that will not be easy to resolve and might not even be 100
 percent solvable within a single release cycle. But I look forward to how
 the TC *will* shepherd improvements to both process and the product and
 help drive the mission.
  On a side note, easy to implement is still just a goal and the
 engineering requirement to deploy and manage Openstack is still a
 prohibitive hurdle for many organizations. But we have more than one tool
 in front of us that will help us to help others who want to use Openstack
 but .. can't. That's something I'd really like to see change soon.
 
 *Topic: Contributor Motivation*
 *How would you characterize the various facets of contributor motivation?*
  I like what I read earlier today: People want to do work that matters and
 enjoy doing it. This sums up Openstack contributors very well but it sums
 up 

Re: [openstack-dev] TC candidacy

[Adam Lawson]

It seems I left out a response. Sorry for the follow-on but here's what was
missing.

*Topic: Technical Committee Mission*
*How do you feel the technical committee is doing in meeting the technical
committee mission?*

*The Technical Committee (TC) is tasked with providing the technical
leadership for OpenStack as a whole (all official programs, as defined
below). It enforces OpenStack ideals (Openness, Transparency, Commonality,
Integration, Quality...), decides on issues affecting multiple programs,
forms an ultimate appeals board for technical decisions, and generally has
oversight over all the OpenStack project.*

I believe the TC has thus far done a pretty fair job given the team and its
charter are both rather new. While the TC has been providing leadership for
individual components, I would not characterize the TC today as providing
highly visible leadership (necessary for openness and transparency) which I
would like to see improved. Much of the TC's work today coalesces around
providing a safe harbor for meaningful program integration and ensure
challenges are resolved optimally but the TC needs to get better at
identifying the good/poorly-defined boundaries of this kind of technical
governance model. In other words, the TC needs to get better at being a
good TC. The instantiation of a TC is a perfect first step but the pink
elephant in the room seems to be around cross-project and architectural
guidance; ensuring Openstack as a whole is moving in a direction that
doesn't require accommodating things we shouldn't be doing in the first
place. The lack of API standardization is a great example of moving in a
direction without a big picture context.
 Communications that have gone back and forth and debated about the big
tent model, layers/cascading, scaling documentation, etc have been visible
and the candor of opposing viewpoints have been awesome to follow. But we
could really benefit from some structural adjustments so more decisions
placed before the team are equally visible, a visible and transparent
decision-making process enabling those who use Openstack understand the
architectural perspectives shepherding it. Not just the decision that have
100+ replies on the mailing list
 Oversight over all the projects is an area that I'm anticipating where
we have some easy low-hanging fruit. Where we are today with regard to
focus is understandable given the number of fires affecting individual
programs that cannot be ignored. But we have a big opportunity (there's
that word again) to get some traction on the larger architectural decisions
that may require more work up front but produce some big wins over the long
term. Customers who want to use Openstack have often played the constant
change = unstable card for good reason; Openstack has a long way to go
before it gets to Production-quality for the masses (i.e. without heavy
re-development requirements). I believe the TC can and should influence
that with better solution-level leadership.
 - The deployment challenge is beyond ready for attention.
- A working default 'out-of-the-box' config that can boot an instance
accessible over the network is STILL a challenge. Long past due in my mind.
- Programs like Oslo that address library requirements moves a cloud closer
to Production-capable but really shouldn't be optional. Doing something
well shouldn't be optional. In fact, a Production context shouldn't be one
option of many despite the prevalence of Openstack PoC and pilots; it
should be a consistent design assumption. Gating a feature to the point
that it's 'good enough' is part of the problem. It must be
Production-worthy otherwise it is NOT good enough. That's ready for
attention.
 We might not be able to address all of these and some ideas could use a
lot more cross-talk, but if elected I would like to champion improving how
the TC approaches problems and vets their potential solutions.


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072


On Tue, Oct 7, 2014 at 7:06 PM, Adam Lawson alaw...@aqorn.com wrote:

 Hello everyone!

 I'll be perfectly straight and dedicate paragraph #1 to address the
 painfully obvious. A number of you are probably reading this after seeing
 'TC Candidacy', looked at my name and wondered 'who is this guy?' In short,
 I'm pretty low-key but I've been heavily involved in Openstack since the
 Folsom release - advising, architecting and deploying Openstack-based
 application clouds for numerous companies and end users. I'm probably a lot
 like many of you in fact; not the loudest or most witty voice in the room,
 I read more than I write, I don't bully ideas and I've never run for
 anything in my life because I hate the spotlight. But the importance of
 Openstack in the cloud marketplace is increasingly important as is the
 integrity of its technical direction. So I'm going to step on a