13:04:52 #startmeeting 13:04:52 Meeting started Mon Jun 15 13:04:52 2015 UTC. The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:04:52 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:04:58 what do we have today? 13:05:01 #agenda 13:05:27 * new patternfly 1.3.0 13:06:28 * fedora 22+n vs rawhide as main dev environment 13:06:29 andreasn: #topic 13:06:37 oh, crap 13:06:42 #topic agenda 13:06:48 did that work? 13:07:06 andreasn: zodbot isn't opped, so it won't change the /topic, but it will be in the notes properly 13:07:16 good 13:08:38 anything else? 13:08:39 I'd like to get a check-in from Shad0w_Crux during the meeting today 13:09:24 lets put that last 13:09:37 #topic New Patternfly 1.3.0 13:09:59 * test images, the next steps 13:10:03 upps 13:10:19 new patternfly version is merged. I think we hammered out the regression, but watch out for bugs caused by it 13:10:52 that's it 13:11:13 #topic Fedora version for main development enviorment 13:11:43 ok, so I was trying to create new rawhide images today 13:11:53 * backwards compatibility 13:12:00 but it fails in a weird way 13:12:13 and now I think we should run tests on rawhide only "for information" 13:12:42 we did find some important bugs already, and one is fixed 13:13:00 and I guess it would be really good to keep running our tests 13:13:07 mvollmer: What is failing on Rawhide? 13:13:13 but we can't afford to wait for fixes, I am afraid. 13:13:22 sgallagh, I'll file a bug soon. 13:13:24 (If there are issues with Rawhide not composing properly, please escalate them to me as soon as you see them) 13:13:50 https://github.com/cockpit-project/cockpit/pull/2427#issuecomment-112048154 13:13:53 sgallagh, ^^ 13:14:52 so, I think the new virt-install method for making test images is really nice and we should keep doing this, and report bugs. 13:14:55 Thanks 13:15:34 but keep using F22 for the 'gating' tests, until f23 alpha or so. 13:15:55 that means we need to get storaged 2 into our f22 images, from the copr. 13:16:05 which I think is totally ok. 13:16:49 is the failing bit for atomic rawhide? or are we using ostree for our image creation now? 13:16:56 * mvollmer sometimes wants to take a few month off just to work on increasing our end-to-end test coverage... 13:17:19 regular fedora rawhide is failing 13:17:33 i think we test fedora 22 atomic 13:18:08 ok, i just saw ostree in the traceback there and was wondering 13:18:27 petervo, where did you see that? 13:18:32 mvollmer: That's what you hire an intern for... 13:18:46 it's just the message 13:18:48 :) 13:19:11 petervo, in https://github.com/cockpit-project/cockpit/pull/2427#issuecomment-112048154 ? 13:19:22 yeah "Specified switch root path /sysroot does not seem to be an OS tree." 13:19:31 ahh, now I see it too 13:19:36 but it probably doesn't mean os tree 13:19:43 no, that's not related to ostree-the-project 13:19:46 yeah 13:19:56 just a filesystem 13:20:28 ok, so I'll make a pull request to put storaged into our f22 images. 13:20:34 should be harmless. 13:20:57 we don't need to merge the new storage code or remove udisks for that. 13:21:05 eot. 13:21:07 :) 13:21:17 all right 13:21:19 thanks 13:21:36 test images now? 13:21:43 or was that part of the last topic? 13:21:57 no, I left that out. :) 13:22:01 #topic test images, the next steps 13:22:06 ok 13:22:14 so we now use virt-install to make f22 images 13:22:21 but that doesn't make much sense 13:22:31 we can use virt-builder to get the same result, faster 13:22:50 I have this basically working here 13:23:13 virt-builder is very powerful, and it can do everything that testvm does, probably 13:23:13 nice! 13:23:25 but we can leave that to a later refactoring 13:23:43 Related question: Are there any plans to put together (and maintain) a Vagrantfile for Cockpit for new developers? 13:23:46 i think we are on a good road here to get rid of all the crazy stuff I did as a kid 13:23:59 three years ago when I was young and scared of virsh etc 13:24:17 sgallagh, not that I know of. 13:24:48 so one thing is to use virt-builder for f22. 13:25:05 the other thing is to redo our image versioning 13:25:14 Might be very useful. Getting the initial dev environment set up can be tricky. I'll have a look (I just built one for SSSD) 13:25:30 right now images have no version, and we update them manually, with all the chaos that comes with that 13:26:23 the basic idea is to add some kind of tag or version to the images, and the sources specify which tag/version they want to use for which flavor. 13:27:10 it's probably quite straightforward, but we might accumulate a lot of images and we need to have some sort of garbage collection for them 13:27:16 also for people that download them 13:28:02 with that in place, we can have automatic daily or weekly updates to the images 13:28:20 or rather, automatic tests whether something has regressed 13:29:21 in any case, the end result should be such that simply merging a pull request is enough to change the images that master uses. 13:29:34 so that anyone can do this easily. 13:30:16 hubbot can do the garbage collection on the CI server, and people might need to run some script locally. 13:30:52 any more on that topic? 13:30:59 no, i think not. 13:31:11 all right, next then 13:31:17 # topic backwards compatibility 13:32:40 basic point is adding the owned notification feature half broke backwards compatibility 13:33:17 so you can't add a newer host to an older one 13:33:59 so never add 0.61 to, say, 0.56 13:34:02 in other words the main cockpit instance that you connect to has to be newer than the servers added to it 13:34:11 right 13:34:19 Ouch 13:34:35 though i'm not sure about the exact versions 13:34:44 That will be difficult at best in a corporate environment 13:36:02 because we already have releases with the change in, i'm not sure what can be done at this point unless we want to backport this PR https://github.com/cockpit-project/cockpit/pull/2425 13:36:05 another dimension for our test matrix... 13:36:07 to earlier versions 13:38:09 silence... :-) 13:38:18 Sorry, multiple conversations 13:38:33 is this in a release already? 13:38:36 petervo: Those releases, they are stable in Fedora? 13:38:37 so, in general, we want to be compatible now, and this is just us learning what that means. 13:38:38 yes 13:38:39 Or just upstream? 13:39:13 and we should fix the bugs as we find them, in all released versions. 13:39:47 petervo: I'm mostly concerned about RHEL/CentOS 13:40:02 so rhel doesn't support multiple hosts 13:40:04 atm 13:40:14 regarding the "owned" 13:40:18 centos i don't know what version we are at 13:40:22 petervo: Define "support"? 13:40:38 the feature is missing 13:41:15 ok 13:42:31 I guess we need to decide what our compatibility guarantee means 13:42:57 Are we guaranteeing backwards and forwards compatibility or just backwards compatibility? 13:43:29 both 13:44:07 regarding the "owned" message, can we avoid sending it when the peer will choke on it? 13:44:19 we would need a way to detect that 13:44:43 and there isn't any obvious way, I guess? 13:45:03 right now the js doesn't inform the channel about it's version of anything 13:45:19 should we have explicit guidelines for how to handle this? 13:45:29 we could add that, but of course that wouldn't work for old versions anyways 13:45:42 like "be conservative in what you send and liberal in what you accept"? 13:45:53 yeah 13:46:21 would be good to write this down 13:46:36 Given that the only systems deploying Cockpit right now are Fedora (which is easy to rebase), I'd say let's eat this one for now, issue updates to the released Fedoras and do better in the future. 13:46:39 Bugs happen. 13:47:44 instead of ignoring unknown messages, the peer could report back that it was unknown, without closing the channel. 13:48:00 hmm, no I am not making sense. 13:48:26 this is the bridge talking to JS, not two JS components talking to each other. 13:49:02 yes 13:49:40 ok, action for me to write down some guidelines? 13:49:49 or should we let stef do that? 13:50:21 and action for this specific bug is to fix it in all released versions? does that make sense? 13:50:50 i'm not sure how to define released versions 13:50:58 but we can talk about that offline 13:51:12 whatever is in Fedora, rhel, and centos. 13:52:16 next topic? 13:52:30 I think we're out of topics actually 13:52:35 or did I miss any? 13:52:41 GSoC 13:52:44 oh, tru 13:52:47 true 13:52:51 #topic GSoC 13:53:01 Shad0w_Crux: are you around? 13:53:01 Shad0W_Crux, you around? 13:53:07 sorry, jinx 13:53:15 Yes. 13:53:21 [cockpit] mvollmer opened pull request #2428: test: Use virt-builder to create Fedora 22 images. (master...test-fedora-builder) http://git.io/vLkdj 13:53:21 (sort of) 13:53:41 how are things going with the project? 13:53:45 Update: For this week I'm working at my university's summer camp so I won't be available for today's meeting. Last week sgallagh had asked me start putting everything up on my github account and make commits so everyone could start keeping track of the progress I've made. I figured out how to sync my fork with the main cockpit branch and now have a dummy page that can navigated to. For this week I'm going to work at adding in some of basic logic 13:53:46 (information and buttons to add roles) to the page. 13:54:00 Question 1: I'm not sure how to create a pull request with the [WIP] tag. Does this mean I need to try to merge my branch with the master branch some how? 13:54:00 Question 2: Although it's not needed for my part, what's the best way keeping up with something that changes as rapidly as cockpit if someone were working on the major components? (Branch is X number of commits behind, pull down new changes every time you work on the project or finished your segment and then merge?) 13:54:24 Shad0w_Crux: For Q1, as soon as you're free today, ping me in here and I'll walk you through it 13:55:08 Q2 sounds like rebasing I think 13:55:20 Q2: That's usually a personal decision. You'll need to do the merge before you send the final pull request (the one that may get committed) 13:56:18 (I personally try to rebase constantly, since it reduces the delta at the end, but that can mean a lot of churn throughout the process) 13:58:11 dperpeet is great at these things, he helped me a lot with git 13:59:40 Shad0w_Crux: sounds good. Good to hear things are moving forward 14:00:09 I guess that was it, unless anyone have any other topic 14:00:44 Shad0w_Crux, you have a link to your github fork? 14:01:37 https://github.com/Shad0wCrux/cockpit 14:02:56 tx 14:04:37 #endmeeting