[atomic-wg] Issue #231 `clarify meaning of "rolling" for future fedora atomic releases`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



dustymabe added a new comment to an issue you are following:
``
>@jberkus
> Agreed, but if we're not supporting the older OSTree in any way, we've effectively given users a very short time limit on when they need to rebase/upgrade, with the possibility of being forced into it when the older OSTree unexpectedly breaks because we're not testing it anymore, or if we're not updating it, because a new security issue is announced.   Either way, we are forcing users to upgrade on our timeline, not theirs.

I'd actually like to have a grace period of like 30-60 days where we provide life support for the previous release so that we're not "forcing" the issue as much.

>@jberkus
> I'm happy to let that issue be a technical decision; I think our users would be OK either way.
> EXCEPT, if you go for "automated add remote + rebase", then we need to solve the issue that you can't roll back from that reliably.  Mind you, that's something that we need to solve anyway.

rolling back would work, but you're "remote" would be wrong. I think this is what you're referring to. 

> @jbrooks
> I'm +1 to combining the ostree repos into one. There's nothing strange about this, it's how the other atomic hosts operate. Fedora is the outlier in requiring rebases between version upgrades.

We could do it, but I'd prefer not to. If there are clean points to "prevent migrations" I'd prefer to just do that. One thing we could do is seed a new ostree repo with the latest N-1 content and then start building from there, but it's still more work than just creating a new repo from scratch.

>@jbrooks
> It'll also be much nicer for vagrant -- try vagrant init fedora/24-atomic-host -- it doesn't work any more. And places like the kube ansible scripts, which call on atlas for the vagrant boxes, need updates each time fedora atomic revs, where centos atomic is always accessible at centos/atomic-host.

This discussion doesn't affect vagrant at all. The reason vagrant init fedora/24-atomic-host doesn't work any more is because we "clean up" old two week release disk images. I personally would like to keep them around, but i've been met with resistance on that and don't have good enough reasons for doing so. 




``

To reply, visit the link below or just reply to this email
https://pagure.io/atomic-wg/issue/231
_______________________________________________
cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Big List of Linux Books]     [Yosemite News]     [Linux Apps]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux