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