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