15:35:12 <jzb> #startmeeting Atomic SIG 15:35:12 <centbot> Meeting started Tue Nov 11 15:35:12 2014 UTC. The chair is jzb. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:35:12 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:35:27 <jzb> #chair jbrooks imcleod kbsingh walters Evolution 15:35:27 <centbot> Current chairs: Evolution imcleod jbrooks jzb kbsingh walters 15:35:44 <jzb> I suspect Evolution is busy with LISA stuff or perhaps still sleeping since it's like 6:30 there. 15:35:58 <quaid> 7:35 15:36:11 <quaid> meaning he & Johnny have probably been up for hours :) 15:36:40 <jzb> quaid: fair enough. 15:37:00 <jzb> #topic SIG Image 15:37:12 <jzb> So we pushed out an image last week on Thursday 15:37:28 <jzb> thanks to everybody that made that happen! 15:37:34 <walters> an agenda item here should be the exported RHEL sources in dist-git versus the SIG sources (which aren't in git, just SRPMs) 15:37:39 <jzb> I've noticed a few bug reports, etc. 15:37:52 <jzb> walters: thanks 15:38:08 <jzb> kbsingh: IIRC we were aiming for nightly trees soon? 15:38:42 <jbrooks> walters, are our sig sources coming from fedora currently/ 15:38:44 <jbrooks> ? 15:39:03 <imcleod> jbrooks: Nay, they are coming from another koji instance.... 15:39:37 <jbrooks> imcleod, I know the rpms come from there, but the source for those rpms... 15:39:48 <imcleod> jbrooks: Ahh. Apols. walters? 15:40:13 <kbsingh> jzb: right, as soon as hughesjr is back in hometown, we will get the tree updates plumbed into the centos7 release process. 15:40:26 <kbsingh> so there will be updates going out, but only on days when there are updates. might not be nightly. 15:40:32 <walters> there is now e.g. https://git.centos.org/summary/rpms!ostree.git 15:40:54 <jzb> kbsingh: good enough. 15:41:01 <kbsingh> within the next few weeks, we will get to a point where a rpm release is in sync with the ostree repo being updated. ie. a new kernel release is available in sync on ostree repo and yum repos. 15:41:04 <walters> which my understanding is, was exported from the RHEL AH public beta 15:41:17 <walters> should we make a new branch for in-centos development? 15:41:25 <walters> and keep that git branch for sources from RHEL? 15:41:31 <kbsingh> walters: so 15:41:44 <kbsingh> rule of the thumb is that a sig can only commit into a branch named after the sig 15:42:18 <kbsingh> and all branches that begin with c? or c?- are #protected#, those are the ones that the Core SIG ( for distro ) and RCM ( from upstream ) can push into 15:43:05 <kbsingh> walters: therefore, for the atomic sig stuff, we can adopt 'sig-atomic' as a branch name ? 15:43:20 <kbsingh> or does dist-git need a distro ver as well ? if so: sig-atomic7 ? 15:43:30 <kbsingh> that then matches the koji build tags as well 15:45:34 <imcleod> kbsingh: Are the branch naming conventions and access controls you've just described documented in the WIKI somewhere? 15:45:52 <walters> sig-atomic-7 ? 15:47:10 <kbsingh> imcleod: they should be, i believe its whats plumbed into koji as well 15:47:38 <kbsingh> when you request a build in koji, it forces the branch name to match the targetname 15:48:43 <kbsingh> one of the action points from the last buildsystem meeting yesterday was to consolidate info down into the wiki into one place, and link it from /Sources page 15:49:16 <imcleod> kbsingh: K. 15:49:20 <kbsingh> http://wiki.centos.org/Sources 15:49:26 <kbsingh> yeah, this is in the git organisation section 15:49:54 <kbsingh> could do with more word-tweeking and mentioing the koji-will-force-branch-name bit. 15:50:17 <jzb> #info Information on CentOS sources can be found under "sources" on the CentOS Wiki 15:50:25 <jzb> #link http://wiki.centos.org/Sources 15:50:53 <kbsingh> what, if any, relation are we likely to see between the c7-atomic-beta braches and what we are doing in the SIG ? 15:54:31 <jzb> kbsingh: I think this is a TBD 15:55:26 <kbsingh> ack 15:55:56 <kbsingh> not sure if this is suiteable point to address this : but a bunch of people have reported inability to use cockpit on the centos atomic image down to the socket thing 15:56:08 <kbsingh> do we know what the issue might be ? 15:56:27 <quaid> jzb: minor meetbot tip, iirc #link isn't necessary, just have a link on a line (maybe not even by itself) 15:56:40 <jbrooks> kbsingh, Dan Walsh commented about improper perms on a file 15:57:05 <jzb> quaid: Hmmm. OK 15:57:24 <jzb> quaid: I thought using #link called out links specifically 15:57:26 <kbsingh> jbrooks: i believe that was an issue in the distro docker, but should not be in the 1.3.1 upstream we are ( or should be ) using here 15:57:30 <jzb> e.g. "this link is important" 15:57:42 <Evolution> so, there are a couple things going on here that all impact 15:58:06 <Evolution> the docker package used in the image is 1.3.1, which doesn't do the socket permissions dan mentioned 15:58:25 <Evolution> that's only the rhel package that currently tries (and fails because systemd) to do socket activation permissions 15:58:56 <Evolution> however, the docker package in %pre, does try to add the docker group. For some reason that group doesn't end up in /etc/group 15:59:03 <Evolution> but the system claims it exists. 15:59:23 <Evolution> so you can't add users to the docker group to do anything useful because it's in a wierd half-on state. 15:59:31 <walters> on atomic it's /usr/lib/group 15:59:46 <walters> however see https://bugzilla.redhat.com/show_bug.cgi?id=1145355 16:00:04 <walters> er https://bugzilla.redhat.com/show_bug.cgi?id=1146250 16:00:51 <walters> basically atomic bug 16:00:58 <Evolution> okay. 16:01:35 <Evolution> lastly, dan's correct about the security of docker, *but* not having the user be able to access the socket file and only using sudo makes cockpit worthless currently 16:01:53 <Evolution> because there's no way to 'sudo' with cockpit 16:02:00 <jzb> Evolution: but if you're signed in as root? 16:02:16 <jzb> that's how I've used Cockpit so far, and I haven't run into this issue. 16:02:21 <Evolution> jzb: which is disabled in the atomic image by default 16:02:40 <jzb> Evolution: sure, but sudo su - / passwd takes care of that. 16:02:48 <jzb> but yeah 16:03:34 <Evolution> if you're logging in as root over a web service then you're simply trading one security risk for another. 16:03:47 <kbsingh> ideally, over https 16:03:51 <Evolution> ideally docker will add permissions eventually 16:04:16 <Evolution> you shouldn't have to log in as root to make it useful. 16:04:23 <jzb> Hrm. So until that happens, how should we solve this? 16:04:33 <jbrooks> And of course any user allowed to use docker can be root, anyway 16:05:28 <kbsingh> there are two things here, cockpit mostly manages the machine state as well, networking and storage and all that boo haa haa.. so its not just a docker thing 16:05:56 <kbsingh> I know there has been some progress on the super priv container model and cockpit running inside that - but dont know what the state of play is over there 16:06:11 <kbsingh> till that gets resolved, cockpit is going to need root perms on the instance 16:06:32 <kbsingh> and once that does get resolved, its still running and abusing root priv's right ? 16:07:03 <jzb> perhaps we should table this and invite stef to next week's meeting? 16:07:23 <jzb> also note that Cockpit folks have a regular IRC meeting too - they're pretty responsive / active. 16:07:30 <kbsingh> +1 16:07:41 <jzb> I'm sure they'd love to help us get the Atomic use case sorted. 16:07:55 <jzb> #action jzb invite Stef and/or other Cockpit folks to next week's SIG meeting. 16:08:41 <jzb> what other topics do we have this week? 16:08:51 <jzb> Evolution: do we have a product in bugs.centos.org yet? 16:09:07 <Evolution> jzb: not yet. I should have time today to sit down and make it 16:09:19 <jzb> Evolution: awesome, thanks! 16:09:24 <jzb> Evolution: how was the Dojo yesterday? 16:09:35 <Evolution> the speakers were amazing. attendance sucked. 16:09:47 <kbsingh> do we want this qcow2 image into EC2 as well ? if so, i can do that fairly quickly 16:10:14 <jzb> kbsingh: +1 16:10:16 <Evolution> kbsingh: I'd vote wait until we can get the group creation bug sorted out 16:11:16 <kbsingh> we have a +1 and a -1, were going to need more votes :) 16:12:12 <imcleod> kbsingh: +1 - release early and often (with notes) 16:12:27 <jbrooks> +1 16:15:08 <kbsingh> the docker perms fix should be deliverable via the repo as well, so people brining up these instances should be able to ostree upgrade and get a fix 16:15:11 <kbsingh> right ? 16:15:33 <walters> i think so yep 16:15:39 <kbsingh> ok 16:15:54 <jzb> kbsingh: Pretty sure you've addressed this before in other fora but 16:16:00 <jzb> kbsingh: what about GCE? 16:16:09 <jzb> what's our hurdle getting over there? 16:16:21 <kbsingh> GCE's harder 16:16:37 <jzb> kbsingh: technically or process-wise? Or both? 16:16:53 <kbsingh> they need contextualisation etc done in the kickstart ( it can be done via an rpm as well, but the rpm does not exist as yet ) 16:17:04 <kbsingh> I'm still working with them to get the licensing and packaging on all those bits sorted out 16:17:11 <jzb> OK 16:17:40 <jzb> kbsingh: I assume this is for all things CentOS and eventually we'll have a path for all the official and SIG CentOS stuff into GCE? 16:17:47 <walters> you mean to use their agent? 16:18:07 <kbsingh> wonder if we can get some time from agrimm to poke that a bit ? 16:18:15 <kbsingh> jzb: yea 16:18:41 <kbsingh> walters: their agent, and their cloud-tools components 16:19:26 <agrimm> kbsingh, ahhhh, that conversation again... 16:19:36 <agrimm> wondered how long it would take for that to come up 16:19:50 <kbsingh> agrimm: i only say this since you enjoy such pain, repeatedly, repeatedly 16:20:42 <walters> i'm not a fan of google's agent, even if it is a better experience on gce at the moment 16:20:58 <walters> better to improve cloud-init 16:21:12 <imcleod> walters: I keep hearing that and cloud-init continues to not improve.... :-( 16:21:24 <imcleod> Not that I've done anything to help.... 16:21:36 <imcleod> Are we aware of any attempts to RPM-ify the google agents and get them into Fedora/EPEL? 16:22:08 <agrimm> imcleod, yes 16:22:10 <kbsingh> imcleod: we've done some work in the centos cloud instance sig... but its mostly blocked on people/time 16:22:25 <kbsingh> I know that there is some effort in fedora lands as well - agrimm might be to blame for some of it 16:22:31 <agrimm> imcleod, in fact, there have been at least two such attempts, but I never saw a review request. there is a github repo for one of them 16:22:56 <imcleod> agrimm: OK. As it happens, I'm just finishing up adding the Rackspace python agent to Fedora. I enjoy the pain of package review. 16:23:04 <kbsingh> there are some buildtime constraints as well.. 16:23:06 <imcleod> agrimm: Actually that's a lie. I don't enjoy it but I like the results. 16:23:26 <agrimm> imcleod, https://github.com/vaijab/google-compute-daemon-rpm 16:23:37 <kbsingh> w.r.t cloud-init, i think its a great time to fork it for something a lot lighter and better maintained with better plugin support. 16:23:38 <agrimm> it's old, but there it is 16:23:41 <jzb> we're getting close to 1 hr 16:23:48 <kbsingh> ideally, not needing a bazillion python deps either 16:23:48 <jzb> I think imcleod had a topic yet? 16:24:17 <imcleod> jzb: Yeah. Very quick. I need a public place to host Anaconda test install trees and Atomic composes. 16:24:23 <imcleod> To test Atomic image building on the CBS. 16:24:29 <kbsingh> imcleod: agrimm: I'll invite you guys to the 23rd Nov Cloud Instance sIG meeting, two google guys should be there as well, we can workout a plan 16:24:41 <imcleod> And, yes, I owe a mail about the image building feature on the CBS to centos-devel. 16:25:03 <imcleod> So, where can I host about 1-2 GB of "work in progress" not-official, only for testing Anaconda and Atomic content in public? 16:25:23 <imcleod> Is there a SIG-affiliated space for this? A general CentOS hosting ground similar to fedorapeople/people.redhat? 16:25:30 <kbsingh> no 16:25:50 <kbsingh> there is a conversation about having a testing/ or devel/ like sectino in buildlogs.centos.org 16:26:04 <kbsingh> alternatively, exposing the cbs content via the cbs site would / should work right ? 16:26:08 <kbsingh> like the /repos does now 16:26:49 <imcleod> kbsingh: That would work for RPMS, but not for an Anaconda install tree or rpm-ostree compose. 16:26:52 <imcleod> kbsingh: AFAIK.... 16:26:54 <kbsingh> imcleod: also, the image should be a single file, with no deps - can people not just consume that from the koji url ? 16:27:18 <imcleod> kbsingh: This is about the content needed to build the image. I have a lorax-generated install tree and my own test rpm-ostree composes. 16:27:34 <imcleod> That content is referenced by the image-build command given to the CBS. 16:27:43 <imcleod> At which point, yes, a single file is produced and hosted on the CBS koji instance. 16:27:49 <kbsingh> lets work this on the centos-devel list 16:27:57 <imcleod> kbsingh: Roger. 16:28:11 <imcleod> kbsingh: I'll announce the image-build stuff and then start a thread about Atomic testing specifically. 16:28:11 <kbsingh> the live media content would be similar ? 16:28:25 <imcleod> kbsingh: Unsure. Need context. 16:28:37 <kbsingh> what all image types can the koji image builder build 16:28:37 <imcleod> kbsingh: Ahh. You mean a live CD for Atomic? Quite possibly. 16:29:12 <imcleod> kbsingh: ATM it cannot build live media directly. I can do so with the Indirection plugin to Factory, but that requires a fresher koji. alphacc is working on that. 16:29:23 <imcleod> kbsingh: Pending prioritization of the auth setup as discussed elsewhere. 16:29:27 <kbsingh> yeah 16:29:54 <kbsingh> ok, for some reason i thought that we'd be good to go for live/docker/vm/atomic etc in one shot - lets work the details out on the -devel list, there is going to be much excitement around this 16:30:13 <imcleod> Everything except live. 16:30:40 <imcleod> Live is a much more complicated transformation of the input image. All the others are supported internally in Factory. 16:30:58 <jzb> #action imcleod carry discussion about Koji builds to centos-devel 16:31:01 <jzb> imcleod: OK ^^ ? 16:31:06 <imcleod> jzb: Yup. 16:31:26 <jzb> I know a lot of folks have another meeting Right Now (TM) 16:31:33 <jzb> any other immediate issues/ 16:31:34 <jzb> ? 16:32:09 * jzb looks around wondering if nobody has issues or if they're only typing slowly 16:32:51 <jzb> OK, calling it - have a good week all see you same Bat-Time and same Bat-Channel next week 16:32:56 <jzb> #endmeeting