Open Stack

On 30.8.2018 16:28, Honza Pokorny wrote:
> Hello!
> 
> Over the last few months, it seems that tripleo-quickstart has evolved
> into a CI tool.  It's primarily used by computers, and not humans.
> tripleo-quickstart is a helpful set of ansible playbooks, and a
> collection of feature sets.  However, it's become less useful for
> setting up development environments by humans.  For example, devmode.sh
> was recently deprecated without a user-friendly replacement. Moreover,
> during some informal irc conversations in #oooq, some developers even
> mentioned the plan to merge tripleo-quickstart and tripleo-ci.
> 
> I think it would be beneficial to create a set of defaults for
> tripleo-quickstart that can be used to spin up new environments; a set
> of defaults for humans.  This can either be a well-maintained script in
> tripleo-quickstart itself, or a brand new project, e.g.
> tripleo-quickstart-humans.  The number of settings, knobs, and flags
> should be kept to a minimum.
> 
> This would accomplish two goals:
> 
> 1.  It would bring uniformity to the team.  Each environment is
>      installed the same way.  When something goes wrong, we can
>      eliminate differences in setup when debugging.  This should save a
>      lot of time.
> 
> 2.  Quicker and more reliable environment setup.  If the set of defaults
>      is used by many people, it should container fewer bugs because more
>      people using something should translate into more bug reports, and
>      more bug fixes.
> 
> These thoughts are coming from the context of tripleo-ui development.  I
> need an environment in order to develop, but I don't necessarily always
> care about how it's installed.  I want something that works for most
> scenarios.
> 
> What do you think?  Does this make sense?  Does something like this
> already exist?

I've been tinkering in this area for a long time, previously with 
inlunch [1], and now quicklunch [2] (which is a wrapper around 
quickstart), and i've been involved in various conversations about this 
over the past years, so i feel like i may have some insight to share on 
all this in general.

* A single config for everyone is not achievable, IMO. Someone wants HA, 
others want Ceph, Sahara, OpenDaylight, etc. There's no overlap here to 
be found i think, while respecting that the resulting deployment needs 
to be of reasonable size.

* "for humans" definition differs significantly based on who you ask. 
E.g. my intention with [2] was to readily expose *more* knobs and tweaks 
and be more transparent with the underlying workings of Ansible, because 
i felt like quickstart.sh hides too much from me. In my opinion [2] is 
sufficiently "for humans", yet it does pretty much the opposite of what 
you're looking for.

* It's hard to strike a good balance between for-CI and for-humans (and 
the various definitions of for-humans ;) ), but it's worth to keep doing 
that as high in the software stack as possible, because there is great 
value in running CI and all dev envs with the same (underlying) tool. 
Over the years i've observed that Quickstart is trying hard to 
consolidate various requirements, but it's simply difficult to please 
all stakeholders, as often the requirements are somewhat contradictory. 
(This point is not in conflict with anything discussed so far, but i 
just think it's worth mentioning, so that we don't display Quickstart in 
a way it doesn't deserve.)

These points are to illustrate my previous experience, that when we go 
above a certain layer of "this is a generic all-purpose configurable 
tool" (= Quickstart), it seems to yield better results to focus on 
building the next layer/wrapper for "humans like me" rather than "humans 
in general".

So with regards to the specific goal stemming from tripleo-ui dev 
requirements as you mentioned above, IMO it makes sense to team up with 
UI folks and others who have similar expectations about what a TripleO 
dev env means, and make some wrapper around Quickstart like you 
suggested. Since you want to reduce rather than extend the number of 
knobs, it could even be just a script perhaps.

My 2 cents, i hope it helps a bit.

Jirka

[1] https://github.com/jistr/inlunch
[2] https://gitlab.com/jistr/quicklunch

> 
> Thanks for listening!
> 
> Honza
> 
> __________________________________________________________________________
> 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
>