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