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 -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to