13:04:52 <andreasn> #startmeeting
13:04:52 <zodbot> Meeting started Mon Jun 15 13:04:52 2015 UTC.  The chair is andreasn. Information about MeetBot at
13:04:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:04:58 <andreasn> what do we have today?
13:05:01 <andreasn> #agenda
13:05:27 <andreasn> * new patternfly 1.3.0
13:06:28 <mvollmer> * fedora 22+n vs rawhide as main dev environment
13:06:29 <sgallagh> andreasn: #topic
13:06:37 <andreasn> oh, crap
13:06:42 <andreasn> #topic agenda
13:06:48 <andreasn> did that work?
13:07:06 <sgallagh> andreasn: zodbot isn't opped, so it won't change the /topic, but it will be in the notes properly
13:07:16 <andreasn> good
13:08:38 <mvollmer> anything else?
13:08:39 <sgallagh> I'd like to get a check-in from Shad0w_Crux during the meeting today
13:09:24 <andreasn> lets put that last
13:09:37 <andreasn> #topic New Patternfly 1.3.0
13:09:59 <mvollmer> * test images, the next steps
13:10:03 <mvollmer> upps
13:10:19 <andreasn> new patternfly version is merged. I think we hammered out the regression, but watch out for bugs caused by it
13:10:52 <andreasn> that's it
13:11:13 <andreasn> #topic Fedora version for main development enviorment
13:11:43 <mvollmer> ok, so I was trying to create new rawhide images today
13:11:53 <petervo> * backwards compatibility
13:12:00 <mvollmer> but it fails in a weird way
13:12:13 <mvollmer> and now I think we should run tests on rawhide only "for information"
13:12:42 <mvollmer> we did find some important bugs already, and one is fixed
13:13:00 <mvollmer> and I guess it would be really good to keep running our tests
13:13:07 <sgallagh> mvollmer: What is failing on Rawhide?
13:13:13 <mvollmer> but we can't afford to wait for fixes, I am afraid.
13:13:22 <mvollmer> sgallagh, I'll file a bug soon.
13:13:24 <sgallagh> (If there are issues with Rawhide not composing properly, please escalate them to me as soon as you see them)
13:13:50 <mvollmer>
13:13:53 <mvollmer> sgallagh, ^^
13:14:52 <mvollmer> 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 <sgallagh> Thanks
13:15:34 <mvollmer> but keep using F22 for the 'gating' tests, until f23 alpha or so.
13:15:55 <mvollmer> that means we need to get storaged 2 into our f22 images, from the copr.
13:16:05 <mvollmer> which I think is totally ok.
13:16:49 <petervo> 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 <mvollmer> regular fedora rawhide is failing
13:17:33 <mvollmer> i think we test fedora 22 atomic
13:18:08 <petervo> ok, i just saw ostree in the traceback there and was wondering
13:18:27 <mvollmer> petervo, where did you see that?
13:18:32 <sgallagh> mvollmer: That's what you hire an intern for...
13:18:46 <petervo> it's just the message
13:18:48 <mvollmer> :)
13:19:11 <mvollmer> petervo, in ?
13:19:22 <petervo> yeah "Specified switch root path /sysroot does not seem to be an OS tree."
13:19:31 <mvollmer> ahh, now I see it too
13:19:36 <petervo> but it probably doesn't mean os tree
13:19:43 <mvollmer> no, that's not related to ostree-the-project
13:19:46 <petervo> yeah
13:19:56 <mvollmer> just a filesystem
13:20:28 <mvollmer> ok, so I'll make a pull request to put storaged into our f22 images.
13:20:34 <mvollmer> should be harmless.
13:20:57 <mvollmer> we don't need to merge the new storage code or remove udisks for that.
13:21:05 <mvollmer> eot.
13:21:07 <mvollmer> :)
13:21:17 <andreasn> all right
13:21:19 <andreasn> thanks
13:21:36 <andreasn> test images now?
13:21:43 <andreasn> or was that part of the last topic?
13:21:57 <mvollmer> no, I left that out. :)
13:22:01 <andreasn> #topic test images, the next steps
13:22:06 <mvollmer> ok
13:22:14 <mvollmer> so we now use virt-install to make f22 images
13:22:21 <mvollmer> but that doesn't make much sense
13:22:31 <mvollmer> we can use virt-builder to get the same result, faster
13:22:50 <mvollmer> I have this basically working here
13:23:13 <mvollmer> virt-builder is very powerful, and it can do everything that testvm does, probably
13:23:13 <andreasn> nice!
13:23:25 <mvollmer> but we can leave that to a later refactoring
13:23:43 <sgallagh> Related question: Are there any plans to put together (and maintain) a Vagrantfile for Cockpit for new developers?
13:23:46 <mvollmer> 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 <mvollmer> three years ago when I was young and scared of virsh etc
13:24:17 <mvollmer> sgallagh, not that I know of.
13:24:48 <mvollmer> so one thing is to use virt-builder for f22.
13:25:05 <mvollmer> the other thing is to redo our image versioning
13:25:14 <sgallagh> 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 <mvollmer> right now images have no version, and we update them manually, with all the chaos that comes with that
13:26:23 <mvollmer> 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 <mvollmer> 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 <mvollmer> also for people that download them
13:28:02 <mvollmer> with that in place, we can have automatic daily or weekly updates to the images
13:28:20 <mvollmer> or rather, automatic tests whether something has regressed
13:29:21 <mvollmer> 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 <mvollmer> so that anyone can do this easily.
13:30:16 <mvollmer> hubbot can do the garbage collection on the CI server, and people might need to run some script locally.
13:30:52 <andreasn> any more on that topic?
13:30:59 <mvollmer> no, i think not.
13:31:11 <andreasn> all right, next then
13:31:17 <andreasn> # topic backwards compatibility
13:32:40 <petervo> basic point is adding the owned notification feature half broke backwards compatibility
13:33:17 <petervo> so you can't add a newer host to an older one
13:33:59 <andreasn> so never add 0.61 to, say, 0.56
13:34:02 <petervo> in other words the main cockpit instance that you connect to has to be newer than the servers added to it
13:34:11 <petervo> right
13:34:19 <sgallagh> Ouch
13:34:35 <petervo> though i'm not sure about the exact versions
13:34:44 <sgallagh> That will be difficult at best in a corporate environment
13:36:02 <petervo> 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
13:36:05 <mvollmer> another dimension for our test matrix...
13:36:07 <petervo> to earlier versions
13:38:09 <mvollmer> silence... :-)
13:38:18 <sgallagh> Sorry, multiple conversations
13:38:33 <andreasn> is this in a release already?
13:38:36 <sgallagh> petervo: Those releases, they are stable in Fedora?
13:38:37 <mvollmer> so, in general, we want to be compatible now, and this is just us learning what that means.
13:38:38 <petervo> yes
13:38:39 <sgallagh> Or just upstream?
13:39:13 <mvollmer> and we should fix the bugs as we find them, in all released versions.
13:39:47 <sgallagh> petervo: I'm mostly concerned about RHEL/CentOS
13:40:02 <petervo> so rhel doesn't support multiple hosts
13:40:04 <petervo> atm
13:40:14 <mvollmer> regarding the "owned"
13:40:18 <petervo> centos i don't know what version we are at
13:40:22 <sgallagh> petervo: Define "support"?
13:40:38 <petervo> the feature is missing
13:41:15 <sgallagh> ok
13:42:31 <sgallagh> I guess we need to decide what our compatibility guarantee means
13:42:57 <sgallagh> Are we guaranteeing backwards and forwards compatibility or just backwards compatibility?
13:43:29 <mvollmer> both
13:44:07 <mvollmer> regarding the "owned" message, can we avoid sending it when the peer will choke on it?
13:44:19 <petervo> we would need a way to detect that
13:44:43 <mvollmer> and there isn't any obvious way, I guess?
13:45:03 <petervo> right now the js doesn't inform the channel about it's version of anything
13:45:19 <mvollmer> should we have explicit guidelines for how to handle this?
13:45:29 <petervo> we could add that, but of course that wouldn't work for old versions anyways
13:45:42 <mvollmer> like "be conservative in what you send and liberal in what you accept"?
13:45:53 <petervo> yeah
13:46:21 <mvollmer> would be good to write this down
13:46:36 <sgallagh> 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 <sgallagh> Bugs happen.
13:47:44 <mvollmer> instead of ignoring unknown messages, the peer could report back that it was unknown, without closing the channel.
13:48:00 <mvollmer> hmm, no I am not making sense.
13:48:26 <mvollmer> this is the bridge talking to JS, not two JS components talking to each other.
13:49:02 <petervo> yes
13:49:40 <mvollmer> ok, action for me to write down some guidelines?
13:49:49 <mvollmer> or should we let stef do that?
13:50:21 <mvollmer> and action for this specific bug is to fix it in all released versions? does that make sense?
13:50:50 <petervo> i'm not sure how to define released versions
13:50:58 <petervo> but we can talk about that offline
13:51:12 <mvollmer> whatever is in Fedora, rhel, and centos.
13:52:16 <petervo> next topic?
13:52:30 <andreasn> I think we're out of topics actually
13:52:35 <andreasn> or did I miss any?
13:52:41 <mvollmer> GSoC
13:52:44 <andreasn> oh, tru
13:52:47 <andreasn> true
13:52:51 <andreasn> #topic GSoC
13:53:01 <andreasn> Shad0w_Crux: are you around?
13:53:01 <petervo> Shad0W_Crux, you around?
13:53:07 <andreasn> sorry, jinx
13:53:15 <Shad0w_Crux> Yes.
13:53:21 <github> [cockpit] mvollmer opened pull request #2428: test: Use virt-builder to create Fedora 22 images. (master...test-fedora-builder)
13:53:21 <Shad0w_Crux> (sort of)
13:53:41 <andreasn> how are things going with the project?
13:53:45 <Shad0w_Crux> 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 <Shad0w_Crux> (information and buttons to add roles) to the page.
13:54:00 <Shad0w_Crux> 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 <Shad0w_Crux> 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 <sgallagh> 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 <andreasn> Q2 sounds like rebasing I think
13:55:20 <sgallagh> 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 <sgallagh> (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 <andreasn> dperpeet is great at these things, he helped me a lot with git
13:59:40 <andreasn> Shad0w_Crux: sounds good. Good to hear things are moving forward
14:00:09 <andreasn> I guess that was it, unless anyone have any other topic
14:00:44 <petervo> Shad0w_Crux, you have a link to your github fork?
14:01:37 <Shad0w_Crux>
14:02:56 <petervo> tx
14:04:37 <andreasn> #endmeeting