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

[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

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

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

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

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

[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 
Distinguished Technologist
HP Converged Cloud

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