Bug 1241469

Created attachment 1050206 [details]
Break out kubectl into kubernetes-client sub-package

Hi Stef,

kubectl is used by both master and node subpackages. I will finish the decomposition. Thanks for the heads up and justification.

Regards
Jan

Stef, Avesh,

can you test the scratch build [1]?. I don't see any problems in this case as kubectl has no config files not service files. Just kubernetes-master and kubernetes-nodes depends on kubernetes-client now. So it is more like to test if master and node subpackages are still working as expected.

[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=10328080

Thanks
Jan

Hi Jan,

what worked:
1. I upgraded from current kubernetes-master/node to kubernetes-master/node and kubernets-client and it worked fine.

2. I installed stand-alone kubectl-cleint on a system and it worked fine.

What did not seem to work:
Uninstalling kubernetes-client uninstalls kubernets-master/node too, which should not happen i think. I can reasonably think use cases where only master/node pieces are installed on a system and kubernetes-client on other system.  

Uninstalling stand-alone kubernets-client seemed to stuck for considerable time (for around more than 15/20 sec) as it seemed to find some dependencies (i think kubernetes-master/node).

(In reply to Avesh Agarwal from comment #4)
> Uninstalling kubernetes-client uninstalls kubernets-master/node too, which
> should not happen i think. I can reasonably think use cases where only
> master/node pieces are installed on a system and kubernetes-client on other
> system.  

It's very common for the server side of a package to require the client side be installed. It's been the case for the database servers (mysql, postgres) ... as well as things like openssh-server.

(In reply to Stef Walter from comment #5)
> (In reply to Avesh Agarwal from comment #4)
> > Uninstalling kubernetes-client uninstalls kubernets-master/node too, which
> > should not happen i think. I can reasonably think use cases where only
> > master/node pieces are installed on a system and kubernetes-client on other
> > system.  
> 
> It's very common for the server side of a package to require the client side
> be installed. It's been the case for the database servers (mysql, postgres)
> ... as well as things like openssh-server.

Agree, but why uninstalling kubernetes-client should uninstall master?

(In reply to Avesh Agarwal from comment #6)
> (In reply to Stef Walter from comment #5)
> > (In reply to Avesh Agarwal from comment #4)
> > > Uninstalling kubernetes-client uninstalls kubernets-master/node too, which
> > > should not happen i think. I can reasonably think use cases where only
> > > master/node pieces are installed on a system and kubernetes-client on other
> > > system.  
> > 
> > It's very common for the server side of a package to require the client side
> > be installed. It's been the case for the database servers (mysql, postgres)
> > ... as well as things like openssh-server.
> 
> Agree, but why uninstalling kubernetes-client should uninstall master?

Because kubernetes-master requires kubernetes-client. 

For extra fun, try uninstalling python, or glibc :)

> I can reasonably think use cases where only master/node pieces are
> installed on a system and kubernetes-client on other system. 

As both kubernetes-master and kubernetes-node both have kubectl command implicitely, it is correct behaviour to uninstall both kubernetes-master and kubernetes-node if kubernetes-client is.

If there is machine with kubernetes-master and kubernetes-client installed on it is the same case as to have kubernetes-master installed before this decomposition.

> Uninstalling stand-alone kubernets-client seemed to stuck for considerable
> time (for around more than 15/20 sec) as it seemed to find some
> dependencies (i think kubernetes-master/node).

Cost that have to paid I guess.

(In reply to Stef Walter from comment #7)
> (In reply to Avesh Agarwal from comment #6)
> > (In reply to Stef Walter from comment #5)
> > > (In reply to Avesh Agarwal from comment #4)
> > > > Uninstalling kubernetes-client uninstalls kubernets-master/node too, which
> > > > should not happen i think. I can reasonably think use cases where only
> > > > master/node pieces are installed on a system and kubernetes-client on other
> > > > system.  
> > > 
> > > It's very common for the server side of a package to require the client side
> > > be installed. It's been the case for the database servers (mysql, postgres)
> > > ... as well as things like openssh-server.
> > 
> > Agree, but why uninstalling kubernetes-client should uninstall master?
> 
> Because kubernetes-master requires kubernetes-client. 
> 
> For extra fun, try uninstalling python, or glibc :)

But what about those use cases, where some admin only wants kubernetes-master on a system and does not want kubernetes-client on the same system for whatever reasons? One reason may be that an admin is running kubernetes-client on a remote system and does not want to increase the attack surface of the kubernets-master system by installing kubernetes-client?

Every file kubernetes-client provides is at the moment included in files provided by kubernetes-master.

Of course it is possible to add kubernetes-client subpackage without removing kubectl from kubernetes-master/node. However, this will duplicate files.

(In reply to Jan Chaloupka from comment #10)
> Every file kubernetes-client provides is at the moment included in files
> provided by kubernetes-master.
> 
> Of course it is possible to add kubernetes-client subpackage without
> removing kubectl from kubernetes-master/node. However, this will duplicate
> files.

How about this to avoid duplication: that master/node installs client, but uninstalling client does not remove master/client, if that makes sense.

(In reply to Avesh Agarwal from comment #11)
> (In reply to Jan Chaloupka from comment #10)
> > Every file kubernetes-client provides is at the moment included in files
> > provided by kubernetes-master.
> > 
> > Of course it is possible to add kubernetes-client subpackage without
> > removing kubectl from kubernetes-master/node. However, this will duplicate
> > files.
> 
> How about this to avoid duplication: that master/node installs client, but
> uninstalling client does not remove master/client, if that makes sense. 

Nuke that, it might not be possible as dependencies wont work like that I think.

>> How about this to avoid duplication: that master/node installs client, but
>> uninstalling client does not remove master/client, if that makes sense. 
>
> Nuke that, it might not be possible as dependencies wont work like that I think.

Yes. There are file duplications and then kubernetes-client is independent of kubernetes-master/node and visa verse. Or there are no duplications but master/nodes depends on client.

> One reason may be that an admin is running kubernetes-client on a remote system
> and does not want to increase the attack surface of the kubernetes-master system
> by installing kubernetes-client?

How could this be used? From my point of view installed files will be the same.

are we sure this is not dnf 'helpfully' uninstall all new leaves?  /me would need to find the dnf magic to make it not do that.  (I haven't actually looked at the provides/requires/stuff you added, just know dnf does that.)

From packaging guidelines [1]:

"A Fedora package must not list a file more than once in the spec file's %files listings. If you think your package is a valid exception to this, please bring it to the attention of the Packaging Committee so they can improve on this Guideline."

So duplication is not implicitly allowed between two %files sections (if my understanding of it is correct). The only exception are license files.

Talking to Lubos Kardos (<lkardos>, rpm maintainer) the work-flow is like this:
1) rpm installs both k8s-master and k8s-client. /usr/bin/kubectl owned by old k8s-master is not deleted
2) both old k8s-master and new k8s-client own the binary
3) old k8s-master is removed and the binary is now owned only by k8s-client

If old and new /usr/bin/kubectl has different checksum, the old one is replaced by the new one.

Eric, does it cover your situation?

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Duplicate_Files

rawhide:
http://pkgs.fedoraproject.org/cgit/kubernetes.git/commit/?id=ec11eb35918ea44410e64d17bab489a23009e7cf

kubernetes-1.0.0-0.9.git2d88675.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/kubernetes-1.0.0-0.9.git2d88675.fc22

kubernetes-1.0.0-0.9.git2d88675.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/kubernetes-1.0.0-0.9.git2d88675.fc21

Package kubernetes-1.0.0-0.9.git2d88675.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing kubernetes-1.0.0-0.9.git2d88675.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11915/kubernetes-1.0.0-0.9.git2d88675.fc22
then log in and leave karma (feedback).

kubernetes-1.0.0-0.9.git2d88675.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

kubernetes-1.0.0-0.9.git2d88675.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.