Hello everyone
Just wanted to see if anyone has made any lead way with supporting
CentOS/RHEL 6.7 via a bridge / agent so these os releases can be brought
into cockpit for resource / servcice monitoring
I know about 8 or 9 months ago this was talked about but not sure if anyone
has taken it upon themselves to come up with a solution yet or if there is
one in the works.
Let me know as we still have a few hundred 6.7 clients hosted in our cloud
and it will take a very long time to safely migrate them if even possible
to a 7.x release.
Regards,
Donald R. D'Avanzo Jr
*Chief Technology OfficerRed Rock Tech LLC. / Sin City Cloud*
*Office:* (702) 660-1500 | *Direct:* (702) 302-9432
*9205 West Russell Road,Suite 240 | **Las Vegas, Nevada 89148*
<http://www.linkedin.com/in/donalddavanzo>
<https://www.facebook.com/SinCityCloudHosting>
*www.sincitycloud.com <http://www.sincitycloud.com/>*
<http://www.sincitycloud.com/>
(Had to put these together by hand, since the urls meetbot gave me at
the end of the meeting were gone...or something like that... got a 404)
Cockpit weekly IRC meeting 2015-11-30
Attendees:
Andreas Nilsson
Marius Vollner
Stef Walters
Dominik Perpeet
Peter Volpe
Agenda:
* External channels
* SOSReport
* OpenSCAP container support
* Debian
* Javascript dependencies
Full log:
andreasn #startmeeting Weekly cockpit meeting 2015-11-30
dperpeet joined
andreasn did that work I wonder
zodbot Meeting started Mon Nov 30 14:03:14 2015 UTC. The chair is
andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
Useful Commands: #action #agreed #halp #info #idea #link #topic.
The meeting name has been set to 'weekly_cockpit_meeting_2015-11-30'
andreasn yup, just slow bot
.hello andreasn
mvollmer .hello mvo
stefw .hello stefw
zodbot mvollmer: mvo 'Marius Vollmer' <marius.vollmer(a)gmail.com>
stefw: stefw 'Stef Walter' <stefw(a)redhat.com>
andreasn: andreasn 'Andreas Nilsson' <anilsson(a)redhat.com>
dperpeet .hello dperpeet
zodbot dperpeet: dperpeet 'None' <dperpeet(a)redhat.com>
andreasn #topic Agenda
mvollmer yay!
* External channels
* SOSReport
andreasn * OpenSCAP container support
mvollmer * Debian
stefw * Javascript dependencies
andreasn all right
#topic External Channels
mvollmer stef has been doing great work on the "external channels"
propmted by the sosreport download feature
andreasn yay
mvollmer now we can open channels just from a GET request with a
special URL
stefw, would you like to add?
stefw the GET request uses a CSRF token
which is sent via the WebSocket in the "init" message
i tried different approaches for these external channels
Son_Goku joined
stefw and this one ended up making the most sense
mvollmer i have changes the sosreport code to use this, and it works
great
stefw cool
mvollmer *changed
andreasn nice
anything else on that subject?
mvollmer review is ongoing, hopefully can be merged very soon.
andreasn nice
#topic SOSReport
mvollmer right
so I changed sosreport to use external channels. :-)
the removes the need to add a file server
now we just open a superuser fsread1 channel
works very well after stefw helped me remember the "binary" option for a
channel
stefw should that be the default for external channels?
dperpeet has disconnected (Ping timeout: 246 seconds)
stefw it would be a bit unexpected
but may help things go better?
mvollmer i don't know...
maybe
or depending on the content-type?
stefw yeah, could be
if content type is set, then make it binary
mvollmer what other uses do we have for the external channels?
stefw well all the resource loading is actually external channels
and they do set binary by default
mvollmer right
hmm, we should decide this before merging
changing the default later is nasty
or culd it be a per-payload default?
fsread1 is binary
fslist1 is not
let's discuss later
stefw ok
mvollmer andreasn, sosreport has "needsdesign"
I would say, let's not do profiles
andreasn all right
so regarding profiles, I looked into that
and made some mockups
https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/sos…
but I ran into the hurdle that Fedora doesn't ship any profiles(?!)
but I could have gotten that backwards
mvollmer they are already inconsistent between f22 and f23 I think.
or rather, don't work on f23
let's bother about that later
dperpeet joined
andreasn yes, I think it would make sense as a version 2
mvollmer ok!
andreasn I'll remove the label for now
mvollmer I'll look into this then.
okay.
yep
andreasn and I'll keep investigating this situation with profiles
all right, next up
#topic OpenSCAP container support
mvollmer i have to check the integration test and make new images,
then sosreport should be ready again
andreasn so I went back to researching Atomic SCAP scanning a bit,
sketching things out and such
but I wonder when and when we need to develop that, if it's urgent and such
or if some other fire is more urgent
mvollmer not a fire, but what about rolekit?
andreasn I have a lot of design done on rolekit already, but I'm
revisiting those a bit as well
mvollmer is that in good shape from your point of view?
andreasn it's in like a half-good state maybe
mvollmer okay
andreasn so it would work, but could be better
I'll do some more work on rolekit as well during this week
mvollmer I am thinking that I start with that towards the end of the
week, maybe
andreasn sounds good
mvollmer okay
ilovelinux joined
andreasn #topic Debian
stefw has to go in 6 minutes
mvollmer let's do stef's topic
andreasn sure, what was that?
#topic Javascript dependencies
mvollmer #topic Javascript dependencies
stefw javascript dependencies
because some distros are complaining about us bundling javascript
dependencies
mvollmer right
andreasn hehehe
this old fight
stefw i'm trying to make progress in the direction of having them
replacable at *build* time
not at *runtime*
mvollmer yes, that makes sense
stefw so as a first step, i'm trying to move all deps into a sane
place (rather than copying them around our tree)
and trying to use unmodified upstream files
andreasn so that a distro could ship a certain patternfly version and
have us pick up that?
stefw this is also interesting for the image registry package i'm
working on
andreasn (maybe a bad example)
stefw lets see how far we get
andreasn, well i would suggest we lock down the versions very specifically
andreasn right
stefw and the distro needs to ship that version (perhaps the dotted
point version can vary)
mvollmer i think we should still ship 'known good' versions in the
tarball
stefw mvollmer, yes, we could do that
mvollmer but allow them to be replaced
stefw and i'm going to do that for the bower dependencies
mvollmer so that we can point fingers
stefw so there are broadly two types of javascript dependencies:
andreasn newer patternfly could break an older cockpit theoretically
stefw 1. the nodejs devel dependencies listed in package.json
2. the bower runtime dependencies currently controlled via 'make
update-lib'
i would like to continue to ship known good versions of the latter
in our git repo
mvollmer yes
stefw especially because then it makes development so much easier
andreasn, yes, and it has
we can be less stringent about the nodejs deps
even though those have broken our build in the past
but for the runtime bower dependencies we need to be quite strict about
versions, or we'll have a mess on our hands
so anyway, just a step in this direction
disentangling things
hopefully there will be a pull request soon
mvollmer nice
andreasn cool
mvollmer it's more or less equivalent to patching configure.ac, no?
if you do it, you need to run some extra steps and need more builddeps
stefw yes, distros will need to place symlinks in the right places
so our build can find them
and then yes, many mor ebuild deps are need.ed
our goal should still be that no javascript is needed to build the tarball
but if distros want to meddle
then they need everything
mvollmer yes
stefw the open question becomes
how can we guarantee that our tests catch the bugs?
likely we'll have to upstream their meddling ... in some way
so it's not a handsoff thing
lets see how it goes
mvollmer right
yes
dperpeet they can run our tests with their packages
it should be drop-in, basically
stefw has got to go
dperpeet our tests only expect cockpit running on the system, they
don't care where it comes from
mvollmer let's see
stefw, see you!
andreasn later!
mvollmer Debian?
dperpeet mvollmer, go ahead with Debian
andreasn sure
#topic Debian
mvollmer ok
I have been making good progress
some status here:
https://github.com/cockpit-project/cockpit/pull/3202#issuecomment-160580658
I'll continue with this
have to figure out network-manager and FreeIPA
and user synching might be a challenge
but it looks good
dperpeet nice work
5 tests failing
mvollmer a lot of work still to be done, of course
storaged
and SELinux
but we need help with that, I'd say
dperpeet I think we can leave storaged out of the picture for now
mvollmer yeah
dperpeet and pick up the work when someone has it running on debian
mvollmer we still don't have a maintainer in Debian, right?
dperpeet not that I know of
mvollmer it's a good chunk of work
for a volunteer
about the PR itself
there is one big commit that adds support for Debian 8
and many small ones that tweak the tests and Cockpit in small ways
I would appreciate it if you could have a look at the PR
looks like a lot, but really isn't
https://github.com/cockpit-project/cockpit/pull/3202
dperpeet ok
mvollmer petervo, still here?
petervo yes
mvollmer petervo, Debian doesn't have ssh_set_agent_port
(or similar)
it's essential for ssh public key stuff, right?
petervo right so no key auth support
mvollmer can we do something about getting it into Debian?
aruiz has disconnected (Ping timeout: 260 seconds)
jfilak has disconnected (Ping timeout: 260 seconds)
mvollmer newer version? patch against upstream?
petervo it's probably a matter of upgrading libshh i can look into it
jsgrant has disconnected (Ping timeout: 260 seconds)
petervo libssh*
mvollmer okay
mhabrnal has disconnected (Ping timeout: 260 seconds)
mvollmer so, I don't feel like spendin 100% on Debian for much longer
andreasn probably makes sense
phatina has disconnected (Ping timeout: 260 seconds)
mvollmer but network-manager and freeipa need to be tackled
I should talk more to mbiebl etc
andreasn what was up with networkmanager?
mvollmer the tests fail, and I haven't bothered to check
also, the tests are pretty fedora specific
fedora and debian have different ways to configure the network
andreasn ah, but networkmanager itself is functional?
mvollmer yes
ahh, one more thing
installiong build dependencies during vm-create
right now, they are installed during vm-install
but I think I know how to do it
that's it
andreasn nice
#topic open floor
since mvollmer is going to start looking at rolekit at the end of the
week, should we move it up one point on the roadmap?
above NFS
(NFS client that is)
mvollmer I'd say yes
andreasn cool, I'll do that then
mvollmer thanks
andreasn anything else?
did I go offline?
mvollmer i think we are done
andreasn__ hups, seems I dropped off
cool
#endmeeting
Are there plans to be able to manage KVM VM in a similar why as Cockpit manages Docker containers. Same question for Xen support, but of less interest.
Nice work on SOSreport.
Would be interesting to support SOSreport inside a container on atomic host.
-subhendu
Sent from Nine
From: Stef Walter
Sent: Nov 19, 2015 5:27 AM
To: Development discussion for the Cockpit Project
Subject: Cockpit 0.83 and 0.84
This is a summary of the Cockpit weekly releases. Over the last weeks
there was was 0.83 and 0.84
Building Cockpit on Debian
--------------------------
At systemd.conf Dominik worked with Michael Biebl one of the Debian
systemd maintainers on packaging Cockpit for Debian. We're still looking
for a maintainer long term.
http://dominik.perpeet.eu/cockpit-on-debian-8-2
Cross Distro Integration Tests
------------------------------
In Cockpit we run hundreds of tests on real operating systems for each
pull request. Without running these tests on an OS it's impossible to
know that the features of Cockpit actually works.
So far we've been running these tests on Fedora, Atomic, and RHEL. But
we'd really like to run them on Debian as well. That'll make Cockpit
much more well rounded.
Marius worked on the first steps toward this, doing the Cockpit build
inside of our test VM images:
https://github.com/cockpit-project/cockpit/pull/3138
Hopefully we'll see more progress on this.
SELinux certificate file type
-----------------------------
The cockpit.service helpfully sets the appropriate user and group on the
certificates that cockpit-ws will use for TLS. Now it also sets the
SELinux file context type properly, so this is one less things to break
for an admin.
Cockpit manual page
-------------------
There is now a 'man cockpit' overview manual page that links to the
guide and elsewhere.
Next
----
Marius has done work on an SOS reporting view. Needs some further
backend work, but should be ready soon:
https://youtu.be/-6rfWUoOQbs
Peter has mostly completed the work to add machines with alternate
users, and non-standard SSH ports. Among other things, this is useful
for cloud instances. I'm looking forward to seeing this in Cockpit 0.85.
Wireframes:
https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/add…
Pull request: https://github.com/cockpit-project/cockpit/pull/3018
There's lots of other work in progress. You can see it here in the
Design and Implementation columns:
https://github.com/cockpit-project/cockpit/wiki/Featureshttps://github.com/cockpit-project/cockpit/pullshttps://trello.com/b/mtBhMA1l/cockpit
Get it
------
You can get Cockpit 0.84 in Fedora 23 or Fedora Rawhide:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-96b41c5190
Or via COPR for CentOS, RHEL, and earlier versions of Fedora:
https://copr.fedoraproject.org/coprs/g/cockpit/cockpit-preview/
Or download the tarball here:
https://github.com/cockpit-project/cockpit/releases/tag/0.84
Cheers,
Stef
Hi!
I'm a member of a team on storage which is trying to make storage more accessible to consumers.
Yesterday, there was a brief dicussion in the Project Springfield meeting of pyblk,
which is a sort of lsblk-like library.
We believe that the capabilities of pyblk would enhance the smart storage administrator's
abilities a lot.
I'm looking for feedback on how Cockpit might be able to use these capabilities, and
what Cockpit would require to make these capabilities accessible to it.
If you can, could you take a look at the whitepaper here:
https://mulhern.fedorapeople.org/pyblk_rfc.pdf ?
We have discussed a lot of ways the info pyblk can generate could be served up to the
user. For example, we could attach graphs (or pointers to the graphs) to journal
entries. We could be more independent and instead have a facility to look up graphs by
means of time-stamps. We can present diffs of graphs of the state of storage before
and after a certain time.
What do you think of any of this? Please let us know.
Thanks!
- mulhern
On RHEL, the rhel-tools container has it. Not sure if Fedora or CentOS are carrying something similar.
Sent from Nine
From: Stef Walter
Sent: Nov 19, 2015 5:47 AM
To: Development discussion for the Cockpit Project; SGhosh
Subject: Re: Cockpit 0.83 and 0.84
On 19.11.2015 11:34, Subhendu Ghosh wrote:
> Nice work on SOSreport.
> Would be interesting to support SOSreport inside a container on atomic host.
Is there such a container? If so, it would be simple matter of changing
the command to do something like 'atomic run soscontainer --arguments'.
Is that right Marius?
Stef
> *From:* Stef Walter
> *Sent:* Nov 19, 2015 5:27 AM
> *To:* Development discussion for the Cockpit Project
> *Subject:* Cockpit 0.83 and 0.84
>
> This is a summary of the Cockpit weekly releases. Over the last weeks
> there was was 0.83 and 0.84
>
>
> Building Cockpit on Debian
> --------------------------
>
> At systemd.conf Dominik worked with Michael Biebl one of the Debian
> systemd maintainers on packaging Cockpit for Debian. We're still looking
> for a maintainer long term.
>
> http://dominik.perpeet.eu/cockpit-on-debian-8-2
>
>
> Cross Distro Integration Tests
> ------------------------------
>
> In Cockpit we run hundreds of tests on real operating systems for each
> pull request. Without running these tests on an OS it's impossible to
> know that the features of Cockpit actually works.
>
> So far we've been running these tests on Fedora, Atomic, and RHEL. But
> we'd really like to run them on Debian as well. That'll make Cockpit
> much more well rounded.
>
> Marius worked on the first steps toward this, doing the Cockpit build
> inside of our test VM images:
>
> https://github.com/cockpit-project/cockpit/pull/3138
>
> Hopefully we'll see more progress on this.
>
>
> SELinux certificate file type
> -----------------------------
>
> The cockpit.service helpfully sets the appropriate user and group on the
> certificates that cockpit-ws will use for TLS. Now it also sets the
> SELinux file context type properly, so this is one less things to break
> for an admin.
>
>
> Cockpit manual page
> -------------------
>
> There is now a 'man cockpit' overview manual page that links to the
> guide and elsewhere.
>
>
> Next
> ----
>
> Marius has done work on an SOS reporting view. Needs some further
> backend work, but should be ready soon:
>
> https://youtu.be/-6rfWUoOQbs
>
>
> Peter has mostly completed the work to add machines with alternate
> users, and non-standard SSH ports. Among other things, this is useful
> for cloud instances. I'm looking forward to seeing this in Cockpit 0.85.
>
> Wireframes:
> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/add…
>
> Pull request: https://github.com/cockpit-project/cockpit/pull/3018
>
>
> There's lots of other work in progress. You can see it here in the
> Design and Implementation columns:
>
> https://github.com/cockpit-project/cockpit/wiki/Features
> https://github.com/cockpit-project/cockpit/pulls
> https://trello.com/b/mtBhMA1l/cockpit
>
>
> Get it
> ------
>
> You can get Cockpit 0.84 in Fedora 23 or Fedora Rawhide:
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2015-96b41c5190
>
>
> Or via COPR for CentOS, RHEL, and earlier versions of Fedora:
>
> https://copr.fedoraproject.org/coprs/g/cockpit/cockpit-preview/
>
>
> Or download the tarball here:
>
> https://github.com/cockpit-project/cockpit/releases/tag/0.84
>
>
> Cheers,
>
> Stef
>
>
>
>
>
> _______________________________________________
> cockpit-devel mailing list
> cockpit-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/cockpit-devel@lists.fedorahosted…
>
This is a summary of the Cockpit weekly releases. Over the last weeks
there was was 0.83 and 0.84
Building Cockpit on Debian
--------------------------
At systemd.conf Dominik worked with Michael Biebl one of the Debian
systemd maintainers on packaging Cockpit for Debian. We're still looking
for a maintainer long term.
http://dominik.perpeet.eu/cockpit-on-debian-8-2
Cross Distro Integration Tests
------------------------------
In Cockpit we run hundreds of tests on real operating systems for each
pull request. Without running these tests on an OS it's impossible to
know that the features of Cockpit actually works.
So far we've been running these tests on Fedora, Atomic, and RHEL. But
we'd really like to run them on Debian as well. That'll make Cockpit
much more well rounded.
Marius worked on the first steps toward this, doing the Cockpit build
inside of our test VM images:
https://github.com/cockpit-project/cockpit/pull/3138
Hopefully we'll see more progress on this.
SELinux certificate file type
-----------------------------
The cockpit.service helpfully sets the appropriate user and group on the
certificates that cockpit-ws will use for TLS. Now it also sets the
SELinux file context type properly, so this is one less things to break
for an admin.
Cockpit manual page
-------------------
There is now a 'man cockpit' overview manual page that links to the
guide and elsewhere.
Next
----
Marius has done work on an SOS reporting view. Needs some further
backend work, but should be ready soon:
https://youtu.be/-6rfWUoOQbs
Peter has mostly completed the work to add machines with alternate
users, and non-standard SSH ports. Among other things, this is useful
for cloud instances. I'm looking forward to seeing this in Cockpit 0.85.
Wireframes:
https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/add…
Pull request: https://github.com/cockpit-project/cockpit/pull/3018
There's lots of other work in progress. You can see it here in the
Design and Implementation columns:
https://github.com/cockpit-project/cockpit/wiki/Featureshttps://github.com/cockpit-project/cockpit/pullshttps://trello.com/b/mtBhMA1l/cockpit
Get it
------
You can get Cockpit 0.84 in Fedora 23 or Fedora Rawhide:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-96b41c5190
Or via COPR for CentOS, RHEL, and earlier versions of Fedora:
https://copr.fedoraproject.org/coprs/g/cockpit/cockpit-preview/
Or download the tarball here:
https://github.com/cockpit-project/cockpit/releases/tag/0.84
Cheers,
Stef