Do we need Cockpit packages pre-installed in ADB?

[LalatenduMohanty]

As per discussion in #389 we are not making Cockpit part of default experience in ADB.

So the question is if we are not making Cockpit part of default experience then is there any value by having Cockpit packages pre-installed in Cockpit. Because Cockpit is available from CentOS base OS, an user can just run command yum install Cockpit to get it installed in addition to the steps we have mentioned i.e. https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/docs/cockpit.rst.
Also removing the packages will reduce the size by 20MB approximately. (will check and confirm)

[praveenkumar]

As per discussion in #389 we are making Cockpit part of default experience in ADB.

Discussion say we are not making Cockpit part as default for ADB.

[LalatenduMohanty]

@praveenkumar fixed it. Thanks

[bexelbie]

@LalatenduMohanty I think the packages should remain and we should start it just for Kube as you suggested users would find it useful. Even if we don't start it in this case, leave the packages in so that the experience of trying to use it is easy for Windows and Mac users. The Yum command has to be run after SSHing in. But if the packages are pre installed, cockpit is started just via vsm. Leaving these packages in for a few releases gives us an opportunity to determine if there is an audience for this or not.

Finally, I don't believe that these packages contribute 20 megs to the actual download weight. Now that the new releases complete let's figure out what we lost and download size from the removal of the development packages.

[LalatenduMohanty]

@bexelbie If we are just targeting the Kubernets users then I need some time to understand it better and getting more feedback. Cockpit with will all its goodies makes sense to me . But just targeting it for Kubernetes GUI user experience, I am not sure. It might add value , but need some time to understand if anyone uses Cockpit for K8s. Also a mail to container-tools would be a good idea.

The Yum command has to be run after SSHing in

Actually Kubernets Vagrantfile can be modified to have yum install commands. So that user does not has to manually do it.

Leaving these packages in for a few releases gives us an opportunity to determine if there is an audience for this or not.

I agree with you. But we are making it part of Kubernetes user experience. Also only for the GUI. So the question I am asking myself is whether a Kubernetes developer needs a GUI or not? How much value it will add to the whole K8s experience.

[LalatenduMohanty]

Here are some interesting videos

1. Kubernetes on Cockpit : https://www.youtube.com/watch?v=Fcfsu22RssU ( it is around 1 year old)
2. Moniotring OpenShift cluster using Cockpit : https://blog.openshift.com/monitoring-openshift-cluster-using-cockpit/

It seems Cockpit is more applicable when someone wants to manage Kubernetes or Openshift using Cockpit. Just not doing stuff on ADB/CDK.

[bexelbie]

It seems Cockpit is more applicable when someone wants to manage Kubernetes or Openshift using Cockpit. Just not doing stuff on ADB/CDK.

I thought this was why we were going to include it. What does "Just not doing stuff on ADB/CDK" mean here?

[hferentschik]

Whether the cockpit binary is installed out of the box, depends a bit how we are going about additional "add-ons". If we find some sort of abstraction which allows the user to enable them where we do the provisioning on our side, there is indeed no value to have the rpm already installed. We can do that when required.

If the user is supposed to enable it manually, already having installed the rpm saves a step in the provisioning, but I think overall I agree that there is no true benefit having the binary installed out of the box.

[bexelbie]

Whether the cockpit binary is installed out of the box, depends a bit how we are going about additional "add-ons". If we find some sort of abstraction which allows the user to enable them where we do the provisioning on our side, there is indeed no value to have the rpm already installed. We can do that when required.

What do you mean by "provisioning abstraction" In the bare ADB use case, there is current no installer or provisioner (other than vagrant files).

If the user is supposed to enable it manually, already having installed the rpm saves a step in the provisioning, but I think overall I agree that there is no true benefit having the binary installed out of the box.

I disagree, in part because I believe we want to start this automatically for the user in some cases, specifically with Kube now and based on Lala's comments, OpenShift.

I don't think this has proven enough value for the bare docker use case.

[LalatenduMohanty]

Kubernetes community focusing on http://kubernetes.io/docs/user-guide/ui/ and OpenShift is enterprise Kubernetes. So I think we do not need cockpit for OpenShift or Kuebernetes.