#2135 set default module stream for cri-o
Closed: Rejected 4 years ago by lsm5. Opened 4 years ago by lsm5.

Describe the issue

the cri-o module doesn't have a default stream yet.
I'd like to set '1.14' as the default module stream.

When do you need this? (YYYY/MM/DD)

ASAP (2019/05/27)

When is this no longer needed or useful? (YYYY/MM/DD)

Ideally, once we have a newer minor version of cri-o released.

If we cannot complete your request, what is the impact?

People will not be able to install cri-o without specifying a stream, and people will create unnecessary bugs, github issues and noise on social media


What packages are in this stream? Do they exist in regular Fedora? What Fedora releases are we discussing here?

What packages are in this stream?

cri-o and cri-tools

Do they exist in regular Fedora?

They did in prior versions. Those branches were retired. They haven't been shipped in f30 yet. We need to support multiple versions of those simultaneously, hence the module route.

What Fedora releases are we discussing here?

Right now, 30 and rawhide. At any given point we plan to support rawhide, the latest release and the release candidate if any.

@lsm5

Just to confirm: there's nothing in the non-modular content that needs this module for building right now?

If so, I'm +1 to grant this default change.

@lsm5
Just to confirm: there's nothing in the non-modular content that needs this module for building right now?

Nothing needs cri-o or cri-tools as build deps right now. kubernetes-node package has an either-or runtime dep on moby-engine or cri-o. We most likely need to ship kubernetes as modular content as well given multiple supported versions (cri-o tracks kube releases).

If so, I'm +1 to grant this default change.

I see cri-tools 1.11.0-3.dev.git19b7255.fc30 in Fedora 30.

I see cri-tools 1.11.0-3.dev.git19b7255.fc30 in Fedora 30.

@churchyard Sounds like nothing requires it at build-time though?

@lsm5 Out of an abundance of caution, is there any reason you can't keep the non-modular package around as well for right now, kept in sync with the one in the module stream? That would be the easiest transition until the buildroot situation is fixed.

I see cri-tools 1.11.0-3.dev.git19b7255.fc30 in Fedora 30.

ack, my not shipped in f30 was about the cri-o package. Note that the cri-o module provides cri-o and cri-tools packages, let me know if it's better to rename the module to something else.

@churchyard Sounds like nothing requires it at build-time though?
@lsm5 Out of an abundance of caution, is there any reason you can't keep the non-modular package around as well for right now, kept in sync with the one in the module stream? That would be the easiest transition until the buildroot situation is fixed.

sgtm, but if there are no non-modular packages (like for cri-o on f30) then I don't need to provide them on the non-modular repos, yes?
https://koji.fedoraproject.org/koji/packageinfo?packageID=24240

I see cri-tools 1.11.0-3.dev.git19b7255.fc30 in Fedora 30.

ack, my not shipped in f30 was about the cri-o package. Note that the cri-o module provides cri-o and cri-tools packages, let me know if it's better to rename the module to something else.

@churchyard Sounds like nothing requires it at build-time though?
@lsm5 Out of an abundance of caution, is there any reason you can't keep the non-modular package around as well for right now, kept in sync with the one in the module stream? That would be the easiest transition until the buildroot situation is fixed.

sgtm, but if there are no non-modular packages (like for cri-o on f30) then I don't need to provide them on the non-modular repos, yes?
https://koji.fedoraproject.org/koji/packageinfo?packageID=24240

As long as no one expects to be able to build non-modular content from them, that is fine. Again, this will be relaxed once default streams can appear in the buildroot, but we're not there quite yet.

I see cri-tools 1.11.0-3.dev.git19b7255.fc30 in Fedora 30.
ack, my not shipped in f30 was about the cri-o package. Note that the cri-o module provides cri-o and cri-tools packages, let me know if it's better to rename the module to something else.
@churchyard Sounds like nothing requires it at build-time though?
@lsm5 Out of an abundance of caution, is there any reason you can't keep the non-modular package around as well for right now, kept in sync with the one in the module stream? That would be the easiest transition until the buildroot situation is fixed.
sgtm, but if there are no non-modular packages (like for cri-o on f30) then I don't need to provide them on the non-modular repos, yes?
https://koji.fedoraproject.org/koji/packageinfo?packageID=24240

As long as no one expects to be able to build non-modular content from them, that is fine. Again, this will be relaxed once default streams can appear in the buildroot, but we're not there quite yet.

ack, SGTM, what else needs to happen to get this resolved?

So to summarize the request (not 100% sure):

"Allow to set a default stream on Fedora 30+ for a module than only ships the cri-o package that is not available in non-modular repo."

Correct?

So to summarize the request (not 100% sure):
"Allow to set a default stream on Fedora 30+ for a module than only ships the cri-o package that is not available in non-modular repo."
Correct?

Yes

-1 (admittedly, non-voting, since not fesco member, but...).

Since cri-o is tied to k8s releases, I feel like neither should have default streams, but the k8s module should depend on the matching cri-o version.

Moreover, once someone does something to make OpenShift exist properly on Fedora again, this will become more of a concern, too.

If you want a default version, you should have a default k8s and openshift version that are both compatible with a specific cri-o version series.

-1 (admittedly, non-voting, since not fesco member, but...).
Since cri-o is tied to k8s releases, I feel like neither should have default streams, but the k8s module should depend on the matching cri-o version.
Moreover, once someone does something to make OpenShift exist properly on Fedora again, this will become more of a concern, too.
If you want a default version, you should have a default k8s and openshift version that are both compatible with a specific cri-o version series.

How about having a default stream for https://src.fedoraproject.org/modules/kubernetes as well? Are you ok with that?

Users expect to dnf install cri-o so we do need a default stream. I can update this ticket with a default stream for kube as well if that's what it takes.

I don't know why people expect dnf install cri-o to work without a k8s or openshift system.

But setting a default without managing in tandem with both openshift and kubernetes modules is foolhardy and dangerous, since CRI-O is deeply tied to those projects.

You also need a plan for changing defaults as new versions of everything come for new Fedora releases.

I'll check with kubernetes/openshift maintainers if they care about supporting multiple versions and if they expect some version to be default. So, best to hold off on this for now. Thanks for the comments Neal.

Metadata Update from @zbyszek:
- Issue tagged with: meeting

4 years ago

This was discussed during today's FESCo meeting:
we decided to wait with a decision based on the previous comment.

Metadata Update from @psabata:
- Issue untagged with: meeting

4 years ago

@lsm5 Can you provide an update here?

Metadata Update from @sgallagh:
- Issue tagged with: stalled

4 years ago

So, I can't spare any time on updating kube and openshift atm, and I don't know if anyone else is working on it either. So, let's close this for now without picking any defaults for cri-o.

Metadata Update from @lsm5:
- Issue close_status updated to: Rejected
- Issue status updated to: Closed (was: Open)

4 years ago

I don't know why people expect dnf install cri-o to work without a k8s or openshift system.

Well, primarily because https://cri-o.io/ and https://github.com/cri-o/cri-o/blob/master/README.md say that should work. The reason why I'm attempting to do that is to be able to then build Kubernetes from sources via ./hack/local-up-cluster.sh.

I've now filed https://github.com/cri-o/cri-o/issues/2713 to get the assumptions in the installation instructions of CRI-O adjusted.

Login to comment on this ticket.

Metadata