Start Cockpit service bydefault for ADB

[LalatenduMohanty]

vagrant up should start the Cockpit service by default in the Vagrantbox. Because Cockpit GUI an user can do docker pulls , docker runs etc . Cockpit also provides a web terminal which can used to run docker commands without logging in to the Vagrantbox (it is useful for Windows users as vagrant ssh does not work naively in Windows).

Also as per Cockpit documentation it can be used to manage Kubernetes clusters. However for that we need to add cockpit-kubernetes RPM to ADB.

[hferentschik]

vagrant up should start the Cockpit service by default in the Vagrantbox

what's the footprint of Cockpit?

Because Cockpit GUI an user can do docker pulls , docker runs etc

Helping you in which way? What do you gain?

it is useful for Windows users as vagrant ssh does not work naively in Window

Why not?

[hferentschik]

Regarding all these add-ons, I am wondering whether some sort of variant system as in Mac Ports could be used (at least syntax wise). Something like:

 # List variants
 $ service-manager variants openshift 

 # Enable variants 
 $ service-manager enable openshift +cockpit +fabric8

[LalatenduMohanty]

what's the footprint of Cockpit?

It uses around 10MB or RAM.

Helping you in which way? What do you gain?

It helps users who are more comfortable with GUI.

Why not?

Because you need ssh client to do vagrant ssh [1] or a bash like environment e.g. Git for Windows. For this user need to install cygwin or Mingw on the Windows machine.

[1] https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/docs/installing.rst#2-install-vagrant

[LalatenduMohanty]

Regarding all these add-ons, I am wondering whether some sort of variant system as in Mac Ports could be used (at least syntax wise)

@hferentschik I am not sure. I will get back if I get better ideas.

[praveenkumar]

@LalatenduMohanty (just a note) we have to make sure 9090 port is not used by any other service otherwise it might create conflict. (currently we don't have any service with using 9090 port but in future we might be).

[hferentschik]

Because you need ssh client to do vagrant ssh [1] or a bash like environment e.g. Git for Windows. For this user need to install cygwin or Mingw on the Windows machine.

I doubt you will get happy with the whole setup without ssh installed. In fact without ssh our shell provisioning is probably not going to work either.

It uses around 10MB or RAM.

10 MB of RAM and that's enough for running the monitoring and web UI and all?

That said, I like the idea of Cockpit. Not for the reasons mentioned so far, but because afaiu is is an alternative to Hawkular when it comes to metrics and hence will allow to configure autoscaling (need to verify this). Whether it should be installed and enabled per default I am not so sure about.

[bexelbie]

I am still opposed to the idea of starting this by default for the following reasons (and a few others which escape me at the moment):

1. We are primarily targeting a group of people who do not want to use a linux bash prompt.
2. This provides no new user story enablement and adds confusion to the onboarding
3. This is trivial to turn on for users who want it
4. If we turn it on by default we will have a difficult time ever turning it back off. Until we have a proven need lets not make this decision.
5. It conflicts with the idea that we believe OpenShift to be a great GUI experience for containers. I realize not all users will want/need OpenShift, but I haven't been given a compelling reason to not drive them in that direction and let them choose an alternative.

I believe cockpit by default appeals to a lot of us, me included, because we are Linux users and want to touch the machine. However, I believe our user base for ADB has the exact opposite feeling. A perfect ADB disappears from the users view.

[LalatenduMohanty]

We are primarily targeting a group of people who do not want to use a linux bash prompt.

Right. But they want to use docker and hence want to run docker commands.

This provides no new user story enablement and adds confusion to the onboarding

Unless we give users an experience we can not say if they will like it or not. Giving different choices to users is not bad thing . However the cost of choices something we should be aware of.

If we turn it on by default we will have a difficult time ever turning it back off. Until we have a proven need lets not make this decision.

We can do it. We have recently removed multiple packages from ADB from default installation package set. It would need a mail to container-tools and waiting for lazy consensus (couple of weeks).

It conflicts with the idea that we believe OpenShift to be a great GUI experience for containers. I realize not all users will want/need OpenShift, but I haven't been given a compelling reason to not drive them in that direction and let them choose an alternative.

RHEL eco-system supports Kubernetes too. OpenShift is not the only user story we have. It again comes to user freedom and choice. User can choose between OpenShift and Kubernetes. If OpenShift proves to be a better solution then user might want to migrate. But ecosystem supports both. Cockpit also give GUI for Kubernetes. So thats another incentive.

[LalatenduMohanty]

10 MB of RAM and that's enough for running the monitoring and web UI and all?

@hferentschik yes, thats what my tests said. But I did a very basic test.

[bexelbie]

We are primarily targeting a group of people who do not want to use a linux bash prompt.

Right. But they want to use docker and hence want to run docker commands.

Yes, docker commands. They don't necessarily want to use a linux bash prompt in a web gui when docker.com shows them how to do it from their built in command line.

This provides no new user story enablement and adds confusion to the onboarding

Unless we give users an experience we can not say if they will like it or not. Giving different choices to users is not bad thing . However the cost of choices something we should be aware of.

Providing instructions and not enabling cockpit by default is not the same as not providing the option. Users can try it now without it being on by default. It is 5 steps. Only 2 steps if you ignore starting the ADB, opening the web browser and using cockpit. This is not a hardship. This is not full of friction.

If we turn it on by default we will have a difficult time ever turning it back off. Until we have a proven need lets not make this decision.

We can do it. We have recently removed multiple packages from ADB from default installation package set. It would need a mail to container-tools and waiting for lazy consensus (couple of weeks).

The built in packages were not heavily promoted or made part of a user story. We pivoted a long time ago away from thinking of shell as our primary access point.

It conflicts with the idea that we believe OpenShift to be a great GUI experience for containers. I realize not all users will want/need OpenShift, but I haven't been given a compelling reason to not drive them in that direction and let them choose an alternative.

RHEL eco-system supports Kubernetes too. OpenShift is not the only user story we have. It again comes to user freedom and choice. User can choose between OpenShift and Kubernetes. If OpenShift proves to be a better solution then user might want to migrate. But ecosystem supports both. Cockpit also give GUI for Kubernetes. So thats another incentive.

Then in the spirit of this we should enable no GUI and let the user choose.

[LalatenduMohanty]

Providing instructions and not enabling cockpit by default is not the same as not providing the option. Users can try it now without it being on by default. It is 5 steps. Only 2 steps if you ignore starting the ADB, opening the web browser and using cockpit. This is not a hardship. This is not full of friction.

There is a difference. Cockpit is not a very famous project at this moment. So I do not see a reason an user would do some steps to enable it unless we make part of the default experience.

The built in packages were not heavily promoted or made part of a user story. We pivoted a long time ago away from thinking of shell as our primary access point.

Shell is not the primary reason I am in favor of Cockpit. It is a mix of goodies. Also we never moved away from shell. Local docker, oc clients are part of this experience. But we want to move away from vagrant ssh.

Then in the spirit of this we should enable no GUI and let the user choose.

If an user uses Vagrantfile for OpenShift he/she gets a GUI. But for Kubernetes we don't have any solution at this moment.

[bexelbie]

Providing instructions and not enabling cockpit by default is not the same as not providing the option. Users can try it now without it being on by default. It is 5 steps. Only 2 steps if you ignore starting the ADB, opening the web browser and using cockpit. This is not a hardship. This is not full of friction.

There is a difference. Cockpit is not a very famous project at this moment. So I do not see a reason an user would do some steps to enable it unless we make part of the default experience.

Actually I think Cockpit has a much stronger community and footprint than ADB (or perhaps even most of Atomic).

In fact, once we get vagrant service-manager start ... merged, I was going to ask Cockpit to list ADB on cockpit.org ... which will help us more than it helps them :)

The built in packages were not heavily promoted or made part of a user story. We pivoted a long time ago away from thinking of shell as our primary access point.

Shell is not the primary reason I am in favor of Cockpit. It is a mix of goodies. Also we never moved away from shell. Local docker, oc clients are part of this experience. But we want to move away from vagrant ssh.

When I wrote shell I meant vagrant ssh

Then in the spirit of this we should enable no GUI and let the user choose.

If an user uses Vagrantfile for OpenShift he/she gets a GUI. But for Kubernetes we don't have any solution at this moment.

Then make Cockpit start automatically in the Kube Vagrantfile and not anywhere else. Before we do that we should determine if this is the right Kube gui or if we should consider bundling one that the Kube community finds to be more effective. Knowing Cockpit's plans for Kube would be helpful in this decision too.

[hferentschik]

Nice discussion :-) I side with @bexelbie, enabling per default seems wrong to me. Documenting how it is done is perfectly fine and I still like my idea variants of some sorts where the user chooses which additional components to install.

Also, as memory efficient as this may be, it still does consume memory and cpu. It feels wrong to keep adding things per default, if we are on the other hand even started to talk about creating slimmed down VM for specific use cases.

[LalatenduMohanty]

After the above discussion I am ok with not starting it by default. But if we are not making part of default experience then I don't think there is much value addition by having Cockpit packages pre-installed in ADB. Because Cockpit is available in CentOS core (base OS). The user can just run command yum install Cockpit to get it installed in addition to the steps i.e. https://github.com/projectatomic/adb-atomic-developer-bundle/blob/master/docs/cockpit.rst, we have mentioned.

I have opened an issue regarding this #396

[LalatenduMohanty]

I dont think we have anything more to discuss in this issue. Closing it.