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
 lim

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 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, October 4, 2016 at 4:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] TC candidacy

On Tue, Oct 4, 2016 at 4:01 AM, Steven Dake (stdake) 
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 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 
mailto:emil...@redhat.com>> wrote:
On Mon, Oct 3, 2016 at 2:50 PM, Clay Gerrard 
mailto:clay.gerr...@gmail.com>> wrote:


On Tue, Sep 27, 2016 at 2:52 PM, Emilien Macchi 
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 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 bein

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)  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 
> 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  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?
>>
>
> 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 d

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

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 defined as "Core".  Answer: Let t

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 know how successful or unsuccessful
these efforts mig

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
> people who deploy OpenStack in production.
> In my experience of d

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 OpenS

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

__
Op

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.
>
> OpenStack is people. If we l

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&feature=youtu.be&t=379
2.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104815.html
3.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104844.html
4.
http://lists.openstack.org/pipermail/openstack-dev/2016-September/104833.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] 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 
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 Open

[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

Re: [openstack-dev] TC Candidacy

[Maru Newby]

> On Apr 24, 2015, at 6:17 AM, Luke Gorrie  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]

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

[Luke Gorrie]

On 23 April 2015 at 01:17, Maru Newby  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

[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

[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

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

[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-requ...@lists

[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

[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

[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

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 5:56 PM, David Lyle  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

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 4:17 PM, Maru Newby  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 micro

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 5:05 PM, Sergey Lukjanov  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

[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

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

Re: [openstack-dev] TC candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 1:13 PM, Armando M.  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

[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

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 11:19 AM, Zane Bitter  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 read

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

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Wed, Apr 22, 2015 at 5:24 AM, Ed Leafe  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 9:43 AM, Dean Troyer  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 9:46 AM, Anita Kuno  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.
>
> Plea

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

[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

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

[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

[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

Re: [openstack-dev] TC Candidacy

[Elizabeth K. Joseph]

confirmed


On Tue, Apr 21, 2015 at 9:33 PM, Robert Collins
 wrote:
> 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 
> 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



-- 
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 
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 5:29 PM, Jay Pipes  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

[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

[Elizabeth K. Joseph]

confirmed


On Tue, Apr 21, 2015 at 4:02 PM, Angus Salkeld  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=all&metric=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

[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=all&metric=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

[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

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 appl

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 b

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

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

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 wo

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

Re: [openstack-dev] TC candidacy

[Anita Kuno]

On 10/08/2014 05:29 PM, Adam Lawson wrote:
> 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
>
Thanks Adam, I will add this to the wikipage.

Thanks,
Anita.
> 
> On Tue, Oct 7, 2014 at 7: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 th

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

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 matt