19:01:28 #startmeeting Tuskar 19:01:29 Meeting started Tue Sep 24 19:01:28 2013 UTC and is due to finish in 60 minutes. The chair is shadower. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:33 The meeting name has been set to 'tuskar' 19:01:45 okay, this'll hopefully be quick 19:02:04 #topic Discuss merger with TripleO including meeting time moving to this slot. 19:02:26 most of you know this but: Tuskar is becoming a part of the TripleO program! 19:02:33 \o/ 19:02:44 +1111 19:02:46 hi 19:03:06 I'm stepping down as the Tuskar PTL and there will be general PTL elections on Friday I believe 19:03:25 lifeless: will the Tuskar devs be elligible for voting? 19:04:11 shadower: are we keeping Tuskar name? 19:04:21 shadower: That will be up to the ajudicating election officials, but I will argue that they should be. 19:04:30 cool 19:04:36 jcoufal: I believe so -- unless there are any objections? 19:04:41 jcoufal: our repos still need names 19:04:53 might as well keep the existing ones 19:04:57 yeah, I just wanted to make sure 19:04:58 yeah, i think keeping the tuskar name for the api/ui makes sense 19:05:07 we can always change it 19:05:09 shadower, can you send an updated invite to the triple-o weekly meeting once the time is decided? 19:05:15 (quantum -> neutron etc) 19:05:19 tuskar as the code name for the ui and api projects is neither here nor there IMO; changing names right now would be disruptive, and HK Is right around the corner. 19:05:19 tzumainn: yup 19:05:23 repos and projects != "OpenStack Programs" .. so I don't think anything gets "renamed" 19:05:31 yea 19:05:43 is documentation/wiki going to remain separate? 19:05:48 we may want to move the tuskar repos into openstack at the next opportunity -infra has. 19:05:58 documentation and wiki should be integrated together 19:06:01 yeah 19:06:10 lifeless: I saw some work on switching to sphinx 19:06:16 in -incubator at least 19:06:19 yup 19:06:34 shadower, lifeless, will the logistics of that be worked out at the next triple-o meeting or. . . ? 19:06:39 Tuskar should do the same I reckon 19:06:56 tzumainn: how do you mean? 19:07:09 merging the wiki/documentation 19:07:15 or should we just kinda do it? 19:08:06 tzumainn: so the program definition should be fine as is but perhaps needs a tweak; the list of projects needs to be expanded, and anything in the Tuskar /program/ namespace needs to move; things in the Tuskar /project/ namespace are fine. 19:09:06 lifeless, I admit that I don't quite understand the distinctiion 19:09:49 we didn't make much of that distinction when we started. Program is TripleO -- i.e. OpenStack Deployment 19:09:51 but documentation wise, we only have the Tuskar wiki pages and documents within our git repo 19:10:06 tripleo-incubator, diskimage-builder etc. are projects belonging to the same program 19:10:13 ah, got it 19:10:20 tuskar repos will be another projects belonging to TripleO program 19:10:31 lifeless: can we merge sphinx docs from multiple repos? 19:10:37 tzumainn: Program is an effort aimed at a mission; Project is a code base. 19:10:41 I think that's what tzumainn is getting at 19:10:54 so concretely, the Tuskar wiki, does that move under TripleO/Tuskar or something? 19:10:57 shadower: oh, I thought tzumainn was asking about wiki. 19:11:14 lifeless: yeah but I'm not sure he understands what the move to sphinx implies 19:11:17 tzumainn: http://docs.openstack.org/developer/nova/ 19:11:29 that's docs generated from a bunch of files in the nova repo 19:11:33 unless I'm mistaken 19:11:39 tripleo is going to do the same 19:11:40 right? 19:12:07 shadower: I don't think we can merge different repos into one spinc output; we may want a dedicated 'deploying openstack' set of dev docs and user docs ... of course such things exist so we'll want to work with annegentle and update them appropriately. 19:12:07 yes 19:12:17 shadower, same with the horizon http://docs.openstack.org/developer/horizon/ 19:12:23 right 19:12:48 tzumainn: so probably, eventually, some of our docs will move to wherever the rest of tripleo sphinx docs end up 19:13:21 shadower, okay, got it 19:13:30 it sounds like a little guidance is needed 19:13:38 yeah 19:14:04 So lets suggest that someone spend the next week poking at the tuskar and tripleo docs and wiki pages and create a blueprint outlining whats needed and where it should go 19:14:19 sounds good 19:14:20 +1 19:14:25 +1 19:14:28 tzumainn: want to have a look at that? 19:14:33 we can vet that when it's ready (either at the meeting or just via the list) and that then provides structure 19:14:34 +1 19:14:34 shadower, sure 19:15:00 #action tzumainn to look at the current docs and wiki pages and document what should go where 19:15:20 regarding blueprints and bugs: those are tracked against each project in their respective launchpad pages 19:15:35 I think that's pretty clear but I wanted to explicitly state that 19:15:45 I have a thought about blueprints 19:15:51 let's hear it 19:15:52 since blueprints will often be cross-project 19:16:09 e.g. tuskar-ui + -api + tripleo-image-elements 19:16:16 yeah 19:16:18 perhaps blueprints should be in just one place 19:16:21 e.g. /tripleo 19:16:28 fine by me 19:16:30 +1 one place 19:16:31 so we don't lose track of them all 19:17:10 #agreed put all blueprints under one launchpad account (tripleo) 19:17:14 LP isn't super good at coordinating blueprints across a subset of an organisation, only the whole org or one project. 19:17:23 yea 19:17:27 yeah 19:17:28 especially given the likely dependency chains we should see between say, templates<->api<->ui 19:17:39 lifeless: do you want to send an announcement regarding the merge? Just to make it official to the community 19:18:01 shadower: certainly, I was holding off for the tuskar folk that weren't at the sprint to chime in 19:18:11 shadower: I will send an announcement today 19:18:17 cool 19:18:34 lifeless: cool, thanks. Sorry I missed yesterday's meeting, I hit the pillow before it happened 19:18:36 is there a place for people to send the wedding presents? 19:18:38 (jetlag) 19:18:42 haha 19:18:44 note that I was at the summit, and did not notice the merger happening ;) 19:18:50 s/summit/sprint/ 19:18:50 tzumainn: New Zealand :) 19:19:05 lol 19:19:12 speaking of .nz .. 19:19:22 if we move to this time slot.. we're making lifeless start at 0700 19:19:34 Thats fine until daylight savings kicks in. 19:19:47 ah then its 0600? 19:19:49 At which point I think we'll want to flip it by 12 hours or so 19:20:06 Or perhaps send me to more conferences 19:20:09 I dunno :) 19:20:11 hehe 19:20:13 haha 19:20:23 Yeah we'll just keep you within 8h of UTC and it will be fine 19:20:38 But, we have a bunch of people here, so we need to minimise the crazy-hours; I'm just one perhaps :) 19:20:39 its only, what, half the year? :p 19:20:46 s/perhaps/person/ 19:21:00 so in case anyone missed that: the tripleo sprint will be moving to this day and time, i.e. Tuesday 7pm UTC 19:21:05 at least until now 19:21:08 If we get some folk in India/Australia/China contributing regularly it will be harder. 19:21:12 s/until/for/ 19:21:29 I will update the global meeting page and merge the agendas 19:21:37 thanks 19:21:51 any more questions/notes regarding the merge? 19:22:08 huzzah 19:22:36 Tuskar folks, feel free to go through devtest, file bugs and do reviews on TripleO 19:23:04 moving on 19:23:06 #topic Finish up last week's voting https://etherpad.openstack.org/tuskar-naming 19:23:34 I'm not sure how helpful this will be -- I wouldn't be surprised if things changed now that the UI's mission expanded a bit 19:23:53 but it's only a couple of terms, it will help the UX folk and we can always change them later 19:24:07 https://etherpad.openstack.org/tuskar-naming 19:25:46 #startvote How should we name Flavors in Tuskar? (flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile) 19:25:47 Begin voting on: How should we name Flavors in Tuskar? Valid vote options are , flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile, . 19:25:48 Vote using '#vote OPTION'. Only your last vote counts. 19:25:52 for a bit of background 19:26:03 these things will end up being Nova Flavours 19:26:11 There are two sets of flavors right? Baremetal flavors and Overcloud flavors 19:26:18 #vote flavors 19:26:26 lifeless, yes 19:26:30 lifeless: right, baremetal flavors aren't exposed via tuskar 19:26:35 (right now anyway) 19:26:37 one specifies particular exact hardware machine configs, and one the vm configuration 19:26:38 lifeless: yeah, what we're talking about here are the overcloud flavors 19:26:43 lifeless: so flavors in tuskar refers to overcloud 19:26:50 however, we define them in the UI at a point where they may not exist in the overcolud yet 19:27:06 they're tied to the resource classes (each resource class may have their own flavors) 19:27:08 #vote overcloud_flavors 19:27:09 matty_dubs: overcloud_flavors is not a valid option. Valid options are , flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile, . 19:27:09 ok; so just to note that as Tuskar gets better at deploying underclouds, we'll need to differentiate between these concepts. 19:27:11 think m1.small, m1 large 19:27:18 yeah 19:27:25 shadower: certainly 19:27:35 #vote flavor_definition 19:27:49 #vote flavors 19:27:55 #vote overcloud_flavors 19:27:56 lifeless: overcloud_flavors is not a valid option. Valid options are , flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile, . 19:28:10 #vote overcloud_flavors 19:28:11 lsmola_: overcloud_flavors is not a valid option. Valid options are , flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile, . 19:28:17 We've got so many options, but not the one I want :'( 19:28:20 I'll count tohse options manually 19:28:28 that sounds good actually 19:28:30 shadower: you want to stop and start voting again with overcloud_flavors option 19:28:31 ? 19:28:33 i think i like overcloud flavors 19:28:42 more precision 19:28:44 looks like a consensus is a-brewin' 19:28:45 ok 19:28:46 okee then 19:29:04 #endvoting 19:29:05 #vote overcloud_flavors 19:29:06 jcoufal: overcloud_flavors is not a valid option. Valid options are , flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile, . 19:29:11 #vote flavors 19:29:22 #endvote 19:29:23 Voted on "How should we name Flavors in Tuskar?" Results are 19:29:24 flavors (2): marios, lsmola_ 19:29:25 flavor_definition (1): jcoufal 19:29:30 oops too soon 19:29:37 #vote flavor_definition 19:29:45 sorry a bit late to vote 19:30:11 julim: it'll start again 19:30:19 people came up with overcloud_flavors 19:30:24 #startvote How should we name Flavors in Tuskar? (flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile, overcloud_flavors) 19:30:25 Begin voting on: How should we name Flavors in Tuskar? Valid vote options are , flavors, flavor_templates, flavor_definition, instance_type, instance_configuration, configuration_template, configuration_profile, overcloud_flavors, . 19:30:26 Vote using '#vote OPTION'. Only your last vote counts. 19:30:29 #vote overcloud_flavors 19:30:31 #vote overcloud_flavors 19:30:31 #vote overcloud_flavors 19:30:32 #vote flavors 19:30:35 #vote overcloud_flavors 19:30:38 #vote overcloud_flavors 19:30:50 #vote overcloud_flavors 19:30:56 #vote flavor_definition 19:31:07 jomara: ^ 19:31:13 #vote overcloud_flavors 19:31:15 shadower: :) 19:31:21 #vote flavor_definition 19:31:21 ouch. 19:31:32 anyone else? 19:31:34 noslzzp: no likey? 19:31:43 I'm indifferent here. 19:31:53 jomara: no likey here :) 19:32:26 Hardware Profile? 19:32:34 :) 19:32:38 #endvote 19:32:39 Voted on "How should we name Flavors in Tuskar?" Results are 19:32:40 flavors (1): marios 19:32:41 flavor_definition (2): shadower, jcoufal 19:32:42 overcloud_flavors (7): rpodolyaka, julim, tzumainn, lifeless, matty_dubs, jomara, lsmola_ 19:32:48 Maybe FrontEndHardwareProfile and BackEndHardwareProfile? 19:33:00 matty_dubs: that was daring 19:33:18 #agreed Tuskar Flavors will be renamed to Overcloud Flavors 19:33:20 heh 19:33:34 shadower: It's in my job description to periodically suggest terrible ideas. 19:33:39 hehe 19:33:58 and also entertain us 19:34:01 :-D 19:34:06 coming up: Management Node 19:34:17 * noslzzp enjoys his front row seat to the MattyDubs show. 19:34:19 which I believe is a fancy name for the undercloud node? 19:35:02 lifeless: do you happen to have any term for that yet? OTher than the "undercloud node" 19:35:13 shadower: yeah, the primary/main, whatever it is called 19:35:18 if we call something an 'overcloud flavor' 19:35:22 which I'm fine with but the over/undercloud terminology will probably be confusing to the people 19:35:22 wouldnt it be good to consistently use those terms 19:35:34 shadower: +1 19:35:38 on the other hand, we just agreed on "overcloud flavors" so whatever 19:35:39 the same for flavors 19:35:46 shadower: what is an 'undercloud node' ? 19:36:02 lifeless: a box running the undercloud 19:36:02 shadower: do you mean the current all-in-one undercloud control plane + bm hypervisor ? 19:36:03 lifeless: node which contains undercloud services 19:36:10 lifeless: yeah 19:36:21 can't we have more than one node in undercloud? 19:36:37 rpodolyaka: we can and very likely want to 19:36:41 at least for HA purposes 19:36:43 rpodolyaka: I believe it is possible (e.g. for high availability) 19:36:44 we don't have a specific term for it; in aggregate we refer to it as the 'Undercloud' or 'Undercloud control plane' 19:36:56 note that as we scale an undercloud there will be some N machines 19:37:11 yeah sure 19:37:11 e.g. we might grow swift + nova-bm or swift + Ironic 19:37:14 etc etc 19:37:18 yeah 19:37:38 jcoufal: do we actually have that term in the UI anywhere? 19:37:41 Is 'Node' not specific enough? 19:37:41 I'm not sure it makes sense to refer to the all-in-one initial node specially, except in the context of bootstrapping the undercloud. 19:37:52 what I was trying to say, we can have plenty of those and each would be differrent 19:37:56 shadower: nope, there was none in POC 19:37:58 Too easily confused with undercloud nodes, maybe? 19:38:16 shadower: the only thing is that we should distinguish regular management node and that one which contains undercloud 19:38:18 jcoufal: shall we drop this from the vote then? Is it really necessary to assign a name now? 19:38:29 jcoufal: what's the difference? 19:38:39 whats' a regular management node 19:38:53 shadower: currently called 'leaf management node' 19:39:17 jcoufal, the one that got cancelled? 19:39:24 jcoufal: oh. Well that's another vote down the road and that won't have much of an undercloud in it 19:39:30 so we can just pick a name for that 19:39:40 right 19:39:46 jcoufal: whts a 'regular management node' ? 19:40:26 lsmola_: was leaf management node cancelled? 19:40:45 lifeless: it was management node in the rack, but based on lsmola_'s node, it was cancelled lately 19:40:53 lifeless: a node of the undercloud. He wants to differentiate that with a term from the architecture Keith described on Thursday 19:40:57 jcoufal, i believe there was a long discussion about that today 19:41:17 I wouldn't say cancelled -- it's quite possible that will be one of the architectures we'll end up supporting 19:41:23 so lifeless, the naming scope here is in relationship to having some "presence" in the logical rack.. 19:41:25 but unlikely the default one 19:41:31 jcoufal, and no one likes it, it won't be default setup, but a possible architecture probably 19:41:48 logical racke being an l2 network 19:41:56 shadower, correct. 19:42:06 could be a part of a rack, a single rack or multiple racks 19:42:19 so assuming that, we have a "primary management node" and a "leaf management node" (within that L2 domain). 19:42:33 so we are discussing names for those elements.. 19:42:35 shadower: I'm sorry I was a bit out of news this day. So I think with this changes, should we wait until we have stable architecture plans? 19:42:48 jcoufal: sounds very reasonable to me 19:42:53 sure, we can wait. 19:42:57 agree 19:43:11 +1 on deferring; we probably need a couple of reference architectures to be able to describe sensible terms 19:43:16 yeah 19:43:30 maybe matty_dubs will come with something cool later 19:43:35 If that 2-undercloud-nodes per L2 domain thing is what I think it is, they are peers not primary/secondary. 19:44:02 shadower: so let's end with flavors voting and the rest we can have a look later 19:44:09 lifeless, maybe, maybe not.. 19:44:14 jcoufal: sounds good to me 19:44:23 and let's call it with some general terms until then 19:44:26 noslzzp: tell me more after the meeting ? 19:44:28 no more votes! 19:44:29 so if I understand the outcome correctly 19:44:34 this should contain the agreed upon terms: https://wiki.openstack.org/wiki/Tuskar/Glossary#Resource_.28Rack_and_Node.29 19:44:35 lifeless, absolutely. 19:44:58 tzumainn: looks legit 19:45:06 awesome 19:45:10 #topic Open discussion 19:45:19 tzumainn: for reference; thats probably a page that wants to move under TripleO, as it's cross-project 19:45:38 lifeless, yep, that makes sense! 19:45:48 it'll be in my doc blueprint or whatever 19:46:05 lifeless: will the next tripleo meeting move to this day of the week and time or will it be in the original slot? 19:46:58 the next tripleo meeting is here, in 24*7h-24m time. 19:46:58 General announcement: Tomorrow at 2:30 pm UTC there will be discussion about Tuskar states 19:47:38 will be probably recorded hangout, whoever is interested, I'll send the link in channels 19:47:48 Could you also send to the -dev list? 19:47:59 IRC backscroll can be quite lossy 19:48:30 lifeless: I'll send invitation announcement + link to the youtube recording 19:49:00 for the hangout invitation (unfortunately limited by 10 people) I believe IRC might be fine 19:49:06 lifeless: sounds good? 19:49:09 jcoufal: thanks! Yes, for the hangout IRC is fine 19:49:16 lifeless: great 19:49:34 jcoufal: It's largely self interest for me; I want to keep on top of whats going on, but in UTC+1200 I can't attend the thing itself. 19:50:20 guys, fyi, I've been working on patches to tripleo-image-elements and tripleo-heat-templates to make it easy to use tuskar in undercloud (https://review.openstack.org/#/c/47589/ and https://review.openstack.org/#/c/47790/). This requires some changes in tuskar (https://review.openstack.org/#/c/47826/). I think, we should have something like modified TripleO devtest guide, that would allow to test Tuskar 19:50:21 lifeless: sure and I'm very sorry for that timing, it will be pretty difficult for sync times, but that's reason for recording 19:50:48 rpodolyaka: I'll have a look at the patches tomorrow. Thanks a lot for getting involved! 19:50:51 lifeless: it will be general discussion which can be followed in mailing list / irc if you have some thoughts around 19:50:58 shadower: thanks! 19:51:15 that works for me 19:51:56 rpodolyaka: Having a devtest story that includes Tuskar makes a lot of sense. 19:52:29 lifeless: should be fairly easy, when we have tuskar-* elements 19:52:47 Another general announcement: Soon(-ish) I'll send POC wireframes to the dev- mailing list so that all the people can get overview about what is happening in the UI 19:53:02 rpodolyaka: one thing we might want to do is have something that drives tuskar via the API, so the CLI testability aspect of the story is preserved. 19:53:03 Nice 19:53:35 rpodolyaka: It would be nice to remove the duplication we currently have between heat template management in the CLI story and the Tuskar story 19:53:41 rpodolyaka: and I see that as related 19:53:49 lifeless: tuskar has sample_data script. I think, we can start from this 19:54:06 lifeless: what's the latest on enabling the gating jobs? 19:54:14 lifeless: I used it to test tuskar deploying overcloud 19:54:26 shadower: the broad brushstrokes plan has been approved just now in #openstack-meeting 19:54:32 rpodolyaka: cool 19:54:33 awesome 19:54:43 okay, 6 more minutes 19:55:00 http://lists.openstack.org/pipermail/openstack-infra/2013-September/000252.html 19:55:19 https://etherpad.openstack.org/tripleo-test-cluster 19:55:34 If anyone wants to dive on this and help, I'd be delighted to drill into more planning detail 19:55:41 cool 19:55:51 lifeless: is LXC still happening though? Could that reduce the mem footprint 19:55:54 ? 19:56:00 nope 19:56:04 oh well 19:56:10 LXC is a no-go due to iscsid using netlink 19:56:14 and netlink not being namespaced 19:56:30 ok 19:56:49 so - anyone wanted to push the gating of tripleo and nova-bm forward, please ping me or pleia2 19:57:00 and we can identify a unit of work they can do to help 19:57:11 jomara: ^ 19:57:14 * SpamapS was pulled away for a second by meatspace issues. did I hear template stuff? 19:57:34 dang 19:57:49 jomara: not assigning work to you for the record. But I thought you might be interested 19:59:03 shadower: the lxc setup was what you were telling me about before right? i was looking forward to less memory requirements 19:59:22 jomara: I was telling you about this effort (tripleo gating) in general 19:59:28 nothing lxc specific 19:59:29 sadly lxc would only ever has saved seed node space 19:59:32 ahh ok 19:59:40 you had mentioned something that would lessen the memory requirements 19:59:53 lifeless: unless we went crazy and simulated pxe booting an lxc container :) 19:59:54 you can reduce memory footprint by treating the seed as the undercloud and going straight to overcloud, if you're focused on overcloud 19:59:54 jomara: one of the lo-mem ideas was to go from seed to overcloud directly 20:00:06 and contrary-wise skip the overcloud if you want to focus on undercloud stories 20:00:21 SpamapS: loco man, loco 20:00:28 this should be fine for most of the tuskar stories for now 20:00:36 and with that, time's up folks! 20:00:38 #endmeeting