(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' <[email protected]>
stefw: stefw 'Stef Walter' <[email protected]>
andreasn: andreasn 'Andreas Nilsson' <[email protected]>
dperpeet .hello dperpeet
zodbot dperpeet: dperpeet 'None' <[email protected]>
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-reports/create-sos-report-v3.png
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
_______________________________________________
cockpit-devel mailing list
[email protected]
https://lists.fedorahosted.org/admin/lists/[email protected]
