20:02:17 <lifeless> #startmeeting tripleo
20:02:18 <openstack> Meeting started Mon May 20 20:02:17 2013 UTC.  The chair is lifeless. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:21 <openstack> The meeting name has been set to 'tripleo'
20:02:36 <lifeless> #topic bugs
20:03:11 <lifeless> #link https://bugs.launchpad.net/tripleo/
20:03:42 <lifeless> I think ng may have tackled bug 1178112
20:03:43 <uvirtbot> Launchpad bug 1178112 in tripleo "baremetal kernel boot options make console inaccessible on ILO environments" [Critical,Triaged] https://launchpad.net/bugs/1178112
20:03:51 <devananda> \o
20:04:26 <lifeless> https://bugs.launchpad.net/tripleo/+bug/1178378 was stale, devananda got it already
20:04:28 <uvirtbot> Launchpad bug 1178378 in tripleo "confused baremetal instance thinks its off, is clearly operational" [Critical,Fix committed]
20:06:10 <lifeless> spamaps has both https://bugs.launchpad.net/tripleo/+bug/1180239 and https://bugs.launchpad.net/tripleo/+bug/1180928 - marked inprogress
20:06:12 <uvirtbot> Launchpad bug 1180239 in tripleo "nova-common deb package is installed by nova element" [Critical,In progress]
20:06:15 <lifeless> anyone know their actual status ?
20:06:54 <lifeless> 928 is fixed
20:06:56 <echohead> nova-common issue was fixed by SpamapS' novnc change which i saw land yesterday.
20:07:10 <echohead> or a couple days ago
20:08:12 <lifeless> I'm investigating https://bugs.launchpad.net/tripleo/+bug/1182200
20:08:13 <uvirtbot> Launchpad bug 1182200 in tripleo "openvswitch datapath module not build/building on quantal" [Critical,Triaged]
20:08:21 <lifeless> which breaks the GRE quantum config
20:09:14 <lifeless> and I have a workaround now - yay
20:09:36 <lifeless> anyone have questions on the high bugs; what things to pick up next etc?
20:09:44 <lifeless> Do we need more oversight/guidance?
20:10:53 * lifeless takes silence as no
20:11:06 <lifeless> ok
20:11:12 <lifeless> #topic grizzly rack POC
20:11:28 <lifeless> current status - we have the undercloud 'there' and are working the overcloud
20:11:36 <lifeless> there are three challenges as I understand it.
20:12:05 <lifeless> firstly we have to get a correct config of all the components
20:12:10 <lifeless> we have to fold that into the automation
20:12:17 <lifeless> and we have to load/scale test it
20:12:38 <lifeless> I'm currently driving through manual configuration for quantum etc in our test rack environment.
20:12:46 <lifeless> Spinning out bugs as before ;>
20:13:58 <lifeless> Spamaps and ghe and ng and cody-somerville are working on the automation, fixing glitches and generally making it more correct / robust
20:14:09 <lifeless> the review queue has been awesome :)
20:14:56 <GheRivero> :)
20:15:03 <lifeless> I have arranged for the wonderful HPCS qa folk to run the same load-test they run internally against our POC endpoint once we're ready; we should also run tempest and cloud-cafe, but they, while good at correctness, are not so hot on scale/load.
20:15:31 <lifeless> questions / suggestions about the POC? We've one week left to knock it out of the ballpark, to quote mordred
20:16:52 <mordred> yup
20:17:16 <mordred> hunch tells me the sooner we can get various people hammering the overcloud with testing things, the better
20:17:22 <lifeless> right
20:17:34 <mordred> otoh, I'm often wrong
20:17:35 <lifeless> ok, silence still..
20:17:42 <lifeless> #topic open discussion
20:18:37 <dkehn> cue crickets
20:18:42 <mordred> we had a discussion this morning that wandered a bit - but was around the idea of "how do we get the source code that's an input to DIB into the right places"
20:18:58 <mordred> it might be nice to tie that off so that any further work in the direction has, well, direction
20:19:39 <mordred> Spamaps (who seems missing) suggested perhaps an element that does the cloning to a local location that other elements can expect to consume?
20:20:03 <mordred> that was other workflows could replace that element with a different element which puts said repos into the same locations or something
20:20:07 <lifeless> so IIRC the previous review, it forced everything to one server
20:20:13 <lifeless> and we're heterogenous
20:20:42 <lifeless> I agree that having an controlling element sounds like a good structure
20:20:45 <mordred> I think the thing is that we want to decouple getting source code to the build machien from the process of using that source code to produce the image
20:20:46 <echohead> mordred: is the primary concern to make dib pick up specific revs?
20:20:49 <lifeless> perhaps a logic one + data one.
20:20:52 <mordred> echohead: that is one of them
20:20:55 <mordred> the other is resilience
20:20:57 <mordred> and caching
20:21:02 <lifeless> reliability in the gate.
20:21:25 <mordred> and - there is the issue that the gate already has an interface, and if we can attach to it, it'll be less re-engineering work
20:21:40 <mordred> but - not if that breaks our design
20:21:45 <lifeless> I will say up front that we shouldn't clone stuff into the image we don't need.
20:21:53 <mordred> absolutely
20:22:07 <echohead> shortest path seems like it would be to provide an interface for copying paths into the chroot.
20:22:20 <lifeless> so, if I were designing this now, I would do something like: have a helper API that takes a git url and returns a git url
20:22:23 <echohead> then the elements could be tweaked to say - oh there's already code in /opt/stack/nova - i'll just use that.
20:22:30 <lifeless> define it in the core to be the identity function
20:22:40 <lifeless> define it in the gate to be a sed onto gerrit.
20:22:51 <mordred> lifeless: sed into containing host filesystem
20:23:21 <lifeless> mordred: can't do that; you're in a chroot when the code executes. Can sed it to localhost://
20:23:26 <mordred> that's the problem
20:23:38 <mordred> we've got an input blocker issue here
20:23:41 <lifeless> mordred: spin up a localhost bound anon git server before calling d-i-c
20:24:00 <lifeless> mordred: I don't understand
20:24:04 <mordred> great
20:24:22 <mordred> if I grab those repos, and then set their heads to specific refspecs
20:24:37 <mordred> I'm assuming that a git server exported to the image build will pick up the right rev?
20:24:46 <lifeless> yes
20:24:54 <mordred> great. sounds like a potential solution
20:25:22 <lifeless> we need to add in the git-url-map identity element and call it where we use git
20:25:27 <lifeless> or even wrap git itself.
20:25:31 <lifeless> thats impl details.
20:25:34 <mordred> yah. it is
20:25:53 <mordred> although I do want to bring up that when I hear "wrap git itself" I want to check in to make sure we'r enot growing a frakenstein
20:26:08 <lifeless> The main concern I had was that urls for e.g. nagios shouldn't suddenly get mangled, which the previous 'all urls are constructed from one environment variable' approach would have done.
20:26:22 <lifeless> monsters R us.
20:26:25 <mordred> we're pulling nagios from git?
20:26:33 <lifeless> mordred: *we* are not.
20:26:42 <mordred> ++ k
20:26:45 <mordred> gotcha
20:26:45 <lifeless> mordred: other deployers may. The infra needs to not mess those folk up.
20:26:58 <mordred> right. which is why I'm a little concerned about "wrap git itself"
20:27:11 <mordred> because I don't want to make people learn a shell meta language to be able to write elements successfully
20:27:19 <mordred> since then we've re-impled chef/puppet in shell
20:27:31 <lifeless> mordred: Right, though as an aside that might not be a bad thing.
20:27:38 <echohead> why not just provide an interface for copying files/directories from the image-build host into the chroot?  this would be more general than a git-specific thing.
20:27:49 <mordred> echohead: ++
20:27:57 <echohead> then you could just specify 'copy these gate-cloned' repos into the chroot at this path.
20:28:06 <lifeless> echohead: that might be good too, but imagine what os-install-svc would look like then ?
20:28:07 <echohead> quote fail
20:28:40 <echohead> lifeless: if directory exists, no-op, else clone.
20:28:50 <mordred> os-install-svc /opt/source/nova ?
20:28:55 <mordred> or that
20:29:00 * mordred shuts up and lets echohead talk
20:29:41 <mordred> I like that - since it allows os-instal-svc to work for people who aren't pre-caching, and also allows us to pre-populate a build env in more complex setups
20:30:08 <echohead> and that way gate-specific concerns would not not be spread through elements/git-magic - they would be cli args/ inputs to the way gate calls dib.
20:30:11 <lifeless> point is it now knows how to do git, so then it would need to know how to evaluate in-image paths, host-machine paths, and git
20:30:17 <lifeless> *and*
20:30:31 <lifeless> there are a huge raft of concerns about letting images ask for any arbitrary file from the host machine
20:30:35 <lifeless> so I'm going to say 'no'.
20:30:51 <lifeless> I am certain it would end up substantially more complex.
20:30:54 <mordred> who said anything about letting images ask for arbitrary files from the host machine?
20:30:56 <echohead> the images wouldn't ask. the person who invokes dib would specify 'put these files in the image'
20:31:05 <mordred> yup
20:31:23 <lifeless> ok, then I'm confused, because thats what elements already do.
20:31:34 <echohead> yes, local-config does this.
20:31:41 <echohead> i'm just proposing a general interface for it.
20:32:01 <mordred> "copy files into image" + if ! -d $dest ; then git clone $source $dest ; fi seems quite easy
20:32:35 <lifeless> Is there a bug tracking the gate's needs?
20:32:48 <lifeless> or bugs
20:35:23 <mordred> no. but I pasted the links of the interface points in channel earlier today in a conversations about toci
20:35:28 <lifeless> ok
20:35:35 <lifeless> so, this week is not the week for this.
20:35:43 <lifeless> Shallow or not, we have a deadline.
20:35:58 <lifeless> Please make a bug - include those links.
20:35:59 <mordred> well, not for the HP tripleo team - but pleia2 and dprince seemed to both be sitting in aplace where they could hack on it
20:36:02 <mordred> will do
20:36:12 <lifeless> #action mordred to make a bug about gate needs
20:36:30 <lifeless> mordred: I will make sure we don't block them on it.
20:36:50 <lifeless> mordred: I need to poke around some of the guts of our existing scripts some more.
20:37:01 <lifeless> echohead: btw when I say existing elements, what I mean is
20:38:40 <lifeless> 'mkdir elements/inject; cp -a $path elements/inject/payload; echo '#!/bin/bash\ncp $(dirname)/../payload/* /' > elements/inject/pre-install.d/99-inject
20:40:06 <lifeless> ok, any other business?
20:42:38 <lifeless> #endmeeting