On 07/12/16 22:56, Sean McArthur wrote:
>
> Does the node binary get bundled into the rpm? Does the upgrade need
to be
> tied to a train? Is it just logistically the sanest approach?
To answer these question first:
- the node binary is not directly bundled into the application rpm
- the upgrade is not tied to a train, but is tied to the "pipeline" that
deploys whichever train.
- when a pipeline is started, inputs are application tags, svcops
sha, and
puppet-config sha. I have parallel-to-master branches for svcops and
puppet-config that handle building with node4 and provisioning
node4 with
the app (actually rpm+yum controls most of this implicitly).
>
> On Tue, Jul 12, 2016, 10:26 PM Ryan Kelly <[email protected]> wrote:
>
> Hi All,
>
> If I understand the landscape correctly, we have all the necessary
> pieces ready to upgrade to node v4 in production, and we just need to
> pick a time to push forward with the deployment. If so, then
let's pick
> a train to target a node v4 release.
>
> Based on nothing but it being the next available train, I propose
that
> we make train-66 the one to go live with node v4 in production.
>
> :jrgm (or anyone else for that matter!), thoughts?
>
I was thinking of doing this off-cycle, i.e., get train-X live, and then
re-test/ship train-X with node4x a couple of days later, so changes in any
metrics/behaviours can be attributed to either the released code, or to
the node4 runtime.
John
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
