New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pill: we can use the autoprop tooling from byob #6231
Comments
tagging @jalehman and @belisarius222 for context - this is the way we can make creating and shipping pills automatic (and something we can ship now) |
We'll probably also want to update the autoprop builder to support auto-building new azimuth snapshots. |
One knee-jerk reaction I have to this is that we should consider making the system resilient to the situation where the sponsor is ahead of the sponsee, so we can decouple releasing pills from releasing new code on galaxies.
That would allow us to remove the delay in autoprop and give us more flexibility in our release processes, in addition to improving resiliency of the network in case of a lazy sponsor who hasn't updated by the time a new sponsee boots up with a later kernel than the sponsor.
…On Fri, Jan 20 2023 at 3:56 PM, fang < ***@***.*** > wrote:
We'll probably also want to update the autoprop builder to support
auto-building new azimuth snapshots.
—
Reply to this email directly, view it on GitHub (
#6231 (comment) ) , or unsubscribe
(
https://github.com/notifications/unsubscribe-auth/AAGVR5J6XLUDOEUQNGGUQELWTMCY5ANCNFSM6AAAAAAUB67D2I
).
You are receiving this because you were mentioned. Message ID: <urbit/urbit/issues/6231/1398999427
@ github. com>
|
To be clear, I support the idea behind this PR too. The previous comment isn't that relevant for the moment.
…On Fri, Jan 20 2023 at 4:44 PM, Ted Blackman < ***@***.*** > wrote:
One knee-jerk reaction I have to this is that we should consider making
the system resilient to the situation where the sponsor is ahead of the
sponsee, so we can decouple releasing pills from releasing new code on
galaxies.
That would allow us to remove the delay in autoprop and give us more
flexibility in our release processes, in addition to improving resiliency
of the network in case of a lazy sponsor who hasn't updated by the time a
new sponsee boots up with a later kernel than the sponsor.
On Fri, Jan 20 2023 at 3:56 PM, fang < ***@***.*** > wrote:
>
>
>
>
>
>
> We'll probably also want to update the autoprop builder to support
> auto-building new azimuth snapshots.
>
>
>
> —
> Reply to this email directly, view it on GitHub (
> #6231 (comment) ) , or unsubscribe
> (
> https://github.com/notifications/unsubscribe-auth/AAGVR5J6XLUDOEUQNGGUQELWTMCY5ANCNFSM6AAAAAAUB67D2I
> ).
> You are receiving this because you were mentioned. Message ID: <urbit/urbit/issues/6231/1398999427
> @ github. com>
>
>
>
|
I'd be curious to do a little speccing on the system resilience line of work, as having that would reduce a significant amount of complexity in the release process. |
#5470, which is presently still unreleased (stuck in mars/urth limbo), comes with an "autoprop" app for auto-building pills and new-style boot props.
This app doesn't really have a hard dependency on any of the changes in that PR, it works perfectly fine without them, except that we can't use the jam files it creates yet. But it can also create pill files, which we can use already!
We don't presently have a good process for uploading new pills (for booting new ships) whenever desk contents change. We do not want to do this at the moment of a release, because this risks booting you into something newer than what your sponsor has. The autoprop app has a five-day delay to accommodate this, but can also be told to re-build pills or props on-demand.
The tool outputs the configured file(s) into the
pier/.urb/put
directory, with the runtime version string in its path, and as such a simple script[1] can be used to upload these to an appropriate place in the bootstrap bucket automatically.(The app has a little bit of logic for stripping the "vere" out of the version string, but maybe we want to intentionally leave that in at this point.)
All of this already exists, and has been running since that PR, on the
autoprop-builder
instance, and is still live... except its vere version is still 1.10. We should just bring this back up to latest, set it up to build pills, and make a point to update its binary for new releases. If we do that, and maybe update vere to use a new pill url format (#5470 will do this anyway), then we can have nearly fully-automated pill generation.(Edit: probably just massage the current thing into being compatible with existing runtime pill fetching practices.)
[1]:
upload-props.sh
The text was updated successfully, but these errors were encountered: