Re: [openstack-dev] [tripleo] quickstart for humans

[Bogdan Dobrelya]

On 8/31/18 6:03 PM, Raoul Scarazzini wrote:

On 8/31/18 12:07 PM, Jiří Stránský wrote:
[...]

* "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.


Hey Jiri,
I think that "for humans" means simply that you launch the command with
just one parameter (i.e. the virthost), and then you have something.


yes, this ^^
I'd also add one more thing: if you later remove that something while 
having the virthost as your localhost, and the non root user as your 
current logged-in user, you remain operational :) Teardown is quite 
destructive for CI, which might be not applicable for devboxes running 
on a laptop. I have a few changes [0] in work for addressing that case.


[0] 
https://review.openstack.org/#/q/topic:localcon+(status:open+OR+status:merged)



And because of this I think here is just a matter of concentrate the
efforts to turn back quickstart.sh to its original scope: making you
launch it with just one parameter and have an available environment
after a while (OK, sometimes more than a while).
Since part of the recent discussions were around the hypotheses of
removing it, maybe we can think about make it useful again. Mostly
because it is right that the needs of everyone are different, but on the
other side with a solid starting point (the default) you can think about
customizing depending on your needs.
I'm for recycling what we have, planet (and me) will enjoy it!

My 0,002 cents.




--
Best regards,
Bogdan Dobrelya,
Irc #bogdando

__
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] [tripleo] quickstart for humans

[Wesley Hayutin]

On Fri, Aug 31, 2018 at 7:12 AM Steven Hardy  wrote:

> On Thu, Aug 30, 2018 at 3:28 PM, 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 was recently directed to the reproducer-quickstart.sh script that's
> written in the logs directory for all oooq CI jobs - does that help as
> a replacement for the previous devmode interface?
>
> Not that familiar with it myself but it seems to target many of the
> use-cases you mention e.g uniform reproducer for issues, potentially
> quicker way to replicate CI results?
>
> Steve
>
>
Thanks Honza and Steve for sharing.
Steve is correctly pointing out that reproducer scripts [1] are the
upgraded version of what was known as devmode.  There are two main goals we
are trying to achieve as a CI team with regards reproducing CI.

A.  Ensure that a developer can reproduce what is executed upstream step by
step as closely as is possible to deliver a 1:1 matching result
B.  Ensure the reliability of the local run is as close to the reliability
of the upstream check job as possible.

The older devmode scripts did a rather poor job at both A and B, where the
reproducer_script will actually execute the upstream CI workflow once an
environment is provisioned.  The results should be identical as long as
there are no yum, or other network related issues.

CI is a very opinionated realm of work, a point that Jirka makes quite
well.  We have to focus on goals that are clearly defined.  The long term
goal is make TripleO very easy to use and deploy, not just make
tripleo-quickstart easy to use.

The TripleO CI team is happy to help Honza or Jason stand up a tripleo job
against the tripleo-ui repo.  At which point you should have something
testing your changes and the scripts and tools to reproduce that job.  I
never like to see an upstream repo w/o any real CI running against it.

Thanks


[1]
https://docs.openstack.org/tripleo-docs/latest/contributor/reproduce-ci.html


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

Wes Hayutin

Associate MANAGER

Red Hat



whayu...@redhat.comT: +1919 <+19197544114>4232509 IRC:  weshay


View my calendar and check my availability for meetings HERE

__
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] [tripleo] quickstart for humans

[mathieu bultel]

Hi

On 08/30/2018 04:28 PM, 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'm agree with the fact that quickstart has turned into a CI tool, more
than a human tool.
I still use quickstart to deploy and work on TripleO but I feel a bit
lost when I have to grep into the config/ dirctory to see which
featureset match to my needs and, if not, try to tweak the config and
pray that the tweaked options will work as expected.

I also discovered the ci reproducer script recently. The script probably
need to be a bit more robust, but it's a real gain when you have to
reproduce CI environments.

I think a first less effort for now would be to bring a set of
Quickstart commands and "human readable config files" to improve the
situation.

> 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

Re: [openstack-dev] [tripleo] quickstart for humans

[Raoul Scarazzini]

On 8/31/18 12:07 PM, Jiří Stránský wrote:
[...]
> * "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.

Hey Jiri,
I think that "for humans" means simply that you launch the command with
just one parameter (i.e. the virthost), and then you have something.
And because of this I think here is just a matter of concentrate the
efforts to turn back quickstart.sh to its original scope: making you
launch it with just one parameter and have an available environment
after a while (OK, sometimes more than a while).
Since part of the recent discussions were around the hypotheses of
removing it, maybe we can think about make it useful again. Mostly
because it is right that the needs of everyone are different, but on the
other side with a solid starting point (the default) you can think about
customizing depending on your needs.
I'm for recycling what we have, planet (and me) will enjoy it!

My 0,002 cents.

-- 
Raoul Scarazzini
ra...@redhat.com

__
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] [tripleo] quickstart for humans

[Honza Pokorny]

On 2018-08-31 13:17, Dougal Matthews wrote:
> On 31 August 2018 at 12:11, Steven Hardy  wrote:
> 
> > On Thu, Aug 30, 2018 at 3:28 PM, 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 was recently directed to the reproducer-quickstart.sh script that's
> > written in the logs directory for all oooq CI jobs - does that help as
> > a replacement for the previous devmode interface?
> >
> > Not that familiar with it myself but it seems to target many of the
> > use-cases you mention e.g uniform reproducer for issues, potentially
> > quicker way to replicate CI results?
> >
> 
> It is very good for that. However, the problem I have with reproducer
> scripts is that they are tied to the CI output. If I am working on a patch,
> the only way I know to get a reproducer is to submit the patch and then
> wait for CI to finish and then run the script again myself.
> 
> It would be very useful if I there was a tool where I could run a specific
> CI job, with a gerrit patch included (or even a local change would be more
> amazing!). Perhaps even a reproducer script generator would do the job.
> 

Yes, the reproducer seems to work quite well.  It's just not very
user-friendly.  The issue is that you need to find the right CI job, go
to the logs, download the file, etc. Instead of simply cloning a repo,
installing the tool, and running it when needed.

As such, we already have a couple of patches to introduce a reproducer
script generator.  One by me, and one by Gabriele.

https://review.openstack.org/#/c/586843/
https://review.openstack.org/#/c/548005/

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

> __
> 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] [tripleo] quickstart for humans

[Dougal Matthews]

On 31 August 2018 at 12:11, Steven Hardy  wrote:

> On Thu, Aug 30, 2018 at 3:28 PM, 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 was recently directed to the reproducer-quickstart.sh script that's
> written in the logs directory for all oooq CI jobs - does that help as
> a replacement for the previous devmode interface?
>
> Not that familiar with it myself but it seems to target many of the
> use-cases you mention e.g uniform reproducer for issues, potentially
> quicker way to replicate CI results?
>

It is very good for that. However, the problem I have with reproducer
scripts is that they are tied to the CI output. If I am working on a patch,
the only way I know to get a reproducer is to submit the patch and then
wait for CI to finish and then run the script again myself.

It would be very useful if I there was a tool where I could run a specific
CI job, with a gerrit patch included (or even a local change would be more
amazing!). Perhaps even a reproducer script generator would do the job.




>
> 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
>
__
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] [tripleo] quickstart for humans

[Steven Hardy]

On Thu, Aug 30, 2018 at 3:28 PM, 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 was recently directed to the reproducer-quickstart.sh script that's
written in the logs directory for all oooq CI jobs - does that help as
a replacement for the previous devmode interface?

Not that familiar with it myself but it seems to target many of the
use-cases you mention e.g uniform reproducer for issues, potentially
quicker way to replicate CI results?

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] [tripleo] quickstart for humans

[Cédric Jeanneret]

On 08/30/2018 04:28 PM, 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?

Hello,

As an exercise in order to learn a bit more ansible and refresh my
deploy knowledge, I've create that simple thing:
https://github.com/cjeanner/tripleo-lab
It's "more or less generic", but it was probably never deployed outside
my home infra - its aim is to provide a quick'n'dropable libvirt env,
allowing some tweaking in a convenient way.
That's not at quickstart level - but in order to boostrap an undercloud
or a more complete env, it's more than enough.

The other reason I made this was the feeling quickstart is a beast, not
really easy to master - apparently I'm not the only one """fearing
it. I probably didn't dig deep enough. And I wanted to get my own thing,
with some proxy/local mirror support in order to alleviate network
traffic on my home line (it's fast, but still... it's faster on the LAN
;) ).

Cheers,

C.

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

-- 
Cédric Jeanneret
Software Engineer
DFG:DF



signature.asc
Description: OpenPGP digital signature
__
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] [tripleo] quickstart for humans

[Jiří Stránský]

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

Re: [openstack-dev] [tripleo] quickstart for humans

[Jason E. Rist]

On 08/30/2018 08:28 AM, 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?
>
> 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
>
Thanks for bringing this up, Honza.  If something like this does exist, please 
share.  Otherwise, we're moving further and further away from Quickstart being 
useful for Devs which is a problem for the entire community, in my opinion.

-J
-- 
Jason E. Rist
Senior Software Engineer
OpenStack User Interfaces
Red Hat, Inc.
Freenode: jrist
github/twitter: knowncitizen

__
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] [tripleo] quickstart for humans

[Honza Pokorny]

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?

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