19:02:04 <lifeless> #startmeeting tripleo
19:02:05 <openstack> Meeting started Tue Nov 26 19:02:04 2013 UTC and is due to finish in 60 minutes.  The chair is lifeless. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:07 <lifeless> #topic agenda
19:02:09 <openstack> The meeting name has been set to 'tripleo'
19:02:13 <lifeless> bugs
19:02:13 <lifeless> reviews
19:02:13 <lifeless> Projects needing releases
19:02:13 <lifeless> CD Cloud status
19:02:13 <lifeless> CI virtualized testing progress
19:02:15 <lifeless> Insert one-off agenda items here
19:02:18 <lifeless> Blueprints and design planning / summit wrap-up
19:02:20 <lifeless> open discussion
19:02:23 <lifeless> #topic bugs
19:02:25 <jog0> o/
19:02:25 <lifeless> #link https://bugs.launchpad.net/tripleo/
19:02:26 <bnemec> o/
19:02:28 <lifeless> #link https://bugs.launchpad.net/diskimage-builder/
19:02:30 <lifeless> #link https://bugs.launchpad.net/os-refresh-config
19:02:33 <lifeless> #link https://bugs.launchpad.net/os-apply-config
19:02:35 <lifeless> #link https://bugs.launchpad.net/os-collect-config
19:02:38 <lifeless> #link https://bugs.launchpad.net/tuskar
19:02:40 <lifeless> #link https://bugs.launchpad.net/tuskar-ui
19:02:43 <lifeless> #link https://bugs.launchpad.net/python-tuskarclient
19:03:21 <lifeless> bug 1255131
19:03:25 <lifeless> bug 1254555
19:03:29 <lifeless> bug 1254246
19:03:42 <lifeless> hmm, I'm seeing a distinct lack of bots
19:03:46 <jtomasek> Hi
19:03:50 <lifeless> https://bugs.launchpad.net/tripleo/+bug/1254246
19:03:56 <lifeless> https://bugs.launchpad.net/tripleo/+bug/1254555
19:04:00 <lifeless> https://bugs.launchpad.net/tripleo/+bug/1255131
19:04:03 <lifeless> criticals
19:04:19 <lifeless> also https://bugs.launchpad.net/diskimage-builder/+bug/1252975 - rhel failin
19:04:22 <lifeless> g in dib
19:04:52 <slagle> i can fix that
19:04:54 <lifeless> so everything is triaged - yay - but we've got four big issues open and being worked
19:04:55 <slagle> looks easy enough
19:04:59 <lifeless> slagle: awesome
19:05:24 <lifeless> nova just approved the revert to fix https://bugs.launchpad.net/tripleo/+bug/1255131
19:05:37 <lifeless> so that should be through soon assuming the gate gods have been appeased recently
19:05:44 <jomara> aloha
19:06:04 <lifeless> we have a workaround for https://bugs.launchpad.net/tripleo/+bug/1254555 in place, so nothing to do there except help the neutron folk as needed
19:06:06 <jog0> lifeless: gate delay is ~ 2 hours right now
19:06:26 <lifeless> and https://bugs.launchpad.net/tripleo/+bug/1254246 is currently not really known
19:07:34 <rpodolyaka1> looks like a race in neutron-server
19:08:06 <lifeless> rpodolyaka1: want to poke into it ?
19:08:23 <rpodolyaka1> lifeless:  sure, will ping neutron folks in mirantis too
19:08:29 <lifeless> rpodolyaka1: brilliant
19:08:34 <lifeless> #topic reviews
19:08:40 <lifeless> http://russellbryant.net/openstack-stats/tripleo-openreviews.html
19:08:42 <dkehn> of late these are db locks
19:08:43 <lifeless> http://russellbryant.net/openstack-stats/tripleo-reviewers-30.txt
19:08:46 <lifeless> http://russellbryant.net/openstack-stats/tripleo-reviewers-90.txt
19:09:10 <lifeless> 
19:09:10 <lifeless> Stats since the last revision without -1 or -2 :
19:09:10 <lifeless> Average wait time: 0 days, 2 hours, 0 minutes
19:09:10 <lifeless> 1rd quartile wait time: 0 days, 0 hours, 14 minutes
19:09:10 <lifeless> Median wait time: 0 days, 2 hours, 2 minutes
19:09:12 <lifeless> 3rd quartile wait time: 0 days, 3 hours, 45 minutes
19:09:18 <lifeless> ^ awwwesome
19:09:32 <lifeless> either that or we're not changing nearly enough :)
19:09:58 <lifeless> New patch sets in the last 30 days: 389 (13.0/day)
19:09:58 <lifeless> Changes involved in the last 30 days: 210 (7.0/day)
19:09:59 <lifeless> New changes in the last 30 days: 201 (6.7/day)
19:10:09 <lifeless> so - not a lack of changes, we're just on top of it. Cool.
19:10:18 <lifeless> any reviews business to raise?
19:10:29 <matty_dubs> We're so good at reviews that it's almost a problem -- I had a hard time finding anything to review the other day. ;)
19:10:32 <matty_dubs> Good problem to have.
19:10:44 <lsmola> hehe
19:11:48 <lifeless> ok, cool
19:11:54 <lifeless> #topic Projects needing releases
19:12:06 <lifeless> this seems to be working well; do we have a volunteer?
19:12:35 <rpodolyaka1> I'm used to doing reviews now, so it doesn't take me much time. Ill take it :)
19:12:40 <rpodolyaka1> *releases
19:12:47 <lifeless> rpodolyaka1: \o/
19:12:51 <lifeless> #action rpodolyaka1 to release the world
19:12:52 * rpodolyaka1 should have some sleep
19:12:59 <lifeless> #topic  CD Cloud status
19:13:15 <lifeless> SpamapS has been poking at this this morning and asked me to proxy for him
19:13:38 <lifeless> 07:23 < SpamapS> lifeless: waitcondition on nova-compute did not fix things. derekh has found a commit to
19:13:41 <lifeless> revert which _does_ seem to fix things..
19:13:43 <lifeless> 07:24 < SpamapS> lifeless: https://review.openstack.org/58577 revert patch
19:13:46 <lifeless> 07:24 < dprince> bad nova
19:13:49 <lifeless> 07:24 < SpamapS> do we have a simple way to cherry pick things in tripleo-cd ?
19:13:52 <lifeless> 07:25 < SpamapS> lifeless: anyway, that is where we are at.
19:13:54 <lifeless> 07:25 < dprince> SpamapS: we actually have a mechanism to handle patches in TOCI, but not cherry picks.
19:13:57 <lifeless> 07:25 < SpamapS> lifeless: also I'm working on NTP because trying to debug crap with skewed clocks _SUCKS_
19:14:00 <lifeless> 07:26 < SpamapS> in theory setting DIB_REPOLOCATION_nova and DIB_REPOREF_nova would work
19:14:03 <lifeless> 07:26 < SpamapS> but my experience with those has been that they unfortunately do not work.
19:14:06 <lifeless> 07:26 < SpamapS> perhaps because I don't understand refs
19:14:09 <lifeless> 07:27 < SpamapS> anyway, have to hit the road now
19:14:11 <lifeless> 07:27 < SpamapS> hopefully will be back
19:14:14 <lifeless> nova have approved that commit
19:14:16 <lifeless> so in theory the cloud is usable again in 3h
19:14:19 <lifeless> anyone else have cd-cloud info to add?
19:15:27 <lifeless> #topic  CI virtualized testing progress
19:15:58 <lifeless> pleia2: / dprince: ^ you've been active recently on this :)
19:16:08 <dprince> some progress this week: https://review.openstack.org/#/q/status:open+project:openstack-infra/tripleo-ci,n,z
19:16:10 <pleia2> got a couple more patches in last week and am now sorting out our networking strategy
19:16:20 <pleia2> only broke my bridge twice last night :)
19:16:53 <lifeless> pleia2: that sounds worse than I hope it is ;)
19:16:56 <dprince> The client and worker elements are in progress. I understand we are waiting on some infra comments there.
19:17:07 <pleia2> need to get dprince in the loop about our networking strategy (meeting later)
19:17:11 <lifeless> dprince: we got infra comments, and I've followed up with my understanding of the implications.
19:17:12 <dprince> I'm chipping away from the top down by adding a couple heat tempaltes
19:17:13 <pleia2> lifeless: not so bad, had to connect a keyboard to it ;)
19:17:26 <dprince> pleia2: sounds good.
19:17:35 <lifeless> dprince: we'd like a second ack from infra (well more from gear afficionados) but I think it's clear
19:18:00 <lifeless> dprince: essentially clients get told about server failures, so we just arrange for two clients and two servers to form a mutual lock
19:18:42 <dprince> lifeless: sounds good.
19:19:11 <dprince> lifeless: I had one question about how we will manage the actual slaves. Which is will *we* actually manage them? or will infra?
19:19:34 <lifeless> tripleo-cd-admins will manage them
19:19:50 <dprince> lifeless/pleia2: would also like to have a meeting right after this if possible too.
19:19:51 <lifeless> infra folk are welcome to join that team of course
19:19:58 * dprince forgot to send out an invite this week though
19:20:02 <pleia2> dprince: wfm
19:20:09 <lifeless> dprince: this is my morning of pain meetings wise but we'll see what we can do
19:20:27 <dprince> lifeless: so will the Jenkins slave need puppet creds to install all the normal infra stuff?
19:20:48 <lifeless> the jenkins slave is spawned by nodepool
19:21:00 <lifeless> this is already in place, just in the old grizzly cloud we have
19:21:30 <lifeless> oh! when you asked about slaves
19:21:37 <lifeless> I thought you mean the test environment machines
19:21:44 <lifeless> so - there are three things in test
19:21:51 <pleia2> maybe we need a glossary of terms
19:21:54 <lifeless> jenkins 'tripleo-gate' slave - infra operated
19:22:03 <lifeless> gear broker - infra operated
19:22:21 <lifeless> test environment on a test environment machine - tripleo-cd-admins operated (has baremetal access)
19:22:41 <lifeless> Oh, I forgot two cd cloud things
19:22:44 <dprince> lifeless: Right. I was asking about the jenkins node above mostly.
19:22:46 <lifeless> firstly we have ipv6 in the HP region now.
19:23:12 <lifeless> it's not all configured but connectivity is there so we can use that to connect to ipv6 only regions some vendors have talked about
19:23:43 <lifeless> secondly I was curious where the RH region was at - do we have admin creds ?
19:24:44 <lifeless> dprince: ^ that ones for you :)
19:25:07 <dprince> lifeless: sorry, too many meetings.
19:25:21 <lifeless> dprince: I know the feeling - no worries! :)
19:25:23 <dprince> lifeless: SO, derekh and I should get initial access (internal) this Friday
19:25:34 <lifeless> ok cool
19:26:02 <lifeless> will follow up next week - note that once a single machine is up and running I think all the tripleo-cd-admins would be delighted to help with the bringup
19:26:03 <dprince> lifeless: So at least we'll be able to take stock of things. A week or two after that I hope the security team can work through the final details and give all the CD admins access as well.
19:26:18 <lifeless> kk
19:26:31 <dprince> lifeless: we are super anxious to get in there though
19:26:31 <lifeless> anything else on CI testing?
19:26:46 <pleia2> also worthy of note, holiday this week in US, I'm out thurs + fri
19:26:54 <lifeless> dprince: yeah - let me know if the security guys want anything from me (e.g. docs/procedures etc)
19:27:01 <lifeless> but it should already be documented.
19:27:06 <lifeless> dprince: where is the region located?
19:27:27 <dprince> Phoenix I think.
19:27:32 <lifeless> cool
19:27:43 * dprince likes his servers hot
19:27:47 <dprince> HOT even
19:29:36 <lifeless> okies
19:29:42 <lifeless> #topic  Blueprints and design planning / summit wrap-up
19:29:57 <lifeless> so, I've done the boring administrivia follow-through from the HK summit
19:30:18 <lifeless> I *think* anyone coming and looking at blueprints will now see an accurate summation of the jointly agreed things
19:30:24 <lifeless> and stuff that needs more discussion is called out
19:30:37 <tzumainn> lifeless, I know that jcoufal was working on wireframes for an installer, should that be part of the summation?
19:31:03 <jomara> it should
19:31:14 <lifeless> Tuskar folk: I closed a bunch of blueprints that really didn't make sense as blueprints - most of them were descriptions of defects - e.g. bugs - rather than genuine major works that need coordination and approval
19:31:38 <jistr> ack
19:31:38 <lifeless> tzumainn: blueprints are very good at capturing, they are not good at design or evolution of ideas.
19:32:27 <lifeless> tzumainn: I think we should capture stuff as blueprints that is big enough we want formal approval on it; and we should do that once the thing has been broadly discussed - the blueprint is an output, not an input.
19:32:38 <tzumainn> lifeless, sure, but should it be included as part of what was discussed at summit?  I noticed that you had a line item that linked to an etherpad instead of a blueprint
19:33:29 <lifeless> tzumainn: ok so:
19:34:12 <lifeless> - the etherpad I linked to was really not a tripleo thing to decide on; it was in our timeslot because it's important to us but all the work for it will be Ironic, so the blueprint aspects should be in Ironic
19:35:01 <tzumainn> lifeless, right, I understand that - I'm just wondering if the installer could have been called out, because it's something we're actively working on for icehouse
19:35:01 <lifeless> - the slick deployment of clouds through the UI story is important, and I'm happy for there to be a broad blueprint about that - I'll reply to Jaromir's mail :)
19:35:04 <jcoufal> lifeless: Yeah, I think, tzumainn's point is, that we want to keep on mind that this is one of our deliverables for Icehouse. We can generate blueprints once we have more details
19:35:41 <lifeless> jcoufal: so I'd say -a- blueprint :)
19:35:47 <lifeless> and yes, having slick install is very important
19:36:06 <lifeless> bugs are super granular; blueprints are not
19:36:34 <lifeless> (building analogy - this nail is not hammered in correctly - bug; the building is the wrong shape - blueprint)
19:36:40 <jcoufal> ok, sounds good
19:36:54 <tzumainn> lifeless, yeah, jcoufal expressed my point better than I did - I was just hoping that we could build awareness that we're working on this feature
19:37:06 <lifeless> tzumainn: agreed
19:37:14 <tzumainn> okay, thanks for answering my question!
19:37:20 <lifeless> I've actually been talking the tuskar story to nvoa folk face to face fairly often
19:37:41 <lifeless> some of the things I've been concerned about from the get go get very strong pushback
19:37:45 <lifeless> like the manual scheduling
19:38:03 <lifeless> other things I thought were cool they were just plain confused about - like creation of flavors
19:38:15 <lifeless> so - why don't we switch to open discussion and spend a bit of time talking through this?
19:38:30 <jcoufal> sure
19:38:35 <lifeless> if there's no more stuff specifically about us having blueprints etc
19:38:40 <lifeless> {waits for timeout}
19:38:43 <ccrouch> https://blueprints.launchpad.net/openstack?searchtext=tripleo
19:38:46 <ccrouch> this is list right?
19:39:59 <ccrouch> presumably there are more than two targeted for icehouse?
19:40:35 <jomara> ccrouch: i think they're mislabeled; some of them actually have iCEHOUSE in the name
19:40:50 <jomara> (but dont have icehouse marked as series)
19:41:01 <lifeless> oh, the series field I have been ignoring
19:41:11 <lifeless> the list itself is accurate
19:41:11 <ccrouch> right, so more administrivia maybe required?
19:41:34 <ccrouch> lifeless: so everything approved is targetted for icehouse?
19:41:55 <lifeless> ccrouch: that is in a tripleo project yes
19:42:02 <lifeless> I can't comment on e.g. ceilometer stuff
19:42:21 <ccrouch> yep, makes sense
19:43:15 <ccrouch> this is the link thats mentioned on  https://wiki.openstack.org/wiki/TripleO so I wanted to make sure we're advertising the right stuff
19:44:10 <lifeless> yup
19:44:13 <lifeless> you are
19:44:22 <lifeless> note that the blueprints isn't the complete list of what TripleO is doing
19:44:33 <lsmola> lifeless, hopefully, all ceilometer stuff we need should land in I
19:44:47 <lifeless> we have the basic theme of 'drive deployments by makign the TripleOCloud better and more awesome' which gives organic structure.
19:45:07 <lifeless> (recorded in the trello experiment)
19:45:19 <lifeless> and we have bugs which gives lots of identified bits of individual work
19:46:09 <lifeless> ok
19:46:13 <lifeless> #topic open discussion
19:46:24 <lifeless> so design stuff around tuskar
19:46:36 <jcoufal> alright just small update from my side
19:46:42 <lifeless> please!
19:47:01 <jcoufal> I am close to send updated story of overcloud installer.
19:47:17 <jcoufal> At the moment, we are focusing on really basic stuff - register nodes (manual + autodiscover) -> assign services -> deploy.
19:47:49 <jcoufal> The whole flavor creation and advanced features are pushed back a bit, in sake of slick well working basic installer.
19:48:16 <lifeless> cool
19:48:18 <shadower> plus given the confusion and pushback it's better to give them space for proper design and discussion
19:48:18 <jcoufal> Once we have it, we can go further and work on adding more advanced features
19:48:22 <lifeless> can we skip assign services?
19:48:32 <lifeless> like - just let nova sort it out?
19:48:58 <jcoufal> to let nova sort out which services are deployed where?
19:49:01 <lifeless> yeah
19:49:13 <lifeless> a big chunk of the complexity in tuskar that is contentious is the way it does it's own scheduling
19:49:14 <marios> lifeless: i believe referring to e.g. neutron, swift etc
19:49:21 <slagle> does assigning services require that nova patch that has been in limbo a while?
19:49:23 <marios> lifeless: not nova-* services
19:49:31 <slagle> the one around returning the baremetal id's
19:49:43 <lifeless> marios: ack; that was my understanding
19:49:48 <marios> slagle: that was merged afaik
19:49:54 <slagle> oh, cool
19:49:56 <shadower> slagle: well I think we should just move to ironic
19:50:00 <lifeless> it might be v3 only
19:50:01 <shadower> was it?
19:50:07 <shadower> ah right
19:50:07 <lifeless> anyhow - focus! :)
19:50:36 <jcoufal> lifeless: well for user it might be confusing that he can't choose which nodes are compute / controller / object or block storage
19:50:37 <lifeless> point is, today - as I understand it - we have tuskar doing scheduling, passing to heat, which passes to nova
19:50:51 <lifeless> jcoufal: It's confusing to me that user would want to choose
19:51:16 <lsmola> lifeless, so how will nova sort it out?
19:51:26 <jistr> lsmola: +1
19:51:55 <lsmola> lifeless, like I have 10 baremetal nodes I reallz need just compute power
19:52:13 <lifeless> In the heat template
19:52:13 <marios> slagle: shadower: https://review.openstack.org/#/c/42047 fyi
19:52:17 <lsmola> lifeless, how will nova know what I need?
19:52:18 <lifeless> choose based on flavor
19:52:20 <lifeless> not on node
19:52:39 <jcoufal> flavor is representing node
19:52:48 <lifeless> flavor represents a collection of nodes
19:53:04 <jistr> jcoufal: well, a hardware type rather than node, right?
19:53:08 <lifeless> the current TripleOCloud, for instance, has two flavors.
19:53:10 <jcoufal> right
19:53:18 <lifeless> one 96GB/24Cores/2TB of disk
19:53:25 <lifeless> and one 64GB/8cores/2TB disk
19:53:49 <lifeless> I'm saying that rather than poking under the hood at the list of nodes
19:54:15 <jcoufal> I still see odd why I cannot control where my stuff goes...
19:54:22 <shadower> lifeless: how do these work in the BM sense? Are they autodiscovered or do you assign a flavour to each node when you register it?
19:54:32 <lifeless> just say 'compute can run on flavors X,Y,Z' 'network on flavors X,Y' etc
19:54:46 <lsmola> lifeless, hmm
19:54:51 <jcoufal> well yes, but this is advanced approach
19:54:58 <jcoufal> why don't we start with basics?
19:55:01 <lifeless> jcoufal: So this is the disconnect I think. If you have 7 machines you can pay attention to such detail. You cannot when you have 7000.
19:55:49 <jcoufal> lifeless: agree with you. But, we want to have basics done first
19:55:51 <lifeless> shadower: baremetal flavor setup is something we could in principle automate. But it's undercloud config and the story being discussed is overcloud install :)
19:55:56 <lsmola> lifeless, well true, we had resource clasess for that
19:56:06 <lsmola> lifeless, now I see that flavor is resource class
19:56:26 <lifeless> jcoufal: ok, so my point is that you need to write /more/ code to do node level stuff
19:56:33 <lifeless> jcoufal: because you have to write a topology generator.
19:56:46 <lifeless> jcoufal: maybe if we step back to even more basic. And say V0: support just one baremetal flavor.
19:57:17 <lifeless> jcoufal: so the inputs to the UI become: you have N machines, we are doing to install a cloud for you. Click here to install.
19:57:50 <marios> lifeless: so that assumes just one service type, compute (to start with)
19:57:53 <lifeless> jcoufal: we can say if N==1 then its an all in one cloud. If N==2 it's control + hypervisor.
19:58:02 <lifeless> marios: no, not at all. ^
19:58:21 <marios> lifeless: i'm equating one baremetal flavor to one service
19:58:27 <lifeless> marios: nope.
19:58:36 <lifeless> marios: it just means there is one type of hardware.
19:58:47 <lifeless> marios: consider the test rack RH had at the summit (which was AWESOME)
19:58:58 <jcoufal> well, but user needs to define the flavors anyway, it's not that he comes to UI and says - install me anything
19:58:59 <lifeless> marios: it had - as far as I know - exactly one hardware config in the entire rack.
19:59:23 <lifeless> jcoufal: thats true, but even so - if the rack is like the one at the summit, its one flavor.
19:59:43 <lifeless> wouldn't truely basic be the ability to install into that rack ?
20:00:34 <lifeless> ok, we're out of time here - but #tripleo is still open, and if it's not too late inyour evening I think this is a good conversation to keep rolling with.
20:00:37 <lifeless> #endmeeting