Re: [openstack-dev] [tripleo] PTL candidacy for the Stein Cycle

[Cédric Jeanneret]

+1 :).

On 07/25/2018 02:03 PM, Juan Antonio Osorio wrote:
> Hello folks!
> 
> I'd like to nominate myself for the TripleO PTL role for the Stein cycle.
> 
> Alex has done a great job as a PTL: The project is progressing nicely
> with many
> new, exciting features and uses for TripleO coming to fruition recently.
> It's a
> great time for the project. But, there's more work to be done.
> 
> I have served the TripleO community as a core-reviewer for some years
> now and,
> more recently, by driving the Security Squad. This project has been a
> great learning experience for me, both technically (I got to learn even
> more of
> OpenStack) and community-wise. Now I wish to better serve the community
> further
> by bringing my experiences into PTL role. While I have not yet served as PTL
> for a project before,I'm eager to learn the ropes and help improve the
> community that has been so influential on me.
> 
> For Stein, I would like to focus on:
> 
> * Increasing TripleO's usage in the testing of other projects
>   Now that TripleO can deploy a standalone OpenStack installation, I hope it
>   can be leveraged to add value to other projects' testing efforts. I
> hope this
>   would subsequentially help increase TripleO's testing coverage, and reduce
>   the footprint required for full-deployment testing.
> 
> * Technical Debt & simplification
>   We've been working on simplifying the deployment story and battle
> technical
>   depth -- let’s keep  this momentum going.  We've been running (mostly)
> fully
>   containerized environments for a couple of releases now; I hope we can
> reduce
>   the number of stacks we create, which would in turn simplify the project
>   structure (at least on the t-h-t side). We should also aim for the most
>   convergence we can achieve (e.g. CLI and UI workflows).
> 
> * CI and testing
>   The project has made great progress regarding CI and testing; lets
> keep this
>   moving forward and get developers easier ways to bring up testing
>   environments for them to work on and to be able to reproduce CI jobs.
> 
> Thanks!
> 
> Juan Antonio Osorio Robles
> IRC: jaosorior
> 
> 
> -- 
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com 
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



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 for the Stein Cycle

[John Fulton]

+1
On Wed, Jul 25, 2018 at 8:04 AM Juan Antonio Osorio  wrote:
>
> Hello folks!
>
> I'd like to nominate myself for the TripleO PTL role for the Stein cycle.
>
> Alex has done a great job as a PTL: The project is progressing nicely with 
> many
> new, exciting features and uses for TripleO coming to fruition recently. It's 
> a
> great time for the project. But, there's more work to be done.
>
> I have served the TripleO community as a core-reviewer for some years now and,
> more recently, by driving the Security Squad. This project has been a
> great learning experience for me, both technically (I got to learn even more 
> of
> OpenStack) and community-wise. Now I wish to better serve the community 
> further
> by bringing my experiences into PTL role. While I have not yet served as PTL
> for a project before,I'm eager to learn the ropes and help improve the
> community that has been so influential on me.
>
> For Stein, I would like to focus on:
>
> * Increasing TripleO's usage in the testing of other projects
>   Now that TripleO can deploy a standalone OpenStack installation, I hope it
>   can be leveraged to add value to other projects' testing efforts. I hope 
> this
>   would subsequentially help increase TripleO's testing coverage, and reduce
>   the footprint required for full-deployment testing.
>
> * Technical Debt & simplification
>   We've been working on simplifying the deployment story and battle technical
>   depth -- let’s keep  this momentum going.  We've been running (mostly) fully
>   containerized environments for a couple of releases now; I hope we can 
> reduce
>   the number of stacks we create, which would in turn simplify the project
>   structure (at least on the t-h-t side). We should also aim for the most
>   convergence we can achieve (e.g. CLI and UI workflows).
>
> * CI and testing
>   The project has made great progress regarding CI and testing; lets keep this
>   moving forward and get developers easier ways to bring up testing
>   environments for them to work on and to be able to reproduce CI jobs.
>
> Thanks!
>
> Juan Antonio Osorio Robles
> IRC: jaosorior
>
>
> --
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing 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 for the Stein Cycle

[Remo Mattei]

+1 for Juan, 


> On Jul 25, 2018, at 5:03 AM, Juan Antonio Osorio  wrote:
> 
> Hello folks!
> 
> I'd like to nominate myself for the TripleO PTL role for the Stein cycle.
> 
> Alex has done a great job as a PTL: The project is progressing nicely with 
> many
> new, exciting features and uses for TripleO coming to fruition recently. It's 
> a
> great time for the project. But, there's more work to be done.
> 
> I have served the TripleO community as a core-reviewer for some years now and,
> more recently, by driving the Security Squad. This project has been a
> great learning experience for me, both technically (I got to learn even more 
> of
> OpenStack) and community-wise. Now I wish to better serve the community 
> further
> by bringing my experiences into PTL role. While I have not yet served as PTL
> for a project before,I'm eager to learn the ropes and help improve the
> community that has been so influential on me.
> 
> For Stein, I would like to focus on:
> 
> * Increasing TripleO's usage in the testing of other projects
>   Now that TripleO can deploy a standalone OpenStack installation, I hope it
>   can be leveraged to add value to other projects' testing efforts. I hope 
> this
>   would subsequentially help increase TripleO's testing coverage, and reduce
>   the footprint required for full-deployment testing.
> 
> * Technical Debt & simplification
>   We've been working on simplifying the deployment story and battle technical
>   depth -- let’s keep  this momentum going.  We've been running (mostly) fully
>   containerized environments for a couple of releases now; I hope we can 
> reduce
>   the number of stacks we create, which would in turn simplify the project
>   structure (at least on the t-h-t side). We should also aim for the most
>   convergence we can achieve (e.g. CLI and UI workflows).
> 
> * CI and testing
>   The project has made great progress regarding CI and testing; lets keep this
>   moving forward and get developers easier ways to bring up testing
>   environments for them to work on and to be able to reproduce CI jobs.
> 
> Thanks!
> 
> Juan Antonio Osorio Robles
> IRC: jaosorior
> 
> 
> -- 
> Juan Antonio Osorio R.
> e-mail: jaosor...@gmail.com 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 

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

[openstack-dev] [tripleo] PTL candidacy for the Stein Cycle

[Juan Antonio Osorio]

Hello folks!

I'd like to nominate myself for the TripleO PTL role for the Stein cycle.

Alex has done a great job as a PTL: The project is progressing nicely with
many
new, exciting features and uses for TripleO coming to fruition recently.
It's a
great time for the project. But, there's more work to be done.

I have served the TripleO community as a core-reviewer for some years now
and,
more recently, by driving the Security Squad. This project has been a
great learning experience for me, both technically (I got to learn even
more of
OpenStack) and community-wise. Now I wish to better serve the community
further
by bringing my experiences into PTL role. While I have not yet served as PTL
for a project before,I'm eager to learn the ropes and help improve the
community that has been so influential on me.

For Stein, I would like to focus on:

* Increasing TripleO's usage in the testing of other projects
  Now that TripleO can deploy a standalone OpenStack installation, I hope it
  can be leveraged to add value to other projects' testing efforts. I hope
this
  would subsequentially help increase TripleO's testing coverage, and reduce
  the footprint required for full-deployment testing.

* Technical Debt & simplification
  We've been working on simplifying the deployment story and battle
technical
  depth -- let’s keep  this momentum going.  We've been running (mostly)
fully
  containerized environments for a couple of releases now; I hope we can
reduce
  the number of stacks we create, which would in turn simplify the project
  structure (at least on the t-h-t side). We should also aim for the most
  convergence we can achieve (e.g. CLI and UI workflows).

* CI and testing
  The project has made great progress regarding CI and testing; lets keep
this
  moving forward and get developers easier ways to bring up testing
  environments for them to work on and to be able to reproduce CI jobs.

Thanks!

Juan Antonio Osorio Robles
IRC: jaosorior


-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] PTL Candidacy

[Steven Hardy]

All, I've proposed my candidacy to the openstack/election repo [1] but
copying here for visibility.

I am announcing my candidacy for PTL for the TripleO team for the Newton
release cycle.

Over the last development cycle, I've been heavily involved with evolving the
TripleO release model to better enable consuming TripleO in the context of
OpenStack coordinated release.

We've had our share of challenges supporting the new stable/liberty branches,
such as CI capacity and an overload of backports, but I still think improving
the experience for both upstream users and downstream consumers of TripleO
remains one of the most important challenges we face, and I intend to commit
further time to this task in the Newton timeframe.

The other area I'd like to help improve is refining our template model to
better support integration with vendor drivers, and potentially giving more
operator choice in terms of the configuration management workflow.  We've
made slow progress on this during Mitaka, but I think improving composability
and enabling more operator choice remains very important, and I'd like to help
fix our branch model and free up capacity so we can make progress on this.

My view of the PTL role is that it's as much about release coordination as it
is about technical leadership, so I'd like to step up and offer to take on this
workload (with the help of our community!) for Newton.

Thanks for your consideration!

[1] https://review.openstack.org/#/c/292817/

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

[openstack-dev] [TripleO] PTL candidacy

[Dan Prince]

Hi TripleO,

My name is Dan Prince and I'm running for the Mitaka TripleO PTL. I've
been working on TripleO since Grizzly and OpenStack since Bexar. I care
deeply about the project and would like to continue the vision of
deploying OpenStack w/ OpenStack.

TripleO has come a long way over the past few years. I like how the
early vision within the project set the stage for how you can deploy
OpenStack with OpenStack. I also like how we are continuing to
transform the OpenStack deployment landscape by using OpenStack, with
all its API goodness, alongside great technologies like Puppet and
Docker. Using the best with the best... that is why I like TripleO.

A couple of areas I'd like to see us focus on for Mitaka:

CI: The ability to land code upstream is critical right now. We need to
continue to refine our CI workflow so that it is both faster, more
reliable, and gives us more coverage.

Upgrades: Perhaps one of the most important areas of focus is around
upgrades. We've made some progress towards minor updates but we've got
plenty of work to be able to support minor updates and full upgrades.

Composability: Better composability within the Heat templates would
make the 3rd party integration even easier and also give us better and
more flexible role flexibility. Role flexibility in particular may
become more desirable as we take steps towards supporting a more
containerized deployment model.

Validations: The extensibility of our low level network infrastructure
is very flexible. But it isn't easy to configure. I would like to see
us continue adding validations at key points to make this easier.
Additionally validations are critical for integration with any sort of
external resource like a Ceph cluster or load balancers.

Features: New network features like IPv6 support and better support for
spine/leaf deployment topologies. We are also refining how Tuskar works
with Heat and continuing to refine Tuskar UI around a common library
that can better leverage the installation workflows OpenStack requires.

Lots of exciting stuff to work on and a great team of developers who
are driving many of these goals. As PTL I would be honored to help
organize and drive forward the efforts of the team where needed.

Thanks for your consideration.

Dan Prince

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

[Tristan Cacqueray]

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

[openstack-dev] [TripleO] PTL Candidacy

[James Slagle]

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!

-- 
-- James Slagle
--

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

[Tristan Cacqueray]

confirmed

On 24/09/14 05:19 PM, James Slagle wrote:
 I'd like to announce my candidacy for TripleO PTL.
 
 I think most folks who have worked in the TripleO community probably know me.
 For those who don't, I work for Red Hat, and over the last year and a half 
 that
 I've been involved with TripleO I've worked in different areas. My focus has
 been on improvements to the frameworks to support things such as other 
 distros,
 packages, and offering deployment choices. I've also tried to focus on
 stabilization and documentation as well.
 
 I stand by what I said in my last candidacy announcement[1], so I'm not going
 to repeat all of that here :-).
 
 One of the reasons I've been so active in reviewing changes to the project is
 because I want to help influence the direction and move progress forward for
 TripleO. The spec process was new for TripleO during the Juno cycle, and I 
 also
 helped define that. I think that process is working well and will continue to
 evolve during Kilo as we find what works best.
 
 The TripleO team has made a lot of great progress towards full HA deployments,
 CI improvements, rearchitecting Tuskar as a deployment planning service, and
 driving features in Heat to support our use cases. I support this work
 continuing in Kilo.
 
 I continue to believe in TripleO's mission to use OpenStack itself.  I think
 the feedback provided by TripleO to other projects is very valuable. Given the
 complexity to deploy OpenStack, TripleO has set a high bar for other
 integrated projects to meet to achieve this goal. The resulting new features
 and bug fixes that have surfaced as a result has been great for all of
 OpenStack.
 
 Given that TripleO is the Deployment program though, I also support 
 alternative
 implementations where they make sense. Those implementations may be in
 TripleO's existing projects themselves, new projects entirely, or pulling in
 existing projects under the Deployment program where a desire exists. Not 
 every
 operator is going to deploy OpenStack the same way, and some organizations
 already have entrenched and accepted tooling.
 
 To that end, I would also encourage integration with other deployment tools.
 Puppet is one such example and already has wide support in the broader
 OpenStack community. I'd also like to see TripleO support different update
 mechanisms potentially with Heat's SoftwareConfig feature, which didn't yet
 exist when TripleO first defined an update strategy.
 
 The tripleo-image-elements repository is a heavily used part of our process 
 and
 I've seen some recurring themes come up that I'd like to see addressed. 
 Element
 idempotence seems to often come up, as well as the ability to edit already
 built images. I'd also like to see our elements more generally applicable to
 installing OpenStack vs. just installing OpenStack in an image building
 context.  Personally, I support these features, but mostly, I'd like to drive
 to a consensus on those points during Kilo.
 
 I'd love to see more people developing and using TripleO where they can and
 providing feedback. To enable that, I'd like for easier developer setups to
 be a focus during Kilo so that it's simpler for people to contribute without
 such a large initial learning curve investment. Downloadable prebuilt images
 could be one way we could make that process easier.
 
 There have been a handful of mailing list threads recently about the
 organization of OpenStack and how TripleO/Deployment may fit into that going
 forward. One thing is clear, the team has made a ton of great progress since
 it's inception. I think we should continue on the mission of OpenStack owning
 it's own production deployment story, regardless of how programs may be
 organized in the future, or what different paths that story may take.
 
 Thanks for your consideration!
 
 [1] http://lists.openstack.org/pipermail/openstack-dev/2014-April/031772.html
 
 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] PTL Candidacy

[Clint Byrum]

I am writing to announce my candidacy for OpenStack Deployment PTL.

Those of you involved with the deployment program may be surprised to
see my name here. I've been quiet lately, distracted by an experiment
which was announced by Allison Randal a few months back. [1]

The experiment has been going well. We've had to narrow our focus from
the broader OpenStack project and just push hard to get HP's Helion
Product ready for release, but we're ready to bring everything back out
into the open and add it to the options for the deployment program. Most
recently our 'tripleo-ansible' repository has been added to stackforge [2],
and I hope we can work out a way where it lands in the official deployment
namespace once we have broader interest.

Those facts may cause some readers to panic, and others to rejoice,
but I would ask you to keep reading, even if you think the facts above
might disqualify me from your ballot.

My intention is to serve as PTL for OpenStack Deployment. I want to
emphasize the word serve. I believe that a PTL's first job is to serve
the mission of the program.

I have watched Robert serve closely, and I think I understand the wide
reach the program already has. We make use of Ironic, Nova, Glance,
Neutron, and Heat, and we need to interface directly with those projects
to be successful, regardless of any other tools in use.

However, I don't think the way to scale this project is to buckle down and
try to be a hero-PTL. We need to make the program's mission more appealing
to a greater number of OpenStack operators that want to deploy and manage
OpenStack. This will widen our focus, which may slow some things down,
but we can collaborate, and find common ground on many issues while still
pushing forward on the fronts that are important to each organization.

My recent experience with Ansible has convinced me that Ansible is not
_the_ answer, but that Ansible is _an_ answer which serves the needs
of some OpenStack users. Heat serves other needs, where Puppet, Chef,
Salt, and SSH in a for loop serve yet more diverse needs.

So, with that in mind, I want to succinctly state my priorities for
the role:

 * Serve the operators. Our feedback from operators has been extremely
   mixed. We need to do a better job of turning operators into OpenStack
   Deployment users and contributors.

 * Improve diversity. I have been as guilty as anyone else in the past
   of slamming the door on those who wanted to join our effort but with
   a different use case. This was a mistake. Looking forward, the door
   needs to stay open, and be widened. Without that, we won't be able
   to welcome more operators.

 * March toward a presence in the gate. I know that the gate is
   a hot term and up for debate right now. However, there will always
   be a gate of some kind for the projects in the integrated release,
   and I'd like to see a more production-like test in that gate. From
   the beginning, TripleO has been focused on supporting continuous
   deployment models, so it would make a lot of sense to have TripleO
   doing integration testing of the integrated release. If there is
   a continued stripping down of the gate, then TripleO would still
   certainly be a valuable CI job for the integrated release. We've had
   TripleO break numerous times because we run with a focus on production
   ready settings and multiple nodes which exposes new facets of the
   code that go untouched in the single-node simple-and-fast focused
   devstack tests.
   
   Of course, our CI has not exactly been rock solid, for various
   reasons. We need to make it a priority to get CI handled for at least
   the primary tooling, and at the same time welcome and support efforts
   to make use of our infrastructure for alternative tooling. This isn't
   something I necessarily think will happen in the next 6 months, but
   I think one role that a PTL can be asked to serve is as shepherd of
   long term efforts, and this is definitely one of those.

So, I thank you for taking the time to read this, and hope that whatever
happens we can build a better deployment program this cycle.

-Clint Byrum

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/042589.html
[2] https://git.openstack.org/cgit/stackforge/tripleo-ansible

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Tristan Cacqueray]

confirmed

On 24/09/14 04:03 AM, Clint Byrum wrote:
 I am writing to announce my candidacy for OpenStack Deployment PTL.
 
 Those of you involved with the deployment program may be surprised to
 see my name here. I've been quiet lately, distracted by an experiment
 which was announced by Allison Randal a few months back. [1]
 
 The experiment has been going well. We've had to narrow our focus from
 the broader OpenStack project and just push hard to get HP's Helion
 Product ready for release, but we're ready to bring everything back out
 into the open and add it to the options for the deployment program. Most
 recently our 'tripleo-ansible' repository has been added to stackforge [2],
 and I hope we can work out a way where it lands in the official deployment
 namespace once we have broader interest.
 
 Those facts may cause some readers to panic, and others to rejoice,
 but I would ask you to keep reading, even if you think the facts above
 might disqualify me from your ballot.
 
 My intention is to serve as PTL for OpenStack Deployment. I want to
 emphasize the word serve. I believe that a PTL's first job is to serve
 the mission of the program.
 
 I have watched Robert serve closely, and I think I understand the wide
 reach the program already has. We make use of Ironic, Nova, Glance,
 Neutron, and Heat, and we need to interface directly with those projects
 to be successful, regardless of any other tools in use.
 
 However, I don't think the way to scale this project is to buckle down and
 try to be a hero-PTL. We need to make the program's mission more appealing
 to a greater number of OpenStack operators that want to deploy and manage
 OpenStack. This will widen our focus, which may slow some things down,
 but we can collaborate, and find common ground on many issues while still
 pushing forward on the fronts that are important to each organization.
 
 My recent experience with Ansible has convinced me that Ansible is not
 _the_ answer, but that Ansible is _an_ answer which serves the needs
 of some OpenStack users. Heat serves other needs, where Puppet, Chef,
 Salt, and SSH in a for loop serve yet more diverse needs.
 
 So, with that in mind, I want to succinctly state my priorities for
 the role:
 
  * Serve the operators. Our feedback from operators has been extremely
mixed. We need to do a better job of turning operators into OpenStack
Deployment users and contributors.
 
  * Improve diversity. I have been as guilty as anyone else in the past
of slamming the door on those who wanted to join our effort but with
a different use case. This was a mistake. Looking forward, the door
needs to stay open, and be widened. Without that, we won't be able
to welcome more operators.
 
  * March toward a presence in the gate. I know that the gate is
a hot term and up for debate right now. However, there will always
be a gate of some kind for the projects in the integrated release,
and I'd like to see a more production-like test in that gate. From
the beginning, TripleO has been focused on supporting continuous
deployment models, so it would make a lot of sense to have TripleO
doing integration testing of the integrated release. If there is
a continued stripping down of the gate, then TripleO would still
certainly be a valuable CI job for the integrated release. We've had
TripleO break numerous times because we run with a focus on production
ready settings and multiple nodes which exposes new facets of the
code that go untouched in the single-node simple-and-fast focused
devstack tests.

Of course, our CI has not exactly been rock solid, for various
reasons. We need to make it a priority to get CI handled for at least
the primary tooling, and at the same time welcome and support efforts
to make use of our infrastructure for alternative tooling. This isn't
something I necessarily think will happen in the next 6 months, but
I think one role that a PTL can be asked to serve is as shepherd of
long term efforts, and this is definitely one of those.
 
 So, I thank you for taking the time to read this, and hope that whatever
 happens we can build a better deployment program this cycle.
 
 -Clint Byrum
 
 [1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/042589.html
 [2] https://git.openstack.org/cgit/stackforge/tripleo-ansible
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 




signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] PTL Candidacy

[James Slagle]

I'd like to announce my candidacy for TripleO PTL.

I think most folks who have worked in the TripleO community probably know me.
For those who don't, I work for Red Hat, and over the last year and a half that
I've been involved with TripleO I've worked in different areas. My focus has
been on improvements to the frameworks to support things such as other distros,
packages, and offering deployment choices. I've also tried to focus on
stabilization and documentation as well.

I stand by what I said in my last candidacy announcement[1], so I'm not going
to repeat all of that here :-).

One of the reasons I've been so active in reviewing changes to the project is
because I want to help influence the direction and move progress forward for
TripleO. The spec process was new for TripleO during the Juno cycle, and I also
helped define that. I think that process is working well and will continue to
evolve during Kilo as we find what works best.

The TripleO team has made a lot of great progress towards full HA deployments,
CI improvements, rearchitecting Tuskar as a deployment planning service, and
driving features in Heat to support our use cases. I support this work
continuing in Kilo.

I continue to believe in TripleO's mission to use OpenStack itself.  I think
the feedback provided by TripleO to other projects is very valuable. Given the
complexity to deploy OpenStack, TripleO has set a high bar for other
integrated projects to meet to achieve this goal. The resulting new features
and bug fixes that have surfaced as a result has been great for all of
OpenStack.

Given that TripleO is the Deployment program though, I also support alternative
implementations where they make sense. Those implementations may be in
TripleO's existing projects themselves, new projects entirely, or pulling in
existing projects under the Deployment program where a desire exists. Not every
operator is going to deploy OpenStack the same way, and some organizations
already have entrenched and accepted tooling.

To that end, I would also encourage integration with other deployment tools.
Puppet is one such example and already has wide support in the broader
OpenStack community. I'd also like to see TripleO support different update
mechanisms potentially with Heat's SoftwareConfig feature, which didn't yet
exist when TripleO first defined an update strategy.

The tripleo-image-elements repository is a heavily used part of our process and
I've seen some recurring themes come up that I'd like to see addressed. Element
idempotence seems to often come up, as well as the ability to edit already
built images. I'd also like to see our elements more generally applicable to
installing OpenStack vs. just installing OpenStack in an image building
context.  Personally, I support these features, but mostly, I'd like to drive
to a consensus on those points during Kilo.

I'd love to see more people developing and using TripleO where they can and
providing feedback. To enable that, I'd like for easier developer setups to
be a focus during Kilo so that it's simpler for people to contribute without
such a large initial learning curve investment. Downloadable prebuilt images
could be one way we could make that process easier.

There have been a handful of mailing list threads recently about the
organization of OpenStack and how TripleO/Deployment may fit into that going
forward. One thing is clear, the team has made a ton of great progress since
it's inception. I think we should continue on the mission of OpenStack owning
it's own production deployment story, regardless of how programs may be
organized in the future, or what different paths that story may take.

Thanks for your consideration!

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-April/031772.html


-- 
-- James Slagle
--

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [TripleO] PTL candidacy

[James Slagle]

I'd like to announce my candidacy for TripleO (Deployment) PTL.

First, a little about myself. I've been involved with OpenStack and
contributing to TripleO for nearly a year now. I'm currently a developer at Red
Hat and I've spent much of my career before OpenStack working on various
systems management tools. Working on Red Hat's Satellite and RHUI offerings
and rPath's rBuilder are where I've done most of my Python, API, and database
development in the past.

To me, the PTL role is about facilitating developers to work on what they want
to work on. I see that as the best way to bring in new developers and increase
our number of contributors. That being said, not everything can fit under the
TripleO umbrella. So, the role of the PTL also should be in assisting in
decisions about the direction of the project in a way that is best for TripleO
and OpenStack as a whole. The PTL role is also an organizational role. Not just
in the day to day tasks, but also in helping to make sure folks are aware of
what others are working on.  Also, encouraging collaboration towards common
goals, maintaining a common focus, and building consensus for the project are
also important.

Many of the contributions that I've made to TripleO to date have been about
broadening support for different use cases and adding to stability. When I
first got involved, I focused primarily on getting TripleO working really well
on Fedora and doing a lot of bug fixing and enablement in that area. In doing
so, I've aimed to do it in a way so that it's easier for the next person coming
along who might like to try something new. I've also championed things like
package install support and stable branches for some of our projects.
Additionally, I have aimed to make TripleO easier for newcomers and developers.

During the Juno cycle, if elected as PTL, I think that TripleO should continue
to focus on many of the same areas that are focal points today. These items are
critical to the success and real world usage of TripleO. The 3 biggest items to
me are:

- Improving our CI infrastructure to where TripleO is voting and in the gate
- HA deployments
- Upgrades
- Tuskar

I'd like to see Tuskar continue to develop to the point where it is ready to be
integrated into TripleO more directly. Specifically, a devtest path that uses
Tuskar, CI jobs that use Tuskar, and generally driving folks towards trying and
providing feedback on the Tuskar work flow.

In addition though, I'd like to focus on some other overarching themes that I
think are important to the project. If elected, my additional goals for the
TripleO project would be to work to broaden it's adoption and increase
contributions.

The first of these is further enablement of alternative implementations. I
would like to see TripleO as broadly adopted as possible, and I think that a
one size fits all approach may not be the best way.  To date, I think TripleO
has done a good job enabling folks to do alternative implementations as long as
there are people willing to step up and do the work. I would continue that
sentiment, but further it some as well by really trying to open the doors for
new developers.

To that end, I'd like to focus on easier developer setups, even if that means
leaving out important pieces of the TripleO process for the sake of giving some
people an easier way to get bootstrapped. Folks that want to work on support
for their favorite configuration management tool, or additional package support,
or additional distro support, don't necessarily have to have a complete
functional TripleO environment with all the bells and whistles.

Secondly, I think we as a community could have some better examples of how
different tools might fit into existing processes, and perhaps even bootstrap
these implementations to a degree. The puppet-openstack is one such effort I'd
like to see have some integration with TripleO.

Thirdly, similar to making things easier for developers, I'd like to make things
easier for operators to try and use TripleO. I think getting real world
operator feedback for TripleO is critical, especially as we are in the process
of defining it's future direction. Some specifics in this area would include
ability to adopt deployments that might be deployed via pre-existing tooling,
integration with existing deployed configuration management solutions, or
ways to integrate with existing upgrade mechanisms (possibly via HOT).

Finally, I'd like to see TripleO become a true default installer for OpenStack.
I'd like to see an implementation of elements that are not image specific, and
instead are the reference implementations of how an OpenStack project gets
installed and configured. I think there is a lot of opportunity to reduce and
reuse code here across projects in this space. Many projects document how they
should be installed, then there are implementations in devstack, and also
implementations now in TripleO.  I'd like to see the elements become more
universal to where they 

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

[Tristan Cacqueray]

confirmed

On 04/03/2014 03:44 PM, James Slagle wrote:
 I'd like to announce my candidacy for TripleO (Deployment) PTL.
 
 First, a little about myself. I've been involved with OpenStack and
 contributing to TripleO for nearly a year now. I'm currently a developer at 
 Red
 Hat and I've spent much of my career before OpenStack working on various
 systems management tools. Working on Red Hat's Satellite and RHUI offerings
 and rPath's rBuilder are where I've done most of my Python, API, and database
 development in the past.
 
 To me, the PTL role is about facilitating developers to work on what they want
 to work on. I see that as the best way to bring in new developers and increase
 our number of contributors. That being said, not everything can fit under the
 TripleO umbrella. So, the role of the PTL also should be in assisting in
 decisions about the direction of the project in a way that is best for TripleO
 and OpenStack as a whole. The PTL role is also an organizational role. Not 
 just
 in the day to day tasks, but also in helping to make sure folks are aware of
 what others are working on.  Also, encouraging collaboration towards common
 goals, maintaining a common focus, and building consensus for the project are
 also important.
 
 Many of the contributions that I've made to TripleO to date have been about
 broadening support for different use cases and adding to stability. When I
 first got involved, I focused primarily on getting TripleO working really well
 on Fedora and doing a lot of bug fixing and enablement in that area. In doing
 so, I've aimed to do it in a way so that it's easier for the next person 
 coming
 along who might like to try something new. I've also championed things like
 package install support and stable branches for some of our projects.
 Additionally, I have aimed to make TripleO easier for newcomers and 
 developers.
 
 During the Juno cycle, if elected as PTL, I think that TripleO should continue
 to focus on many of the same areas that are focal points today. These items 
 are
 critical to the success and real world usage of TripleO. The 3 biggest items 
 to
 me are:
 
 - Improving our CI infrastructure to where TripleO is voting and in the gate
 - HA deployments
 - Upgrades
 - Tuskar
 
 I'd like to see Tuskar continue to develop to the point where it is ready to 
 be
 integrated into TripleO more directly. Specifically, a devtest path that uses
 Tuskar, CI jobs that use Tuskar, and generally driving folks towards trying 
 and
 providing feedback on the Tuskar work flow.
 
 In addition though, I'd like to focus on some other overarching themes that I
 think are important to the project. If elected, my additional goals for the
 TripleO project would be to work to broaden it's adoption and increase
 contributions.
 
 The first of these is further enablement of alternative implementations. I
 would like to see TripleO as broadly adopted as possible, and I think that a
 one size fits all approach may not be the best way.  To date, I think 
 TripleO
 has done a good job enabling folks to do alternative implementations as long 
 as
 there are people willing to step up and do the work. I would continue that
 sentiment, but further it some as well by really trying to open the doors for
 new developers.
 
 To that end, I'd like to focus on easier developer setups, even if that means
 leaving out important pieces of the TripleO process for the sake of giving 
 some
 people an easier way to get bootstrapped. Folks that want to work on support
 for their favorite configuration management tool, or additional package 
 support,
 or additional distro support, don't necessarily have to have a complete
 functional TripleO environment with all the bells and whistles.
 
 Secondly, I think we as a community could have some better examples of how
 different tools might fit into existing processes, and perhaps even bootstrap
 these implementations to a degree. The puppet-openstack is one such effort I'd
 like to see have some integration with TripleO.
 
 Thirdly, similar to making things easier for developers, I'd like to make 
 things
 easier for operators to try and use TripleO. I think getting real world
 operator feedback for TripleO is critical, especially as we are in the process
 of defining it's future direction. Some specifics in this area would include
 ability to adopt deployments that might be deployed via pre-existing tooling,
 integration with existing deployed configuration management solutions, or
 ways to integrate with existing upgrade mechanisms (possibly via HOT).
 
 Finally, I'd like to see TripleO become a true default installer for 
 OpenStack.
 I'd like to see an implementation of elements that are not image specific, and
 instead are the reference implementations of how an OpenStack project gets
 installed and configured. I think there is a lot of opportunity to reduce and
 reuse code here across projects in this space. Many projects document how they
 should be 

[openstack-dev] [TripleO] PTL Candidacy

[Robert Collins]

I'm running for TripleO PTL again!

Over the last 6 months TripleO has come a long way in the last 6 months:
 - CI on all changes (not yet gating)
 - Persistent storage on nodes
 - a significantly increased community

I've been thrilled to see our progress - and the more time we spend
running running clouds the more feedback we generate to other
OpenStack programs.

My view on PTL is unchanged from 6 months ago - it is an enabling
position: working with the
team to identify blockers, constraints issues and weak points in the
(design/code/architecture) and then respectively remove/socialise and
target them.

I think I fell short of that aspiration in the last cycle, and commit
to doing better if I am elected.

For folk who are new to the community in the last 6 months, this was
my platform last time -
http://lists.openstack.org/pipermail/openstack-dev/2013-September/015431.html


Last cycle I said 
Icehouse is the first opportunity we'll have to have a fully
functional story, and even now thats still a fairly aggressive goal :
my focus over the next 6 months will be getting us out of fire-drill
mode and into the steady-state that is needed for confident
deployments... in addition to fleshing out the features required for
Tuskar, overcloud upgrades and undercloud upgrades. That means, in big
ticket items...


I believe the delivery of scaled CI has been a crucial step - we no
longer break ourselves, and we find out quickly when changes elsewhere
in openstack break the tripleo tooling. Thats been invaluable so far -
and will be more so as we broaden CI and make it voting and then
gating.


To my mind over the next 6 months we need to focus on

* Continuing the CI path
* HA of everything out of the box
* Graceful upgrades
* pushing our deployment experience feedback to the project we deploy
* expanding our coverage to deploy everything
* Migrating to Tuskar for everything but the deployment of the seed

Obviously, if you have questions please ask!

-Rob

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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Anita Kuno]

confirmed

On 04/02/2014 06:23 PM, Robert Collins wrote:
 I'm running for TripleO PTL again!
 
 Over the last 6 months TripleO has come a long way in the last 6 months:
  - CI on all changes (not yet gating)
  - Persistent storage on nodes
  - a significantly increased community
 
 I've been thrilled to see our progress - and the more time we spend
 running running clouds the more feedback we generate to other
 OpenStack programs.
 
 My view on PTL is unchanged from 6 months ago - it is an enabling
 position: working with the
 team to identify blockers, constraints issues and weak points in the
 (design/code/architecture) and then respectively remove/socialise and
 target them.
 
 I think I fell short of that aspiration in the last cycle, and commit
 to doing better if I am elected.
 
 For folk who are new to the community in the last 6 months, this was
 my platform last time -
 http://lists.openstack.org/pipermail/openstack-dev/2013-September/015431.html
 
 
 Last cycle I said 
 Icehouse is the first opportunity we'll have to have a fully
 functional story, and even now thats still a fairly aggressive goal :
 my focus over the next 6 months will be getting us out of fire-drill
 mode and into the steady-state that is needed for confident
 deployments... in addition to fleshing out the features required for
 Tuskar, overcloud upgrades and undercloud upgrades. That means, in big
 ticket items...
 
 
 I believe the delivery of scaled CI has been a crucial step - we no
 longer break ourselves, and we find out quickly when changes elsewhere
 in openstack break the tripleo tooling. Thats been invaluable so far -
 and will be more so as we broaden CI and make it voting and then
 gating.
 
 
 To my mind over the next 6 months we need to focus on
 
 * Continuing the CI path
 * HA of everything out of the box
 * Graceful upgrades
 * pushing our deployment experience feedback to the project we deploy
 * expanding our coverage to deploy everything
 * Migrating to Tuskar for everything but the deployment of the seed
 
 Obviously, if you have questions please ask!
 
 -Rob
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev