19:03:47 #startmeeting arch_wg 19:03:48 Meeting started Thu Sep 8 19:03:47 2016 UTC and is due to finish in 60 minutes. The chair is SpamapS. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:51 The meeting name has been set to 'arch_wg' 19:03:53 ttx: good idea! 19:04:05 #topic roll call 19:04:21 Let's just shout ideas of things the group should try to cover i priority 19:04:23 o/ 19:04:26 * dtroyer is here but multitasking 19:04:40 * rustyl in his first openstack irc meeting 19:04:47 Hi! This is the first time we've done this meeting. So I do expect sporadic attendence. 19:05:00 I have to close my laptop, so there'll be a 5 minute outage 19:05:07 o/ 19:05:07 I'll take it over 19:05:13 ttx: thanks! 19:05:17 #topic open discussion 19:05:25 * SpamapS bbiab 19:05:38 So I'd like to discuss immediate priorities. I have 3 on my mind 19:05:46 SpamapS already knows about them 19:06:03 seems like we should discuss what is left to merge the proposal 19:06:05 1/ create a solid motivated group 19:06:28 2/ Start discussing the concept of "base services" 19:06:43 which are things that can be assumed to be present in an openstack deployment 19:06:56 currently keystone, Mysql, and a MQ (Rabbit) 19:07:12 but we've been talking of extending that set 19:07:18 with a DLM, wiht Barbican 19:07:47 Additions need to be as limited as possible to limit the operational burden 19:08:04 But we still need to add, to get access to awesome features 19:08:19 DLM is becoming more common every day, so is easier. 19:08:28 3/ Create an overall sclaing model 19:08:32 scaling* 19:08:35 This one is harder 19:09:09 But we need to define an openstack-wide scaling model. Could be to have each service scale horizontally, could be cells, could be tricircle-like... 19:09:12 Key management is tougher, because without HSM barbican is kind of just a toy. 19:09:17 but we need to have a big picture 19:09:51 That would be my 3 initial objectives 19:10:05 But I bet you have plenty on your list 19:10:39 I suspect scaling in one for or another will be on many lists 19:10:53 seems like we need to have something fairly easy to tackle first in order to work out the kinks of how this group works 19:10:56 what we need to try and do here is be clear on terms like that 19:11:17 I mostly want to make sure any efforts are transparent, and productive. My list is so long, I need help choosing what to even start talking about 19:11:38 rustyl: yes. i think establishing the base service concept could be easy 19:12:00 ttx: so that would just be a document? 19:12:21 (before thinking of extending the set, just expressing that openstack deployments can be expected to have a MQ, a DB and keystone 19:12:44 In addition to "what do we want to change" I want to also answer "what doesn't have a stated architecture?" So we can start to help with understanding of the system at higher levels 19:13:08 rustyl: ideally the same document would list the tradeoff we need to make when considering adding stuff 19:13:48 The base system services effort would be a good one to start with for documenting as well. 19:13:50 i.e. balancing adding operational complexity vs. giving developers more efficient features 19:14:22 The discussion around triggers is a bit of the same vein 19:14:34 But here's another thought that throws a wrench into that plan... What if we want to do micro services? 19:14:51 (which I do) 19:15:15 the base services could be the non-openstack microservices :) 19:16:14 or maybe I don't get what you mean 19:16:38 Documenting all the coupling that prevents micro services today will tell us how hard it's going to be too implement. Adding base services might make it harder, since every micro service would in theory need it's own isolated instance of the base services 19:17:11 What I mean is that I have a hard time just updating cinder. 19:17:18 ok, so picking an item to work on that basically results in a document definitly falls into the easier side of things (for some definition of easy), but... i'm woried about figuring out how work in this group results in a set of patches to multiple projects 19:17:34 There are interdependencies that have risen from the integrated gate 19:17:34 SpamapS: would it ? a microservice could need to talk to a DLM microservice... 19:18:18 it's microservices, not micromonoliths :) 19:18:30 The APIs between cinder and Nova are not well defined and because of that, I have to update them in lock step 19:18:57 yes, that kind of work likely needs to be done in all cases 19:19:15 I want them to be constrained to their public APIs only 19:19:47 But the scale-out /microservice question is clearly level 2 boss 19:19:47 OK going into takeoff now for real 19:19:58 I think we need to tackle level 1 first 19:20:22 OK, I don't have much more to discuss 19:20:23 We could close now 19:20:47 rustyl: anythind to add ? 19:20:50 +g 19:20:59 quick question.... how to we close on the actual proposal thats under code review? 19:21:25 seems like the conversation on the review is nearing an end, but no +2's yet 19:21:34 I'm wondering if we need to close it. The Arch WG can exist without approval of anyone 19:21:58 cross-project specs are discussed by the crossproject grop, you can ask thingee for help 19:22:15 but frankly I wonder if you should go through that step 19:22:15 at the least shouldn't the group point at that, or something like it, to define its mission? 19:22:32 or just abando nthe review and take the draft to some arch-wg repo or wiki page 19:22:52 dtroyer: we should definitely keep the text 19:22:55 dtroyer: thoughts on getting +2's 19:23:20 I just don't think we need crossproject team approval to start the group 19:23:23 * rustyl just realized that dtroyer was already talking... damn lag 19:23:44 it was useful to iterate on the text 19:24:17 agreed. maybe what we need to do is start putting together the structure for this group to put is stiff, and that would be doc #1 19:24:19 so option 1/ abandon the review, copy the text to a wiki page or some arch-WG git repo 19:24:31 I lean toward the repo. 19:24:35 option 2/ ask thingee for help to bring it to the approval stage 19:24:53 I think the API WG=has generally worked well and we can borrow a lot of process from them 19:25:01 but I fear people would read too much into the need for approval, like they would fear it gives some authority to the group over them 19:25:30 since people those days seem to read too much into any change proposed 19:26:42 I'll let the choice between options to SpamapS but my personal advice would be to go with 1 19:26:51 ++ 19:27:15 either way for me 19:28:27 The immediate action is to publicize the meeting and get all the people who expressed interest to show up next time 19:29:25 then agree on some easy initial target (I'd propose the base services stuff) 19:29:48 sounds reasonable 19:29:56 then if all goes well tackle something more ambitious 19:30:10 yes. It would be great to have something to talk about in Barcelona, even just informally 19:30:29 fwiw we could totally give the Arch Wg a room for two days at the PTG event 19:30:32 the base services should be doable 19:30:42 (space permitting) 19:31:00 so that we can make in-person progress and use it as a sprint 19:31:08 * dtroyer is afraid it would be like early Neutron rooms ;) 19:31:46 yes, I don't want to force it, just let you know there is this option 19:32:13 A great option, thanks 19:32:15 agree it could be more destructive than productive 19:32:33 In /theory/ we have extra space on the "horizontal" side of the event 19:32:39 that and the comemnts in the review are what keep me wanting to keep the focus narrow, at least at first 19:32:44 (the monday/tuesday) 19:32:56 people want to boil the desert 19:33:16 SpamapS: are at at 10000ft yet ? 19:33:46 should we just end the meeting or wait for him to come back and read scrollback ? 19:33:53 +1 19:34:10 +1 to end, or to wait ? 19:34:14 to end 19:34:20 he started it… but you probably want to find a pillow by now 19:34:29 I'll hang here for a while either way 19:34:33 * ttx wonders if he can actually end it 19:34:45 let's try otherwise we'll wait :) 19:34:47 he didn't make you chair 19:34:50 so no you can't 19:35:02 damn SpamapS 19:35:12 anyone can end it after 20:04 19:35:20 ok, I'll do some karaoke and dance then 19:35:27 next time he could do #chair ttx and then you are good 19:35:38 oh my goodness, glad I wandered by for this 19:35:47 I didn' t know that one, thanks anteaya 19:35:49 aaaaand Iiiiiiiiii iiiii wiiilll alwayyyyys looooove yooooouuuuuuououououou 19:35:54 dtroyer: welcome 19:36:04 quick fungi please end the meeting 19:36:19 llloooooove youououououououo 19:36:44 (karaoke usually makes SpamapS reappear) 19:37:14 like kibo? 19:37:19 apparently you need to keep crooning 19:39:08 Neun und neunzig luftballons.. und ihrem weg zum horizon 19:39:36 oh I like that one 19:39:45 haven't heard that one in a long time 19:40:19 much better than celine 19:40:27 horizont* 19:40:50 dtroyer: kibo one of the volcanic cones on kilimanjaro? 19:41:16 damn, my German doesn't work as well as in 1984 19:41:29 no, he was a guy in the Usenet days who would pop inot any discussion that mentioned his name 19:41:35 I still got the jist 19:41:46 dtroyer: ha ha ha 19:41:55 https://en.wikipedia.org/wiki/James_Parry 19:42:24 I only saw it firsthand once 19:42:29 do tell 19:43:10 in the original comp.os.linux group, someone mentioned him directly and he replied within 8 hours or so. I totally forget what the topic actually was 19:45:04 what an interesting pattern of behaviour 19:45:29 Usenet used to be fun ;) 19:45:34 I bet 19:45:39 so many things used to be fun 19:45:50 Then came endless September (AOL) and Cantor and Siegel's grene card spam 19:45:53 the fact that such a thing was even possible at one point 19:45:54 Long taxi 19:45:56 * SpamapS is in the air 19:46:06 * SpamapS reads backscroll 19:46:09 don't look down 19:46:20 SpamapS: yes, you won't be disappointed 19:46:28 ha ha ha 19:47:33 this should be framed: http://www.kibo.com/menu.shtml 19:47:55 :) 19:47:57 ok 19:48:06 so yeah, I'm in favor of a less formal process and more forward progress 19:48:24 and of karaoke 19:48:49 * dtroyer not so sure about karaoke 19:48:59 alt.religion.kibology, classic 19:49:04 my original thought in using the process was to make sure we don't step on anyone's toes or bypass parallel efforts, but I think we've shown that we're not doing that. 19:50:02 So an architecture-specs repo might be a better way to go. I think we should discuss that at next week's meeting. 19:50:20 I'll try to socialize the time for the meeting between now and then. I recommend everyone do the same. :) 19:50:21 agreed 19:50:36 thanks to those of you who came. and to ttx for reminding me it was happening while I was in line to board my flight ;) 19:50:44 #endmeeting