Open Stack

Steve Baker wrote:
> On 07/08/15 00:12, Dan Prince wrote:
>> On Thu, 2015-07-23 at 07:40 +0100, Derek Higgins wrote:
>>> See below
>>>
>>> On 21/07/15 20:29, Derek Higgins wrote:
>>>> Hi All,
>>>> Something we discussed at the summit was to switch the focus of
>>>> tripleo's deployment method to deploy using instack using images
>>>> built
>>>> with tripleo-puppet-elements. Up to now all the instack work has
>>>> been
>>>> done downstream of tripleo as part of rdo. Having parts of our
>>>> deployment story outside of upstream gives us problems mainly
>>>> because it
>>>> becomes very difficult to CI what we expect deployers to use while
>>>> we're
>>>> developing the upstream parts.
>>>>
>>>> Essentially what I'm talking about here is pulling instack
>>>> -undercloud
>>>> upstream along with a few of its dependency projects (instack,
>>>> tripleo-common, tuskar-ui-extras etc..) into tripleo and using them
>>>> in
>>>> our CI in place of devtest.
>>>>
>>>> Getting our CI working with instack is close to working but has
>>>> taken
>>>> longer then I expected because of various complications and
>>>> distractions
>>>> but I hope to have something over the next few days that we can use
>>>> to
>>>> replace devtest in CI, in a lot of ways this will start out by
>>>> taking a
>>>> step backwards but we should finish up in a better place where we
>>>> will
>>>> be developing (and running CI on) what we expect deployers to use.
>>>>
>>>> Once I have something that works I think it makes sense to drop the
>>>> jobs
>>>> undercloud-precise-nonha and overcloud-precise-nonha, while
>>>> switching
>>>> overcloud-f21-nonha to use instack, this has a few effects that
>>>> need to
>>>> be called out
>>>>
>>>> 1. We will no longer be running CI on (and as a result not
>>>> supporting)
>>>> most of the the bash based elements
>>>> 2. We will no longer be running CI on (and as a result not
>>>> supporting)
>>>> ubuntu
>> One more side effect is that I think it also means we no longer have
>> the capability to test arbitrary Zuul refspecs for projects like Heat,
>> Neutron, Nova, or Ironic in our undercloud CI jobs. We've relied on the
>> source-repositories element to do this for us in the undercloud and
>> since most of the instack stuff uses packages I think we would loose
>> this capability.
>>
>> I'm all for testing with packages mind you... would just like to see us
>> build packages for any projects that have Zuul refspecs inline, create
>> a per job repo, and then use that to build out the resulting instack
>> undercloud.
>>
>> This to me is the biggest loss in our initial switch to instack
>> undercloud for CI. Perhaps there is a middle ground here where instack
>> (which used to support tripleo-image-elements itself) could still
>> support use of the source-repositories element in one CI job until we
>> get our package building processes up to speed?
>>
>> /me really wants 'check experimental' to give us TripleO coverage for
>> select undercloud projects
> If Derek is receptive, I would find it useful if Delorean became a
> stackforge/openstack hosted project with better support for building
> packages from local git trees rather than remote checkouts.
>
> With a bit of hackery I was doing this for a while, developing features
> locally on heat and other repos, then deploying an undercloud from a
> locally hosted delorean repo.

Just an fyi, but anvil is now building centos7 rpms in its gate,  from 
git checkouts (somethings its been doing for a long time but now does it 
in the gate as well), this includes all the dependencies not already 
found in EPEL:

A run from a little while ago showing the various stages:

http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/ 
(the full logs + rpmbuild logs output)...

Stages:

(1) Git checkouts @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_16_34_130

(2) Requirement unifying/modification @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_17_22_862

(3) Determination of whats already satisfiable via epel or other repos @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_17_41_733 


(4) Downloading using pip unsatisfied/not found dependencies @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_17_42_113

(5) Filtering what was downloaded (pip pulls in dependencies of 
dependencies so have to kick out things that are already satisfiable 
again) @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_18_51_638

(6) Creation of source rpms from pip downloaded archives @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_18_52_365

(7) Creation of source rpms (spec files generated here for each git repo 
from common templates...) from git checked out repositories @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_19_41_450

(8) Preparation stage finish @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_20_12_201 
(source rpms are all created here)

(9) Translation from source rpms -> binary rpms for all pip dependencies 
previously turned into source rpms @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_20_29_813 
(these end up in 'anvil-deps' repo @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_23_58_908)

(10) Translation of git repos previously made into source rpms into 
binary rpms @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_24_00_165 
(these end up in 'anvil' repo @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_25_22_710)

(11) Done, build phase completed happily @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-rpms-dsvm-devstack-centos7/1aa3f56/console.html#_2015-08-10_00_25_23_619

And then u go on and use these repos to deploy openstack, and profit....

I believe refspecs now work also, due to 
https://github.com/stackforge/anvil/commit/b9217f327bdae but I haven't 
tried that out, anyways now u know... Oh ya, anvil also builds venv 
tarballs (on trusty in the gate) using some of the same code (log for 
that @ 
http://logs.openstack.org/43/210643/1/check/gate-anvil-venv-bare-trusty/83754d9/console.html#_2015-08-10_00_32_00_335)

-Josh

>
> This would help getting CI working with Zuul refspecs, but it may be
> what Dan was meaning anyway when he said "get our package building
> processes up to speed"
>>>> Should anybody come along in the future interested in either of
>>>> these
>>>> things (and prepared to put the time in) we can pick them back up
>>>> again.
>>>> In fact the move to puppet element based images should mean we can
>>>> more
>>>> easily add in extra distros in the future.
>>>>
>>>> 3. While we find our feet we should remove all tripleo-ci jobs from
>>>> non
>>>> tripleo projects, once we're confident with it we can explore
>>>> adding our
>>>> jobs back into other projects again
>>>>
>>>> Nothing has changed yet, I order to check we're all on the same
>>>> page
>>>> this is high level details of how I see things should proceed so
>>>> shout
>>>> now if I got anything wrong or you disagree.
>>> Ok, I have a POC that has worked end to end in our CI environment[1],
>>>
>>> there are a *LOT* of workarounds in there so before we can merge it I
>>>
>>> need to clean up and remove some of those workarounds and todo that a
>>>
>>> few things need to move around, below is a list of what has to happen
>>>
>>> (as best I can tell)
>>>
>>> 1) Pull in tripleo-heat-template spec changes to master delorean
>>> We had two patches in the tripleo-heat-template midstream packaging
>>> that
>>> havn't made it into the master packaging, these are
>>> https://review.gerrithub.io/241056 Package firstboot and extraconfig
>>> templates
>>> https://review.gerrithub.io/241057 Package environments and newtork
>>> directories
>>>
>>> 2) Fixes for instack-undercloud (I didn't push these directly incase
>>> it
>>> effected people on old versions of puppet modules)
>>> https://github.com/rdo-management/instack-undercloud/pull/5
>>>
>>> 3) Add packaging for various repositories into openstack-packaging
>>> I've pulled the packaging for 5 repositories into
>>> https://github.com/openstack-packages
>>> https://github.com/openstack-packages/python-ironic-inspector-client
>>> https://github.com/openstack-packages/python-rdomanager-oscplugin
>>> https://github.com/openstack-packages/tuskar-ui-extras
>>> https://github.com/openstack-packages/ironic-discoverd
>>> https://github.com/openstack-packages/tripleo-common
>>>
>>> I havn't imported these into gerrithub (incase following discussion
>>> we
>>> need to delete them again) but assuming we're in agreement we should
>>> pull them into gerrithub)
>>>
>>> 4) update rdoinfo
>>> https://github.com/redhat-openstack/rdoinfo/pull/69
>>> If everybody is happy with all above we should merge this, all of the
>>>
>>> packages needed will now be on the delorean master repository
>>>
>>> 5) Move DELOREAN_REPO_URL in tripleo-ci to a new delorean repo that
>>> includes all of the new packages
>> There is a puppet-neutron change I needed to use the latest Neutron
>> packages BTW:
>> https://review.openstack.org/#/c/207861/
>>
>> Just a heads up if we rebase the Delorean URL to something more recent
>> (last 2 weeks or so) that includes this neutron commit.
>>
>>> 6) Take most of the workarounds out of this patch[1] and merge it
>>>
>>> 7) Reorg the tripleo ci tests (essentially remove all of the bash
>>> element based tests).
>>>
>>> 8) Pull instack, instack-undercloud, python-rdomanager-oscplugin,
>>> triple-common, tuskar-ui-extras and maybe more into the upstream
>>> gerrit
>> I would really like to see us rename python-rdomanager-oscplugin. I
>> think any project having the name "RDO" in it probably doesn't belong
>> under TripleO proper. Looking at the project there are some distro
>> specific things... but those are fairly encapsulated (or could be made
>> so fairly easily).
>>
>>
>>> From here on the way to run the tripleo will be to follow the
>>> documentation in instack-undercloud, we should no longer be using
>>> devtest, this means we've lost the automation devtest gave us, so we
>>> will have to slowly build that up again. The main thing we have
>>> gained
>>> is that we will now be developing upstream all parts of how we expect
>>>
>>> deployers to use tripleo.
>>>
>>> - we will still have dependencies on tripleo-incubator we need to
>>> remove
>>> these (or move things into other repositories), essentially were
>>> finished with this process once we're no longer installing the
>>> "tripleo"
>>> package.
>>> - The new CI (as is) is running on Fedora jenkins nodes but building
>>> (and deploying) centos images, we also discussed that some people
>>> would
>>> want to develop on Fedora we will have to create a Fedora job as well
>>>
>>> (which I'm sure will involve the need for adding Fedora support into
>>> instack)
>> Yes. I would like to see instack support Fedora as well.
>>
>>> Everything in the first 4 steps is ready to go now, once done we can
>>> investigate moving DELOREAN_REPO_URL and remove the workarounds from
>>> the
>>> CI patch.
>>>
>>> Thanks,
>>> Derek
>>>
>>> [1] - https://review.openstack.org/#/c/185151/
>>>
>>> _____________________________________________________________________
>>> _____
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
>>> cribe
>>> 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