505318 - [Tracking bug] kicking off a release shouldn't require a reconfig

Status: RESOLVED INCOMPLETE

(Release Engineering :: General, defect, P4)

Description

[Chris AtLee [:catlee]]

Having all of the parameters for a release stored in release_config.py means that do start a release you need to:
- Push changes to release_config.py
- ssh to production-master, pull and update changes
- reconfig production-master

This isn't easily automated (thinking of production-master reconfiguring itself makes me shudder), and there's also the risk of pulling in unwanted changes from buildbot-configs just to get the updated release configs.  The current method also becomes a bit complicated when considering releases on multiple branches.

We should continue to have the release parameters stored in version control, but figure out a way to avoid the ssh and reconfigure step.

One idea is to have the release configs checked out on the build slave, and set as build properties.  Which config file to read could be a function of which release branch is triggered, or maybe listed in the 'files' parameter of a sendchange event.

Comment 1

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 2

[Armen [:armenzg]]

I don't think I will manage to get this done before the end of the quarter.

I agree with catlee's approach.

Let's also wait to see what the release automation looks like after we upgrade to 0.8.x

Comment 3

[Armen [:armenzg]]

After talking with bhearsum and catlee last week there few things that are to be fixed. The general opinion is that this bug should close this bug because there is no workable actions on this bug OR turn this into a tracking bug.

@triagefollowup can we close this bug and/or turn into a tracking bug?

As a summary:
#############
Each builder on a release should be able to pull the information from buildbot-configs rather than being passed as parameters to each builder's factory.

Besides that, the FTP poller has to be fixed. 

After the work that bhearsum is doing with tagging and l10n we won't depend on a reconfig anymore.

Comment 4

[Chris Cooper [:coop] (he/him)]

(In reply to comment #3)
> After the work that bhearsum is doing with tagging and l10n we won't depend on
> a reconfig anymore.

If that's true, then you can dupe this bug to one of those (and provide a link to the other.

Comment 5

[[e-mail] (:bhearsum)]

(In reply to comment #4)
> (In reply to comment #3)
> > After the work that bhearsum is doing with tagging and l10n we won't depend on
> > a reconfig anymore.
> 
> If that's true, then you can dupe this bug to one of those (and provide a link
> to the other.

I think Armen means that those steps won't depend on a reconfig anymore. We still need one for all other builders.

Comment 6

[Mike Taylor [:bear]]

Armen,

Can you follow up with Ben to get the issue settled?  It sounds like you should create a tracking bug (or find one if it exists) and create a followup bug for the new issues.

The make both this bug and the new one block the tracker.  That will let you close this bug and we will still have history and dependency tree data

Comment 7

[Chris Cooper [:coop] (he/him)]

(In reply to comment #6)
> Can you follow up with Ben to get the issue settled?  It sounds like you should
> create a tracking bug (or find one if it exists) and create a followup bug for
> the new issues.

Let's make this bug the tracking bug. Armen can get new bugs filed for the remaining issues and make them dependencies of this bug.

Comment 8

[Armen [:armenzg]]

triage: If I file the required dependent bugs would it then be good to drop the [oldbugs] from the whiteboard?

Comment 9

[Chris Cooper [:coop] (he/him)]

(In reply to comment #8)
> triage: If I file the required dependent bugs would it then be good to drop the
> [oldbugs] from the whiteboard?

Well, it's still going to be an oldbug. The bug # is still going to determine that. But yes, please do file any outstanding dependent bugs.

Comment 10

[Armen [:armenzg]]

@triagefollowup

I won't get to this.

This is a whole one quarter goal in itself and cannot be hit this quarter even if everything else was dropped to work on it.

It pretty much requires every single builder to behave the same way as the tagging and L10n repacks builders which checkout buildbot-configs to grab information from mozilla/release-firefox-$branch.py files (IIUC).

It also requires to find a solution to fix the L10n pollers (the ones that trigger partner repacks) and the poller for triggering postsigning builders.

Comment 11

[Chris Cooper [:coop] (he/him)]

(In reply to comment #10)
> It pretty much requires every single builder to behave the same way as the
> tagging and L10n repacks builders which checkout buildbot-configs to grab
> information from mozilla/release-firefox-$branch.py files (IIUC).
> 
> It also requires to find a solution to fix the L10n pollers (the ones that
> trigger partner repacks) and the poller for triggering postsigning builders.

As it stands, this bug is a tracking bug with no dependencies, so I'm closing it.

*However*, Armen, can I please ask you to file specific bugs for fixing up the pollers and builders that are outstanding. Make them block the new hg-automation tracking bug rather than this one, please.

Comment 12

[Armen [:armenzg]]

I filed bug 633304 and bug 633307 to track this.