Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Thierry Carrez]

Steven Dake (stdake) wrote:

[...]
Brain still booting this morning - 8am ftl.  Thinking more clearly on this
point, we could add a requirement that the software produce a functional
out of the box working environment.  This would easily apply to OSA and
possibly even Puppet/Chef efforts.

A stab at it would be:
"After deployment is complete, the starter-kit:compute is fully
operational without further interaction from the Operator."

Open to language help in the review itself - I'll propose an update this
morning.  I'd like to be inclusive of projects like Puppet and Chef and
obviously OSA which are clearly deployment systems which rely on
deployment tools like Puppet, Chef, and Ansible respectively.  This is the
same model Kolla follows as well.  Kolla Doesn't reinvent Ansible, we just
use it.

A type:packaging doesn't really fit though, because Kolla provides a
completely working out of the box deployment whereas packaging (deb,
docker, rpm) only package the software for other deployment tools to
consume.


Right, my point is that since the tag applies to specific deliverables, 
I would apply the type:deployment to the thing that people must install 
to produce a deployment -- that thing can then depend on other things 
(libraries, packaging/recipes/playbooks), but what we need to 
communicate to downstream users is where the entry point is.


I'll follow up on the review.

--
Thierry Carrez (ttx)

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

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Dan Prince]

On Tue, 2016-03-22 at 15:37 +, Steven Dake (stdake) wrote:
> 
> On 3/22/16, 2:15 AM, "Thierry Carrez"  wrote:
> 
> > 
> > Steven Dake (stdake) wrote:
> > > 
> > > Technical Committee,
> > > 
> > > Please accept my proposal of a new type of project called a
> > > deployment
> > > [1].  If people don¹t like the type name, we can change it.  The
> > > basic
> > > idea is there are a class of projects unrepresented by
> > > type:service and
> > > type:library which are deployment projects including but not
> > > limited to
> > > Fuel, Kolla, OSA, and TripleO.  The main motivation behind this
> > > addition
> > > are:
> > > 
> > >  1. Make it known to all which projects are deployment projects
> > > in the
> > > governance repository.
> > >  2. Provide that information via the governance website under
> > > release
> > > management tags.
> > >  3. Permit deployment projects to take part in the assert tags
> > > relating
> > > to upgrades [2].
> > > 
> > > 
> > > Currently fuel is listed as a type:service in the governance
> > > repository
> > > which is only partially accurate.  It may provide a ReST API, but
> > > during
> > > the Kolla big tent application process, we were told we couldn't
> > > use
> > > type:service as it only applied to daemon services and not
> > > deployment
> > > projects.
> > I agree that type:service is not really a good match for Fuel or
> > Kolla,
> > and we could definitely use something else -- that would make it a
> > lot
> > clearer what is what for the downstream consumers of the software
> > we
> > produce.
> > 
> > One issue is that tags are applied to deliverables, not project
> > teams.
> > For the Fuel team it's pretty clear (it would apply to their "fuel"
> > deliverable). For Kolla team, I suspect it would apply to the
> > "kolla"
> > deliverable. But the TripleO team produces a collection of tools,
> > so
> > it's unclear which of those would be considered the main
> > "deployment"
> > thing.
> For kolla we are considering splitting the repository (to be
> discussed at
> the Kolla midcycle) into our docker packaging efforts and our Ansible
> deployment efforts since the ABI is very stable at this point and we
> don't
> see any requirements for changing the container ABI at present.  What
> this
> would mean is our repositories would be
> 
> Kolla - build docker containers - type:packaging
> Kolla-ansible - deploy Kolla's docker containers - type:deployment
> (and
> type:upgrade in the future once we get a gate up to meet the
> requirements
> and assuming this proposal is voted in by the technical committee).
> 
> In essence Kolla would be affected by this same scenario as TripleO.
> 
> Perhaps the tripleo folks could weigh-in in the review.  I don't want
> the
> tag to be onerous to apply.  I believe tags should be relatively easy
> to
> obtain if the project meets the "spirit of the tag".  That said if
> the
> proposed language could be written to include TripleO's deliverable
> without excluding it, then that is what I'd be after.
> 
> Dan can you weigh in?

I see no harm in adding this extra type:deployment tag to some of the
TripleO deliverables.

+1 from me.

> 
> > 
> > 
> > For OSA, we don't produce the deployment tool, only a set of
> > playbooks.
> > I was thinking we might need a type:packaging tag to describe which
> > things we produce are just about packaging OpenStack things for
> > usage by
> > outside deployment systems (Ansible, Puppet, Chef, Deb, RPM...). So
> > I'm
> > not sure your type:deployment tag would apply to OSA.
> Brain still booting this morning - 8am ftl.  Thinking more clearly on
> this
> point, we could add a requirement that the software produce a
> functional
> out of the box working environment.  This would easily apply to OSA
> and
> possibly even Puppet/Chef efforts.
> 
> A stab at it would be:
> "After deployment is complete, the starter-kit:compute is fully
> operational without further interaction from the Operator."
> 
> Open to language help in the review itself - I'll propose an update
> this
> morning.  I'd like to be inclusive of projects like Puppet and Chef
> and
> obviously OSA which are clearly deployment systems which rely on
> deployment tools like Puppet, Chef, and Ansible respectively.  This
> is the
> same model Kolla follows as well.  Kolla Doesn't reinvent Ansible, we
> just
> use it.
> 
> A type:packaging doesn't really fit though, because Kolla provides a
> completely working out of the box deployment whereas packaging (deb,
> docker, rpm) only package the software for other deployment tools to
> consume.
> 
> Thanks Thierry for the feedback.
> 
> Regards,
> -steve
> 
> 
> > 
> > 

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

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Steven Dake (stdake)]

On 3/22/16, 2:15 AM, "Thierry Carrez"  wrote:

>Steven Dake (stdake) wrote:
>> Technical Committee,
>>
>> Please accept my proposal of a new type of project called a deployment
>> [1].  If people don¹t like the type name, we can change it.  The basic
>> idea is there are a class of projects unrepresented by type:service and
>> type:library which are deployment projects including but not limited to
>> Fuel, Kolla, OSA, and TripleO.  The main motivation behind this addition
>> are:
>>
>>  1. Make it known to all which projects are deployment projects in the
>> governance repository.
>>  2. Provide that information via the governance website under release
>> management tags.
>>  3. Permit deployment projects to take part in the assert tags relating
>> to upgrades [2].
>>
>>
>> Currently fuel is listed as a type:service in the governance repository
>> which is only partially accurate.  It may provide a ReST API, but during
>> the Kolla big tent application process, we were told we couldn't use
>> type:service as it only applied to daemon services and not deployment
>> projects.
>
>I agree that type:service is not really a good match for Fuel or Kolla,
>and we could definitely use something else -- that would make it a lot
>clearer what is what for the downstream consumers of the software we
>produce.
>
>One issue is that tags are applied to deliverables, not project teams.
>For the Fuel team it's pretty clear (it would apply to their "fuel"
>deliverable). For Kolla team, I suspect it would apply to the "kolla"
>deliverable. But the TripleO team produces a collection of tools, so
>it's unclear which of those would be considered the main "deployment"
>thing.

For kolla we are considering splitting the repository (to be discussed at
the Kolla midcycle) into our docker packaging efforts and our Ansible
deployment efforts since the ABI is very stable at this point and we don't
see any requirements for changing the container ABI at present.  What this
would mean is our repositories would be

Kolla - build docker containers - type:packaging
Kolla-ansible - deploy Kolla's docker containers - type:deployment (and
type:upgrade in the future once we get a gate up to meet the requirements
and assuming this proposal is voted in by the technical committee).

In essence Kolla would be affected by this same scenario as TripleO.

Perhaps the tripleo folks could weigh-in in the review.  I don't want the
tag to be onerous to apply.  I believe tags should be relatively easy to
obtain if the project meets the "spirit of the tag".  That said if the
proposed language could be written to include TripleO's deliverable
without excluding it, then that is what I'd be after.

Dan can you weigh in?

>
>For OSA, we don't produce the deployment tool, only a set of playbooks.
>I was thinking we might need a type:packaging tag to describe which
>things we produce are just about packaging OpenStack things for usage by
>outside deployment systems (Ansible, Puppet, Chef, Deb, RPM...). So I'm
>not sure your type:deployment tag would apply to OSA.

Brain still booting this morning - 8am ftl.  Thinking more clearly on this
point, we could add a requirement that the software produce a functional
out of the box working environment.  This would easily apply to OSA and
possibly even Puppet/Chef efforts.

A stab at it would be:
"After deployment is complete, the starter-kit:compute is fully
operational without further interaction from the Operator."

Open to language help in the review itself - I'll propose an update this
morning.  I'd like to be inclusive of projects like Puppet and Chef and
obviously OSA which are clearly deployment systems which rely on
deployment tools like Puppet, Chef, and Ansible respectively.  This is the
same model Kolla follows as well.  Kolla Doesn't reinvent Ansible, we just
use it.

A type:packaging doesn't really fit though, because Kolla provides a
completely working out of the box deployment whereas packaging (deb,
docker, rpm) only package the software for other deployment tools to
consume.

Thanks Thierry for the feedback.

Regards,
-steve


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


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

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Steven Dake (stdake)]

From: Jesse Pretorius 
<jesse.pretor...@gmail.com<mailto:jesse.pretor...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, March 22, 2016 at 7:40 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing 
type:deployment

On 22 March 2016 at 09:15, Thierry Carrez 
<thie...@openstack.org<mailto:thie...@openstack.org>> wrote:

For OSA, we don't produce the deployment tool, only a set of playbooks. I was 
thinking we might need a type:packaging tag to describe which things we produce 
are just about packaging OpenStack things for usage by outside deployment 
systems (Ansible, Puppet, Chef, Deb, RPM...). So I'm not sure your 
type:deployment tag would apply to OSA.

Yeah, I suppose it depends on how you define 'deployment tool'. OSA is an 
umbrella project providing Ansible roles which deploy services, and playbooks 
that put them together in an integrated deployment.

Fuel similarly has libraries, Puppet roles, plugins, etc which are all packaged 
together to provide what we call 'Fuel'.

I expect that there are other similarities - for instance 'Keystone' may be a 
service, but that service has libraries and all combined together we call it a 
daemon service.

I guess it would be nice to have some sort of designation to allow easier 
filtering for consumers, assuming that this actually does add value to 
Operators/Packagers who consume these projects.

Jessie,

The only requirement is:

  *
The repository contains software that deploys at minimum
  deliverables tagged with starter-kit:compute in the
  projects.yaml file.

I guess we could add more if needed, but I'm a big fan of less is more, so I'd  
be open to adding requirements if the above is unclear that the tool 
(puppet/chef/osa/kolla/fuel/triploe0) needs to deploy OpenStack and it needs to 
be functional afterwards.

I think the "functional afterwards" is unstated and probably needs an update to 
the patch to differentiate between packaging efforts and deployment efforts.

I also think the project should deploy the dependencies required to operate 
start-kit:compute which include a database of their choosing and a message 
queue service supported by oslo.

Note compute-kit is not onerous - there are only a few projects which have the 
starter-kit:compute tag.  They include keystone, glance, neutron, and nova.  
Clearly that could change in the future, but at present, it wouldn't be a 
burden on any deployment project to just simply apply the tag and move on.

Thanks for jogging my thought processes - I'll update the review this morning.

Regards
-steve

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

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Steven Dake (stdake)]

On 3/22/16, 2:15 AM, "Thierry Carrez"  wrote:

>Steven Dake (stdake) wrote:
>> Technical Committee,
>>
>> Please accept my proposal of a new type of project called a deployment
>> [1].  If people don¹t like the type name, we can change it.  The basic
>> idea is there are a class of projects unrepresented by type:service and
>> type:library which are deployment projects including but not limited to
>> Fuel, Kolla, OSA, and TripleO.  The main motivation behind this addition
>> are:
>>
>>  1. Make it known to all which projects are deployment projects in the
>> governance repository.
>>  2. Provide that information via the governance website under release
>> management tags.
>>  3. Permit deployment projects to take part in the assert tags relating
>> to upgrades [2].
>>
>>
>> Currently fuel is listed as a type:service in the governance repository
>> which is only partially accurate.  It may provide a ReST API, but during
>> the Kolla big tent application process, we were told we couldn't use
>> type:service as it only applied to daemon services and not deployment
>> projects.
>
>I agree that type:service is not really a good match for Fuel or Kolla,
>and we could definitely use something else -- that would make it a lot
>clearer what is what for the downstream consumers of the software we
>produce.
>
>One issue is that tags are applied to deliverables, not project teams.
>For the Fuel team it's pretty clear (it would apply to their "fuel"
>deliverable). For Kolla team, I suspect it would apply to the "kolla"
>deliverable. But the TripleO team produces a collection of tools, so
>it's unclear which of those would be considered the main "deployment"
>thing.
>
>For OSA, we don't produce the deployment tool, only a set of playbooks.
>I was thinking we might need a type:packaging tag to describe which
>things we produce are just about packaging OpenStack things for usage by
>outside deployment systems (Ansible, Puppet, Chef, Deb, RPM...). So I'm
>not sure your type:deployment tag would apply to OSA.

Thierry,

I was focused on Kolla when I proposed the type:deployment tag.  I can
also add a type:packaging tag as well if the community would find that
helpful for deb/rpm packaging efforts.  I agree type:packaging doesn't fit
with deployment tools in general.  I hadn't considered Puppet and Chef in
my original proposal, but I think they do fit into the type:deployment
tag, because they deploy the compute-kit.

Relating to OSA, OSA produces full playbooks and other tools for
deployment, so I think it is more a deployment system then a packaging
system.
>
>-- 
>Thierry Carrez (ttx)
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Jesse Pretorius]

On 22 March 2016 at 09:15, Thierry Carrez  wrote:

>
> For OSA, we don't produce the deployment tool, only a set of playbooks. I
> was thinking we might need a type:packaging tag to describe which things we
> produce are just about packaging OpenStack things for usage by outside
> deployment systems (Ansible, Puppet, Chef, Deb, RPM...). So I'm not sure
> your type:deployment tag would apply to OSA.
>

Yeah, I suppose it depends on how you define 'deployment tool'. OSA is an
umbrella project providing Ansible roles which deploy services, and
playbooks that put them together in an integrated deployment.

Fuel similarly has libraries, Puppet roles, plugins, etc which are all
packaged together to provide what we call 'Fuel'.

I expect that there are other similarities - for instance 'Keystone' may be
a service, but that service has libraries and all combined together we call
it a daemon service.

I guess it would be nice to have some sort of designation to allow easier
filtering for consumers, assuming that this actually does add value to
Operators/Packagers who consume these projects.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Thierry Carrez]

Steven Dake (stdake) wrote:

Technical Committee,

Please accept my proposal of a new type of project called a deployment
[1].  If people don’t like the type name, we can change it.  The basic
idea is there are a class of projects unrepresented by type:service and
type:library which are deployment projects including but not limited to
Fuel, Kolla, OSA, and TripleO.  The main motivation behind this addition
are:

 1. Make it known to all which projects are deployment projects in the
governance repository.
 2. Provide that information via the governance website under release
management tags.
 3. Permit deployment projects to take part in the assert tags relating
to upgrades [2].


Currently fuel is listed as a type:service in the governance repository
which is only partially accurate.  It may provide a ReST API, but during
the Kolla big tent application process, we were told we couldn't use
type:service as it only applied to daemon services and not deployment
projects.


I agree that type:service is not really a good match for Fuel or Kolla, 
and we could definitely use something else -- that would make it a lot 
clearer what is what for the downstream consumers of the software we 
produce.


One issue is that tags are applied to deliverables, not project teams. 
For the Fuel team it's pretty clear (it would apply to their "fuel" 
deliverable). For Kolla team, I suspect it would apply to the "kolla" 
deliverable. But the TripleO team produces a collection of tools, so 
it's unclear which of those would be considered the main "deployment" 
thing.


For OSA, we don't produce the deployment tool, only a set of playbooks. 
I was thinking we might need a type:packaging tag to describe which 
things we produce are just about packaging OpenStack things for usage by 
outside deployment systems (Ansible, Puppet, Chef, Deb, RPM...). So I'm 
not sure your type:deployment tag would apply to OSA.


--
Thierry Carrez (ttx)

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

[openstack-dev] [tc][fuel][kolla][osa][tripleo] proposing type:deployment

[Steven Dake (stdake)]

Technical Committee,

Please accept my proposal of a new type of project called a deployment [1].  If 
people don't like the type name, we can change it.  The basic idea is there are 
a class of projects unrepresented by type:service and type:library which are 
deployment projects including but not limited to Fuel, Kolla, OSA, and TripleO. 
 The main motivation behind this addition are:

  1.  Make it known to all which projects are deployment projects in the 
governance repository.
  2.  Provide that information via the governance website under release 
management tags.
  3.  Permit deployment projects to take part in the assert tags relating to 
upgrades [2].

Currently fuel is listed as a type:service in the governance repository which 
is only partially accurate.  It may provide a ReST API, but during the Kolla 
big tent application process, we were told we couldn't use type:service as it 
only applied to daemon services and not deployment projects.

Regards
-steve

[1] https://review.openstack.org/295528
[2] https://review.openstack.org/295529
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev