Follow the effort to update the kubernetes package to 1.7.x
Thanks already @jchaloup for [1], [2] and [3] [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=919466 [2] http://pkgs.fedoraproject.org/cgit/rpms/kubernetes.git/commit/?id=9efe74b63a9ba482715aa1474506c87af8f88002 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1471767
pinging: @dimtheo @jasonbrooks @jberkus @tstclair @sjenning @suiwenfeng
fyi @dustymabe
@jchaloup is a hero indeed!
@strigazi, is the proposal here to eventually get kube 1.7.x into fedora 26?
In the meantime people can test the builds linked by running a rawhide atomic host link and running rpm-ostree install kubernetes etcd && reboot
rpm-ostree install kubernetes etcd && reboot
@jchaloup is a hero indeed! @strigazi, is the proposal here to eventually get kube 1.7.x into fedora 26?
If FA26 continues to ship kubernetes in it I think it should contain 1.7.x. In 70 days 1.8.x will be out and fedora 26 which was released this month will be stuck with 1.6.x.
I don't know if there are any blockers to not include it in fedora 26.
The kubernetes project maintains two releases at a time -- one way we might approach this is to keep the newer release in rawhide and the N-1 release in Fedora stable, and swap when a new upstream releases goes GA. As long as we produce rawhide containers for the newer release, people running f26 can opt for either one.
Having the latest kubernetes in rawhide is must-have, having it in the latest fedora stable in nice-to-have. Sounds reasonable to me.
Or, we could track the latest in Fedora stable and the alpha releases in rawhide -- that seems a bit more true to rawhide, and still worthwhile, but I can imagine people wanting to run the N-1 version, and we don't have a way of maintaining two versions in fedora stable, I don't think. I guess, unless we did some renaming...
Let's do the simple solution first then :) stable in rawhide and stable-1 in fedora stable
Metadata Update from @dustymabe: - Issue tagged with: k8s
some sort of policy like this would be good to put in a readme over in https://pagure.io/atomic/kubernetes-sig
Since 1.7 is now in rawhide and we have the above policy should we leave this issue open?
Let's do the simple solution first then :) stable in rawhide and stable-1 in fedora stable some sort of policy like this would be good to put in a readme over in https://pagure.io/atomic/kubernetes-sig Since 1.7 is now in rawhide and we have the above policy should we leave this issue open?
some sort of policy like this would be good to put in a readme over in https://pagure.io/atomic/kubernetes-sig Since 1.7 is now in rawhide and we have the above policy should we leave this issue open?
Good idea! We can close this and add a README in kubernetes-sig as you said.
Metadata Update from @jberkus: - Issue close_status updated to: Duplicate - Issue status updated to: Closed (was: Open)
Closed as duplicate since it's moved to Kubernetes sig.
Login to comment on this ticket.