[openstack-dev] [E] [tripleo] quickstart for humans

Wesley Hayutin whayutin at redhat.com
Wed Sep 5 21:52:33 UTC 2018


On Wed, Sep 5, 2018 at 5:08 PM Wesley Hayutin <whayutin at redhat.com> wrote:

> On Wed, Sep 5, 2018 at 3:55 PM Gordon, Kent <
> Kent.Gordon at verizonwireless.com> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: Honza Pokorny [mailto:honza at redhat.com]
>> > Sent: Thursday, August 30, 2018 9:28 AM
>> > To: OpenStack Development Mailing List (not for usage questions)
>> > <openstack-dev at lists.openstack.org>
>> > Subject: [E] [openstack-dev] [tripleo] quickstart for humans
>> >
>> > 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
>>
>> What is the recommended way to bring up a small POC of TripleO outside of
>> CI?
>>
>> Documentation suggests using quickstart
>>
>>
>> https://docs.openstack.org/tripleo-docs/latest/install/introduction/architecture.html
>>
>> "For development or proof of concept (PoC) environments, Quickstart can
>> also be used."
>>
>> Quickstart.sh outside of CI has been broken for a while.
>> It requires zuul cloner to work.
>>
>> https://bugs.launchpad.net/tripleo/+bug/1754498
>>
>>
> The issue described in bug [1] was caused by pip requirement install
> errors being swallowed up and not written to the console.
> TripleO-QuickStart-Extras was not pip installed due to previous errors, and
> that would cause quickstart-extras.yml to not be installed.
>
> The root cause of the failures is that pip install dependencies are not
> working as expected or in the same way without a http proxy  server.  This
> bug [1] should be closed, a RFE bug to ensure things work w/ a http proxy
> server should be opened.
>
> Please let me know if your work proves otherwise.
> Thank you!
>
> [1] https://bugs.launchpad.net/tripleo/+bug/1754498
>
>
>
I just launched an install with the following.

export WD=/var/tmp/test; ./quickstart.sh  --no-clone --release
tripleo-ci/master  --tags all --clean  --teardown all  -w $WD
whayutin-testbox

Where whayutin-testbox is my remote testbox, everything is working well atm
however there may be an issue w/ the bmc [1]

[1] https://bugs.launchpad.net/tripleo/+bug/1790969


>
>
>
>>
>>
>> __________________________________________________________________________
>> 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
>>
> --
>
> Wes Hayutin
>
> Associate MANAGER
>
> Red Hat
>
> <https://www.redhat.com/>
>
> whayutin at redhat.com    T: +1919 <+19197544114>4232509     IRC:  weshay
> <https://red.ht/sig>
>
> View my calendar and check my availability for meetings HERE
> <https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
>
-- 

Wes Hayutin

Associate MANAGER

Red Hat

<https://www.redhat.com/>

whayutin at redhat.com    T: +1919 <+19197544114>4232509     IRC:  weshay
<https://red.ht/sig>

View my calendar and check my availability for meetings HERE
<https://calendar.google.com/calendar/b/1/embed?src=whayutin@redhat.com&ctz=America/New_York>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180905/3cef1837/attachment.html>


More information about the OpenStack-dev mailing list