RFD 58: Package Distribution #10746
RFD 58: Package Distribution #10746
Conversation
We do not publish pre-releases to apt repos, but we do publish them to github. That means we need to filter them out when considering if an apt release should be published. We don't want v8.3.3 to be blocked by v9.0.0-dev.1, only by v9.0.0. Honestly, this is a bit of a mess, but it only needs to hold out a bit longer until #10746 lands. Contributes to #10800
We do not publish pre-releases to apt repos, but we do publish them to github. That means we need to filter them out when considering if an apt release should be published. We don't want v8.3.3 to be blocked by v9.0.0-dev.1, only by v9.0.0. Honestly, this is a bit of a mess, but it only needs to hold out a bit longer until #10746 lands. Contributes to #10800 (cherry picked from commit 08bc483)
We do not publish pre-releases to apt repos, but we do publish them to github. That means we need to filter them out when considering if an apt release should be published. We don't want v8.3.3 to be blocked by v9.0.0-dev.1, only by v9.0.0. Honestly, this is a bit of a mess, but it only needs to hold out a bit longer until #10746 lands. Contributes to #10800 (cherry picked from commit 08bc483)
There was a problem hiding this comment.
Thanks for all the research that went into this!
Some meta notes:
When you submit a PR, please provide a summary in the description field, including any related issues. While I may have that context, others who look at this PR (e.g. our open source community, or maintainers in two years time) won't have as much context implicitly available. Better to make that context explicitly available.
For RFDs, I also like to link to the rendered version in the description:
This is especially helpful for looking at e.g. the table, which is difficult to parse in the two column diff layout.
rfd/0058-package-distribution.md
Outdated
| To maintain backwards compatibility with our current solution we can reroute requests for the current repos to the new ones. This can be accomplished by placing a reverse proxy in front of the current repos and then using it to rewrite or redirect the incoming request to the new repos. | ||
|
|
||
| ### Future work | ||
| While a specific solution is outside of the scope of this RFD, it is pertinent to discuss a disaster scenario that is common to all solutions, including the current one. If the hosting solution that contains the repo (i.e. a S3 bucket or GCP Artifact Registry) is deleted then all artifacts must be rebuilt and published from scratch. It looks like the Drone pipeline for Teleport takes around 90 minutes to run. Depending on how many instances can be ran at once without conflicting with each other, it could take several hours to get the repository back online to it's previous state. This could be alleviated by backing up artifacts after they're built, or by backing up the entire hosting solution. |
There was a problem hiding this comment.
I've got some ideas here. DR backups are defiantly worth doing, with data replicated to a seperate region and versioning turned on.
Furthermore, I'd like to push towards a two phase publishing process:
- upon tag (or maybe even push to
master/releases/*) push the bits to a internal, private, staging repo. - upon promotion, re-sign with production keys, and push to the customer facing repo
Mostly, I want this so we can test most of the publishing without impacting customers. This has been a pain point for me, and many others running releases, as discussed recently at #10804 (review)
…10806) We do not publish pre-releases to apt repos, but we do publish them to github. That means we need to filter them out when considering if an apt release should be published. We don't want v8.3.3 to be blocked by v9.0.0-dev.1, only by v9.0.0. Honestly, this is a bit of a mess, but it only needs to hold out a bit longer until #10746 lands. Contributes to #10800 (cherry picked from commit 08bc483) Co-authored-by: Roman Tkachenko <roman@goteleport.com>
…10804) We do not publish pre-releases to apt repos, but we do publish them to github. That means we need to filter them out when considering if an apt release should be published. We don't want v8.3.3 to be blocked by v9.0.0-dev.1, only by v9.0.0. Honestly, this is a bit of a mess, but it only needs to hold out a bit longer until #10746 lands. Contributes to #10800
…10805) We do not publish pre-releases to apt repos, but we do publish them to github. That means we need to filter them out when considering if an apt release should be published. We don't want v8.3.3 to be blocked by v9.0.0-dev.1, only by v9.0.0. Honestly, this is a bit of a mess, but it only needs to hold out a bit longer until #10746 lands. Contributes to #10800 (cherry picked from commit 08bc483)
There was a problem hiding this comment.
@fheinecke One thing I'm not sure I really understood is this:
Does it download the entire content of S3 bucket with deb packages before sync? This is not going to be scalable, any way to do it without that? Unless I misunderstood of course.
|
In the past we have preferred using libraries rather than shelling out to command line apps. If we can, we should try using the |
|
@tcsc Can you take another look? |
fheinecke
force-pushed
the
rfd/0058-package-distribution
branch
from
118ece8 to
fe84b45
Compare
|
|
||
| kind: pipeline | ||
| type: kubernetes | ||
| name: migrate-apt-new-repos |
There was a problem hiding this comment.
Does this need to be a part of the drone pipeline?
There was a problem hiding this comment.
Thought about this a lot while building this part out. Putting it in the pipeline is by far the easiest way to implement migrations for older versions. In 99.9% of cases this pipeline will never be ran, but when we need to add previous versions this will save significant time. This section along with this new dronegen function takes another migration process like I did last week and turns it into a 5m change.
There was a problem hiding this comment.
I don't understand why this particular pipeline is here, though. I get publish-apt-new-repos, but not this one. Is it just marking that you intend to implement the migration of legacy here?
There was a problem hiding this comment.
This pipeline is the implementation of old artifact migration. It's just not enabled/ran unless dronegen is configured to migrate specific versions. When specific versions are added to this function then running make dronegen will add migration steps to this pipeline for Drone to run. When there are not any functions listed there, running make dronegen will replace the pipeline with a "NOP" pipeline to prevent repeated migrations.
| } | ||
|
|
||
| // Instantiates a new apt repo tool instance and performs any required setup/config. | ||
| func NewAptRepoTool(config *Config, supportedOSs map[string][]string) (*AptRepoTool, error) { |
There was a problem hiding this comment.
Why not make supportedOSs a part of the Config?
There was a problem hiding this comment.
When writing this I thought that would be a great idea, but ultimately decided against it as it has several downsides:
- The
flagslibrary does not support it, so implementing amap[string][]stringinput would likely add several hundred lines of parsing and code - Whatever format I went with would make reading the
.drone.ymland related dronegen function more difficult, and would make adding/removing OS and OS versions more difficult, or would make the dronegen function more brittle
Not pulling in the supportedOSs map makes the code overall easier to read and maintain, and pushes the burden of validating the map to the compiler.
fheinecke
force-pushed
the
rfd/0058-package-distribution
branch
from
3f642da to
f2bb06b
Compare
fheinecke
force-pushed
the
rfd/0058-package-distribution
branch
from
f2bb06b to
aa2663f
Compare
fheinecke
force-pushed
the
rfd/0058-package-distribution
branch
from
aa2663f to
5f0a933
Compare
|
@wadells here are some example runs:
|
|
|
||
| kind: pipeline | ||
| type: kubernetes | ||
| name: migrate-apt-new-repos |
There was a problem hiding this comment.
I don't understand why this particular pipeline is here, though. I get publish-apt-new-repos, but not this one. Is it just marking that you intend to implement the migration of legacy here?
Wrote a RFD to update how we handle deb and rpm package distribution. Available at https://github.com/gravitational/teleport/blob/rfd/0058-package-distribution/rfd/0058-package-distribution.md.
Related issues: