Support different endpoints for `convox rack update` #477

Closed
nzoschke opened this Issue Mar 23, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@nzoschke
Contributor

nzoschke commented Mar 23, 2016

Currently convox rack update only works with to a single, convox-managed channel of releases. This should be generalized to support:

  • using a different convox-managed release channel like, e.g. "unstable"
  • managing a totally independent channel, e.g. your own fork of convox

This will also require changes to the https://github.com/convox/release tools.

@nzoschke

This comment has been minimized.

Show comment
Hide comment
@nzoschke

nzoschke Mar 23, 2016

Contributor

cc @anthonyrisinger who is already doing this in practice!

Contributor

nzoschke commented Mar 23, 2016

cc @anthonyrisinger who is already doing this in practice!

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Mar 23, 2016

Contributor

I can't post our build script directly because there's too much unrelated and/or sensitive activity, but I'll capture the things it does here. I think another PR that adds development.md might note these same things.

  • Create new version string: VERSION
  • Create bucket to hold all the global things: BUCKET
  • Create buckets to hold all the regional things: BUCKET-REGIONAL (I'm not doing this yet, so I'm locked to us-east-1... thanks lambda)
  • Decide where you'll be storing the convox api (and old registry) images: REGISTRY-URL
  • Update all hardcoded S3 references:
    sed -i -r 's,//([^./]+)(.s3.amazonaws.com/release),//BUCKET\2,g' \
        cmd/convox/install.go \
        api/provider/aws/system.go \
        api/models/templates/app.tmpl \
        Godeps/_workspace/src/github.com/convox/release/version/version.go
  • Update relevant part of S3Bucket in api/models/templates/app.tmpl to BUCKET
  • Regen templates.go
  • Update api/dist/kernel.json to set .Parameters.Version.Default to VERSION
  • Update api/dist/kernel.json to set .Resources.CustomTopic.Properties.Code.S3Bucket to BUCKET
  • Update api/dist/kernel.json to set convox/(api|registry) to REGISTRY-URL/convox/(api|registry)
  • Build client for each platform eg. CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build
  • Upload client to s3://BUCKET/release/VERSION/client/$GOOS/$GOARCH/convox
  • Generate and upload formation.zip to each BUCKET-REGIONAL (I'm not doing this yet, so I'm locked to us-east-1)
  • Build the api image as convox/api:VERSION
  • Push convox/api:VERSION to REGISTRY-URL/convox/api:VERSION
  • Push convox/registry:latest to REGISTRY-URL/convox/registry:VERSION
  • Update s3://BUCKET/release/versions.json with the new entry

I don't currently set published: true on any release (also convox rack releases --unpublished doesn't seem to work anymore?) but I assume it would work fine. This just requires you to pass the version explicitly when performing a rack upgrade.

The main thing is the bucket... but there is a problem then when "switching" channels. If you install the rack from the unstable channel it's locked to that forever. Currently each channel is a different bucket, but there is some desire to merge them all so I can just update a rack to whatever I want. I think there is benefit to making the channel concept work within a single bucket (maybe teaching the updater to explicitly accept a channel, which would mean a new bucket, is enough).

The only thing I know I do extra is uploading the clients right along with everything else.

Contributor

anthonyrisinger commented Mar 23, 2016

I can't post our build script directly because there's too much unrelated and/or sensitive activity, but I'll capture the things it does here. I think another PR that adds development.md might note these same things.

  • Create new version string: VERSION
  • Create bucket to hold all the global things: BUCKET
  • Create buckets to hold all the regional things: BUCKET-REGIONAL (I'm not doing this yet, so I'm locked to us-east-1... thanks lambda)
  • Decide where you'll be storing the convox api (and old registry) images: REGISTRY-URL
  • Update all hardcoded S3 references:
    sed -i -r 's,//([^./]+)(.s3.amazonaws.com/release),//BUCKET\2,g' \
        cmd/convox/install.go \
        api/provider/aws/system.go \
        api/models/templates/app.tmpl \
        Godeps/_workspace/src/github.com/convox/release/version/version.go
  • Update relevant part of S3Bucket in api/models/templates/app.tmpl to BUCKET
  • Regen templates.go
  • Update api/dist/kernel.json to set .Parameters.Version.Default to VERSION
  • Update api/dist/kernel.json to set .Resources.CustomTopic.Properties.Code.S3Bucket to BUCKET
  • Update api/dist/kernel.json to set convox/(api|registry) to REGISTRY-URL/convox/(api|registry)
  • Build client for each platform eg. CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build
  • Upload client to s3://BUCKET/release/VERSION/client/$GOOS/$GOARCH/convox
  • Generate and upload formation.zip to each BUCKET-REGIONAL (I'm not doing this yet, so I'm locked to us-east-1)
  • Build the api image as convox/api:VERSION
  • Push convox/api:VERSION to REGISTRY-URL/convox/api:VERSION
  • Push convox/registry:latest to REGISTRY-URL/convox/registry:VERSION
  • Update s3://BUCKET/release/versions.json with the new entry

I don't currently set published: true on any release (also convox rack releases --unpublished doesn't seem to work anymore?) but I assume it would work fine. This just requires you to pass the version explicitly when performing a rack upgrade.

The main thing is the bucket... but there is a problem then when "switching" channels. If you install the rack from the unstable channel it's locked to that forever. Currently each channel is a different bucket, but there is some desire to merge them all so I can just update a rack to whatever I want. I think there is benefit to making the channel concept work within a single bucket (maybe teaching the updater to explicitly accept a channel, which would mean a new bucket, is enough).

The only thing I know I do extra is uploading the clients right along with everything else.

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Mar 24, 2016

Contributor

Probably a bucket-per-channel is the way to go, because it maps so cleanly. In this model one can choose the channel at installation and upgrade time. Some things I don't like about this or are unsolved:

  • convox rack releases stops making sense because now some of the releases you passed through are from other channels. We'd need to track the channel too for rollback purposes.
  • How are required releases handled? Multiple channels are together not linear.
  • When an app is launched in one channel, it is linked to a lambda CF handler that corresponds to the rack release. Switching channels would break all apps created in the old channel because their handler would not exist.

The last problem (CF handler) is maybe the big advantage of splitting installation and upgrades: at install time you choose the bucket (your "upstream"), at upgrade time you select a prefix in that bucket (channel). I'm not sure about that CF handler because it's not clear to me how that even works today... even though my app's formation continues to evolve (since the rack itself is upgraded) it's permanently linked to that old CF handler? What if it starts receiving stuff it doesn't understand?

If we can address the CF handler issue for switching channels I think it will help us understand what the best step is.

Contributor

anthonyrisinger commented Mar 24, 2016

Probably a bucket-per-channel is the way to go, because it maps so cleanly. In this model one can choose the channel at installation and upgrade time. Some things I don't like about this or are unsolved:

  • convox rack releases stops making sense because now some of the releases you passed through are from other channels. We'd need to track the channel too for rollback purposes.
  • How are required releases handled? Multiple channels are together not linear.
  • When an app is launched in one channel, it is linked to a lambda CF handler that corresponds to the rack release. Switching channels would break all apps created in the old channel because their handler would not exist.

The last problem (CF handler) is maybe the big advantage of splitting installation and upgrades: at install time you choose the bucket (your "upstream"), at upgrade time you select a prefix in that bucket (channel). I'm not sure about that CF handler because it's not clear to me how that even works today... even though my app's formation continues to evolve (since the rack itself is upgraded) it's permanently linked to that old CF handler? What if it starts receiving stuff it doesn't understand?

If we can address the CF handler issue for switching channels I think it will help us understand what the best step is.

@nzoschke

This comment has been minimized.

Show comment
Hide comment
@nzoschke

nzoschke Aug 18, 2016

Contributor

In light of the Aug 17th Rack Password issue, i'm bumping this issue for more immediate consideration. The primary goal is to:

  • Offer a way to put staging racks on an unstable channel for maximum velocity
  • Offer a way to put production racks on a stable channel for maximum reliability
$ convox rack update
Updating to stable version: 20160706200033

$ convox rack params set Unstable=true
Updating parameters... OK

$ convox rack update
Updating to unstable version: 20160706200033
Contributor

nzoschke commented Aug 18, 2016

In light of the Aug 17th Rack Password issue, i'm bumping this issue for more immediate consideration. The primary goal is to:

  • Offer a way to put staging racks on an unstable channel for maximum velocity
  • Offer a way to put production racks on a stable channel for maximum reliability
$ convox rack update
Updating to stable version: 20160706200033

$ convox rack params set Unstable=true
Updating parameters... OK

$ convox rack update
Updating to unstable version: 20160706200033
@ddollar

This comment has been minimized.

Show comment
Hide comment
@ddollar

ddollar Aug 18, 2016

Member

Just for future-proofishness

$ convox rack params set Channel=unstable
Updating parameters... OK
Member

ddollar commented Aug 18, 2016

Just for future-proofishness

$ convox rack params set Channel=unstable
Updating parameters... OK

@ddollar ddollar added kind/feature and removed enhancement labels Jan 4, 2017

@ddollar ddollar added area/design and removed area/experience labels Apr 6, 2017

@ddollar ddollar removed the area/design label Nov 15, 2017

@ddollar ddollar removed the kind/feature label Jan 26, 2018

@ddollar ddollar closed this Jan 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment