Open Stack

On 2016-10-04 19:08:25 -0700 (-0700), Christopher Aedo wrote:
[...]
> From the last conversation we had around this[1], we would be at step
> 7 "deploy stagging.apps.openstack.org from 'glare-support' branches".
> There was one point fungi brought up[2], which was that we would not
> be creating special branches for this work.  Rather, the puppet
> manifest[3] would be adjusted to accept git commit IDs where un-merged
> code was called for.
[...]

By "un-merged" here I assume you mean commits merged to the
feature/glare-support branch of the openstack/app-catalog repo even
though that branch has not yet been merged back into the master
branch.

The openstack-infra/puppet-apps_site repo looks like it already
supports the logic you need: it has a $commit parameter which takes
an arbitrary Git reference, and defaults to 'master' so that your
apps.openstack.org server is continuously deployed with the master
branch tip of openstack/app-catalog. That was the relatively
complicated logic and it looks like it was implemented originally,
so you've actually already done the hard part there.

In the openstack-infra/system-config repo you need to update the
global site manifest (in manifests/site.pp) adding a separate dev
server (probably named more like apps-dev.openstack.org for
consistency with most of our other dev servers) and pass in
commit=>'feature/glare-support' telling it to deploy from the tip of
the openstack/app-catalog repo's feature/glare-support branch.

After that's done, an infra-root sysadmin needs to manually launch a
server named apps-dev.openstack.org and help troubleshoot any
configuration management errors which might arise from incomplete
automated testing.

Once you're satisfied with the state of feature/glare-support as
evidenced from using the dev server, merge that branch back into
master and the continuous automation you already have will make it
live on the production apps.openstack.org server.
-- 
Jeremy Stanley