Open Stack

On Thu, Jan 5, 2017 at 5:56 PM, Alex Schultz <aschultz at redhat.com> wrote:

> On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski <inc007 at gmail.com>
> wrote:
> > Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
> > there is no reason in my mind for kolla-ansible/k8s core team to vote
> > on accepting new deliverable. I think this should be lightweight and
> > easy, we should allow experimentation (after all, kolla itself went
> > through few fail iterations before ansible).
> >
> > Ad disconnect, I think we all are interested in other orch tools more
> > or less, but it's more about "who should allow new one to be added",
> > and that requires more than interest as might potentially block adding
> > new deliverable. Avoiding this disconnect is exactly why I'd like to
> > keep all deliverable team under one Kolla umbrealla, keep everyone in
> > same community so they can make use of each others experience (that
> > would also mean, that kolla-puppet is what I'd like to see rather than
> > puppet-kolla:)).
> >
>
> I mean it depends on what a proposed 'kolla-puppet' does.  If it's
> like puppet-tripleo, which falls under the TripleO umbrella and not
> Puppet OpenStack because it configures more than just a single
> 'openstack' related service then that would make sense.  Since
> puppet-tripleo a way of deploying all things OpenStack it lives in the
> TripleO world.  But I don't necessarily agree that kolla-puppet should
> exist over puppet-kolla if it just configures 'kolla'.  I would like
> to see more cross group collaboration with the deployment tool groups
> and not keeping things to themselves.  As for the intricacies of the
> specific deployment tooling, because we already have patterns and
> plenty of tooling for deploying OpenStack related services in our
> other 40 or so modules I think the Puppet OpenStack community might be
> better suited to provide review feedback than say the Kolla group when
> it comes to puppet specific questions and best practices.  And
> speaking as the Puppet PTL there would not be anything stopping us
> from having Kolla cores also be cores on puppet-kolla.
>

These are good points. I don't know which way I lean on this subject at the
moment. But I would mention that kolla-ansible doesn't exist under
openstack-ansible-kolla. And kolla-salt (should that become a thing) isn't
openstack-salt-kolla.

Just because there is an openstack project that uses a orchestration tool
doesn't mean only one such project can exist. Nor that all approaches would
be the same, even if the end goal is the same (deploy openstack).

So I am going to remain neutral on this point and say what you are saying
is reasonable, though on the other hand it may not be compatible in some
situations.

Thanks,
SamYaple

I think its important to focus on the sense of OpenStack community
> building (not just Kolla community) and spreading knowledge I think it
> would be better not to try and keep everything to yourself if there's
> already a group of people in the community who specialize in a
> specific thing.  As an aside, I'd honestly like to see more
> contribution by the upstream projects into the puppet-* world because
> I think it's important for people to understand how the software they
> right actually gets consumed.
>
> Thanks,
> -Alex
>
> > Ad multi-deployment-tool friendly rivalry, it is meant to extend
> > breadth of the project indeed, but let's face it, religious wars are
> > real (and vim is better than emacs.);) I don't thing problem would be
> > ill intent tho, I could easily predict problem being rather in "I
> > don't have time to look at this review queue" sort. Stalling reviews
> > can kill lots of potentially great changes.
> >
> >
> > On 5 January 2017 at 09:02, Sam Yaple <samuel at yaple.net> wrote:
> >> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley <fungi at yuggoth.org>
> wrote:
> >>>
> >>> On 2017-01-05 16:46:36 +0000 (+0000), Sam Yaple wrote:
> >>> [...]
> >>> > I do feel this is slightly different than whats described. Since it
> is
> >>> > not
> >>> > unrelated services, but rather, for lack of a better word, competing
> >>> > services. To my knowledge infra doesn't have several service doing
> the
> >>> > same
> >>> > job with different core teams (though I could be wrong).
> >>>
> >>> True, though I do find it an interesting point of view that helping
> >>> Kolla support multiple and diverse configuration management and
> >>> automation ecosystems is a "competition" rather than merely
> >>> extending the breadth of the project as a whole.
> >>
> >>
> >> Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'?
> I
> >> expect these different deploy tools to bring new techniques that can
> then be
> >> reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
> >>
> >> Thanks,
> >> SamYaple
> >>>
> >>> --
> >>> Jeremy Stanley
> >>>
> >>> ____________________________________________________________
> ______________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> 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/20170105/aaf5ea5e/attachment.html>