[Openstack] Should the OpenStack API re-use the EC2 credentials?

Eric Day eday at oddments.org
Thu Feb 24 22:55:35 UTC 2011


That is how it works now, but if we need to run tests that are not
on the tarmac machine, we need to push that local branch somewhere
so other things can test the same thing.

Monty Taylor will have a much better idea of how to orchestrate all
of this, I'm going off what we did in the past, and I know things
have changed some since then.

-Eric

On Thu, Feb 24, 2011 at 04:46:28PM -0600, Trey Morris wrote:
>    yikes! i assumed tarmac was running things locally merged with trunk to
>    test and actually merging after success. That's surprising. The branches
>    would definitely be safer.
> 
>    On Thu, Feb 24, 2011 at 4:41 PM, Eric Day <eday at oddments.org> wrote:
> 
>      Yup. Right now when a <project>-core member clicks 'Approve'
>      after code review, tarmac picks it up and pushes to trunk assuming
>      unittests pass. Instead it could push to staging and trigger a hook
>      in jenkins which would fire off a bunch of other jobs that run the
>      staging branch through a battery of tests. If they all check out ok
>      (possibly a human check in there to make sure variable results like
>      performance testing are ok), staging gets pushed to the real trunk.
>      -Eric
>      On Thu, Feb 24, 2011 at 04:36:16PM -0600, Trey Morris wrote:
>      >    I see. So their use would in general be for the use of automated
>      systems?
>      >
>      >    On Thu, Feb 24, 2011 at 4:33 PM, Eric Day <eday at oddments.org>
>      wrote:
>      >
>      >      The extra branches are just an implementation detail, we can have
>      >      them or not. It's really a matter of if it's possible and/or
>      easier
>      >      to have jenkins fire off new jobs with arbitrary branches that
>      need
>      >      to be merged with trunk for each job vs merging and pushing to a
>      >      staging branch and have the jobs test that. Either way, we get
>      the
>      >      same result. We will also have the flexibility to test arbitrary
>      >      branches before proposing either way. These extra "trunks" will
>      not
>      >      need to be managed, as tarmac/jenkins will control them.
>      >      -Eric
>      >      On Thu, Feb 24, 2011 at 04:24:11PM -0600, Trey Morris wrote:
>      >      >    I'm curious what the point of having a line of trunks for a
>      commit
>      >      to
>      >      >    bounce down on its way to trunk would gain us other than
>      having to
>      >      manage
>      >      >    a line of trunks. What's wrong with status quo branch
>      management
>      >      (other
>      >      >    than tests)? What's wrong with having the commit sit in its
>      LP
>      >      topic
>      >      >    branch, which is every bit as publicly accessible as any
>      branch in
>      >      the
>      >      >    line of trunks would be? The test system (or anyone who
>      wants to
>      >      play with
>      >      >    it) can just grab trunk merge the topic branch and run
>      however many
>      >      levels
>      >      >    or types of tests we deem appropriate. Success = trunk. Fail
>      = test
>      >      fail
>      >      >    status in the test report.
>      >      >
>      >      >    On Thu, Feb 24, 2011 at 3:39 PM, Jay Pipes
>      <jaypipes at gmail.com>
>      >      wrote:
>      >      >
>      >      >      On Thu, Feb 24, 2011 at 4:05 PM, Mark Washenberger
>      >      >      <mark.washenberger at rackspace.com> wrote:
>      >      >      >> This is what we're working on, and what Justin is
>      proposing,
>      >      Mark.
>      >      >      >>
>      >      >      >> Basically, in Drizzle-land, people propose a merge into
>      trunk,
>      >      Hudson
>      >      >      >> picks up that proposal, pulls the brnach into
>      >      lp:drizzle/staging,
>      >      >      >> builds Drizzle on all supported platforms (>12
>      OS/distro
>      >      combos),
>      >      >      then
>      >      >      >> runs all automated regression testing against the
>      proposed
>      >      branch
>      >      >      (can
>      >      >      >> take 3 or more hours).
>      >      >      >>
>      >      >      >> We're proposing the same kind of automation for
>      OpenStack.
>      >      >      >
>      >      >      > Sorry, I misunderstood what Justin was proposing. This
>      sounds
>      >      good to
>      >      >      me.
>      >      >      >
>      >      >      > We could also do this without a staging branch by having
>      the
>      >      automated
>      >      >      system check out trunk and merge the proposed branch
>      locally.
>      >      >
>      >      >      Sure, this is, of course, quite possible, too :)
>      >      >
>      >      >      One thing that a staging-first branch allows, though, is
>      to set
>      >      up an
>      >      >      environment where some *very* minor or style-only type
>      commits
>      >      can be
>      >      >      fed into trunk directly without having to got through the
>      full
>      >      testing
>      >      >      loop...
>      >      >      -jay
>      >      >      _______________________________________________
>      >      >      Mailing list: https://launchpad.net/~openstack
>      >      >      Post to     : openstack at lists.launchpad.net
>      >      >      Unsubscribe : https://launchpad.net/~openstack
>      >      >      More help   : https://help.launchpad.net/ListHelp
>      >
>      >      > _______________________________________________
>      >      > Mailing list: https://launchpad.net/~openstack
>      >      > Post to     : openstack at lists.launchpad.net
>      >      > Unsubscribe : https://launchpad.net/~openstack
>      >      > More help   : https://help.launchpad.net/ListHelp




More information about the Openstack mailing list