20:01:48 #startmeeting octavia 20:01:49 Meeting started Wed Oct 22 20:01:48 2014 UTC and is due to finish in 60 minutes. The chair is blogan. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:50 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:52 The meeting name has been set to 'octavia' 20:01:54 o/ 20:02:09 im not sure where stephen is, ill pass chair to him when gets back 20:02:20 sbalukoff: Error: Can't start another meeting, one is in progress. Use #endmeeting first. 20:02:20 #topic Roll call 20:02:20 Wait a minute.. 20:02:20 coup d'état! 20:02:21 Is the bot busted? 20:02:25 #endmeeting 20:02:32 #chair sbalukoff 20:02:33 Current chairs: blogan sbalukoff 20:02:49 Ok, looks like brief network interruption. 20:02:51 sbalukoff: your client must have errored 20:03:14 please dont punish me dear leader, i wasn't trying to take over 20:03:22 mutiny! 20:03:29 FLOG HIM 20:03:32 Can y'all see what I'm typing? 20:03:33 Hi 20:03:38 yes 20:03:40 ye 20:03:40 sbalukoff maybe re-log mang 20:03:44 sbalukoff, we see you 20:03:47 I'm beginning to think I'm having some major network issues on my end. 20:03:52 Crapsticks. 20:04:07 lol 20:04:16 sbalukoff: can you see what WE'RE typing? :P 20:04:25 is sbalukoff saying anything? 20:04:29 yes 20:04:33 jk. i can see him. 20:04:39 Can the real sbalukoff please stand up? 20:04:47 I'm going to attempt a re-connect. Apologies, folks. 20:05:04 sbalukoff is abot 20:05:09 ok now that he is gone ... 20:05:24 Ok, back now? 20:05:27 yup 20:05:33 yep, your bot is back 20:05:35 we can see you, but can you see us? 20:05:36 no, i can't see you 20:05:40 Yay! 20:05:43 Ok, that's annoying. 20:05:51 #topic Announcements 20:06:05 good thing all of that got into the meeting log 20:06:05 Ok! So! 20:06:13 Indeed. 20:06:26 Has anyone heard back about the design summit schedule yet? 20:06:38 mestery posted a thread on the ML 20:06:38 kyle posted the tentative schedule to the ML. 20:06:58 Ok, cool. Did Octavia get a session? 20:07:14 i dont think anything lbaas got a session 20:07:18 #link https://etherpad.openstack.org/p/kilo-neutron-summit-topics-distilled 20:07:20 no, it did not. 20:07:33 Damn. Ok, well then I guess we'll be collaborating in the pods. 20:07:39 closest sessions to us are one on splitting out services and one on splitting out drivers. 20:07:59 and thats fine, i think we'll get more out of a design session in a closer setting 20:08:04 Forgive me, session different than a talk? 20:08:14 yep 20:08:15 TrevorV: yes 20:08:17 both of those sessions I can support 20:08:30 rm_work just hooked me up with a response :D 20:08:34 For those not attending the summit: Would you like those of us who are to post a schedule or something of when we're going to be trying to get together so we can collab with y'all offline? 20:08:43 that sucks! 20:08:46 yes 20:08:54 I am hoping some stuff will be streamed 20:08:55 sbalukoff, some of us night-birds would love that... :D 20:08:55 (Keep in mind this will be EU timezone appropriate--- meaning it'll be at very odd hours for you.) 20:09:06 sbalukoff: you mean normal hours for me 20:09:17 #action sbalukoff to come up with collaboration schedule for summit prior to summit 20:09:27 Ok! 20:09:36 also keep in mind that we will be snobbishly consuming wine and cheese at the top of the eiffel tower while you try to connect. 20:09:44 The other thing I wanted to announce: If it ain't in gerrit it doesn't exist. :) 20:09:48 dougwig: +1 20:10:07 add that to comment to doesdouglikeit.com 20:10:12 dougwig: I was there last April (3 floor of the Eiffel tower) and it is pretty cool! 20:10:14 Basically, what I mean by that is, I've noticed that while some blueprints have been assigned for several weeks now, we have yet to see anything concrete. 20:10:38 johnsonm is busy working on it 20:10:41 yeah, it's hunting season. 20:10:41 Add to that the fact that in a large project like this with people coming from many companies, people can get pulled off this project without warning. 20:10:59 dougwig: Haha! Noted! 20:11:02 well, we all have our ptoduction issues 20:11:04 It's also vacation season for some. 20:11:13 Yes, but what I mean is: 20:11:14 ;-) 20:11:45 http://i.imgur.com/SvVv6hg.jpg 20:11:47 Even if you don't have much to share, I would like to see what you have in gerrit (checked in with -1 workflow) so that people can know where you're at. 20:12:12 +1 sbalukoff 20:12:15 +1 20:12:22 The last things we need is for someone to spend a month working on something important that others are waiting for, only to get reassigned 2 days before it's "ready" for review. 20:12:39 or 2 days before they go on vacation 20:12:47 yep 20:12:51 or a forced vacation... 20:13:00 Yeah, I'll try to get my TLS blueprint stuff in Gerrit before the summit... 20:13:08 So, going back to the idea of trying to be courteous to those who are in charge of blueprints assigned to them: The other half of that relationship is keeping people up to date with progress in the form of code / specs / whatever in gerrit. 20:13:09 well, then they can keep working ... to build their res8ume 20:13:19 +1 20:13:25 to sbalukoff 20:13:32 Any questions or concerns about this? 20:13:44 sounds good to me 20:13:48 same 20:13:50 totally agree 20:13:53 +1 20:13:56 +1 20:14:15 #resolved If it ain't in gerrit, it doesn't exist. 20:14:25 I don't know if that's actually a tag. 20:14:32 Anyway, moving on 20:14:34 sbalukoff: oh, what if it's in Launchpad? 20:14:42 I've been using the Launchpad whiteboard :P 20:15:09 rm_work: If what you're working on requires feedback, gerrit is the place for that. 20:15:17 But yes, keeping launchpad up to date is a good idea. 20:15:39 Again, the idea here is to increase communication in appropriate ways, and to try not to lose the work of someone who gets re-assigned. 20:15:42 well there will be some time delay between assigning yourself to a blueprint and getting your thoughts organized and written down into a spec 20:16:18 yep 20:16:22 rm_work: Does that make sense? 20:16:26 yes 20:16:29 Ok. 20:16:32 Moving on! 20:16:34 and gerrit is not a godd tool for brainstorming 20:16:34 #topic Reviews Needing Attention 20:17:13 I think the biggest one here is Brandon's and Trevor's work on the Operator API. 20:17:17 there is the massive, horrificly large operator-api review, i expect that to take some time 20:17:20 Lots of code there, needs some eyes. 20:17:39 #link https://review.openstack.org/#/c/121233/ 20:18:18 Anyone else want to pitch a review needing eyes? 20:18:34 ajmiller? 20:18:49 Yes, getting the link 20:19:27 https://review.openstack.org/#/c/130002/ 20:19:52 also the amphora API spec 20:19:57 #link https://review.openstack.org/#/c/126801/ 20:20:11 Oh yeah, that. 20:20:12 ;) 20:20:16 I've gotten feedback form several folks already, have posted one set of patches, and am working on another. 20:20:29 which id like to discuss with you after the meeting, or in open discussion 20:20:36 sbalukoff ^^ 20:20:44 blogan: Sounds good. 20:20:52 Ok, anything else? 20:21:02 ajmiller: thanks for getting that up 20:21:07 +1 20:21:20 Yes, thanks, ajmiller! 20:21:21 my pleasure 20:21:33 Ok, next topic... 20:21:36 #topic Logging requirements discussion (jorgem) 20:21:41 jorgem: Take it away! 20:21:47 alrighty 20:21:54 everyone read my mail on the ML? 20:22:05 Let's assume "yes" 20:22:06 ;) 20:22:12 If not please do. 20:22:19 I'm trying to build requirements for usage and logging 20:22:38 so far xgerman opposed for scaling reasons? 20:22:38 When you say "usage" what do you mean? 20:22:44 * dougwig cries for UDP 20:22:45 ("logging" is clear to me.) 20:22:50 tracking usage, billing usage and real-time usage 20:22:57 * sbalukoff kicks UDP while it's down. 20:23:05 Oh, right. 20:23:10 billing should be in ceilometer 20:23:24 All three of those are things Rackspace needs 20:23:29 jorgem: By Billing usage I am assuming you mean metering. right? Billing is different to me 20:23:40 sure 20:23:42 :) 20:24:02 * dougwig cries for UDP (<-- since you kicked it, it repeated) 20:24:06 So I wanted to clarify on the cielometer thing 20:24:14 ok 20:24:26 I don't think we are going to be using that but others will be (HP ahem) 20:24:33 UDP = good :-D 20:24:45 yep, we have ceilometer as a requirement 20:24:53 I still think the other pros make logging worthwhile 20:25:02 ah stateless protocols... they are great until engineers try to overload them... 20:25:05 jorgem: +1 20:25:15 Do you think of logging for general running or diagnosing what broke? 20:25:20 the amount stored after sending to cielometer can be modified 20:25:43 so my email has the arguments for it 20:25:54 but to answer your question quickly... 20:26:10 diagnostic support for technicians is one reason I want it 20:26:22 usually people want logs after the fact 20:26:35 and then they find out they don't have them :( 20:26:42 jorgem +1 20:26:54 +1 20:26:57 anyways we can continue on the ML as it is a heavy topic 20:27:02 sballe and xgerman: Would it be possible for you to draw up your requirements around ceilometer usage and share that in jorgem's thread on the ML? 20:27:15 that would be great sbalukoff +1 20:27:46 I'm thinking that having *all* the requirements laid out somewhere (and probably eventually documented in the project) will help us to make sure we're solving for use cases that people are actually going to need. 20:27:52 Also I'd like people to add what kinds of usage parameters they want to track/bill for. 20:28:01 i think the main concern is the large amounts of data this will require, but if fine tuning of it can mitigate it then I wouldn't have a problem with it 20:28:01 jorgem: We need to store the logs in a centralized logging service. 20:28:05 jorgem: +1 20:28:09 bandwidth in/out, concurrent connections, uptime etc. 20:28:31 To me what we do with the logs are different than what we do with Ceilomter. It serves two different purposes 20:28:56 #action Everyone with usage and logging concerns to share their specific requirements on ML in jorgem's thread. 20:28:56 yep + logs from all load balancers will be heavy so we need to see how that scales in parctice 20:28:58 sballe: from my understanding, you would analyze the logs to determine the usage and send those numbers to ceilometer 20:28:59 sballe: +1 20:29:08 sballe: +1 20:29:14 correct but the granular data the logs provides can serve both. Polling usage is messy 20:29:39 its how you analyze the data that makes it a different use case 20:29:40 yeah, hence it was proposed to have the amphora emi that straight to ceilometer 20:29:44 the logs are used for SOC compliance, to debug what is wrong with a system, etc... 20:29:45 I just want to use the same raw data 20:29:57 We also get users who want "as up to date as possible" real-time usage information for dashboards and whatnot (not strictly used for billing) 20:30:15 To be clear I'm envisioning apache style request logs 20:30:27 jorgem: We analyze the data in or centralized logging services 20:30:36 sbalukoff: real-time usage would be another item I want 20:30:46 not if we debug a problem here and now 20:31:09 I'll elaborate on the ML sballe. I don't think I've been clear enough 20:31:23 but your insight into what you'd like would be helpful as well :) 20:31:52 Yep. 20:32:16 Ok, anything else on this topic, jorgem? 20:32:22 Also this is from my experience building 4 usage collection systems 20:32:43 sbalukoff: We can move on I think ML is the right forum for this discussion 20:32:52 jorgem: Yeah, I look forward to not repeating any pain y'all went through doing that. XD 20:32:53 jorgem: Have you looked at somethign like lumberjack to forward the logs real time? 20:33:34 We don't do that on our end. We use hadoop but I've heard of it yes 20:33:57 flume I believe is the real-time forwarding for haddop 20:34:05 yep, 20:34:24 So many log puns... 20:34:30 :) 20:34:33 Ok, moving on! 20:34:37 #topic Progress reports 20:34:55 So this topic is mostly about where we're at on the blueprints assigned to us. 20:35:19 For my part: Vacation was excellent! And I totally didn't get anything done on the stuff assigned to me as a result. 20:35:59 blogan: We've already heard you need eyes on the operator-api review. How are things going on that otherwise? 20:36:20 just waiting on feedback really 20:36:35 im sure there is plenty of feedback people will have 20:36:52 i know its massive though 20:36:52 Ok, no major changes envisioned at this point (other than probably minor stuff brought up in review)? 20:37:10 yeah unless someone comes in and says they don't want to use pecan or wsme 20:37:35 dougwig: Could we get a progress report on the network driver and neutron implementation stuff? 20:38:24 so far, initial research complete, but nothing written up (not in gerrit, doesn't exist). between hunting and coordinating an office move, i don't expect to have cycles until nov 1. 20:38:42 lol you mean until the summit 20:38:42 dougwig: Ok, so just in time for the summit. 20:38:57 lots of airplane time on the way to the summit, yes. :) 20:39:02 just in time to have discussions about it 20:39:07 Anyway, hopefully we can collaborate on this then, eh. 20:39:08 Yep. 20:39:11 bc im sure there is a lot of things to discuss on it 20:39:28 Is johnsom around? Does anyone know where he's at on the base image work? 20:39:36 he gave an update last wek 20:39:37 week 20:39:53 Ok, no change since then? (HP folks?) 20:40:28 He is dealing with an operations issue this afternoon. 20:40:40 and I was on vacation 20:40:47 ajmiller: Got it. 20:40:49 but we are slowly getting back into the groove 20:41:14 german gets his groove back! 20:41:21 ajmiller: I'm guessing your update is "need eyes on my review" right? Anything else you'd like to share on that one? 20:41:24 blogan: +1 20:41:49 yes, that's basically it. I will be posting a patch with whatever current feedback I have later this afternoon. 20:42:09 Sounds good. 20:42:19 Ok, any other progress reports y'all would like to share? 20:42:29 Barbican is a moving target 20:42:35 :-( 20:42:40 I'm going to try to get stuff out today though 20:43:07 I think we're going to copy Cinder/Nova and have it actually be a "Certificate Manager" interface, with a Barbican implementation 20:43:33 by "we" do you mean Octavia? 20:43:38 yes 20:43:38 rm_work: Wow, that sounds like a significant change. 20:43:52 Cool. 20:43:55 oh, I thpught rm_work was using the royal we 20:43:55 I might try to schedule a hangout to discuss at some point 20:44:07 need to figure out when people have some time 20:44:16 im sure this affects neutron lbaast oo 20:44:20 basically, I could use eyes on: https://blueprints.launchpad.net/octavia/+spec/define-barbican-touchpoints 20:44:21 rm_work: Sounds good. You know how to get a hold of us, eh. :) 20:44:25 the whiteboard section 20:44:45 blogan: it's... yeah. it's interesting. probably will also do the same thing in LBaaS 20:44:49 Ok, moving on... 20:44:54 #topic Open Discussion 20:45:11 Aah... wonderful. I see I'm getting random IRC delays again. 20:45:11 amphora API spec 20:45:21 how convenient 20:46:14 blogan: Let me try reconnecting again, as that seemed to make a difference last time. 20:46:35 okay 20:47:02 Ok... 20:47:20 (Part of the reason I like connecting from home: Office wireless suuuuucks. :P ) 20:47:36 blogan: Did you want to discuss the amphora API spec? 20:47:39 yeah 20:47:48 me too 20:47:49 i replied to your comments 20:48:00 I saw that, haven't had time to reply back yet. 20:48:16 But seeing as how we're here... 20:48:16 well i guess im just concerned that there is the possibility for it to connect to the octavia database 20:48:18 each amphora 20:48:29 blogan: Nope, there shouldn't be. 20:48:34 okay good 20:48:37 amphora should not have that kind of access. 20:48:42 yes agreed 20:48:46 that would be bad voodoo 20:48:52 And if I'm giving that impression, I've either not thought something through or misspoken. 20:49:22 Yeah, amphorae can't be trusted that way-- they're going to be targets of attacks. 20:49:59 okay so then, how does the API decide whether an haproxy instance is in an PENDING_CREATE/PENDING_UPDATE/PENDING_DELETE 20:50:01 Ok, so, I'll respond to your comments with that in mind. Any other major concerns there? 20:50:12 oh okay we can wait till comments 20:50:13 thats fine 20:50:32 I am curious how the amphora API initiates a secure connection to the controller 20:50:42 ssl certs? 20:50:46 and by that I mean, secure in both directions -- IE, server/client cert 20:50:47 yeah 20:51:04 but, will each amphora API spin up with its own cert? is the cert part of the base image? 20:51:21 rm_work: Controller / driver needs to have an API interface on the same network as the amphorae, and yes, authentication / encryption is handled through bi-directional certificate verification. 20:51:24 in libra's case cert is part of base image 20:51:40 Which piles a whole bunch more crap on the barbican plate. :) 20:51:40 ok, so I am interested in the specifics of how we'll set that up 20:51:50 sbalukoff: i don't know that that's true 20:52:11 I thought so originally, but i think it may actually not be barbican related at all 20:52:14 rm_work: I was planning on telling you "You handle this!" 20:52:16 kidding 20:52:22 which is part of what I wanted to discuss in a hangout :P 20:52:26 Haha! 20:52:35 Yeah, so I've got some ideas there, but it sounds like you do to. 20:52:42 what are you guys up to in... uhh... 8 minutes? :P 20:52:44 I also know how we handle it in our current environment... 20:52:44 well, I am ok if we bake it into the image for 0.5 20:53:05 xgerman does that mean the same cert across all amphora? 20:53:13 yeah probably 20:53:17 TrevorV: Yes. 20:53:17 yes 20:53:59 if we use different certs for each amphora we need a secure mechanism to get them there + a plan when we fail over an amphora 20:54:11 rm_work: So, 6 minutes from now sounds like it's not going to work, but I could do later this afternoon. 20:54:22 xgerman: Correct. 20:54:24 sbalukoff: lol, later this afternoon 20:54:34 that works for me I guess, but it's already 4pm :P 20:54:49 let me know when you could, ASAP is great for me since this is a blocker for a bit of work 20:54:52 rm_work: Or tomorrow or Friday if that's better. If this isn't urgent / a blocker for you. 20:54:56 lol 20:55:04 Haha 20:55:06 Ok. 20:55:17 yeah, if you need me or johnsom I can arrange for that :-) 20:55:21 Let's say... 30 minutes from now? 20:55:33 kk 20:55:38 rm_work: PLease ping me if I am around. I am interested in this topic. 20:55:40 (Also, I have no idea whether the sound on this new laptop works. I may need to literally phone in. 20:55:47 xgerman / sballe could be good to have you on, yeah 20:55:52 xgerman: you or johnsom or both should get involved too, sounds lke yall can add some valuable insight 20:56:02 * TrevorV thinks sbalukoff should use a smart phone like rm_work 20:56:13 what is a "smart phone"? 20:56:16 lol 20:56:20 Haha! 20:56:24 well, I have a meeting 30 minutes but I am free after 3 pm PST 20:56:26 anything better than blogan's dumb phone 20:56:34 my phone is awesome 20:56:41 Is 3:00pm too late for you, rm_work? 20:56:44 ok so, 3pm PST? 20:56:45 (PDT) 20:56:45 nah 20:56:46 flip phones were cool in the 90 20:56:48 s 20:56:55 I'm here till like 7pm CST 20:56:55 That's an hour from now. 20:56:58 yep 20:57:11 ok I will join too. 20:57:14 kk 20:57:15 Great! Gives me a short window in which to troubleshoot sound problems on my laptop 20:57:22 :-) 20:57:25 Ok, folks. 20:57:27 awesome 20:57:31 kk 20:57:33 We're almost out of time. 20:57:49 Anyone have anything else they'd like to say in the last 2 minutes? 20:58:14 nope 20:58:19 I'd like to say: Word. 20:58:32 Ok, folks! Thanks for your participation! 20:58:36 #endmeeting