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

[RFE] Only auto-push once a week #1157

Closed
mattdm opened this Issue Dec 14, 2016 · 17 comments

Comments

Projects
None yet
6 participants
@mattdm
Contributor

mattdm commented Dec 14, 2016

See background thread here https://da.gd/wlgro

This is conceptually connected to issue #1156, but really could be implemented independently.

I suggest that we only automatically push updates which have hit their thresholds (both the karma one and the minimum-cook-time threshold Adam proposes) once per week — on Monday, say. This will reduce updates churn, while still letting packagers push updates earlier if they have reason to.

As a further enhancement, it would be nice to also have the default for non-security updates to be "push with next batch" with "push to stable today" as a secondary choice.

This way, we get somewhat-batched updates without needing to develop elaborate rel-eng or QA infrastructure.

@bowlofeggs bowlofeggs added the RFE label Dec 14, 2016

@trishnaguha

This comment has been minimized.

Show comment
Hide comment
@trishnaguha

trishnaguha Jan 10, 2017

Contributor

I'd like to assign this to myself.

Contributor

trishnaguha commented Jan 10, 2017

I'd like to assign this to myself.

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Feb 2, 2017

Member

After thinking about this for 120 seconds, I have a half-baked idea: we could introduce a new package request state called "batched stable" (or maybe a better name). When updates hit the karma threshold, they move to this request state rather than moving to request "stable". Also, we can give devs a button to explicitly choose this state (while retaining the button for push to stable for when they want that option). Then we can have a weekly cron task that finds all updates in the request batch state, and all it would do is switch them to request stable. This way, bodhi-push just keeps working like it always does, and the release engineers don't have to change their process at all.

What do you think @trishnaguha?

Member

bowlofeggs commented Feb 2, 2017

After thinking about this for 120 seconds, I have a half-baked idea: we could introduce a new package request state called "batched stable" (or maybe a better name). When updates hit the karma threshold, they move to this request state rather than moving to request "stable". Also, we can give devs a button to explicitly choose this state (while retaining the button for push to stable for when they want that option). Then we can have a weekly cron task that finds all updates in the request batch state, and all it would do is switch them to request stable. This way, bodhi-push just keeps working like it always does, and the release engineers don't have to change their process at all.

What do you think @trishnaguha?

@mattdm

This comment has been minimized.

Show comment
Hide comment
@mattdm

mattdm Feb 2, 2017

Contributor

Sounds good to me, at least with some UX work to make it clear which button does what, and gives hints for when to pick what thing.

Contributor

mattdm commented Feb 2, 2017

Sounds good to me, at least with some UX work to make it clear which button does what, and gives hints for when to pick what thing.

@trishnaguha

This comment has been minimized.

Show comment
Hide comment
@trishnaguha

trishnaguha Mar 8, 2017

Contributor

How about renaming Batched state to Queued?

Contributor

trishnaguha commented Mar 8, 2017

How about renaming Batched state to Queued?

@mattdm

This comment has been minimized.

Show comment
Hide comment
@mattdm

mattdm Mar 8, 2017

Contributor

How about renaming Batched state to Queued?

I don't know if that's any different. :) Maybe we can get input from a UX designer in Fedora Design?

Contributor

mattdm commented Mar 8, 2017

How about renaming Batched state to Queued?

I don't know if that's any different. :) Maybe we can get input from a UX designer in Fedora Design?

@mattdm

This comment has been minimized.

Show comment
Hide comment
@mattdm

mattdm Mar 8, 2017

Contributor

I basically want one button that says:

"This update is ready to be included in the next batch update window."

and another one that says:

"This update is important and urgent and is ready to be sent out as an update now."

but that's a lot of text to put on a button. :)

Contributor

mattdm commented Mar 8, 2017

I basically want one button that says:

"This update is ready to be included in the next batch update window."

and another one that says:

"This update is important and urgent and is ready to be sent out as an update now."

but that's a lot of text to put on a button. :)

@trishnaguha

This comment has been minimized.

Show comment
Hide comment
@trishnaguha

trishnaguha Mar 8, 2017

Contributor

but that's a lot of text to put on a button. :)

We are going to have it anyway. May be as hover or something :).

Contributor

trishnaguha commented Mar 8, 2017

but that's a lot of text to put on a button. :)

We are going to have it anyway. May be as hover or something :).

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Mar 8, 2017

Member

Maybe we can get input from a UX designer in Fedora Design?

@ryanlerch is currently working on a redesign of Bodhi (in #1313 - it's so good) - perhaps he would have some feedback for wording on this feature?

Member

bowlofeggs commented Mar 8, 2017

Maybe we can get input from a UX designer in Fedora Design?

@ryanlerch is currently working on a redesign of Bodhi (in #1313 - it's so good) - perhaps he would have some feedback for wording on this feature?

@ryanlerch

This comment has been minimized.

Show comment
Hide comment
@ryanlerch

ryanlerch Mar 9, 2017

Contributor

Just a query, how does this currently work? Is there a button to allow a user to push to stable? Or is this the "autopush" option that is in the create / edit update form?

Contributor

ryanlerch commented Mar 9, 2017

Just a query, how does this currently work? Is there a button to allow a user to push to stable? Or is this the "autopush" option that is in the create / edit update form?

@trishnaguha

This comment has been minimized.

Show comment
Hide comment
@trishnaguha

trishnaguha Mar 9, 2017

Contributor

#1157 (comment)

The button is here https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/templates/update.html#L554-L572

autopush/manual-push depends on the create/ edit update form.

Contributor

trishnaguha commented Mar 9, 2017

#1157 (comment)

The button is here https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/templates/update.html#L554-L572

autopush/manual-push depends on the create/ edit update form.

@trishnaguha

This comment has been minimized.

Show comment
Hide comment
@trishnaguha
Contributor

trishnaguha commented Mar 9, 2017

@ryanlerch This is the form that decides autopush/manual-push for an update: https://github.com/fedora-infra/bodhi/blob/develop/bodhi/server/templates/new_update.html#L241-L306

@cgwalters

This comment has been minimized.

Show comment
Hide comment
@cgwalters

cgwalters Mar 9, 2017

Contributor

For Fedora Atomic Host, we (finally!) switched to a ~two-week cadence for updates. I'm in full support of the "Fedora RPM set" being on a batched cadence as well. But it really feels like we should at least try to align those.

Particularly for reasons such as projectatomic/rpm-ostree#415

Contributor

cgwalters commented Mar 9, 2017

For Fedora Atomic Host, we (finally!) switched to a ~two-week cadence for updates. I'm in full support of the "Fedora RPM set" being on a batched cadence as well. But it really feels like we should at least try to align those.

Particularly for reasons such as projectatomic/rpm-ostree#415

@mattdm

This comment has been minimized.

Show comment
Hide comment
@mattdm

mattdm Mar 9, 2017

Contributor

I think it's okay to have this be one week and Fedora Atomic Host spun at two weeks (wave alignment and all that). But maybe the arbitrary choice of "Monday" isn't right — we'd want to make sure that (in most cases at least) the new AH each time includes a relatively fresh batch (not one from 6 days ago).

Contributor

mattdm commented Mar 9, 2017

I think it's okay to have this be one week and Fedora Atomic Host spun at two weeks (wave alignment and all that). But maybe the arbitrary choice of "Monday" isn't right — we'd want to make sure that (in most cases at least) the new AH each time includes a relatively fresh batch (not one from 6 days ago).

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Mar 9, 2017

Member

@cgwalters @mattdm The vision I had for this feature is that the bodhi-push CLI would just have flags for whether or not to push the batched update. The release engineers use that CLI to do the daily pushes (which is currently a manual process), so in the short term a human would be deciding when to push. I.e., we don't have to put a schedule for when these batched updates would be pushed into code.

I have been talking with releng about using cron (or loop-a-bull) to call bodhi-push instead of a human. If we get there, it would be similarly easy to have whatever triggers bodhi-push call the batched push on whatever schedule we like.

tl;dr; we can push whenever we want with the current proposed design, it's pretty flexible ☺

Member

bowlofeggs commented Mar 9, 2017

@cgwalters @mattdm The vision I had for this feature is that the bodhi-push CLI would just have flags for whether or not to push the batched update. The release engineers use that CLI to do the daily pushes (which is currently a manual process), so in the short term a human would be deciding when to push. I.e., we don't have to put a schedule for when these batched updates would be pushed into code.

I have been talking with releng about using cron (or loop-a-bull) to call bodhi-push instead of a human. If we get there, it would be similarly easy to have whatever triggers bodhi-push call the batched push on whatever schedule we like.

tl;dr; we can push whenever we want with the current proposed design, it's pretty flexible ☺

@dustymabe

This comment has been minimized.

Show comment
Hide comment
@dustymabe

dustymabe Apr 20, 2017

Contributor

i think a good thing to think about for the future is making bodhi's processing of updates (and thus pushing to stable) happen more and more often. Many times a day, in fact. What I'm thinking is that we have this "stable" stream continuously (buzz word bingo, here) being updated and then we have a "batched stable" repo that get's pushed approximately once a week.

We can change the names to represent whatever you like, but basically:

  • one yum repo is continously getting updated when packages get requested for stable (and thus pushed to stable soon after).
  • one yum repo (mirrored) that most users follow that gets batch updated once a week
  • the ability to push critical fixes to the batch updated repo when necessary

This would help us get to a vision of having an atomic host "stream" where the deltas are as small as possible (a single bodhi update) and we can have better more fine grained testing all the way around.

Contributor

dustymabe commented Apr 20, 2017

i think a good thing to think about for the future is making bodhi's processing of updates (and thus pushing to stable) happen more and more often. Many times a day, in fact. What I'm thinking is that we have this "stable" stream continuously (buzz word bingo, here) being updated and then we have a "batched stable" repo that get's pushed approximately once a week.

We can change the names to represent whatever you like, but basically:

  • one yum repo is continously getting updated when packages get requested for stable (and thus pushed to stable soon after).
  • one yum repo (mirrored) that most users follow that gets batch updated once a week
  • the ability to push critical fixes to the batch updated repo when necessary

This would help us get to a vision of having an atomic host "stream" where the deltas are as small as possible (a single bodhi update) and we can have better more fine grained testing all the way around.

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Jun 21, 2017

Member

@crungehottman is going to work on this!

Member

bowlofeggs commented Jun 21, 2017

@crungehottman is going to work on this!

crungehottman added a commit to crungehottman/bodhi that referenced this issue Jul 20, 2017

crungehottman added a commit to crungehottman/bodhi that referenced this issue Jul 24, 2017

crungehottman added a commit to crungehottman/bodhi that referenced this issue Jul 31, 2017

crungehottman added a commit to crungehottman/bodhi that referenced this issue Jul 31, 2017

crungehottman added a commit to crungehottman/bodhi that referenced this issue Jul 31, 2017

crungehottman added a commit to crungehottman/bodhi that referenced this issue Aug 3, 2017

@bowlofeggs

This comment has been minimized.

Show comment
Hide comment
@bowlofeggs

bowlofeggs Sep 5, 2017

Member

The fix for this issue will appear in the upcoming 2.11.0 release:

#1790

Member

bowlofeggs commented Sep 5, 2017

The fix for this issue will appear in the upcoming 2.11.0 release:

#1790

@bowlofeggs bowlofeggs closed this Sep 5, 2017

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