from:"Tristan Cacqueray"

On 09/17/2015 09:15 PM, Nikhil Komawar wrote:
> 
> I like to solve problems and seems like this is a common problem in many
> conferences, seminars, etc. The usual way of solving this issue is to
> have a grace period with last minute extension to deadline for
> proposals, possibly for a unknown period of time and unannounced.

I'm strongly against this extra rules. OpenStack Officials Elections are
ran by volunteers and any rules that adds complexity should be avoided.

Thanks,
Tristan




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] [all][elections] PTL nomination period is now over

On 09/18/2015 09:41 AM, Steven Hardy wrote:
>> In my previous email I mentioned that folks can simply send the
>> > candidacy in advance or have someone else to propose it. Seriously,
>> > it's not about having a single day for sending the candidacy, it's
>> > about having a clear deadline where no more candidacies are
>> > considered. If a candidacy is sent 4 months in advance, I guess that's
>> > fine. I don't care.
> Cool, that wasn't really how I interpreted your previous mail, sounds like
> we're in violent agreement! :)
> 
> Cheers,
> 
> Steve

There is one technical issue if we want to let candidate submit their
candidacy early on. The openstack/election repository needs a cycle name
as well as a the final project list.



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] [all][elections] PTL nomination period is now over

On 09/18/2015 06:58 AM, Flavio Percoco wrote:
> On 17/09/15 15:47 -0400, Doug Hellmann wrote:
>> Excerpts from Thierry Carrez's message of 2015-09-17 18:10:26 +0200:
>>> Monty Taylor wrote:
>>> > I agree- and this is a great example of places where human
>>> judgement is
>>> > better than rules.
>>> >
>>> > For instance - one of the projects had a nominee but it missed the
>>> > deadline, so that's probably an easy on.
>>> >
>>> > For one of the projects it had been looking dead for a while, so
>>> this is
>>> > the final nail in the coffin from my POV
>>> >
>>> > For the other three - I know they're still active projects with people
>>> > interested in them, so sorting them out will be fun!
>>>
>>> Looks like in 4 cases (Magnum, Barbican, Murano, Security) there is
>>> actually a candidate, they just missed the deadline. So that should be
>>> an easy discussion at the next TC meeting.

To be more precise, there are 2 candidacies for Magnum and 1 for
Security. I would prefer all candidates have their candidacy statement
proposed and then merged upon TC decision.

>>>
>>> For the last one, it is not an accident. I think it is indeed the final
>>> nail on the coffin.
>>>
>>
>> Yes, I was planning to wait until after the summit to propose that we
>> drop MagnetoDB from the official list of projects due to inactivity. We
>> can deal with it sooner, obviously.
> 
> +1
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




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] [all][elections] PTL Voting is now open

Elections are underway and will remain open for you to cast your vote
until 13:00 UTC September 24, 2015

We are having elections for Cinder, Glance, Ironic, Keystone, Mistral,
Neutron and Oslo.

If you are a Foundation individual member and had a commit in one of the
program's projects[0] over the Kilo-Liberty timeframe (September 18,
2014 06:00 UTC to September 18, 2015 05:59 UTC) then you are eligible to
vote. You should find your email with a link to the Condorcet page to
cast your vote in the inbox of your gerrit preferred email[1].

What to do if you don't see the email and have a commit in at least one
of the programs having an election:
  * check the trash or spam folders of your gerrit Preferred Email
address, in case it went into trash or spam
  * wait a bit and check again, in case your email server is a bit slow
  * find the sha of at least one commit from the program project
repos[0] and email me and Tony[2] at the below email addresses. If
we can confirm that you are entitled to vote, we will add you to
the voters list for the appropriate election.

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

Candidate statements/platforms can be found linked to Candidate names on
the wiki[3].

Happy voting,
Tristan


[0] The list of the program projects eligible for electoral
status:https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=sept-2015-elections

[1] Sign into review.openstack.org:
Go to Settings > Contact Information.
Look at the email listed as your Preferred Email.
That is where the ballot has been sent.

[2] Tony's email: tony at bakeyournoodle dot com
Tristan's email: tristan dot cacqueray at enovance dot com

[3]
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_candidates:



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] [all][elections] PTL nomination period is now over

2015-09-17 Thread Tristan Cacqueray

On 09/17/2015 03:05 PM, Douglas Mendizábal wrote:
> I think someone jumped the gun on this thread.  According to the wiki
> [1] the cutoff time is not until 5:59 UTC, which
> doesn't happen for another few hours. [2]
> 
> Am I missing something?
> 
> [1] https://wiki.openstack.org/wiki/PTL_Elections_September_2015
> [2] http://time.is/UTC
> 
> Douglas Mendizábal
> 


Hi Douglas,

UTC time is now:  "Thu Sep 17 15:16:46 UTC 2015".
The deadline was: "Thu Sep 17 05:59:00 UTC 2015"

You can check UTC time using this command line "TZ=UTC date".

Regards,
Tristan



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] [all][elections] PTL nomination period is now over

2015-09-17 Thread Tristan Cacqueray

PTL Nomination is now over. The official candidate list is available on
the wiki[0].

There are 5 projects without candidates, so according to this
resolution[1], the TC we'll have to appoint a new PTL for Barbican,
MagnetoDB, Magnum, Murano and Security

There are 7 projects that will have an election: Cinder, Glance, Ironic,
Keystone, Mistral, Neutron and Oslo. The details for those will be
posted tomorrow after Tony and I setup the CIVS system.

Thank you,
Tristan


[0]:
https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
[1]:
http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html




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

Re: [openstack-dev] [all][elections] PTL nomination period is now over

2015-09-17 Thread Tristan Cacqueray

On 09/17/2015 01:32 PM, Flavio Percoco wrote:
> On 17/09/15 13:25 +0000, Tristan Cacqueray wrote:
>> PTL Nomination is now over. The official candidate list is available on
>> the wiki[0].
>>
>> There are 5 projects without candidates, so according to this
>> resolution[1], the TC we'll have to appoint a new PTL for Barbican,
>> MagnetoDB, Magnum, Murano and Security
> 
> Magnum had a candidacy on the mailing list. I'd assume this is because
> it wasn't proposed to openstack/election. Right?

That is correct, but the candidacy was submitted after the deadlines so
we can't validate this candidate.

> 
> Thanks for the hard work here,
> Flavio
> 
>>
>> There are 7 projects that will have an election: Cinder, Glance, Ironic,
>> Keystone, Mistral, Neutron and Oslo. The details for those will be
>> posted tomorrow after Tony and I setup the CIVS system.
>>
>> Thank you,
>> Tristan
>>
>>
>> [0]:
>> https://wiki.openstack.org/wiki/PTL_Elections_September_2015#Confirmed_Candidates
>>
>> [1]:
>> http://governance.openstack.org/resolutions/20141128-elections-process-for-leaderless-programs.html
>>
>>
>>
> 
> 
> 
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




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] [all] Election Season, PTL and TC September/October 2015

2015-09-09 Thread Tristan Cacqueray

PTL Election details:
  https://wiki.openstack.org/wiki/PTL_Elections_September_2015
TC Election details:
  https://wiki.openstack.org/wiki/TC_Elections_September/October_2015

Please read the stipulations and timelines for candidates and electorate
contained in these wikipages.

There will be an announcement email opening nominations as well as an
announcement email opening the polls.

Please note that election's workflow is now based on gerrit through the
new openstack/election repository. All candidacies must be submitted as
a text file to the openstack/election repository. Please check the
instructions on the wiki documentation.

Be aware, in the PTL elections if the program only has one candidate,
that candidate is acclaimed and there will be no poll. There will only
be a poll if there is more than one candidate stepping forward for a
program's PTL position.

There will be further announcements posted to the mailing list as action
is required from the electorate or candidates. This email is for
information purposes only.

If you have any questions which you feel affect others please reply to
this email thread. If you have any questions that you which to discuss
in private please email both myself Tristan Cacqueray (tristanC) email:
tdecacqu at redhat dot com and Tony Breed (tonyb) email: tony at
bakeyournoodle dot com so that we may address your concerns.

Thank you,
Tristan



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] [all] Criteria for applying vulnerability:managed tag

2015-09-02 Thread Tristan Cacqueray

Thanks you Jeremy for starting this discussion :-)

Proposed criteria works for me and they concurs with what have been
discussed in Vancouver.

My comments on the open-question below.


On 09/01/2015 06:56 PM, Jeremy Stanley wrote:
> A. Can the VMT accept deliverables in any programming language?

Any supported programming language by the openstack project should/could
also be accepted for vulnerability management.
As long as there is a way to test patch, I think the VMT can support
other languages like Go or Puppet.


> 
> B. As we expand the VMT's ring within the Big Top to encircle more
> and varied acts, are there parts of our current process we need to
> reevaluate for better fit? For example, right now we have one list
> of downstream stakeholders (primarily Linux distros and large public
> providers) we notify of upcoming coordinated disclosures, but as the
> list grows longer and the kinds of deliverables we support becomes
> more diverse some of them can have different downstream communities
> and so a single contact list may no longer make sense.
> 
The risk is to divide downstream communities, and managing different
lists sounds like overkill for now. One improvement would be to maintain
that list publicly like xen do for their pre-disclosure list:
  http://www.xenproject.org/security-policy.html


> C. Should we be considering a different VMT configuration entirely,
> to better service some under-represented subsets of the OpenStack
> community? Perhaps multiple VMTs with different specialties or a
> tiered structure with focused subteams.
> 
> D. Are there other improvements we can make so that our
> recommendations and processes are more consumable by other groups
> within OpenStack, further distributing the workload or making it
> more self-service (perhaps reducing the need for direct VMT
> oversight in more situations)?
> -- Jeremy Stanley

With a public stakeholder list, we can clarify our vmt-process to be
directly usable without vmt supervision.

Anyway, imo the five criteria proposed are good to be amended to the
vulnerability:managed tag documentation.

Again, thank you fungi :-)
Tristan



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] [all] PTL/TC candidate workflow proposal for next elections

2015-08-24 Thread Tristan Cacqueray

On 08/24/2015 01:37 PM, Doug Hellmann wrote:
 Excerpts from Tristan Cacqueray's message of 2015-08-21 14:20:00 +:
 Hello folks,

 as discussed previously, we'd like to improve elections workflow using
 gerrit:

 * A new repository to manage elections: openstack/election
 * Candidates submit their candidacy through a file as a CR, e.g.:
   sept-2015-ptl/project_name-candidate_name
 * A check job verifies if the candidate is valid (has ATC and
   contributor to the project)
 * Elections officials +2 the review
 * Once merged, a post jobs could publish the candidacy to openstack-dev@
   and to the wiki.
 
 What would publish the candidacy to openstack-dev look like? Would
 that be an email from you publishging, for example, my candidacy and
 position statement for the TC election?
 
 Having you send that email seems a bit odd. How about if we ask
 candidates to email the list, and then submit their name and a link
 to that email post to the election repository? That keeps the
 majority of the discussion on the ML, while still ensuring that
 you've seen everyone's candidacy.
 
 Doug
 

That would also works. Maybe the ML posts would then be optional and up
to the candidate to publicize its candidacy.




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] [all] PTL/TC candidate workflow proposal for next elections

2015-08-21 Thread Tristan Cacqueray

Hello folks,

as discussed previously, we'd like to improve elections workflow using
gerrit:

* A new repository to manage elections: openstack/election
* Candidates submit their candidacy through a file as a CR, e.g.:
  sept-2015-ptl/project_name-candidate_name
* A check job verifies if the candidate is valid (has ATC and
  contributor to the project)
* Elections officials +2 the review
* Once merged, a post jobs could publish the candidacy to openstack-dev@
  and to the wiki.


Automated jobs would be great, but the first iteration could be managed
using manual tools.

While this workflow doesn't tackle actual elections (using CIVS), it
should already greatly help elections officials.

Thought ?


Tristan



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] [Security] Nominating Travis McPeak for Security CoreSec

2015-06-18 Thread Tristan Cacqueray

On 06/16/2015 02:28 AM, Clark, Robert Graham wrote:
 I'd like to nominate Travis for a CoreSec position as part of the Security 
 project. - CoreSec team members support the VMT with extended consultation on 
 externally reported vulnerabilities.
 
 Travis has been an active member of the Security project for a couple of 
 years he's a part of the bandit subproject and has been very active in 
 discussions over this time. He's also found multiple vulnerabilities and has 
 experience of the VMT process.
 
 -Rob
 
 

+1 !



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] [all] [stable] No longer doing stable point releases

2015-06-05 Thread Tristan Cacqueray

On 06/05/2015 05:46 AM, Thierry Carrez wrote:
 So.. summarizing the various options again:
 
 Plan A
 Just drop stable point releases.
 (-) No more release notes
 (-) Lack of reference points to compare installations
 
 Plan B
 Push date-based tags across supported projects from time to time.
 (-) Encourages to continue using same version across the board
 (-) Almost as much work as making proper releases
 
 Plan C
 Let projects randomly tag point releases whenever
 (-) Still a bit costly in terms of herding cats
 
 Plan D
 Drop stable point releases, publish per-commit tarballs
 (-) Requires some infra changes, takes some storage space
 
 Plans B, C and D also require some release note / changelog generation
 from data maintained *within* the repository.
 
 Personally I think the objections raised against plan A are valid. I
 like plan D, since it's more like releasing every commit than not
 releasing anymore. I think it's the most honest trade-off. I could go
 with plan C, but I think it's added work for no additional value to the
 user.
 
 What would be your preferred option ?
 

Apologize if I'm off-track here, but Plan A and D seems like a steep
change for users. Imo having stable release (at least between two
releases) is a valid use-case.

I guess Plan C is the preferred option, along with a stable-release
tag, projects that opt-in would have the responsibility to create stable
branches and maintain them.

Regards,
Tristan



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] [Elections] Results of the TC Election

2015-04-30 Thread Tristan Cacqueray

Please join me in congratulating the 7 newly elected members of the TC.

* Thierry Carrez
* Jay Pipes
* James E. Blair
* Flavio Percoco
* Mark McClain
* Dean Troyer
* Robert Collins

Full results:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688

Thank you to all candidates who stood for election, having a good group
of candidates helps engage the community in our democratic process,

Thank you to all who voted and who encouraged others to vote. We need to
ensure your voice is heard.

Thanks to my fellow election official, Elizabeth K. Joseph, I appreciate
your help and perspective.

Thank you for another great round.

Here's to Libery,
Tristan



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] [Elections] Vote Vote Vote in the TC election!

2015-04-28 Thread Tristan Cacqueray

We are coming down the the last day plus hours for voting in the TC
election.

Search your gerrit preferred email address[0] for the following subject:
Poll: OpenStack Technical Committee (TC) Election - April 2015

That is your ballot and links you to the voting application. Please
vote. If you have voted, please encourage your colleagues to vote.

Candidate statements are linked to the names of all confirmed candidates:

https://wiki.openstack.org/wiki/TC_Elections_April_2015#Confirmed_Candidates

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

Please vote!

Thank you,
Tristan

[0] Sign into review.openstack.org: Go to Settings Contact
Information. Look at the email listed as your Preferred Email.
That is where the ballot has been sent.
[1]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=april-2015-elections
[2] Elizabeth K. Joseph (pleia2): lyz at princessleia dot com
Tristan (tristanC): tristan dot cacqueray at enovance dot com

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

2015-04-24 Thread Tristan Cacqueray

Voting for the TC Election is now open and will remain open until 1300
UTC April 30 2015.

We are electing 7 positions from a pool of 19 candidates[0].

When you receive your email providing your link to the ballot, follow
the instructions that are available on the page where you may vote. If
you are confused and need more instruction, close the webpage without
submitting your vote and then email myself and Elizabeth[1]. Your ballot
will still be enabled to vote until the election is closed, as long as
you don't submit your ballot before your close your webpage.

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

You are eligible to vote if are a Foundation individual member[2] that
also has committed to one of the official programs projects[3] over the
Juno-Kilo timeframe (April 9, 2014 06:00 UTC to April 9, 2015 05:59 UTC)
or if you are one of the extra-atcs.[4]

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

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

Candidate statements/platforms can be found linked to Candidate names on
this page:
https://wiki.openstack.org/wiki/TC_Elections_April_2015#Candidates

Happy voting,
Tristan. (tristanC)

[0]
https://wiki.openstack.org/wiki/TC_Elections_April_2015#Confirmed_Candidates
[1] Tristan: tristan dot cacqueray at enovance dot com
Elizabeth: lyz at princessleia dot com
[2] http://www.openstack.org/community/members/
[3]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=april-2015-elections
[4]
http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=april-2015-elections
[5] Sign into review.openstack.org: Go to Settings Contact
Information. Look at the email listed as your Preferred Email. That is
where the ballot has been sent.

Re: [openstack-dev] TC candidacy

2015-04-24 Thread 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

confirmed

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




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

Re: [openstack-dev] TC candidacy

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

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

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

2015-04-22 Thread 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

2015-04-22 Thread 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

Re: [openstack-dev] TC Candidacy

2015-04-21 Thread 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

Re: [openstack-dev] TC candidacy

2015-04-20 Thread 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] PTL Election Conclusion and Results

2015-04-17 Thread Tristan Cacqueray

Thank you to the electorate, to all those who voted and to all
candidates who put their name forward for PTL for this election. A
healthy, open process breeds trust in our decision making capability
thank you to all those who make this process possible.

Now for the results of the PTL election process, please join me in
extending congratulations to the following PTLs:

* Compute (Nova)
** John Garbutt
* Object Storage (Swift)
** John Dickinson
* Image Service (Glance)
** Nikhil Komawar
* Identity (Keystone)
** Morgan Fainberg
* Dashboard (Horizon)
** David Lyle
* Networking (Neutron)
** Kyle Mestery
* Block Storage (Cinder)
** Mike Perez
* Metering/Monitoring (Ceilometer)
** Gordon Chung
* Orchestration (Heat)
** Steve Baker
* Database Service (Trove)
** Nikhil Manchanda
* Bare metal (Ironic)
** Devananda van der Veen
* Common Libraries (Oslo)
** Davanum Srinivas
* Infrastructure
** James E. Blair
* Documentation
** Lana Brindley
* Quality Assurance (QA)
** Matthew Treinish
* Deployment (TripleO)
** James Slagle
* Release cycle management
** Thierry Carrez
* Message Service (Zaqar)
** Flavio Percoco
* Data Processing Service (Sahara)
** Sergey Lukjanov
* Key Management Service (Barbican)
** Douglas Mendizabal
* DNS Services (Designate)
** Kiall Mac Innes
* Shared File Systems (Manila)
** Ben Swartzlander
* Command Line Client (OpenStackClient)
** Dean Troyer
* OpenStack Containers Service (Magnum)
** Adrian Otto
* Application Catalog (Murano)
** Serg Melikyan
* Non-Domain Specific Policy Enforcement (Congress)
** Tim Hinrichs

Election Results:
* Nova:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4a879ff581b99e7a
* Glance:
http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_13a14da9986cac8c

Shortly I will post the announcement opening TC nominations and then we
are into the TC election process.

Thank you to all involved in the PTL election process,
Tristan



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] Candidate proposals for TC (Technical Committee) positions are now open

2015-04-17 Thread Tristan Cacqueray

Candidate proposals for the Technical Committee positions (7 positions)
are now open and will remain open until 05:59 UTC April 23, 2015.

Candidates for the Technical Committee Positions: Any Foundation
individual member can propose their candidacy for an available,
directly-elected TC seat. [0] (except the six TC members who were
elected for a one-year seat last October : Monty Taylor, Sean Dague,
Doug Hellmann, Russell Bryant, Anne Gentle, John Griffith) [1]

Propose your candidacy by sending an email to the openstack-dev at
lists.openstack.org mailing-list, with the subject: TC candidacy.
Please start your own thread so we have one thread per candidate. Since
there will be many people voting for folks with whom they might not have
worked, including a platform or statement to help voters make an
informed choice is recommended, though not required. Note that unlike in
the last TC election, no set of questions are proposed and it's entirely
up to the candidate to compose their candidacy.

Elizabeth and I will confirm candidates with an email to the candidate
thread as well as create a link to the confirmed candidate's proposal
email on the wikipage for this election. [1]

The election will be held from April 24 through to 13:00 UTC April 30,
2015. The electorate are the Foundation individual members that are also
committers for one of the official programs projects [2] over the
Juno-Kilo timeframe (April 9, 2014 06:00 UTC to April 9, 2015 05:59
UTC), as well as the extra-ATCs who are acknowledged by the TC. [3]

Please see the wikipage for additional details about this election. [1]

If you have any questions please be sure to either voice them on the
mailing list or email Elizabeth or myself [4] or contact Elizabeth or
myself on IRC.

Thank you, and we look forward to reading your candidate proposals,
Tristan

[0] https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee
[1] https://wiki.openstack.org/wiki/TC_Elections_April_2015
[2]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=april-2015-elections
Note the tag for this repo, april-2015-elections.
[3]
http://git.openstack.org/cgit/openstack/governance/tree/reference/extra-atcs?id=april-2015-elections
[4] Elizabeth K. Joseph (pleia2): lyz at princessleia dot com
Tristan (tristanC): tristan dot cacqueray at enovance dot com



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] [cinder] CHAP secret is visible in cinder volume log

2015-04-16 Thread Tristan Cacqueray

On 04/16/2015 08:54 AM, Yogesh Prasad wrote:
 Hi,
 
 I am wondering why screen-c-vol.log is displaying the CHAP secret.
 
 Logs:
 
 2015-04-16 16:04:23.288 7306 DEBUG oslo_concurrency.processutils
 [req-23c699df-7b21-48d2-ba14-d8ed06642050 ce8dccba9ccf48fb956060b3e54187a2
 4ad219788df049e0b131e17f603d5faa - - -] CMD sudo cinder-rootwrap
 /etc/cinder/rootwrap.conf iscsiadm -m node -T
 iqn.2015-04.acc1.tsm1:acc171fe6fc15fcc4bd4a841594b7876e3df -p
 192.10.44.48:3260 --op update -n* node.session.auth.password -v ***
 returned:* 0 in 0.088s execute
 /usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:225
 
 Above log hides the secret.
 
 2015-04-16 16:04:23.290 7306 DEBUG cinder.brick.initiator.connector
 [req-23c699df-7b21-48d2-ba14-d8ed06642050 ce8dccba9ccf48fb956060b3e54187a2
 4ad219788df049e0b131e17f603d5faa - - -] *iscsiadm ('--op', 'update', '-n',
 'node.session.auth.password', '-v', u'fakeauthgroupchapsecret')*: stdout=
 stderr= _run_iscsiadm
 /opt/stack/cinder/cinder/brick/initiator/connector.py:455
 
 However, this one does not hide the secret.
 
 In addition, i find that the CHAP credentials are stored as plain string
 the database table (volumes).
 
 I guess these are security risks in the current implementation. Any
 comments ?
 

Hi Yogesh,

we can't realistically consider DEBUG logs as a security risks. the real
issue in my opinion is that services are ran in DEBUG mode in production...

Also the database content is also considered sensitive and should not be
available to users.

Though I agree with you and both issues should be considered security
hardening (hide passwords in debug logs and use encrypted storage so
that only the service could decrypt the passwords).

Thanks for raising these issues
Tristan



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] [Nova][Glance] Last day to elect your PTL!

2015-04-16 Thread Tristan Cacqueray

Hello Nova and Glance contributors,

Just a quick reminder that elections are closing soon, if you haven't
already you should use your right to vote and pick your favourite candidate!

Thanks for your time!
Tristan



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] PTL Voting is now open

2015-04-11 Thread Tristan Cacqueray

Attention voters, ballots have been sent to one of your Gerrit
additional E-mail Addresses. Due to this error we must cancel this
election and start a new one. Any vote that has already been cast is
null and void.

The title of the new poll is changed to New OpenStack ... PTL Election
and all votes must be re-submitted using the new ballots sent to your
Gerrit Preferred E-mail Address.

The end date is now extended by one day so you can vote until
13:00 UTC April 17, 2015.

Please accept my apologies for any inconvenience this error may have caused.

Tristan

On 04/10/2015 01:01 PM, Tristan Cacqueray wrote:
Elections are underway and will remain open for you to cast your vote
until 13:00 UTC April 16, 2015

We are having elections for Nova and Glance.

If you are a Foundation individual member and had a commit in one of the
program's projects[0] over the Juno-Kilo timeframe (April 9, 2014 06:00
UTC to April 9, 2015 05:59 UTC) then you are eligible to vote. You
should find your email with a link to the Condorcet page to cast your
vote in the inbox of your gerrit preferred email[1].

What to do if you don't see the email and have a commit in at least one
of the programs having an election:
* check the trash or spam folders of your gerrit Preferred Email
address, in case it went into trash or spam
* wait a bit and check again, in case your email server is a bit slow
* find the sha of at least one commit from the program project
repos[0] and email me and Elizabeth[2] at the below email addresses. If
we can confirm that you are entitled to vote, we will add you to the
voters list for the appropriate election.

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

Candidate statements/platforms can be found linked to Candidate names on
this page:
https://wiki.openstack.org/wiki/PTL_Elections_April_2015#Confirmed_candidates:

Happy voting,
Tristan (tristanC)

[0] The list of the program projects eligible for electoral status:
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=april-2015-elections

[1] Sign into review.openstack.org:
Go to Settings Contact Information.
Look at the email listed as your Preferred Email.
That is where the ballot has been sent.

[2] Elizabeth's email: lyz at princessleia dot com
Tristan's email: tristan dot cacqueray at enovance dot com

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

Re: [openstack-dev] [Glance] PTL Candidacy

2015-04-09 Thread Tristan Cacqueray

confirmed

On 04/09/2015 12:55 AM, Nikhil Komawar wrote:
 Hello everyone,
 
 I would like to announce my candidacy as PTL for Glance for Liberty cycle.
 
 I have been part of the Glance program since Folsom release and have seen it 
 grow and get better over the years. As the PTL for Kilo, I have helped this 
 program achieve a steady forward momentum. In the process, quite a few 
 developers have joined the program, become core reviewers, and have been 
 providing excellent feedback on reviews, specs and development of libraries. 
 It has been a pleasure to collaborate with everyone and get the newer members 
 up to speed on the Glance project's development patterns and processes. Also, 
 we have been able to accomplish good progress on the newly added features 
 namely Artifacts and the Catalog Index Service. At the same time, other 
 blueprints have had good attention both from code contributors as well as 
 reviewers side. Although we began with a relatively small review team at the 
 advent of Kilo, over a dozen blueprints were implemented for Glance.  
 Additionally, we have been making continued progress in improving the 
 glance_store and python-glance
client libraries. Also, we've made a lot of progress in Glance for incubating 
cross-project changes like adopting graduated oslo policy, support of multiple 
sort keys and directions in glance and in the client, etc. We have also seen 
better feedback time on reviews, better awareness on review guidelines, more 
IRC presence, better collaboration in the meetings and on the Mailing Lists, 
and prompt attention to security bugs.  There have also been improvements in 
subtle aspects of the program like more Documentation support, feature updates 
in the client, as well as increased frequency of releases of the libraries. All 
of this great work has been made possible by the support of a group of really 
talented and proactive developers who have made the Glance ATCs into a vibrant 
community.
 
 For Liberty I would like to encourage the team to help Artifacts and the 
 Catalog Index Service achieve feature completion early in the first phase of 
 the cycle.  This will put us in a good position to address stability concerns 
 and make stability the primary focus of the Liberty cycle. As we have made 
 good progress in reducing the technical debt of promised features and 
 improving cross project experience within Glance, I think it's time to put 
 more focus in stabilizing the code bases. glance_store was introduced in the 
 Juno cycle, saw great improvements in Kilo, but requires more work to become 
 a mature repository. So, for Liberty, as a part of stability goal I would 
 like to work with the team in rising its Development Status to level 4 at the 
 very least. Also, there have been some really great feature proposals in the 
 later phase of Kilo that couldn't be implemented in the short window 
 available. I would like to help these proposal get some feedback as well as 
 work with their respe
ctive development teams in building solutions cohesive to the Glance program.
 
 During Kilo, Glance made the full transition from the old blueprint style of 
 design specifications to the more rigorous specs-based system.  From that 
 experience, the team has learned what did and didn't work well and has asked 
 for a better process for managing blueprints, specs and documentation. I 
 would like to partner with developers as well as operators in understanding 
 and addressing the pain points therein. I would like to partner with a wider 
 group in being able to setup documentation for the same. I would also like to 
 help the team get a healthier review speed and start implementing the 
 rotation policy for core reviewers.
 
 I have enjoyed working with all the Glance contributors and have learned a 
 lot while serving as PTL for Kilo. I'd appreciate the opportunity to apply 
 what I've learned to the Liberty release.
 
 Thanks for your consideration and support,
 -Nikhil Komawar
 
 
 
 __
 OpenStack Development Mailing 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] [RelMgt] PTL Candidacy

confirmed

On 04/08/2015 06:18 AM, Thierry Carrez wrote:
 Hello list,
 
 I'm announcing my candidacy for OpenStack Release Cycle Management PTL
 for the Liberty cycle.
 
 Release Management is a function that existed since the inception of
 OpenStack and I always filled that role, so this candidacy may sound
 like business as usual. I like to think there are a lot of important
 changes we need to implement during the Liberty cycle though, which
 makes it extra-interesting.
 
 First, we need to scale and evolve the various Release Cycle Management
 subteams to accommodate the big-tent initiative. How to scale those
 central activities to a higher number of OpenStack projects ? That
 effort is already started for the stable maintenance subteam, which
 implemented a number of structural changes to support more projects
 while preserving the ideals outlined in the Stable branch policy. For
 the release subteam, that means evolving from doing only direct release
 management to providing advice, reusable tools and documented processes.
 It is a pretty significant change that will require a bit of work and
 recruitment in the team, and I'd like to lead that change if you give me
 your trust.
 
 Second, we need to have a discussion on long-term evolution of the
 release model to better serve our users. The 6-month cycle with 3
 intermediary milestones was always a compromise between our stable
 support and documentation capacity and our goal of releasing early,
 releasing often. As our base projects slowly mature and we welcome more
 OpenStack projects, we want to reconsider that trade-off and at least
 bring some flexibility to it. I think my experience there can be useful
 while we navigate that treacherous pass.
 
 You'll note that I'm not mentioning the Vulnerability Management Subteam
 anymore, since that one got reassigned to the new Security team that
 just got approved.
 
 Thank you 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

Re: [openstack-dev] [designate] PTL Candidacy

confirmed

On 04/08/2015 09:32 AM, Kiall Mac Innes wrote:
 I would like to announce my candidacy for Designate / DNS Services
 Program PTL position for the Liberty cycle.
 
 Keeping this short! I've been working on the Designate project since day
 1, and believe we've made great progress over the last few cycles. For
 Liberty, I expect our focus will be on tighter integration with other
 OpenStack projects, scalability and reliability improvements, and
 community growth.
 
 Thanks,
 Kiall
 
 __
 OpenStack Development Mailing 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] [elections] Last hours for PTL candidate announcements

A quick reminder that we are in the last hours for PTL candidate
announcements.

If you want to stand for PTL, don't delay, follow the instructions on
the wikipage and make sure we know your intentions:
https://wiki.openstack.org/wiki/PTL_Elections_April_2015

Thank you,
Tristan



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] [sahara] PTL Candidacy

confirmed

On 04/08/2015 10:49 AM, Sergey Lukjanov wrote:
 Hey folks,
 
 I'd like to announce my intention to continue being PTL of the Data
 Processing program (Sahara).
 
 I’m working on Sahara (ex. Savanna) project from scratch, from the
 initial proof of concept implementation and till now. I have been the
 acting/elected PTL since Sahara was an idea. Additionally, I’m
 contributing to other OpenStack projects, especially Infrastructure
 for the last three releases where I’m core/root teams member now.
 
 My high-level focus as PTL is to coordinate work of subteams, code
 review, release management and general architecture/design tracking.
 
 During the Kilo cycle we successfully adopted specs and czars systems.
 Tons of operability and supportability improvements were done as well
 as number of interesting features.
 
 For Liberty cycle my focus is to keep going in the same direction and
 to ensure that everything we're working on is related to the end users
 needs. So, in a few words it's about continuing moving forward in
 implementing scalable and flexible Data Processing aaS for OpenStack
 ecosystem by investing in quality, usability and new features.
 
 A few words about myself: I’m Principle Software Engineer in Mirantis.
 I was working a lot with  Big Data projects and technologies (Hadoop,
 HDFS, Cassandra, Twitter Storm, etc.) and enterprise-grade solutions
 before (and partially in parallel) working on Sahara in OpenStack ecosystem.
 
 
 
 __
 OpenStack Development Mailing 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] [Heat] PTL Candidacy

confirmed

On 04/06/2015 10:50 PM, Steve Baker wrote:
 I'd like to announce my candidacy for the Heat PTL in Liberty.
 
 As I was the PTL during Icehouse, this will be Heat's first rerun PTL
 under our convention for rotating leaders. Even if elected I would hope
 that we continue to find Heat PTL new-blood for future cycles.
 
 Towards the end of the Kilo cycle we started to get some momentum on
 landing the changes required for the Convergence effort. The aim will be
 to get much of the first-phase features landing early in Liberty, and
 spend the rest of the cycle focusing on convergence features which
 provide the most user benefit.
 
 There are important maintenance tasks in the Liberty cycle which will
 need continued effort, including functional/integration testing, content
 for the template-writer's guide, and general usability improvements.
 
 It seems that our merge throughput would be higher if our existing
 review attention were more coordinated. Nova has had some success with
 priorities, and Swift works well with a PTL curated etherpad of
 suggested reviews. I'd like to discuss the options with other heat
 cores, and am currently suggesting something like the Swift approach.
 
 As the Big Tent process continues to mature I'd like to ensure that Heat
 is well positioned to qualify for the appropriate tags as they are
 defined. Also it would be worth looking into whether there should be
 heat-related tags available for projects with sufficiently mature
 resource implementations.
 
 I'll be continuing Heat's tradition of the leadership emerging from a
 shared consensus, leaving the PTL as a point of coordination within the
 project, and a point of communication to the greater ecosystem.
 
 I look forward to the opportunity to do this!
 
 Steve
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 




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] [Zaqar] PTL Candidacy

confirmed

On 04/07/2015 05:35 AM, Flavio Percoco wrote:
 Greetings,
 
 You read it right, you've not burned out yet - I probably will. Here's
 a crazy idea, what if I run for 2 PTL positions on the projects I've
 been putting my focus on lately? Hopefully, by sending this out now,
 I'll be able to answer all your questions in time before the candidacy
 period closes.
 
 Before you jump out of your chair, pull your hair off and start
 asking: Is that even possible? Let me tell you that, as far as I can
 tell by reading our governance repo[0], it seems to be entirely
 legal. If you think it is not, please do let me know.
 
 Now, to my candidacy. During the Juno development cycle, I had the
 pleasure to be Zaqar's PTL. During this cycle, we managed to kick of
 complete - at least in an experimental version - some exciting
 features and we've also kicked off others - you can read more about
 that here[1]. We did that with a small team of old and new
 contributors, if it doesn't seem much to you, I'd love to invite you
 to our team and help us out. :D
 
 That said, I think our most important goal during Juno was
 incorporating the feedback we got from the community, after our last
 incubation attempt, in a way that doesn't compromise the project's
 goals but still brings in way more flexibility to the project. This
 will allow for the community (Zaqar's and OpenStack's) to finally
 adopt the project wherever it might be needed.
 
 Based on the above results and the fact that I believe the community
 hasn't seen enough (anything) of Zaqar yet, I'd like to throw my hat
 out there to be Zaqar's PTL for another cycle. Here are some things
 that I'd like us to do during this cycle:
 
 1. Spread the word and improve our interaction with the overall
 community. We've spent lot of time heads down coding new features and
 working out the best way to deliver this project. I believe it's time
 to throw it out there and let it crash (if you know what I mean).
 
 2. Restore/Improve our community activities by improving our
 communications through the openstack mailing list, restoring our
 weekly meetings and contributing back to other projects.
 
 3. Keep improving our deployment story/tools. We've a draft of a
 puppet manifest that we need to complete, we've devstack support but
 we ought to bring it into our code base and extend it with other
 features that have been developed.
 
 4. Keep our amazing mentoring story alive by helping new mentees to
 integrate with OpenStack, open source and obviously, Zaqar. Something
 this team should be proud of is that it's mentored new contributors
 since it was created.
 
 The above and more, I'd be honored to do together with the rest of the
 team.
 
 Now, to the obvious natural question: How will I be the PTL of 2
 projects and get to the end of the  cycle?
 
 Well, this definitely will require some changes from my side and my
 current focus that you'll see happen if I have the honor to be elected
 for both projects. Will I be burned out at the end of the cycle?
 Probably, but that's a price I'm willing to pay for these 2 projects
 and more importantly for OpenStack because I truly believe these
 projects play (or will play in the case of Zaqar) and important role
 in our ecosystem.
 
 In addition to the above, I must say that, thankfully enough, Zaqar is
 still not such a time consuming project from a PTL perspective and
 it's entirely feasible to be the PTL of these 2 projects and still do
 a good job - last famous words.
 
 In all seriousness, I'd be honored to serve for both projects and I
 hope you'll join me in this experiment.
 
 [0]
 https://git.openstack.org/cgit/openstack/governance/tree/reference/charter.rst
 
 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2015-April/060446.html
 
 Cheers,
 Flavio
 
 -- 
 @flaper87
 Flavio Percoco
 
 
 __
 OpenStack Development Mailing 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] [TripleO] PTL Candidacy

confirmed

On 04/06/2015 11:42 PM, James Slagle wrote:
 Hi,
 
 I'm running for TripleO PTL for the Liberty cycle. I've been an active
 TripleO developer and contributor for going on 2 years now.
 
 I'm really excited about all the great progress TripleO made during Kilo.
 The puppet integration is almost fully complete and has enabled several
 aspects that I'd like to see TripleO continue to improve on during Liberty:
 
 * Better defined interfaces in tripleo-heat-templates -- The puppet work has
 moved us to having a cleaner separation in the templates between the actual
 deployment and configuration of the Overcloud. I'd like to see us build on
 this work, particularly in a way that will enable integration with Kolla so
 we can have a Heat deployed containerized Overcloud.
 
 * Package based updates -- I really feel a traditional distribution based
 package based story is the quickest way to providing an update solution for
 TripleO. Containerization, once integrated, could provide a second update
 solution that would provide many of the same benefits as an image based
 update model.
 
 * CI coverage -- tripleo-ci continues to prove it's value by finding real
 regressions in OpenStack that otherwise would have been missed. I'd like to
 continue to press on our CI and use it to report on other projects (such as
 the puppet modules) where that desire exists.
 
 There are a few other items that I feel are important for us to focus on
 during Liberty:
 
 I feel we can do a better job releasing our software projects in a way that
 makes it easier to consume TripleO.  Particularly in such a way that it's
 more obvious how to use it together to deploy OpenStack. I think a part of
 that would be the re-introduction of using stable branches and to improve
 our documentation on deploying via TripleO.
 
 I'd also like to see us make it easier for users to get started with
 TripleO.  The only so called entry point or way to get started with
 TripleO currently is devtest.  While devtest works for developers and at
 driving our CI, I don't consider it something to be used for deploying an
 actual production cloud. I think we need to work to fill this gap.
 
 Making things easier to get started would also help us bring in new
 developers.  In the same vein, we grow our developer community by
 integrating with things like Puppet and Kolla. I think we have a lot of
 great opportunity here to show how TripleO can integrate with new and
 existing deployment solutions.
 
 Finally, moving forward, I'd like to see our project encourage more
 leadership growth. I don't feel like the majority of a project's leadership
 needs to come from just 1 (or a few) individual or role. If elected as PTL,
 I'd look forward to fostering this type of growth in our community.
 
 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

Re: [openstack-dev] [Ironic] PTL Candidacy

confirmed

On 04/07/2015 06:58 AM, Devananda van der Veen wrote:
 Hi all,
 
 I'd like to announce my candidacy as PTL for Ironic for the Liberty cycle.
 I've been involved in OpenStack since the Essex cycle, and have served as
 PTL for Ironic since I started the project at the Havana summit. As the
 project has matured, my day-to-day activity within the project has changed
 from writing code to mentoring to enabling subteams. Recently, I have begun
 to spend more time on projects within my employer; while I expect that to
 continue, the two roles complement each other and, as such, I would like to
 continue to serve as PTL for another cycle.
 
 I'd like to thank everyone who continues to lend their knowledge, hard
 work, and humor to making this project successful and this community
 enjoyable to work with.
 
 Looking back at the Juno release, we saw integration with Nova and many new
 hardware drivers in Ironic. During Kilo, we have had minimal changes to the
 nova.virt.ironic driver, and only two new hardware drivers. On the other
 hand, we've had many changes within Ironic and implemented several features
 which align with the goals which I set out at the beginning of the cycle.
 
 In the day-to-day pace of staring at review boards and patches that haven't
 merged yet, we often get frustrated because it feels like things don't move
 fast enough. When I look back at the last six months, the picture looks
 different. I think we have accomplished a lot, and I believe that is a
 result of empowering sub-teams and building stable APIs between services
 and libraries. I'd like to highlight a few of the biggest accomplishments.
 
 As a result of discussions at the Paris design summit, we spent a hefty
 chunk of the cycle designing and implementing a finite state machine [1] to
 formally model the transitions between node states. We then implemented
 support for two of the new state transitions (introspection and cleaning).
 
 This exposed a flaw in the pre-Kilo node states which we've addressed, but
 that change caused us to rev the API in an incompatible way. To maintain
 compatibility with Juno-era clients, we borrowed from Nova's lead with API
 microversions and implemented support [2] for those as well. Even so, this
 change led to more friction than any other change in Ironic during this
 cycle, and is a good reminder that building a stable API is possibly the
 most important thing we do.
 
 We gave drivers the ability to maintain internal state in the database and
 to register their own periodic tasks, and we added iRMC (Fujitsu) and AMT
 (Intel) drivers. We also continue to hold to our guarantee of
 backwards-compatibility at the driver API layer, which has led to more than
 one out-of-tree driver cropping up. It has also led to some driver
 developers publishing new libraries for their hardware, and plugging those
 in to Ironic with relatively little effort. [3] For the record, I think
 that's fantastic, and we should continue enabling that. The proliantutils
 [4] project is just one example of this; several others are being developed
 elsewhere and released to pypi by their vendors.
 
 The ironic-python-agent [5] project has been around for just over a year
 now, and I'm very pleased both with the project and the team integration.
 The ironic-discoverd project [6] is just over six months old; devstack
 support is in the works and so I hope that by the end of the Liberty cycle,
 it will be integrated and tested alongside with Ironic. Even more recently,
 the bifrost project [7] was created to demonstrate the functionality of a
 stand-alone Ironic service and simplify small-scale hardware deployment. As
 it turns out, this is a convenient way to do functional testing of Ironic
 without a full OpenStack deployment, so we'll be exploring that in Liberty.
 
 I'm sure I've left some things out - this really isn't the place for full
 release notes anyway :)
 
 In Liberty, I'd like us to complete the state machine, split the boot and
 deploy interfaces, and complete the client side of client-server version
 negotiation. That's enough changes in the core of the project for one cycle.
 
 I'd like to see more consistency in feature coverage across hardware
 drivers, as well as better tracking and communication about each drivers'
 capabilities.
 
 We need to keep abreast of changes in the horizontal efforts across
 OpenStack -- oslo, qa, and docs. In particular, we will need to look at the
 move to in-tree functional testing and determine how we want to structure
 that for ourselves. We also have no presence in the OpenStack Manual,
 though our developer docs have sprouted several pages geared towards
 operators [8]. Whether our operator-centric docs stay in the code tree or
 are moved elsewhere, we should continue to develop them.
 
 As the contributor base grows, we may need to re-evaluate the team
 structure, but right now I think things are going well in this area. I plan
 to continue guiding us in a

Re: [openstack-dev] [Horizon] PTL Candidacy

confirmed

On 04/03/2015 01:28 PM, David Lyle wrote:
 I would like to announce my candidacy for Horizon PTL. I have been actively
 contributing to Horizon since the Grizzly Summit and I've had the pleasure
 of serving as PTL for the last three cycles.
 
 In Kilo, we accelerated Horizon's adoption of AngularJS. We made a great
 deal of progress, with a near finished replacement of the launch instance
 workflow, The launch instance workflow was the number one usability issue
 in Horizon when tested. We've also created a framework to standardize and
 improve how filtering, pagination and data loading is managed in tables.
 The utilization of this framework begins in Liberty.
 
 We've worked to better incorporate UX design into our process. The UX team
 is now a part of the feature design process. In Liberty, we'll look to
 further formalize this workflow. Additionally, we've conducted several
 usability studies to obtain feedback on designs and information
 architecture from users and potential users. The results are helping guide
 design as we move forward. We will continue to test new and existing
 interfaces and designs.
 
 Over the past three cycles, interest in Horizon has grown dramatically, but
 as with most of OpenStack, we are feeling those growing pains. As a
 horizontal integration point, Horizon needs to adapt to handle the
 increasing breadth of services in OpenStack. In Juno and Kilo, we built and
 refined a plugin system for adding new content into Horizon. In Liberty,
 we'll see more services utilizing this mechanism and allow service teams to
 retain greater control of their Horizon content.
 
 In Liberty, Horizon needs to focus on existing efforts around improving
 usability, better support for large deployments and more useful
 administrative interfaces. We've set the stage to make significant strides
 in Liberty. I appreciate your consideration for the opportunity to continue
 enabling our tremendous team of contributors to make it happen.
 
 I'm excited by the progress we've made and the prospect of seeing several
 of our project's long term goals become reality in Liberty.
 
 Thanks,
 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
 




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] [Infra] PTL Candidacy

confirmed

On 04/02/2015 05:35 PM, James E. Blair wrote:
 I would like to announce my candidacy for the Infrastructure PTL.
 
 I have developed and operated the project infrastructure for several
 years and have been honored to serve as the PTL for the Kilo cycle.
 
 I was instrumental not only in creating the project gating system and
 development process, but also in scaling it from three projects to 600.
 
 In Juno, we have begun a real effort to make the project infrastructure
 consumable in its own right.  We've made a lot of progress and we're
 seeing more people joining this effort as we get closer to the goal of
 re-usability.  It's starting to pay off, but we still have a lot to do.
 
 We're also looking at getting into the business of operating an
 OpenStack cloud.  This is potentially a very exciting new venture, with
 a heavily used production cloud available for anyone in OpenStack to see
 and alter its operation.  We're only just starting this project and hope
 to settle on some parameters as soon as we finish up our current
 priorities.
 
 I have also proposed some major changes to the key infrastructure
 projects Zuul and Nodepool.  In both cases, the intent is to help us
 continue to scale out the system to handle more projects easier, and to
 make the overall system more comprehensible.
 
 Those are just three of several important efforts I anticipate this
 cycle and they span the spectrum from software development to
 operations.  Once again, a large part of the work of the PTL this cycle
 will be helping to coordinate and facilitate these efforts.
 
 I am thrilled to be a part of one of the most open free software project
 infrastructures, and I would very much like to continue to serve as its
 PTL.
 
 Thanks,
 
 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

Re: [openstack-dev] [Ceilometer] PTL candidacy

confirmed

On 04/02/2015 04:29 PM, gordon chung wrote:
 hi,
 i'd like to announce my candidacy for PTL of Ceilometer.
 as a quick introduction, i've been a contributor in OpenStack for the past 
 few years and for the majority of that time i've been primarily focused on 
 Ceilometer where i contribute regularly to the project with code[1] and 
 reviews[2]. i'm currently an engineer at Red Hat and have previously worked 
 for eNovance and IBM, where in the latter's case, i helped work on advancing 
 the adoption of cloud auditing practices within the community, which i 
 continue to do.
 to model myself on past PTLs i've worked with, my main goal as PTL will be to 
 support the community of contributors that exists within OpenStack with 
 interests in telemetry. i believe we have a wide variety of contributors with 
 various expertise in Ceilometer and OpenStack and while differing opinions 
 have arisen, as a collective, we have -- and can continue to -- hash out the 
 ideal solutions.
 with the politically correct portion all covered, my other interests are: 
 stability, the transition to time-series data modeling aka Gnocchi, and 
 events.
 - we've made strides in Ceilometer over the past cycles to improve stability 
 by adding HA support, remodeling backends, and removing redundancies in 
 Ceilometer. i want to make sure we remain critical of new changes and always 
 ensure they do not add bloat to Ceilometer.
 - in regards to data storage, while Ceilometer can be used solely as a data 
 retrieval service, i believe Gnocchi -- the modeling of data as a time-series 
 -- will provide a scalable means to storing measurement data regarding 
 OpenStack[3]. this work, i believe, will be important for those using 
 Ceilometer as a complete solution.
 - the concept of events was realised by the team at RAX and was worked on 
 further in the last cycle. i hope to see this functionality continue to 
 expand by adding the ability to derive and act on events to allow greater 
 insight into the system.
 - lastly, i want to emphasise documentation. Ceilometer's scope touches all 
 projects and because of that, it can be difficult to pick up. in Kilo, we 
 started to emphasise the importance of documentation and i hope we continue 
 to do so going forward.
 [1] 
 https://review.openstack.org/#/q/owner:%22gordon+chung%22+project:openstack/ceilometer,n,z[2]
  http://russellbryant.net/openstack-stats/ceilometer-reviewers-365.txt[3] 
 http://www.slideshare.net/EoghanGlynn/rdo-hangout-on-gnocchi
 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

Re: [openstack-dev] [QA] PTL Candidacy

confirmed

On 04/03/2015 12:33 PM, Matthew Treinish wrote:
 Hi Everyone,
 
 I'd like to throw my hat into the ring for another cycle as the PTL for the QA
 program/team/group/whatever it's called under the new governance model.
 
 This past cycle has been a very exciting one for the QA program. We've made a
 bunch of progress on numerous work items to improve the growing number of
 projects under the QA umbrella. While this work is ongoing we've also had to
 adapt as the wider community has been moving to a new governance model.
 
 We've been working to make the QA program more externally accessible and
 consumable in preparation for a large growth in the number of projects. On the
 tempest side this has meant a steady expansion of code being moved into
 tempest-lib to provide resources, which were previously only available in
 tempest, externally consumable. For devstack we've seen the addition of plugin
 support which allows new projects to leverage deploying, testing, and 
 developing
 with devstack without needing to modify devstack's code itself.
 
 Another effort which I outlined in my candidacy email for this past cycle [1]
 and a blog post preceding that [2] was the work to make the QA projects more
 modular and reusable. It turned out that this work lines up quite well with 
 what
 is needed to enable the self service model we're working towards under the big
 tent. I expect that as we continue to evolve our current set of projects to be
 more modular and work under the big tent that using the tooling in different
 workflows will also improve.
 
 Moving into Liberty my plan is to continue heading down this same path and
 working to enable more projects to become self sufficient when using QA
 projects. To this end I expect we'll be adding a similar external plugin
 interface into grenade early in liberty, a continued expansion on the use of
 devstack plugins, and migrating more of tempest's common code over to
 tempest-lib.
 
 Additionally, the continued efforts that we've been pushing for some time to
 make tempest and the other QA projects easier to use in general, both in and
 out of the gate, will definitely continue. This is something we've made a lot 
 of
 progress on this past cycle and think it will definitely be a continued 
 priority
 for Liberty.
 
 It's been my honor to serve as the QA PTL for the past 2 cycles and I'm 
 looking
 forward to helping make Liberty another great cycle. I hope to have the
 opportunity to continue leading the QA program as PTL and work towards making
 a better OpenStack with the rest of the community.
 
 Thanks,
 
 Matt Treinish
 
 [1] 
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/046704.html
 [2] http://blog.kortar.org/?p=4
 
 
 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 




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] [Keystone] PTL Candidacy

confirmed

On 04/02/2015 04:31 PM, Morgan Fainberg wrote:
 Hello Everyone!
 
 
 
 It’s been an exciting development cycle (Kilo) and it is now time to start
 looking forward at Liberty and what that will hold. With that said, I’d
 like to ask for the community’s support to continue as the Keystone PTL for
 the Liberty release cycle.
 
 
 
 I came to the table last cycle with a general goal of driving towards
 stability and improvement on user experience[1]. For the most part the
 Keystone team has managed to improve on a number of the big outstanding
 issues:
 
 
 
 * Token Persistence issues (table bloat, etc), solved with non-persistent
 (Fernet) tokens.
 
 
 
 * Improvements on the Federated identity use-cases.
 
 
 
 * Hierarchical Multi-Tenancy (initial implementation)
 
 
 
 * Significant progress on Keystone V3-only deployment models (a lot of work
 in the Keystone Client and Keystone Middleware)
 
 
 
 * A good deal of technical debt paydown / cleanup
 
 
 
 This cycle I come back to say that I don’t want to shake things up too
 much. I think we have a successful team of developers, reviewers,
 bug-triagers, and operators collaborating to make Keystone a solid part of
 the OpenStack Ecosystem. I remain committed to enabling the contributors
 (of all walks) to be part of our community and achieve success.
 
 
 
 For the Liberty cycle I would like to see a continued focus on performance,
 user experience, deployer experience, and stability. What does this really
 mean for everyone contributing to Keystone? It means there are two clear
 sides for the Liberty cycle.
 
 
 
 New Feature Work:
 
 -
 
 
 
 I want to see the development community pick a solid 5 or so “new” features
 to land in Liberty and really hit those out of the park (focused
 development from the very beginning of the cycle). Generally speaking, it
 looks that the new feature list is lining up around providing support /
 significantly better experience for the other project(s) under the
 OpenStack  tent. In short, I see Keystone new development being less about
 the “interesting thing Keystone can do” and more about “the great things
 Keystone can do for the other projects”.
 
 
 
 Non-Feature Work:
 
 -
 
 
 
 We have a lot of drivers/plugins, backends, all with their own rapidly
 moving interfaces that make it hard to know what to expect in the next
 release. It is time we sit down and commit to the interfaces for the
 backends, treat them as stable (just like the REST interface). A stable ABI
 for the Keystone backends/plugins goes a long way towards enabling our
 community to develop a rich set of backends/plugins for Identity,
 Assignment, Roles, Policy, etc. This is a further embracing of the “Big
 Tent” conversation; for example we can allow for constructive competition
 in how Keystone retrieves Identity from an Identity store (such as LDAP,
 AD, or SQL). Not all of the solutions need to be in the Keystone tree
 itself, but a developer can be assured that their driver isn’t going to
 need radical alterations between Liberty and the next release with this
 commitment to stable ABIs.
 
 
 
 Beyond the stable interface discussion, the other top “non-feature”
 priorities are having a fully realized functional test suite (that can be
 run against an arbitrary deployment of Keystone, with whichever
 backend/configuration is desired), a serious look at performance profiling
 and what we can do to solve the next level of scaling issues, the ability
 to deploy OpenStack without Keystone V2 enabled, and finally looking at the
 REST API itself so that we can identify how we can improve the end-user’s
 experience (the user who consumes the API itself) especially when it comes
 to interacting with deployments with different backend configurations.
 
 
 
 Some Concluding Thoughts:
 
 
 
 
 
 I’ll reiterate my conclusion from the last time I ran, as it still
 absolutely sums up my feelings:
 
 
 
 Above and beyond everything else, as PTL, I am looking to support the
 outstanding community of developers so that we can continue Keystone’s
 success. Without the dedication and hard work of everyone who has
 contributed to Keystone we would not be where we are today. I am extremely
 pleased with how far we’ve come and look forward to seeing the continued
 success as we move into the Liberty release cycle and beyond not just for
 Keystone but all of OpenStack.
 
 
 
 Cheers,
 
 Morgan Fainberg
 
 
 
 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/046571.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
 




signature.asc
Description: OpenPGP digital signature

Re: [openstack-dev] [Cinder] PTL Candidacy

confirmed

On 04/02/2015 02:46 PM, Mike Perez wrote:
 Hello all,
 
 I'm announcing my candidacy for Cinder PTL for the Liberty release.
 
 I have contributed to block storage in OpenStack since Bexar back when things
 were within nova-volume, before Cinder, and the honor of serving as PTL for
 Cinder in the Kilo cycle.
 
 I've spoke in the past about focused participation, something I still feel is
 needed in the projects that are the basic foundation of OpenStack. Compute,
 storage and networking need to be solid. My work as core in Cinder and
 continuing as PTL has involved a lot of evangelizing and making new
 contributors feel comfortable with becoming part of the team. As a project
 grows, communication needs to be excellent, coordination is key to making sure
 reviews don't stick around too long for contributors to feel discouraged.
 I think the Cinder team has done an excellent job in managing this as we grow,
 based on the feedback received. I really do think participation in Cinder
 is getting better, and it's wonderful to be part of that.
 
 If we take the Kilo-3 milestone for example, we landed 44 blueprints in
 a single milestone [1]. That's huge progress. I would like to believe this
 happens because of focus, and that happens because of better tracking of what
 is a priority and clear communication. Lastly participation, not just core
 folks, but any contributor that feels welcomed by the team and not to be burnt
 out on never ending patch revisions.
 
 Most of 2014 in Cinder was a lot of discussions on third party CI's. Third
 party CI's are a great way for vendors to verify if a proposed upstream patch
 would break their integration. In addition, it identifies if a vendor really
 does work with the current state of the OpenStack project. There have been
 plenty of cases that vendors discovered that their integration in OpenStack
 really didn't work until they ran these tests. Last year, there was a real 
 lack
 of coordination and communication with vendors on getting them on board with
 reporting third party CI results. In 2015 I took on the responsibility of 
 being
 the point of contact for the 70+ drivers in Cinder, emailing the mailing list,
 countless reminders on IRC, contacting maintainers directly, and actually
 making phone calls to companies if maintainers were not responsive by email.
 
 I'm happy to report that majority of vendors have responded back and are 
 active
 in the Cinder community to ensure their integration is solid. Compare that to
 last year when we just had one or two vendors reporting and majority of 
 vendors
 not having a clue! It's very exciting to help build a better experience for
 their users using OpenStack. The communities pouring support to me on this
 issue was hugely appreciated, and is what keeps me coming back to help.
 
 We added 14 new drivers to Cinder in the Kilo release. Coordination was
 beautiful thanks to clear communication and coordination with the hard working
 reviewers in the Cinder team.
 
 My priorities for Cinder in the Kilo release was to make progress on rolling
 upgrades. I have spent a greater deal of my time testing the work to allow
 Cinder services to not be dependent on database schemas. This is a big change,
 and doesn't completely solve rolling upgrades in Cinder, but is a building
 block needed to begin solving the other rolling upgrade problems. I'm really
 happy with the work done by the team in the Kilo release and excited with how
 comfortable I feel in terms of stability of the work thanks to the amount of
 testing we've done.
 
 This work however not only benefits Cinder, but is a general solution into
 Oslo, in attempt to help other OpenStack projects in upgrades. Upgrades are
 a huge problem that needs to be solved across OpenStack, and I'm proud of the
 Cinder team for helping do their part to help drive adoption. Long term I see
 this work contributing to an ideal single upgrade solution, so that operators
 aren't having to learn how to upgrade 12 different services they may deploy.
 
 My plans for Liberty is to work with the team on creating a better use of
 milestones for appropriate changes. While we started some initial requirements
 like making new drivers focus on the first milestone only, I think stability
 time needs to be stretched a bit longer, and I think others will agree Kilo
 didn't have a lot of this as planned for Kilo-3.
 
 Cinder  will continue on efforts for rolling upgrades by now focusing on
 compatibility across Cinder services with RPC. This is a very important piece
 for making rolling upgrades complete. We will continue to work through 
 projects
 like Oslo to make sure these solutions general enough to benefit other
 OpenStack projects, so as a whole, we will improve together.
 
 Cinder volumes that end up in a stuck state. This has been a problem for ages,
 and I have heard from countless people at the Ops Midcycle Meetup that
 I attended. I'm happy to say, as reported from my take on

Re: [openstack-dev] [Magnum] PTL Candidacy

confirmed

On 04/02/2015 12:36 PM, Adrian Otto wrote:
 I respectfully respect your support to continue as your Magnum PTL.
 
 Here are are my achievements and OpenStack experience and that make me the 
 best choice for this role:
 
 * Founder of the OpenStack Containers Team
 * Established vision and specification for Magnum
 * Served as PTL for Magnum since the first line of code was contributed in 
 November 2014
 * Successful addition of Magnum to the official OpenStack projects list on 
 2015-03-24
 * Planned and executed successful Magnum Midcycle meetup in March 2015
 * 3 terms of experience as elected PTL for Solum
 * Involved with OpenStack since Austin Design Summit in 2010
 
 What background and skills help me to do this role well:
 
 * 20 years of experience in technical leadership positions
 * Considerable experience leading milti-organization collaborations
 * Diplomacy skills for inclusion of numerous viewpoints, and ability to drive 
 consensus and shared vision
 * Considerable experience in public speaking, and running design summit 
 sessions
 * Deep belief in Open Source, Open Development, Open Design, and Open 
 Community
 * I love OpenStack and I love containers, probably more than anyone else in 
 the world in this combination.
 
 What to expect in the Liberty release cycle:
 
 We will continue to focus on making the best Containers-as-a-Service solution 
 for cloud operators. This requires a valuable vertical integration of 
 container management tools with OpenStack. Magnum is quickly maturing. Here 
 are key focus areas that I believe are important for us to work on during our 
 next release:
 
 * Functional testing, and unit test code coverage
 * Overlay networking 
 * Bay type choices (allow for plugging in prevailing container execution 
 engines as needed)
 * Surface additional (small/medium) features (TLS Security, Autoscaling, Load 
 balancer management, etc.)
 
 I look forward to your vote, and to helping us succeed together.
 
 Thanks,
 
 Adrian Otto
 __
 OpenStack Development Mailing 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] [Elections] Nominations for OpenStack PTLs (Program Technical Leads) are now open

Nominations for OpenStack PTLs (Program Technical Leads) are now open
and will remain open until April 9, 2015 05:59 UTC.

To announce your candidacy please start a new openstack-dev at
lists.openstack.org mailing list thread with the program name as a tag,
example [Glance] PTL Candidacy with the body as your announcement of
intent. People who are not the candidate, please refrain from posting +1
to the candidate announcement posting.

I'm sure the electorate would appreciate a bit of information about why
you would make a great PTL and the direction you would like to take the
program, though it is not required for eligibility.

In order to be an eligible candidate (and be allowed to vote) in a given
PTL election, you need to have contributed an accepted patch to one of
the corresponding program's projects[0] during the Juno-Kilo
timeframe (April 9, 2014 06:00 UTC to April 9, 2015 05:59 UTC).

We need to elect PTLs for 25 programs this round:
* Compute (Nova) - one position
* Object Storage (Swift) - one position
* Image Service (Glance) - one position
* Identity (Keystone) - one position
* Dashboard (Horizon) - one position
* Networking (Neutron) - one position
* Block Storage (Cinder) - one position
* Metering/Monitoring (Ceilometer) - one position
* Orchestration (Heat) - one position
* Database Service (Trove) - one position
* Bare metal (Ironic) - one position
* Common Libraries (Oslo) - one position
* Infrastructure - one position
* Documentation - one position
* Quality Assurance (QA) - one position
* Deployment (TripleO) - one position
* Release cycle management  - one position
* Message service (Zaqar) - one position
* Data Processing Service (Sahara) - one position
* Key Management Service (Barbican) - one position
* DNS Services (Designate) - one position
* Shared File Systems (Manila) - one position
* Command Line Client (OpenStackClient) - one position
* OpenStack Containers Service (Magnum) - one position
* Application Catalog (Murano) - one position

Additional information about the nomination process can be found here:
https://wiki.openstack.org/wiki/PTL_Elections_April_2015

As Elizabeth and I confirm candidates, we will reply to each email
thread with confirmed and add each candidate's name to the list of
confirmed candidates on the above wiki page.

Elections will begin on April 10, 2015 (as soon as we get each election
set up we will start it, it will probably be a staggered start) and run
until after 13:00 UTC April 16, 2015.

The electorate is requested to confirm their email address in gerrit,
review.openstack.org  Settings  Contact Information   Preferred
Email, prior to April 9, 2015 05:59 UTC so that the emailed
ballots are mailed to the correct email address.

Happy running,
Tristan Cacqueray (tristanC)

[0]
https://github.com/openstack/governance/blob/master/reference/projects.yaml



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] [Glance] PTL Candidacy

confirmed

On 04/02/2015 10:53 AM, Flavio Percoco wrote:
 Greetings,
 
 I'd like to put my name out there for the Glance PTL position.
 
 Few words about me:
 
 I'm Flavio Percoco (flaper87 on IRC and everywhere). I've been an
 OpenStack fellow for the last 2 1/2 years. During this time I've
 spread my efforts on several projects but mainly on Glance, from which
 you may/may not know me.
 
 Glance
 ==
 
 Since my early days in OpenStack, I've been part of every core - core
 in terms of service, not membership - decision in Glance. From what to
 do with the registry service, glance_store, API stability etc.
 Throughout these decisions, I've participated in the release process,
 leading positions and also as a voice for those changes.
 
 I'm happy to say that our project has grown a lot and that we're
 facing new challenges that I'd love to be part of and more
 importantly, I'd love to help leading those efforts along side our,
 growing, community.
 
 Interesting things happened in Kilo but I'd like to focus now on
 what's coming next, Liberty.
 
 One of the things that is still pending for us is the work on
 Artifacts. Despite I don't believing that Glance is the best for it to
 live forever, I'd love to see this work done and for it to grow. The
 effort that is being put there not only code-wise, feature-wise but
 also review-wise is already a good enough proof of how the impact this
 could have in our community.
 
 In addition to the above, I'd love our team to improve Glance's API
 story throughout OpenStack and see such API grow and stabilize. This
 not only refers to the service itself but the libraries that Glance
 relies on too. I strongly believe that stability and consistency
 should be part of our main goals in the upcoming development cycle.
 
 New features will be proposed for sure and I'd love us all to review
 them together and decide together what's best for the project's future
 baring in mind the goals of the cycle.
 
 Community
 =
 
 Thankfully enough, I've had the pleasure to be involved in many areas
 of our community and this has given me a good knowledge of how our
 community is structured and how the different parts interact with each
 other. From the stability team to our infrastructure team going
 through OpenStack's common ground (Oslo). I'd love to use this broad
 view in this position as I've been using it as a contributor.
 
 In the other hand, I'm also known from being noisy, speaking up and
 ready to fight whenever it's needed (even when it is not :P). Just
 like with everything else, I'm looking forward to apply all this to
 this position as I've done in my current position.
 
 Last but no least, I've had the pleasure to be Zaqar's PTL during Kilo
 (and co-PTL since the beginning), which has as well prepared me for
 this task.
 
 Thanks for reading thus far, I hope you'll consider me as a good
 candidate for this position.
 Flavio
 
 
 
 __
 OpenStack Development Mailing 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] [Nova] PTL Candidacy

confirmed

On 04/02/2015 02:20 AM, Michael Still wrote:
 I'd like another term as Nova PTL, if you'll have me.
 
 I feel Kilo has gone reasonably well for Nova -- our experiment with
 priorities has meant that we’ve got a lot of important work done. We
 have progressed well with cells v2, our continued objects transition,
 scheduler refactoring, and the v2.1 API. The introduction of the
 trivial bug review list at the mid-cycle meetup has also seen 123 bug
 fixes merged since the mid-cycle, which is a great start.
 
 Kilo is our second release using specs, and I think this process is
 still working well for us -- we’re having fewer arguments at code
 review time about the fundamentals of design, and we’re signalling to
 operators much better what we’re currently working on. Throughout Kilo
 I wrote regular summaries of the currently approved specs, and that
 seems to have been popular with operators.
 
 We also pivoted a little in Kilo and created a trivial approval
 process for Kilo specs which either were very small, or previously
 approved in Juno. This released the authors of those specs from
 meaningless paperwork, and meant that we were able to start merging
 that work very early in the release cycle. I think we should continue
 with this process in Liberty.
 
 I think its a good idea also to examine briefly some statistics about specs:
 
 Juno:
approved but not implemented: 40
implemented: 49
 
 Kilo:
approved but not implemented: 30
implemented: 32
 
 For those previously approved in Juno, 12 were implemented in Kilo.
 However, we’ve now approved 7 specs twice, but not merged an
 implementation. I’d like to spend some time at the start of Liberty
 trying to work out what’s happening with those 7 specs and why we
 haven’t managed to land an implementation yet. Approving specs is a
 fair bit of work, so doing it and then not merging an implementation
 is something we should dig into.
 
 There are certainly priorities which haven’t gone so well in Kilo. We
 need to progress more on functional testing, the nova-network
 migration effort, and CI testing consistency our drivers. These are
 obvious things to try and progress in Liberty, but I don’t want to
 pre-empt the design summit discussions by saying that these should be
 on the priority list of Liberty.
 
 In my Kilo PTL candidacy email, I called for a “social approach” to
 the problems we faced at the time, and that’s what I have focussed on
 for this release cycle. At the start of the release we didn’t have an
 agreed plan for how to implement the specifics for the v2.1 API, and
 we talked through that really well. What we’ve ended up with is an
 implementation in tree which I think will meet our needs going
 forward. We are similarly still in a talking phase with the
 nova-network migration work, and I think that might continue for a bit
 longer -- the problem there is that we need a shared vision for what
 this migration will look like while meeting the needs of the deployers
 who are yet to migrate.
 
 Our velocity continues to amaze me, and I don’t think we’re going
 noticeably slower than we did in Juno. In Juno we saw 2,974 changes
 with 16,112 patchsets, and 21,958 reviews. In Kilo we have seen 2,886
 changes with 15,668 patchsets and 19,516 reviews at the time of
 writing this email. For comparison, Neutron saw 11,333 patchsets and
 Swift saw 1,139 patchsets for Kilo.
 
 I’d like to thank everyone for their hard work during Kilo. I am
 personally very excited by what we achieved in Nova in Kilo, and I’m
 looking forwards to Liberty. I hope you are looking forward to our
 next release as well!
 
 Michael
 




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] [neutron] PTL Candidacy