14:06:41 <mvollmer> #startmeeting
14:06:41 <zodbot> Meeting started Mon Mar 23 14:06:41 2015 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:06:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:06:49 <andreasn_> we're meeting a guy regarding guadec stuff that could only do it today
14:06:51 <mvollmer> .hello mvo
14:06:52 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:07:13 <mvollmer> #topic Agenda
14:07:25 <andreasn_> .hello andreasn
14:07:26 <zodbot> andreasn_: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:07:30 <dperpeet> .hello dperpeet
14:07:32 <jscotka> .hello jscotka
14:07:32 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
14:07:35 <mvollmer> * Fedora 22 Test day
14:07:35 <zodbot> jscotka: jscotka 'Jan Ščotka' <jscotka@redhat.com>
14:09:02 <stefw> .hello stefw
14:09:03 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
14:09:16 <stefw> * Status on removing cockpitd
14:09:24 <stefw> * Status on javascript bundles
14:09:32 <mvollmer> * Status of integration tsts
14:09:51 <andreasn_> * Status on Patternfly migration
14:11:29 <mvollmer> ok.
14:11:40 <mvollmer> #topic Fedora 22 Test Day
14:11:59 <mvollmer> i think we are ready.
14:12:12 <mvollmer> i went over the test cases, they are working ok.
14:12:19 <mvollmer> i added a "Terminal" test cas
14:12:27 <mvollmer> but nothing else.
14:12:34 <jscotka> images  are ready and widely available in  https://fedorapeople.org/groups/qa/test_days
14:12:37 <mvollmer> maybe we should encourage people to experiment more
14:12:52 <andreasn_> jscotka: does those work on Firefox?
14:12:53 <mvollmer> i have added workarounds to the known problems to the landing page
14:13:05 <jscotka> mvollmer, I have to  regenerate testday form.
14:13:22 <jscotka> mvollmer, mwhen do you plan to have all testcases ready (to be able regenerate form)
14:13:33 <mvollmer> they are ready
14:13:43 <jscotka> andreasn_, that containg 0.45 version, so should work
14:13:54 <andreasn_> jscotka: excellent. Downloading now
14:13:54 <jscotka> ah perfect, nothing will be added?
14:13:59 <mvollmer> no.
14:14:18 <jscotka> mvollmer, perfect, I'll update testapp metadata
14:15:09 <mvollmer> ok
14:15:33 <mvollmer> the two issues are Firefox cert handling, and the firewall.
14:15:54 <mvollmer> i make it clearer that the firewall is supposed to be open.
14:16:20 <stefw> where is the fedora bug for the latter?
14:16:38 <stefw> #info Fedora bug for Firefox cert handling: https://bugzilla.redhat.com/show_bug.cgi?id=1204670
14:17:40 <mvollmer> I have filed a bug against anaconda
14:17:47 <mvollmer> but can't find it anymore?!?
14:18:36 <mvollmer> firewall config is correct, but the wrong zone is active after installation.
14:18:48 <stefw> interesting, good catch
14:18:49 <stefw> sgallagh, ^^
14:19:03 <mvollmer> yeah, sgallagh is on cc.
14:19:07 <sgallagh> stefw: I've already seen and commented on it
14:19:19 <sgallagh> I know exactly why it's happening and I've requested blocker status for it.
14:19:30 <mvollmer> sgallagh, thanks.
14:19:38 <mvollmer> could you link to the bug?
14:19:38 <jscotka> mvollmer, stefw I've disabled firewall in testVM and ISOs, it is better for VM handling and testing purposes
14:19:49 <mvollmer> I _can_ _not_ _find_ _it_...
14:19:55 <sgallagh> .bug 1204739
14:19:59 <zodbot> sgallagh: Bug 1204739 Installing Fedora Server netinst ends up with blocked Cockpit port - https://bugzilla.redhat.com/1204739
14:20:20 <sgallagh> (Sorry, missed that we're in the meeting and probably want that in the record)
14:20:33 <stefw> #info https://bugzilla.redhat.com/show_bug.cgi?id=1204739
14:20:38 <mvollmer> thanks.
14:20:56 <mvollmer> (it's not on my "My Bugs" list, or I am getting old.)
14:21:18 <stefw> so anything else outstanding for the test day?
14:21:59 <sgallagh> What day is that?
14:22:07 <mvollmer> sgallagh, tomorrow.
14:22:16 <jscotka> Only remind today and tomorrow somehow, via emails IRCs
14:22:20 <sgallagh> oof, ok I may or may not be able to get the fix in by then.
14:22:30 <mvollmer> no problem.
14:22:59 <mvollmer> eot?
14:23:09 <mvollmer> maybe a summary is in order.
14:23:23 <mvollmer> #action mvo tell people to go explore
14:23:45 <mvollmer> #action mvo phrase firewall opening instructions as a workaround, with link to bug.
14:24:14 <mvollmer> #action mvo check what is in the repos and update page once 0.45 is available.
14:24:48 <mvollmer> #topic  Status on removing cockpitd
14:25:00 <mvollmer> stefw?
14:25:10 <stefw> i'm working on removing cockpitd so we can have more flexible dependencies
14:25:20 <stefw> the accountsservice work that fridex did gets us in that direction
14:25:26 <stefw> the three areas i'm working on right now:
14:25:34 <stefw> * Removing the Machines and Machine code
14:25:51 <stefw> * Dropping use of accountsservice while adding a server
14:26:00 <stefw> * Removing use of the various resource monitors for graphing
14:26:12 <stefw> in particular with the first item, I would like to move to a JSON based machines file format
14:26:29 <stefw> is this something we can do without retaining backwards compatibility if we do it before Fedora 22?
14:26:47 <stefw> #info Suggestion to move to JSON format for list of machines, without retaining backwards compatibility
14:27:19 <mvollmer> yes, I think that is possible.
14:27:30 <mvollmer> people are looking for an API to add machines, and that file seems to be the API.
14:27:41 <mvollmer> so we need to worry about compat issues.
14:27:56 <mvollmer> after we decide that it is the API.
14:28:16 <stefw> i agree
14:28:43 <dperpeet> it seems to be our de facto API
14:29:16 <sgallagh> mvollmer: BTW, I have a topic for Open Floor, please ping me when you get there.
14:29:25 <mvollmer> ok!
14:30:29 <stefw> #action Will migrate the machines format file to JSON without backwards-compatibility ... the plan being that the new format will be regarded as stable
14:32:49 <mvollmer> next?
14:32:59 <jscotka> I have one question here
14:33:27 <jscotka> is somehow solved localhost issue (if you can remove that) and to be able to add it back?
14:34:10 <jscotka> like if you remove localhost and add it back it is back as normal remote machine, not via locahost hacks
14:34:47 <stefw> we can fix that
14:34:50 <stefw> but it's orthogonal to this
14:35:30 <jscotka> stefw, yes, but is is related to JSON format :-)
14:35:52 <stefw> no it's not
14:35:58 <stefw> we treat "localhost" specially
14:36:00 <jscotka> stefw, ah perfect
14:36:08 <stefw> mvollmer, next topic, i think
14:36:08 <petervo> not really, it's related to this https://github.com/cockpit-project/cockpit/issues/1817
14:36:48 <mvollmer> #topic Status on javascript bundles
14:36:49 <jscotka> stefw, oh, okay, thanks
14:37:15 <stefw> On javascript bundles: I've pushed a branch which combines bundles AMD modules in production into larger files
14:37:28 <stefw> for quicker loading into the browser, and so that we can also be more free with having javascript in separate files
14:37:47 <stefw> https://github.com/cockpit-project/cockpit/pull/1980
14:38:10 <stefw> in many cases, individual javascript files are not installed in production
14:38:16 <stefw> and only are present when the debuginfo is installed
14:38:44 <stefw> because of the way AMD works, we preload the bundles via <script> tags, and the AMD loader will recognize them as already loaded, and won't try to load other files
14:39:07 <mvollmer> ok
14:39:14 <stefw> in the base1 package, we still ship the individual files in addition to the bundle ... because the individual files are documented API
14:39:19 <stefw> but that's the exception
14:39:27 <mvollmer> so we have min.gz bundles, and non-min individual files?
14:39:33 <stefw> in general yes
14:39:38 <stefw> although there are exceptions, as noted above
14:39:54 <dperpeet> does this mean we will move towards implementing more small js files?
14:39:58 <stefw> we can do that
14:40:04 <stefw> we don't necessarily need to refactor everything right away
14:40:08 <stefw> but for example in subscriptions
14:40:23 <stefw> you might have the logic necessary to drive the loading of subscribed information in one javascript file
14:40:26 <dperpeet> yes, that's the first package I thought about
14:40:30 <stefw> and the javascript related to the actual subscriptions page in another
14:40:48 <stefw> in addition, future work could combine all the bundle.min.js.gz from all the installed packages into one bundle
14:41:14 <stefw> i don't think this would be too hard, but it's already complicated enough, so we can wait on that
14:41:28 <mvollmer> the bridge creates the bundels dynamically?
14:41:36 <stefw> however i would like to reserve the name 'bundle.js' (and its' min and gz derivates) for bundles that should (at some point in the future) be loaded dynamically
14:41:38 <stefw> mvollmer, yes
14:41:45 <mvollmer> cool, nice.
14:41:47 <stefw> just by concatenating the contents of bundle.min.js.gz from all the packages
14:42:06 <stefw> so we would only name a bundle "bundle.min.js.gz" if it was part of the "default experience"
14:42:11 <mvollmer> and if everything is in ~/.local/share, say, the bundle is empty?
14:42:21 <stefw> in particular the kubernetes and subscriptions packages shouldn't have bundles called "bundle.min.js.gz"
14:42:27 <mvollmer> ahh, I see.
14:42:29 <stefw> .... instead they can have other names
14:42:52 <stefw> mvollmer, that sort of question is why i hesitate to do the combining of bundles across packages
14:42:59 <stefw> we don't have time to figure out all the corner cases
14:43:02 <mvollmer> right
14:43:07 <stefw> but combining single package bundles is vital to the speed of loading cockpit
14:43:19 <stefw> and also to the way that we code
14:44:12 <stefw> one thing to note
14:44:19 <stefw> there are dummy 'bundle.js' files installed with the debuginfo
14:44:24 <stefw> and present in the cockpit repo
14:44:39 <stefw> because these are empty (with only a comment in them) they force the AMD loader to load individual files for the various javascript modules
14:44:41 <stefw> as nothing is preloaded
14:44:58 <stefw> "real websites" do this sorta thing as well
14:45:03 <mvollmer> aha
14:45:05 <stefw> this is not new territory we are inventing
14:45:14 <stefw> but they tend to do this at build time rather than at install and runtime
14:45:26 <stefw> that is, do the choosing of bundled vs. non-bundled files
14:45:47 <stefw> the base1 package is an exception to several of these concepts
14:45:55 <stefw> in that the non-minified bundle.js has something in it
14:46:00 <stefw> but such is life, base1 is a special case
14:46:08 <mvollmer> yeah
14:46:09 <stefw> alright, that's it from me on this
14:46:14 <mvollmer> sounds really good.
14:46:20 <stefw> i wish it was simpler
14:46:26 <stefw> ... but browsers
14:46:50 <stefw> the legacy shell code has its own way of bundling that cannot be migrated to this new system, because it does not use AMD
14:46:52 <stefw> but that's fine
14:46:52 <andreasn_> I unfortunatley need to run. :( But patternfly migration is still in progress, hope to wrap up this week.
14:47:05 <stefw> andreasn_, great news
14:47:06 <mvollmer> ahh, right, sorry.
14:47:15 <mvollmer> nice!
14:47:46 <mvollmer> next?
14:47:55 <mvollmer> #topic Status of integration tests
14:48:11 <mvollmer> ok, so, it's a mess. :)
14:48:22 <mvollmer> a bit more than usual, I am afraid.
14:48:47 <mvollmer> the transition to Fedora 22 was a bit hasty, but I think we are green again on master.
14:49:09 <mvollmer> anaconda tests are running, but I don't pay much attention to them, unfortunately.
14:49:35 <mvollmer> our super trivial docker image broke docker
14:49:39 <dperpeet> mvollmer, do the anaconda tests have a timeout?
14:49:50 <stefw> what are anaconda tests?
14:49:51 <mvollmer> dperpeet, not in all places.
14:50:00 <dperpeet> stefw, the "new" tests
14:50:03 <mvollmer> hah.
14:50:04 <stefw> oh, avocado
14:50:05 <mvollmer> Avcado
14:50:06 <dperpeet> https://github.com/cockpit-project/cockpit/pull/1988 has been busy for a while
14:50:16 <dperpeet> :)
14:50:20 <mvollmer> ouch
14:50:39 <mvollmer> and we are waiting for a kernel update to unbreak udisks re raid.
14:51:08 <stefw> should we raise that issue as a fedora blocker?
14:51:25 <mvollmer> on unresolved issue is that sometimes the vms boot without any output, and testvm.py times out waiting for COCKPIT_ADDRESS etc.
14:52:07 <dperpeet> mvollmer, are you sure about the missing output? on my machines it was usually an issue of the network not yet fully ready for ssh
14:52:20 <dperpeet> https://github.com/cockpit-project/cockpit/pull/1988 adds an env variable to wait a bit
14:52:32 <stefw> dperpeet, that was the case for me too
14:52:35 <dperpeet> that fixed it on my machine when it was busy with multiple vms
14:52:37 <stefw> i never saw missing output
14:52:38 <mvollmer> dperpeet, yes, there is debug output, and unless that is buggy, too, it shows that testvm doesn't receive any output.
14:52:44 <mvollmer> it likely gets lost somewhere.
14:53:35 <mvollmer> right, the delay makes sense.
14:54:37 <dperpeet> I didn't want to hardcode it
14:54:39 <jscotka> mvollmer, dperpeet see code in https://github.com/jscotka/cockpit/blob/new_test_structure/test-avocado/lib/create_test_machine.sh#L79
14:54:43 <dperpeet> on my system I use 5s
14:55:05 <mvollmer> anyway, so the tests had a had time, but it is getting better.
14:55:47 <jscotka> mvollmer, dperpeet it is waiting until ssh will response
14:56:31 <mvollmer> next topic?
14:57:00 <stefw> yup
14:57:07 <mvollmer> #topic Open Floor
14:57:12 <mvollmer> sgallagh, ping!
14:57:27 <sgallagh> Hello!
14:57:35 <dperpeet> * getting current vm ip
14:57:45 <sgallagh> So, as you may know, this is the last week for Google Summer of Code applications.
14:58:15 <sgallagh> I proposed a Cockpit-oriented topic for this summer that we've already received one application for (and there is probably a second applicant coming this week as well)
14:59:00 <sgallagh> Specifically, this will be a task to add the Domain Controller and (time permitting) the Database Server Roles to Cockpit, following the Cockpit Project's design principles.
14:59:10 <stefw> that sounds good
14:59:13 <stefw> who will be the mentor?
14:59:18 <stefw> or mentors?
14:59:21 <sgallagh> This will require at least one person from the core team to mentor, if we accept them
14:59:23 <dperpeet> that is the question here I guess
14:59:31 <sgallagh> So I need to ask for volunteers :)
14:59:57 <dperpeet> I have some experience with mentoring students, but I've never done GSoC
15:00:01 <stefw> I'm mentoring GSoC in GNOME
15:00:05 <sgallagh> #info There are applicants to Google Summer of Code who want to work on Cockpit.
15:00:07 <stefw> so i don't think i should take on Cockpit montoring this year
15:00:16 <stefw> dperpeet, there's a whole manual that google produces
15:00:24 <stefw> i think the documentation site is down today
15:00:36 <sgallagh> https://web.archive.org/web/20140713130957/http://en.flossmanuals.net/GSoCMentoring/managing-the-mentors/ works as a backup
15:00:43 <stefw> dperpeet, flossmanuals.net/GSoCMentoring/
15:00:46 <dperpeet> since I've recently joined, I think I could help someone get started pretty quickly
15:01:03 <stefw> dperpeet, yes, and you've also landed a feature with design driven development
15:01:07 <petervo> i don't mind helping out as well
15:01:09 <stefw> so i think you're well suited
15:01:17 <dperpeet> I'll volunteer
15:01:55 <dperpeet> my master's students were always happy ;-)
15:03:04 <dperpeet> if that topic is done I would like to address my final question for today's session
15:03:27 <dperpeet> sgallagh, contact me if you need additional details from me
15:03:34 <sgallagh> dperpeet: I do, and I will :)
15:03:41 <dperpeet> thanks
15:03:42 <mvollmer> dperpeet, go aheaad.
15:03:49 <sgallagh> In particular, I need to get you signed on as a proposed mentor
15:04:00 <dperpeet> we work with virtual machines in new and old test
15:04:01 <dperpeet> s
15:04:17 <dperpeet> currently we get the ip via virsh net-dumpxml
15:04:33 <dperpeet> this has bugged for me before when the system's mac didn't match the one in the xml for some reason
15:04:45 <dperpeet> so I wanted to know if anything speaks against using virsh domiflist
15:05:04 <dperpeet> if not I'll open a pull request to that end
15:05:33 <mvollmer> dperpeet, I was thinking we could use static IPs for the avocado test machines.
15:05:53 <mvollmer> wouldn't that be simpler still?
15:06:08 <stefw> jscotka, but that wouldn't work with beaker would it? ^^
15:06:35 <dperpeet> mvollmer, I dislike static ip's because they incur manual upkeep
15:06:58 <mvollmer> well, the "run" script would assign them.
15:07:11 <mvollmer> anyway, not a strong opinion.
15:07:33 <dperpeet> I see this is more than a simple discussion, I'll write my opinion in a pull request
15:09:24 <github> [cockpit] stefwalter closed pull request #1976: tools: Update spec file from Fedora (master...fedora-spec-update) http://git.io/h6uP
15:10:02 <mvollmer> ok, that's it?
15:10:29 <stefw> seems like it
15:10:45 <mvollmer> #endmeeting