Open Stack

On 13 June 2016 at 21:29, Ben Nemec <openstack at nemebean.com> wrote:
> So our documented repo setup steps are three curls, a sed, and a
> multi-line bash command.  And the best part?  That's not even what we
> test.  The commands we actually use in tripleo.sh --repo-setup consist
> of the following: three curls, four seds, and (maybe) the same
> multi-line bash command.  Although whether that big list of packages in
> includepkgs is actually up to date with what we're testing is anybody's
> guess because without actually plugging both into a diff tool you
> probably can't visually find any differences.

Looking at the docs I think we should remove the list of packages
altogether, what we document for people trying to use tripleo should
only include the current-tripleo and deps repositories, as we know
this has passed a periodic CI job. This would reduce the documented
process too just 2 curls. The only place we need to worry about
pulling certain packages from /current is in CI and for devs who need
the absolute most up to date tripleo packages in these two cases
tripleo.sh should be used.


> What is my point?  That this whole process is overly complicated and
> error-prone.  If you miss one of those half dozen plus commands you're
> going to end up with a broken repo setup.  As one of the first things
> that a new user has to do in TripleO, this is a pretty poor introduction
> to the project.

Yup, couldn't agree more here, the simpler we can make things for a
new user the better

>
> My proposal is an rdo-release-esque project that will handle the repo
> setup for you, except that since dlrn doesn't really deal in releases I
> think the -repo name makes more sense.  Here's a first pass at such a
> tool: https://github.com/cybertron/dlrn-repo
>
> This would reduce the existing commands in tripleo.sh from:
> sudo sed -i -e 's%priority=.*%priority=30%' $REPO_PREFIX/delorean-deps.repo
> sudo curl -o $REPO_PREFIX/delorean.repo
> $DELOREAN_REPO_URL/$DELOREAN_REPO_FILE
> sudo sed -i -e 's%priority=.*%priority=20%' $REPO_PREFIX/delorean.repo
> sudo curl -o $REPO_PREFIX/delorean-current.repo
> http://trunk.rdoproject.org/centos7/current/delorean.repo
> sudo sed -i -e 's%priority=.*%priority=10%'
> $REPO_PREFIX/delorean-current.repo
> sudo sed -i 's/\[delorean\]/\[delorean-current\]/'
> $REPO_PREFIX/delorean-current.repo
> sudo /bin/bash -c "cat <<-EOF>>$REPO_PREFIX/delorean-current.repo
> includepkgs=diskimage-builder,instack,instack-undercloud,os-apply-config,os-cloud-config,os-collect-config,os-net-config,os-refresh-config,python-tripleoclient,tripleo-common,openstack-tripleo-heat-templates,openstack-tripleo-image-elements,openstack-tripleo,openstack-tripleo-puppet-elements
> EOF"
> sudo yum -y install yum-plugin-priorities
>
> to:
> sudo yum install -y http://tripleo.org/dlrn-repo.rpm # or wherever
> sudo dlrn-repo tripleo-current
>
> As you can see in the readme it also supports the stable branch repos or
> running against latest master of everything.
>
> Overall I think this is clearly a better user experience, and as an
> added bonus it would allow us to use the exact same code for repo
> management on the user side and in CI, which we can't have with a
> developer-specific tool like tripleo.sh.
>
> There's plenty left to do before this would be fully integrated (import
> to TripleO, package, update docs, update CI), so I wanted to solicit
> some broader input before pursuing it further.

I'm a little on the fence about this, I think the main problem you
bring up is the duplication of the includepkgs list, which I think we
can just remove from the docs, so whats left is the ugly blurb of
script in tripleo.sh --repo-setup, using a tool to do this certainly
improves the code, but does the creation of a new project complicate
things in its own way?

If we do go ahead with this the one suggestion I would have is
s/dlrn/trunk/g
delorean is the tool used to create trunk repositories, we shouldn't
care, it may even change some day, we are just dealing with trunk
repositories

>
> Thanks.
>
> -Ben
>
> __________________________________________________________________________
> 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