We seem to be missing the cockpit rpm that includes the systemd files (e.g. /usr/lib/systemd/system/cockpit.socket).
Can we add cockpit-ws for the next update? We'll probably not be able to respin the images, but an atomic update can pull in the package.
F22 only includes the Cockpit core, the rest comes as a container. I noted this in the Fedora wiki page I can't find now that was supposed to list the changes.
See also https://lists.fedoraproject.org/pipermail/rel-eng/2015-May/020170.html
I think it was premature to pull it from the base image before we are able to distribute it in our own infrastructure. I know Fedora Releng is interested in being able to do that, but I don't know who if anyone is signed up to actually make that happen.
In the above thread, it's raised as something for the FAD next week, but that doesn't really help for the current release. If we needed this yesterday, we needed to know about this... at least before yesterday.
For reference the commit is here:
https://git.fedorahosted.org/cgit/fedora-atomic.git/commit/?h=f22&id=5a3cc4b0ee70ad4ff8d3729a72d215dda9de5595
Which also links to discussion from February. We expected to move faster on having Cockpit come as a container, but didn't identify as a priority having Fedora rel-eng ship it.
It's done now, so let's focus on moving forward? Which is having Fedora rel-eng be capable of building and delivering the image, right?
Although looking at this more I realize that a lot of the actual discussion happened out of band, and we didn't quite clearly communicate that Cockpit was effectively being removed from the host by default.
currently there we have no way to build and support containers and different layered images. It is being worked on and hopefully will be landing in Fedora 23. for now we are likely best servered by adding cockpit abck to the images. and shipping it out in the next spin, though I am open to some other option that we can support.
+1 to focusing on moving forward. I have great confidence that everyone here wants to do the right thing; there's just a lot up in the air all at once.
I'm told that [https://fedoraproject.org/wiki/User:Ttomecek Tomas Tomecek] is working on something w.r.t. layered image building. Dennis, is that what you're referring to, or something else? If we land this for F23 (ideally, as I know you like to do, before alpha), can we also turn it on for F22?
The Cloud WG discussed this today and the consensus is that we should revert to a traditional rpm/service based approach for F22 and re-release the container based approach at a future date with proper announcements and documentation that help people migrate easily.
Replying to [comment:7 dustymabe]:
+1 from me.
In order to get cockpit to run on a F22 atomic host is two commands:
docker pull fedora/cockpitws atomic run docker.io/fedora/cockpitws
Then you are ready to go.
The thing, the whole point of this effort is to containerize. Anyone who wants the traditional "one set of packages" model has plenty of other options within Fedora, such as Fedora Server and Fedora Cloud Base.
There's also the aspect that even if we add cockpit into the tree in an update, anyone who does an initial install won't get it, so there will still be issues with that.
Finally, while Fedora 21 shipped with it enabled by default, I'm a bit hesistant to ship a new service that listens on the network by default in an update to Fedora 22. It's very reasonable for organizations to evaluate a "gold" OS configuration, perform some customization including turning on/off services, setting up firewalling etc. These types of deployments would be unhappy to have new services appear.
(It's actually not completely easy to simply blacklist all services, because it's reasonable for e.g. nfs-utils to include a new internal service, and if you then disable it by default, you wouldn't want to break NFS. This is more about services which listen on the network)
Replying to [comment:6 mattdm]:
+1 to focusing on moving forward. I have great confidence that everyone here wants to do the right thing; there's just a lot up in the air all at once. I'm told that [https://fedoraproject.org/wiki/User:Ttomecek Tomas Tomecek] is working on something w.r.t. layered image building. Dennis, is that what you're referring to, or something else? If we land this for F23 (ideally, as I know you like to do, before alpha), can we also turn it on for F22?
That is what I am talking about, we can look at turning it on for f22 updates also. It is still a way off, so I am not sure when we will be able to do it.
So in comment#7 I stated the decision of the Cloud WG to revert back to the old rpm model for now. In comment#11 it looks like we are ignoring that. What can we do to move this forward?
Is cockpit only going to be delivered via container in the future (for atomic and for non-atomic)?
I think the important part of this is that the user has a good and consistent experience. If we can deliver that with containers now then we would be open to that approach. Otherwise we should revert and make that change for F23.
Comment #11 was hardly ignoring - it raised a number of points which could use a reply.
However as far as governance goes: https://fedoraproject.org/wiki/Cloud/Governance says:
{{{ For bigger issues, where there may be disagreement, or where there is long-term impact, or where an action may not easily be undone, we will use a ticketing system for voting https://fedorahosted.org/cloud/. Working group members can vote +1 to approve, -1 to disagree, or 0 to abstain; five +1 votes are necessary for a measure to pass. }}}
And there is definitely disagreement here.
I am not on the WG, but I am one of the people who commits most often to the manifest. I would make the change if it had the +1 of 5 WG members, per the charter. I'm also open to alternatives such as transferring ownership of the fedora-atomic git repo to the Cloud WG (giving members access), but I think for this issue the 5 +1s makes the most sense.
Finally coming back to this. So - I had known that containerizing Cockpit was in the offing, I hadn't realized that it was in the offing for F22. It's entirely possible that this information had crossed my screen at some point and it got lost in the shuffle - if so, mea culpa.
I've installed and run Cockpit via container a few times for demos, and here's my current thinking now that I'm aware how easy this is, etc.:
All that said, I think I'm -1 on reverting the change at this point. If I'd spotted this before release, I'd feel differently, but I think we can just go forward from here.
walters, jzb. Thank you for your input.
At the time we did the meeting (2 weeks ago) the container story was a little farther off. Now we have some documentation (http://www.projectatomic.io/blog/2015/06/running-cockpit-as-a-service/) and perhaps can get the container included in atomic.
I think if we can get the container story right and situated for the release of an updated atomic (as part of the updated releases https://fedorahosted.org/cloud/ticket/94) then I would +1 going forward with the container.
If there are things that would block having it get into an updated atomic image then I would propose we stay with the rpm approach and get that into the updated image instead.
Thoughts?
Replying to [comment:10 walters]:
You mentioned some of these points needed to be replied to.. I'll give it a stab.
The thing, the whole point of this effort is to containerize. Anyone who wants the traditional "one set of packages" model has plenty of other options within Fedora, such as Fedora Server and Fedora Cloud Base. There's also the aspect that even if we add cockpit into the tree in an update, anyone who does an initial install won't get it, so there will still be issues with that.
We are planning to release updated images. Does that change your opinion?
If we don't want it to listen on the network by default and we are delivering as a container then should we just not include it at all?
Replying to [comment:15 dustymabe]:
walters, jzb. Thank you for your input. At the time we did the meeting (2 weeks ago) the container story was a little farther off. Now we have some documentation (http://www.projectatomic.io/blog/2015/06/running-cockpit-as-a-service/) and perhaps can get the container included in atomic. I think if we can get the container story right and situated for the release of an updated atomic (as part of the updated releases https://fedorahosted.org/cloud/ticket/94) then I would +1 going forward with the container. If there are things that would block having it get into an updated atomic image then I would propose we stay with the rpm approach and get that into the updated image instead. Thoughts?
I don't think we want to put it in the atomic image. We'd be bloating the image significantly - over and above what it'd add just to have the RPMs for the additional cockpit components. The idea is that users who want Cockpit can easily add it with one command ("sudo atomic install fedora/cockpitws") and those who don't simply don't need the additional space consumed by the packages.
Ok so what I am hearing is that we probably don't want to include it at all inside atomic. We can have a vote on that. I would be +1 if we can publish some documentation:
1 - How to bring up a cloud node and automatically download and start cockpit using cloud-init 2 - How we can bring up a bare metal node and do the same thing (via kickstart??)
If we can get those two items out then I think we can move forward with just doing the container. Agree/Disagree?
jbrooks has volunteered to do some of the docs mentioned in the previous comment.
I'm working on the cloud-init part of this in this gist: https://gist.github.com/jasonbrooks/20cd3ebba36f851b957b.
I have it working, mostly, but docker won't start until I reboot the VM. I'm not sure why -- any ideas?
As discussed in the cloud wg meeting today, I'll work on the kickstart part of this and connect w/ dustymabe on smoothing the cloud-init part by 2015-08-03.
For cloud-init, the directions in the gist at https://gist.github.com/jasonbrooks/20cd3ebba36f851b957b work, I'm going to put these in a blog post and in the fedora cloud wiki.
Blogged here: http://www.projectatomic.io/blog/2015/08/running-a-containerized-cockpit-ui-from-cloud-init/
will check out where to add on the cloud wiki
Now on the wiki at https://fedoraproject.org/wiki/Cloud/Tutorials/cockpit-in-a-container
Login to comment on this ticket.