Description of problem: Following utilities in nfs-utils sub-package requires Python: /usr/sbin/mountstats /usr/sbin/nfsiostat In Fedora CoreOS we are trying to not have Python dependencies in base host. Can we ship Python dependent utilities in a separate sub-package so that we can have nfs-utils utilities available in FCOS Base System without worrying about Python?
(In reply to Sinny Kumari from comment #0) > Description of problem: > > Following utilities in nfs-utils sub-package requires Python: > /usr/sbin/mountstats > /usr/sbin/nfsiostat > > In Fedora CoreOS we are trying to not have Python dependencies in base host. > Can we ship Python dependent utilities in a separate sub-package so that we > can have nfs-utils utilities available in FCOS Base System without worrying > about Python? Not really... There is also nfsconvert.py used by the nfs-convert.service systemd script that used to convert sysconfig/nfs configuration into /etc/nfs.conf configurations, see bug 1644049
(In reply to Steve Dickson from comment #1) > (In reply to Sinny Kumari from comment #0) > > Description of problem: > > > > Following utilities in nfs-utils sub-package requires Python: > > /usr/sbin/mountstats > > /usr/sbin/nfsiostat > > > > In Fedora CoreOS we are trying to not have Python dependencies in base host. > > Can we ship Python dependent utilities in a separate sub-package so that we > > can have nfs-utils utilities available in FCOS Base System without worrying > > about Python? > > Not really... There is also nfsconvert.py used by the nfs-convert.service > systemd script that used to convert sysconfig/nfs configuration into > /etc/nfs.conf configurations, see bug 1644049 Hmm, I checked against F29 packages and hence didn't noticed the newly added changes :/ Thinking out loud: As far as I understood, nfs-convert.service will be required/used to migrate from sysconfig/nfs to nfs.conf if user is using older way. Can we also move nfs-convert.service and related required files like (usr/sbin/nfsconvert, usr/libexec/nfs-utils/nfsconvert.sh ) to Python sub-package? Since, FCOS is a new operating system we can instruct users to add their config to etc/nfs.conf for the very beginning.
(In reply to Sinny Kumari from comment #2) > (In reply to Steve Dickson from comment #1) > > (In reply to Sinny Kumari from comment #0) > > > Description of problem: > > > > > > Following utilities in nfs-utils sub-package requires Python: > > > /usr/sbin/mountstats > > > /usr/sbin/nfsiostat > > > > > > In Fedora CoreOS we are trying to not have Python dependencies in base host. > > > Can we ship Python dependent utilities in a separate sub-package so that we > > > can have nfs-utils utilities available in FCOS Base System without worrying > > > about Python? > > > > Not really... There is also nfsconvert.py used by the nfs-convert.service > > systemd script that used to convert sysconfig/nfs configuration into > > /etc/nfs.conf configurations, see bug 1644049 > > Hmm, I checked against F29 packages and hence didn't noticed the newly added > changes :/ > > Thinking out loud: > As far as I understood, nfs-convert.service will be required/used to migrate > from sysconfig/nfs to nfs.conf if user is using older way. > Can we also move nfs-convert.service and related required files like > (usr/sbin/nfsconvert, usr/libexec/nfs-utils/nfsconvert.sh ) to Python > sub-package? > Since, FCOS is a new operating system we can instruct users to add their > config to etc/nfs.conf for the very beginning. Continuing your thinking.... By putting all the Python scripts (including the nfsconvert scrips) in to a separate package, calling it nfs-utils-python, would allow nfs-utils to be installed w/out the nfs-utils-python package. If that is the case... that would defeat the purpose even having the conversion scripts. The conversions are needed to ensure nfs configuration are moved from the deprecated sysconfig/nfs file to /etc/nfs.conf (which makes nfs configurations compatible throughout all Linux distros). So even if we did move the all Python scripts into a separate package the nfs-utils spec file would still needed "Requires: nfs-utils-python" to insure the conversation is done... Thus pull in Python. Am I missing something?
(In reply to Steve Dickson from comment #3) > (In reply to Sinny Kumari from comment #2) > > Thinking out loud: > > As far as I understood, nfs-convert.service will be required/used to migrate > > from sysconfig/nfs to nfs.conf if user is using older way. > > Can we also move nfs-convert.service and related required files like > > (usr/sbin/nfsconvert, usr/libexec/nfs-utils/nfsconvert.sh ) to Python > > sub-package? > > Since, FCOS is a new operating system we can instruct users to add their > > config to etc/nfs.conf for the very beginning. > > Continuing your thinking.... By putting all the Python scripts (including the > nfsconvert scrips) in to a separate package, calling it nfs-utils-python, > would allow nfs-utils to be installed w/out the nfs-utils-python package. > If that is the case... that would defeat the purpose even having the > conversion scripts. > > The conversions are needed to ensure nfs configuration are moved from > the deprecated sysconfig/nfs file to /etc/nfs.conf (which makes nfs > configurations compatible throughout all Linux distros). > > So even if we did move the all Python scripts into a separate package > the nfs-utils spec file would still needed "Requires: nfs-utils-python" > to insure the conversation is done... Thus pull in Python. Agreed, if we create nfs-utils-python sub-pacakge, this will be required for the conversion. I was suggesting if possible we can make nfs-utils-python as Suggests or Recommends instead of making it Requires when installing nfs-utils package. In that case, nfs-utils will not hard depend on nfs-utils-python . This will be a new change in Fedora 30, so user will be aware of the change through Changelog message. I understand that this is not the ideal solution but this is the best I can think of considering both use-cases.
(In reply to Sinny Kumari from comment #4) > (In reply to Steve Dickson from comment #3) > > (In reply to Sinny Kumari from comment #2) > > > > Thinking out loud: > > > As far as I understood, nfs-convert.service will be required/used to migrate > > > from sysconfig/nfs to nfs.conf if user is using older way. > > > Can we also move nfs-convert.service and related required files like > > > (usr/sbin/nfsconvert, usr/libexec/nfs-utils/nfsconvert.sh ) to Python > > > sub-package? > > > Since, FCOS is a new operating system we can instruct users to add their > > > config to etc/nfs.conf for the very beginning. > > > > Continuing your thinking.... By putting all the Python scripts (including the > > nfsconvert scrips) in to a separate package, calling it nfs-utils-python, > > would allow nfs-utils to be installed w/out the nfs-utils-python package. > > If that is the case... that would defeat the purpose even having the > > conversion scripts. > > > > The conversions are needed to ensure nfs configuration are moved from > > the deprecated sysconfig/nfs file to /etc/nfs.conf (which makes nfs > > configurations compatible throughout all Linux distros). > > > > So even if we did move the all Python scripts into a separate package > > the nfs-utils spec file would still needed "Requires: nfs-utils-python" > > to insure the conversation is done... Thus pull in Python. > > Agreed, if we create nfs-utils-python sub-pacakge, this will be required for > the conversion. > > I was suggesting if possible we can make nfs-utils-python as Suggests or > Recommends instead of making it Requires when installing nfs-utils package. > In that case, nfs-utils will not hard depend on nfs-utils-python . This will > be a new change in Fedora 30, so user will be aware of the change > through Changelog message. And if they say no don't don't do it... they will, unknowing, use a deprecated configuration which would be very hard to debug why things are not working as they should be... The conversion has to happen. Even on fresh installs, the conversion has to happen so sysconfig/nfs is immuted otherwise automated IT systems (aka Ansible) will populate the config with a deprecated configuration... again hard to debug.
Sinny, I'm afraid Steve is correct here. We can't make the conversion scripts optional because it will break the overwhelming majority of non-ostree users of NFS. Also, anyone who reuses an Ansible/Puppet configuration for NFS will still be using the old approach. Assuming that dropping Python from the base system is mandatory for CoreOS, I see two options we can use to address this: 1) We rewrite the conversion script into a compiled language (C, Go, Rust, etc.) 2) We change the packaging to include nfs-utils-python and use `Requires: (nfs-utils-python unless fedora-release-coreos)` which will mean it will be pulled in as a hard dependency everywhere but CoreOS. Number 2 is a huge hack and still doesn't address the cargo-cult Ansible case, so I think that realistically only leaves option 1.
(In reply to Stephen Gallagher from comment #6) > > Assuming that dropping Python from the base system is mandatory for CoreOS, > I see two options we can use to address this: > 1) We rewrite the conversion script into a compiled language (C, Go, Rust, > etc.) > 2) We change the packaging to include nfs-utils-python and use `Requires: > (nfs-utils-python unless fedora-release-coreos)` which will mean it will be > pulled in as a hard dependency everywhere but CoreOS. > > Number 2 is a huge hack and still doesn't address the cargo-cult Ansible > case, so I think that realistically only leaves option 1. By rewriting we lose all the testing we have done in both RHEL8 and Fedora. Plus this will be branching from RHEL8 which is not good either. The bug is open against rawhide... what release does the mean? Hopefully not f30.... Also what is the reason for not putting python in CoreOS?
(In reply to Steve Dickson from comment #7) > (In reply to Stephen Gallagher from comment #6) > > > > Assuming that dropping Python from the base system is mandatory for CoreOS, > > I see two options we can use to address this: > > 1) We rewrite the conversion script into a compiled language (C, Go, Rust, > > etc.) > > 2) We change the packaging to include nfs-utils-python and use `Requires: > > (nfs-utils-python unless fedora-release-coreos)` which will mean it will be > > pulled in as a hard dependency everywhere but CoreOS. > > > > Number 2 is a huge hack and still doesn't address the cargo-cult Ansible > > case, so I think that realistically only leaves option 1. > > By rewriting we lose all the testing we have done in both RHEL8 and Fedora. > Plus this will be branching from RHEL8 which is not good either. I understand that. Requested other CoreOS members to add their input to see what will be best here. > The bug is open against rawhide... what release does the mean? > Hopefully not f30.... We are targeting FCOS first release around F30, so preferably F30. > Also what is the reason for not putting python in CoreOS? Main reason of trying to not ship Python in base coreOS is to prevent users from running Python scripts directly on the host and prevent issues where user's python script needs library X that isn't installed. More details were discussed at https://github.com/coreos/fedora-coreos-tracker/issues/32
(In reply to Sinny Kumari from comment #8) > > > Also what is the reason for not putting python in CoreOS? > > Main reason of trying to not ship Python in base coreOS is to > prevent users from running Python scripts directly on the host and > prevent issues where user's python script needs library X that isn't > installed. > More details were discussed at > https://github.com/coreos/fedora-coreos-tracker/issues/32 Thank you for point me there.... It appears the Kubernetes folks are happy about this either. So in a nutshell, f30 will only support python in a container, the host will be immutable... How is that going to work with NFS or any other filesystem for that matter that use python scripts to monitor the host filesystem? Granted my container knowledge is weak but can host's filesystems be see from inside a container? If the answer is no, then this concept has some serious problem with it comes to monitoring filesystems... IMHO. Here are a few things that jumped out at me The Kubernetes guy said "prevent users from running scripts directly on the host seems like an anti-pattern for me as a user." which spot on... There is one theme that is completely missing from the from the above conversation... Is this good for our user base? There does not seem to be much concern about this will effect our users's... Its more we don't what to support python because it is a pain... Basically looking inward not outward. What exactly is a "system python approach"? "better perception we're a minimal OS" An OS is only as good as the applications that can run on. an OS does not support popular applications (which use pthyon) are dead... IMHO.. Are any other distros doing this? "we don't think we'd lose a significant number of users/community members if we shipped a system python, vs no python." We are going to lose the majority of python users since are making jump through hoops that they don't want to or don't have to on a different distro May I suggest we don't go with the "we don't think" approach instead we get some immutable facts on how this will impact our users... my two cents.
(In reply to Steve Dickson from comment #9) > So in a nutshell, f30 will only support python in a container, > the host will be immutable... Hey Steve. I just want to make sure we aren't getting confused here: We are specifically speaking about Fedora CoreOS here, and not the rest of Fedora (Fedora Server, Fedora Workstation, Fedora Cloud, etc). This is for a new offering. Some context is that Container Linux never shipped python and built a substantial user base, so it's not an unreasonable ask. In the Fedora CoreOS community we're exploring this option as well in an effort to be more minimal. I'm not necessarily trying to justify it here, just adding some context where we are coming from. I've added the meeting label to the upstream discussion about this ticket and we'll talk about it in our Fedora CoreOS community meeting on Wednesday: https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment-460369555 Does that help?
(In reply to Dusty Mabe from comment #10) > (In reply to Steve Dickson from comment #9) > > > So in a nutshell, f30 will only support python in a container, > > the host will be immutable... > > Hey Steve. I just want to make sure we aren't getting confused here: > > We are specifically speaking about Fedora CoreOS here, and not the > rest of Fedora (Fedora Server, Fedora Workstation, Fedora Cloud, etc). > This is for a new offering. Thank you for the clarification > > Some context is that Container Linux never shipped python and built > a substantial user base, so it's not an unreasonable ask. In the Fedora > CoreOS community we're exploring this option as well in an effort to be > more minimal. I'm not necessarily trying to justify it here, just adding > some context where we are coming from. Fair enough... What would happen if nfs-utils was not included in the CoreOS? It turns out nfs-utils is not part of the default install in both RHEL 7 and RHEL 8. Please see bug 1659546 I guess I would rather not include it than rip it apart. :-) > > I've added the meeting label to the upstream discussion about this ticket > and we'll talk about it in our Fedora CoreOS community meeting on Wednesday: > https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment- > 460369555 Thank you... where and when is the meeting... I can make myself available if need be. > > Does that help? It does... thanks again!
(In reply to Steve Dickson from comment #11) > (In reply to Dusty Mabe from comment #10) > > (In reply to Steve Dickson from comment #9) > > > > > So in a nutshell, f30 will only support python in a container, > > > the host will be immutable... > > > > Hey Steve. I just want to make sure we aren't getting confused here: > > > > We are specifically speaking about Fedora CoreOS here, and not the > > rest of Fedora (Fedora Server, Fedora Workstation, Fedora Cloud, etc). > > This is for a new offering. > Thank you for the clarification No problem!! Thanks for your prompt communication here. > > > > > Some context is that Container Linux never shipped python and built > > a substantial user base, so it's not an unreasonable ask. In the Fedora > > CoreOS community we're exploring this option as well in an effort to be > > more minimal. I'm not necessarily trying to justify it here, just adding > > some context where we are coming from. > Fair enough... > > What would happen if nfs-utils was not included in the CoreOS? > It turns out nfs-utils is not part of the default install > in both RHEL 7 and RHEL 8. Please see bug 1659546 > I guess I would rather not include it than rip it apart. :-) yeah - IIUC not including nfs-utils would mean people couldn't perform nfs mounts on their systems, which is a use case we'd like to support. It won't be easy for people to add packages to the base so we probably need to bake it in. > > > > > I've added the meeting label to the upstream discussion about this ticket > > and we'll talk about it in our Fedora CoreOS community meeting on Wednesday: > > https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment- > > 460369555 > Thank you... where and when is the meeting... I can make myself available if > need be. I don't think you are required to attend since you've been so helpful in this thread. If you'd like to our meetings are on Wednesday's at 16:30 UTC in #fedora-meeting-1 on freenode. https://github.com/coreos/fedora-coreos-tracker#meetings We'll post any decisions/discussion items to the ticket: https://github.com/coreos/fedora-coreos-tracker/issues/121 You can subscribe there if you like. > > > > Does that help? > It does... thanks again! No. Thank you!
(In reply to Dusty Mabe from comment #12) > (In reply to Steve Dickson from comment #11) > > (In reply to Dusty Mabe from comment #10) > > > > > > Some context is that Container Linux never shipped python and built > > > a substantial user base, so it's not an unreasonable ask. In the Fedora > > > CoreOS community we're exploring this option as well in an effort to be > > > more minimal. I'm not necessarily trying to justify it here, just adding > > > some context where we are coming from. > > Fair enough... > > > > What would happen if nfs-utils was not included in the CoreOS? > > It turns out nfs-utils is not part of the default install > > in both RHEL 7 and RHEL 8. Please see bug 1659546 > > I guess I would rather not include it than rip it apart. :-) > > > yeah - IIUC not including nfs-utils would mean people couldn't perform > nfs mounts on their systems, which is a use case we'd like to support. > It won't be easy for people to add packages to the base so we probably > need to bake it in. > I had a meeting with the NFS team... Here is what we camp up with. Since you only need NFS client mounting... instead of creating a nfs-utils-python package, we create a nfs-utils-coreos package that has minimal needed to do a NFS mount. It would also contain the nfsstat binary which would admin to monitor the mounts. Think this goes nicely with your "minimal OS" concept. thoughts?
Will discuss in the meeting tomorrow and reply here. Thanks Steve!
Here is a scratch build of nfs-utils-coreos package I'm suggesting https://koji.fedoraproject.org/koji/taskinfo?taskID=32582126 It is one third the size of a full nfs-utils and it will support secure NFS mounts. No NFS server.... Only the client...
Hey Steve. We chatted about this in the community meeting yesterday and we decided to accept your proposal to make a nfs-utils-coreos package. Thanks for offering. Here is a link to the community meeting minutes: https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/fedora_coreos_meeting.2019-02-06-16.30.html (In reply to Steve Dickson from comment #15) > Here is a scratch build of nfs-utils-coreos package I'm suggesting > https://koji.fedoraproject.org/koji/taskinfo?taskID=32582126 > > It is one third the size of a full nfs-utils and it will support secure NFS > mounts. > No NFS server.... Only the client... Interesting. This is a new possibility. In my mind it would have been the same set of files in nfs-utils minus the python files, but let's explore this new possibility. A few questions/statements: - I'll need to confirm with the community that not shipping the server is acceptable - Would it be possible to take what you've provided and call it nfs-client-utils and then have a nfs-server-utils? nfs-utils meta package would provide require both. Again, thanks for your continued communications here.
(In reply to Dusty Mabe from comment #16) > Hey Steve. We chatted about this in the community meeting yesterday and > we decided to accept your proposal to make a nfs-utils-coreos package. > Thanks for offering. Here is a link to the community meeting minutes: > > https://meetbot-raw.fedoraproject.org/teams/fedora_coreos_meeting/ > fedora_coreos_meeting.2019-02-06-16.30.html > > > (In reply to Steve Dickson from comment #15) > > Here is a scratch build of nfs-utils-coreos package I'm suggesting > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32582126 > > > > It is one third the size of a full nfs-utils and it will support secure NFS > > mounts. > > No NFS server.... Only the client... > > Interesting. This is a new possibility. In my mind it would have been > the same set of files in nfs-utils minus the python files, but let's explore > this new possibility. A few questions/statements: > > - I'll need to confirm with the community that not shipping the server is > acceptable I think this goes with the "keep the host immutable" theme... > - Would it be possible to take what you've provided and call it > nfs-client-utils > and then have a nfs-server-utils? nfs-utils meta package would provide > require both. We talked about his at our NFS team meeting... Testing could be come an issues since two packages would needed to be tested instead of one... again may or may not be an issue. nfs-server-utils or nfs-utils-server ;-) would depend on python due to the conversion script so it is not clear breaking them up would buy us.
(In reply to Steve Dickson from comment #17) > (In reply to Dusty Mabe from comment #16) > > > > - I'll need to confirm with the community that not shipping the server is > > acceptable > I think this goes with the "keep the host immutable" theme... yeah. just want to keep suprises minimal :) > > > - Would it be possible to take what you've provided and call it > > nfs-client-utils > > and then have a nfs-server-utils? nfs-utils meta package would provide > > require both. > We talked about his at our NFS team meeting... Testing could be > come an issues since two packages would needed to be tested > instead of one... again may or may not be an issue. > > nfs-server-utils or nfs-utils-server ;-) would depend on python > due to the conversion script so it is not clear breaking them > up would buy us. Yes, nfs-server-utils would indeed still depend on python. So the questions are: - is it ok for FCOS to ship just the client? (action item: dusty) - if it is ok for FCOS to ship just the client would the package be useful to anyone else other than FCOS? If so then maybe renaming it to nfs-client-utils and splitting the server out to a separate package as well would be useful. The second question depends on the first so I'll get back to you here :). Does anything not make sense at this point?
Discussed today: https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment-463294800 We will try to ship just the nfs client in Fedora CoreOS and allow the server to be run in a container if needed by users. So the remaining questions: - Should we rename it to nfs-client-utils (or nfs-utils-client) in case it would be useful for others? - Should we split out the server package like we did the client and have nfs-client require them both?
s/nfs-client require them both/nfs-utils require them both
(In reply to Dusty Mabe from comment #19) > Discussed today: > https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment- > 463294800 > > We will try to ship just the nfs client in Fedora CoreOS and allow the server > to be run in a container if needed by users. Well this will be easier said than done... Due to the fact /proc/fs is mount read-only in a standard container, to run a NFS server a "privileged container" is needed... I have not got my head around that... quite yet.. > > So the remaining questions: > > - Should we rename it to nfs-client-utils (or nfs-utils-client) in case it > would be useful for others? Fine... This probably makes sense... Does the naming really matter?? > - Should we split out the server package like we did the client and have > nfs-client require them both? I don't see the reason for this... By far the NFS client is used more than the server... so think break out the client does make sense. But in what scenario would only a server (which needs python) be installed and not the client? I just see a justification for the amount of work and testing it would to make this happen.
(In reply to Steve Dickson from comment #21) > (In reply to Dusty Mabe from comment #19) > > Discussed today: > > https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment- > > 463294800 > > > > We will try to ship just the nfs client in Fedora CoreOS and allow the server > > to be run in a container if needed by users. > Well this will be easier said than done... Due to the fact /proc/fs is > mount read-only in a standard container, to run a NFS server > a "privileged container" is needed... I have not got my head around > that... quite yet.. agreed. but I believe we already tackle this in kubernetes/openshift today so it shouldn't be too hard to turn the right knobs to get it to work. > > > > > So the remaining questions: > > > > - Should we rename it to nfs-client-utils (or nfs-utils-client) in case it > > would be useful for others? > Fine... This probably makes sense... Does the naming really matter?? The question is more related to: "is this completely specific and only useful to coreos, or not". If it would only ever be useful to Fedora CoreOS then I'm fine keeping `coreos` in the name. If it could be useful for anyone else I like the `client` in the name better. A followup question would be: - does nfs-utils provide some of the same files that nfs-client-utils would or does it now require nfs-client-utils ? If we remove `coreos` from the name of the package I think I'd prefer them to not provide some of the same files and just add the dep on nfs-utils. > > > - Should we split out the server package like we did the client and have > > nfs-client require them both? > I don't see the reason for this... By far the NFS client is used > more than the server... so think break out the client does make sense. > But in what scenario would only a server (which needs python) be installed > and not the client? I just see a justification for the amount of work > and testing it would to make this happen. I guess the request was more for symmetry. It is not required and if it imposes extra work probably should not be done.
(In reply to Dusty Mabe from comment #22) > (In reply to Steve Dickson from comment #21) > > (In reply to Dusty Mabe from comment #19) > > > Discussed today: > > > https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment- > > > 463294800 > > > > > > We will try to ship just the nfs client in Fedora CoreOS and allow the server > > > to be run in a container if needed by users. > > Well this will be easier said than done... Due to the fact /proc/fs is > > mount read-only in a standard container, to run a NFS server > > a "privileged container" is needed... I have not got my head around > > that... quite yet.. > > agreed. but I believe we already tackle this in kubernetes/openshift today so > it shouldn't be too hard to turn the right knobs to get it to work. Could you please point me to that work? I would love see how you made it happen. > > > > > > > > > > So the remaining questions: > > > > > > - Should we rename it to nfs-client-utils (or nfs-utils-client) in case it > > > would be useful for others? > > Fine... This probably makes sense... Does the naming really matter?? > > The question is more related to: > "is this completely specific and only useful to coreos, or not". > If it would only ever be useful to Fedora CoreOS then I'm fine keeping > `coreos` > in the name. If it could be useful for anyone else I like the `client` in > the name > better. My thoughts were if in the future more "things" that were needed in coreos package it would be easily to be added. > > A followup question would be: > > - does nfs-utils provide some of the same files that nfs-client-utils would > or > does it now require nfs-client-utils ? Yes nfs-utils provides the exact same client files and no nfs-utils does not dep on the a client package. > > If we remove `coreos` from the name of the package I think I'd prefer them > to not > provide some of the same files and just add the dep on nfs-utils. This is a bit more complicated than I was thinking.... Plus I thought adding a dep on nfs-utils was a no go... due to the nfs-covert python script for the server. Again, I was just thinking create separate sub package with everything coreos needed to do an NFS client mount... Maybe as time goes on and we see how people are using coreos, we revisit the idea of creating a client package that nfs-utils deps on... > > > > > > > - Should we split out the server package like we did the client and have > > > nfs-client require them both? > > I don't see the reason for this... By far the NFS client is used > > more than the server... so think break out the client does make sense. > > But in what scenario would only a server (which needs python) be installed > > and not the client? I just see a justification for the amount of work > > and testing it would to make this happen. > > I guess the request was more for symmetry. It is not required and if it > imposes extra > work probably should not be done. I'm not against doing the work... actually I think SUSE break this up differently that we do... But again I would like to see how coreos is going to be used... I think ensuring coreos has a NFS client is a good start... If there is push back on the naming or the lack of a server... that is something we can deal with down the road.... Heck, Fedora release are every 6 mons ;-)
(In reply to Steve Dickson from comment #23) > (In reply to Dusty Mabe from comment #22) > > (In reply to Steve Dickson from comment #21) > > > (In reply to Dusty Mabe from comment #19) > > > > Discussed today: > > > > https://github.com/coreos/fedora-coreos-tracker/issues/121#issuecomment- > > > > 463294800 > > > > > > > > We will try to ship just the nfs client in Fedora CoreOS and allow the server > > > > to be run in a container if needed by users. > > > Well this will be easier said than done... Due to the fact /proc/fs is > > > mount read-only in a standard container, to run a NFS server > > > a "privileged container" is needed... I have not got my head around > > > that... quite yet.. > > > > agreed. but I believe we already tackle this in kubernetes/openshift today so > > it shouldn't be too hard to turn the right knobs to get it to work. > Could you please point me to that work? I would love see how you > made it happen. I haven't done this myself but here is something someone linked me to: https://github.com/kubernetes/examples/blob/master/staging/volumes/nfs/nfs-server-rc.yaml It is privileged, yes. > > > > > > > > > > > > > > > > So the remaining questions: > > > > > > > > - Should we rename it to nfs-client-utils (or nfs-utils-client) in case it > > > > would be useful for others? > > > Fine... This probably makes sense... Does the naming really matter?? > > > > The question is more related to: > > "is this completely specific and only useful to coreos, or not". > > If it would only ever be useful to Fedora CoreOS then I'm fine keeping > > `coreos` > > in the name. If it could be useful for anyone else I like the `client` in > > the name > > better. > My thoughts were if in the future more "things" that were needed > in coreos package it would be easily to be added. Indeed. > > > > > A followup question would be: > > > > - does nfs-utils provide some of the same files that nfs-client-utils would > > or > > does it now require nfs-client-utils ? > Yes nfs-utils provides the exact same client files and no nfs-utils does > not dep on the a client package. > > > > > If we remove `coreos` from the name of the package I think I'd prefer them > > to not > > provide some of the same files and just add the dep on nfs-utils. > This is a bit more complicated than I was thinking.... Plus I thought > adding a dep on nfs-utils was a no go... due to the nfs-covert python > script for the server. Sorry if I was misleading. I was referring to a possible solution where 1. nfs-utils depends on nfs-utils-client 2. nfs-utils and nfs-utils-client contain different files (no same files) 3. nfs-utils-client could be installed standalone So we would be installing only nfs-utils-client and would get no python deps. We don't need to carry that discussion any farther. Just wanted to clarify. > > Again, I was just thinking create separate sub package with everything > coreos needed to do an NFS client mount... Maybe as time goes on and > we see how people are using coreos, we revisit the idea of creating > a client package that nfs-utils deps on... This works. The discussion here is mostly academic (i.e. exploring the best possible solution). There are many practical solutions that work and we are happy with any of them. We'd like you to use your judgement here. > > > > - Should we split out the server package like we did the client and have > > > > nfs-client require them both? > > > I don't see the reason for this... By far the NFS client is used > > > more than the server... so think break out the client does make sense. > > > But in what scenario would only a server (which needs python) be installed > > > and not the client? I just see a justification for the amount of work > > > and testing it would to make this happen. > > > > I guess the request was more for symmetry. It is not required and if it > > imposes extra > > work probably should not be done. > I'm not against doing the work... actually I think SUSE break this up > differently that we do... But again I would like to see how coreos is > going to be used... > > I think ensuring coreos has a NFS client is a good start... If there is push > back on the naming or the lack of a server... that is something we can > deal with down the road.... Heck, Fedora release are every 6 mons ;-) +1
Hey Steve, Where do we stand on this? Thoughts on next steps?
(In reply to Dusty Mabe from comment #25) > Hey Steve, Where do we stand on this? Thoughts on next steps? I just did both the f30 and f31 builds.... https://koji.fedoraproject.org/koji/taskinfo?taskID=32925998 https://koji.fedoraproject.org/koji/taskinfo?taskID=32926002 I just check there is really no way to update f30 yet.. Closing as in current release. Lets open another bz if issues are found.
(In reply to Steve Dickson from comment #26) > (In reply to Dusty Mabe from comment #25) > > Hey Steve, Where do we stand on this? Thoughts on next steps? > > I just did both the f30 and f31 builds.... > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32925998 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=32926002 > > I just check there is really no way to update f30 yet.. > > Closing as in current release. > > Lets open another bz if issues are found. But... feel free to reopen this if this is not the right thing to do... ;-)
Thank you!
*** Bug 1607570 has been marked as a duplicate of this bug. ***