search

projectatomic / adb-atomic-developer-bundle

a prepackaged development environment filled with production-grade pre-configured tools that makes container development easier
GNU General Public License v2.0
83 stars 51 forks source link

Do we need Cockpit packages pre-installed in ADB? #396

Open LalatenduMohanty opened 8 years ago

LalatenduMohanty commented 8 years ago

As per discussion in https://github.com/projectatomic/adb-atomic-developer-bundle/issues/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 commented 8 years ago

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 commented 8 years ago

@praveenkumar fixed it. Thanks

bexelbie commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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.