Open Stack

On Thu, Sep 4, 2014 at 12:39 PM, Tim Bell <Tim.Bell at cern.ch> wrote:

> > -----Original Message-----
> > From: Thierry Carrez [mailto:thierry at openstack.org]
> > Sent: 04 September 2014 16:59
> > To: openstack-dev at lists.openstack.org
> > Subject: Re: [openstack-dev] [Zaqar] Comments on the concerns arose
> during
> > the TC meeting
> >
> > Sean Dague wrote:
> > > [...]
> > > So, honestly, I'll probably remain -1 on the final integration vote,
> > > not because Zaqar is bad, but because I'm feeling more firmly that for
> > > OpenStack to not leave the small deployers behind we need to redefine
> > > the tightly integrated piece of OpenStack to basically the Layer 1 & 2
> > > parts of my diagram, and consider the rest of the layers exciting
> > > parts of our ecosystem that more advanced users may choose to deploy
> > > to meet their needs. Smaller tent, big ecosystem, easier on ramp.
> > >
> > > I realize that largely means Zaqar would be caught up in a definition
> > > discussion outside of it's control, and that's kind of unfortunate, as
> > > Flavio and team have been doing a bang up job of late. But we need to
> > > stop considering "integration" as the end game of all interesting
> > > software in the OpenStack ecosystem, and I think it's better to have
> > > that conversation sooner rather than later.
> >
> > I think it's pretty clear at this point that:
> >
> > (1) we need to have a discussion about layers (base nucleus, optional
> extra
> > services at the very least) and the level of support we grant to each --
> the
> > current binary approach is not working very well
> >
> > (2) If we accept Zaqar next week, it's pretty clear it would not fall in
> the base
> > nucleus layer but more in an optional extra services layer, together
> with at the
> > very least Trove and Sahara
> >
> > There are two ways of doing this: follow Sean's approach and -1
> integration
> > (and have zaqar apply to that "optional layer" when we create it), or +1
> > integration now (and have zaqar follow whichever other integrated
> projects we
> > place in that layer when we create it).
> >
> > I'm still hesitating on the best approach. I think they yield the same
> end result,
> > but the -1 approach seems to be a bit more unfair, since it would be
> purely for
> > reasons we don't (yet) apply to currently-integrated projects...
> >
>
> The one concern I have with a small core is that there is not an easy way
> to assess the maturity of a project on stackforge. The stackforge projects
> may be missing packaging, Red Hat testing, puppet modules, install/admin
> documentation etc. Thus, I need to have some indication that a project is
> deployable before looking at it with my user community to see if it meets a
> need that is sustainable.
>
>
I identify with this concern as Docs PTL. That said, it's very difficult
already even if a project is under the "openstack" github org to know how
well documented it is.


> Do you see the "optional layer" services being blessed / validated in some
> way and therefore being easy to identify ?
>
>
I've already started to work on doc requirements for incubating and
integrating projects [1], which may help with some checklist creation. My
thinking is, if you can't document it, it's not well-validated. Is that
reasonable, to adopt a "docs or it didn't happen" stance here?

Thanks for thinking on this -- I do like the layers approach and I think we
just need to define expectations for layers so all the community can do a
quick sanity check.
Anne

1. https://wiki.openstack.org/wiki/Documentation/IncubateIntegrate

 Tim
> > --
> > Thierry Carrez (ttx)
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140904/0c67f5c7/attachment.html>