20:00:12 #startmeeting Octavia 20:00:13 Meeting started Wed Apr 8 20:00:12 2015 UTC and is due to finish in 60 minutes. The chair is xgerman. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:17 The meeting name has been set to 'octavia' 20:04:34 o/ 20:04:34 o/ 20:04:34 o/ 20:04:34 #chair blogan 20:04:34 o/ 20:04:34 o/ 20:04:34 hi! 20:04:34 o/ 20:04:34 Current chairs: blogan xgerman 20:04:34 #topic Announcements 20:04:34 o/ 20:04:35 meetbot stopped yielding to my commands 20:04:35 #action xgerman pull out hair 20:04:35 i asked about it in infra. 20:04:35 * blogan kicks meetbot 20:04:35 thanks 20:04:35 i think we can carry on... 20:04:35 yeah 20:04:35 #link https://www.youtube.com/watch?v=dQw4w9WgXcQ 20:04:36 * TrevorV kicks blogan 20:04:36 ok, after all the kicking - any announcements? 20:04:36 Anyhting from the Neutron meeting? 20:04:36 two notes. 20:04:36 RC1 is being cut tomorrow, so any last minute kilo bug fixes need to be in the merge queue today. 20:04:37 and the neutron mid-cycle for Liberty has been announced: https://etherpad.openstack.org/p/neutron-liberty-mid-cycle 20:04:37 #link https://etherpad.openstack.org/p/neutron-liberty-mid-cycle 20:04:44 * blogan hugs meetbot 20:05:03 meetbot is sleepy today 20:05:07 ok, meetbot was just getting a coffee 20:05:12 +1, sleepy day 20:05:49 no more announcements? 20:06:02 nope 20:06:14 #topic Brief progress reports 20:06:36 none from me. i need to switch from Kilo to the neutron-lbaas driver this week. 20:06:40 Ive made a couple updates to templater. Begining to test drivers 20:06:42 ssh_driver under review 20:06:51 * blogan kicks dougwig into action 20:07:01 api server almost done 20:07:01 I'm also updating the API PUT methods to have database updates after the queue 20:07:02 Controller worker is progressing. All of the framework is there. I'm adding driver plugins with stevedore today. 20:07:15 Octavia devstack plugin is getting close. 20:07:35 #link https://review.openstack.org/#/c/167796/ 20:07:38 network driver is almost complete, i will need to coordinate with johnsom on the changes needed from the controller worker's perspective 20:07:42 TrevorV, I want to talk about that later in the agenda 20:07:58 johnsom: Do you have a timeframe on when you think the controller worker will no longer be a WIP? 20:08:24 I have one TODO in there about shutdown tasks, for which I need working control plane to finish. 20:08:48 jorgem That depends on our discussion about the api/db. I hope in the next week or two 20:09:08 johnsom: Gotcha, I'm guessing we will be talking about that later in the meeting 20:09:10 ajmiller: thanks, this will be great to have once we have an end 2 end 20:09:40 yep, people will want to download an dplay with it right after the demo in 6 weeks 20:10:47 sorry, disconnected for a bit there... 20:10:51 also mwang2 did some more work on the health manager and sballe is closer with the REST based driver 20:10:55 we had methos for health check in amphora driver, please reveiw and comment on the code too 20:11:03 #link https://review.openstack.org/#/c/170599/ 20:12:06 any more progress? 20:12:21 johnsom you had to talk to me about something? Do you mean outside this meeting? 20:12:29 mwang2: just commented on that review 20:12:54 TrevorV No, we can hit it in the API/DB agenda item 20:13:01 Alrighty sounds good 20:13:05 blogan: thank you , let me take a look 20:13:05 ok, 20:13:13 #topic Summer Midcycle for LBaaS/Octavia 20:13:45 dougwig suggested having one and I was thinking about opening up to VPNaaS and FWaaS as well 20:14:02 dougwig wanted to do it in boise 20:14:32 i wouldn't be opposed to anywhere. certainly boise is available, but the group can decide. 20:14:52 Doesn't everything close at 7 in Boise? 20:14:57 I can offer Seattle 20:15:11 we can offer San Antonio 20:15:14 * blogan shrugs 20:15:16 lol 20:15:23 johnsom: ha. 20:15:25 How about Hawaii? 20:15:33 :) 20:15:38 +2 for Hawaii 20:15:44 RAX is sponsoring! 20:15:45 We won't be able to go but you guys can! 20:15:51 lol 20:15:56 Hawaii, TX? 20:16:01 in boise, we can go out into the desert and shoot holes into hard drives containing v1. 20:16:05 Sadly, that probably exists 20:16:14 +1 dougwig 20:16:17 sounds fun! 20:16:24 anyway, vpnaas, fwaas i dont mind joining, but that means there might need to be separated areas 20:16:36 vpn is usually just paul. :) 20:16:59 oh well i dont want him to come 20:17:01 and FWaaS is a cardboard cutout 20:17:15 im kidding 20:17:48 fwaas guys usually push for the bay area 20:19:09 well, let's start an etherpad? 20:19:19 and kick around some dates/venues 20:19:50 also if we don't do some 150 mile radius around San Antonio how many of you can come? 20:20:00 I will start one 20:20:07 :/ 20:20:13 #action johnsom start midcycle etherpad 20:20:23 i will pay own way to drive a day a way. I would like to be part of these 20:20:29 xgerman: hard to say right now, we shall see 20:20:47 mexico! 20:20:56 +1 20:21:00 Thats def within a days drive ;) 20:21:00 juarez? 20:21:26 ptoohill: so you saying stay in Texas then right? 20:21:28 lol 20:21:30 i'm down for the bay 20:21:38 :P 20:21:44 eh, i can no-doze it 20:21:45 bay area attracts too many tourists, IMO. 20:21:46 #link https://etherpad.openstack.org/p/LBaaS-FWaaS-VPNaaS_Summer_Midcycle_meetup 20:21:56 I just want to be part of these. 20:21:59 dougwig: maybe for neutron 20:22:33 ok, let's move on 20:22:52 #topic Confirm API Server vs. Controller Worker database updates 20:22:54 Wait is this conversations concerning Octavia meetup or LBaaS meetup? 20:23:10 Octavia, LBaaSm VPN, FW 20:23:10 btoh 20:23:25 since the last two don't have a home 20:23:48 Ok, so I am about to update the controller worker code for the database changes we have talked about previously. 20:24:01 TrevorV: merged octavia/lbaas. 20:24:10 I want to make sure that the Consumer Worker as coded here: https://review.openstack.org/#/c/149789/16/octavia/controller/queue/endpoint.py 20:24:17 is the current plan. 20:24:46 johnsom: yes, the idea was to make controller workers calls 20:24:58 Meaning, when I am passed an ID the database was updated by something upstream of controller worker and I will reference. 20:25:31 negative I believe the worker is updating the database 20:25:42 the queue consumer is just a pass through delegator 20:25:46 For updates I will be passed an object representing the end game for the object and I will update after success. 20:25:48 johnsom: the controller would update the entity to the object htat was passed to it 20:26:09 johnsom: the object passed to it will probably be a dictionary, and updated as a PATCH 20:26:25 on updates you are given the updates as well as what is currently in the db 20:26:39 oh wait err 20:27:00 updates are passed to you along with id 20:27:08 so that you can make the appropriate db changes 20:27:20 and it will be update by patch, not full replace 20:27:21 So, where is the data when I get "load_balancer_id" passed in for create_loadbalancer? 20:27:38 in the database 20:27:39 johnsom: yes in the db 20:27:57 johnsom: the api will insert on create 20:27:59 xgerman: I am here sorry my other meeting ran over :-( 20:28:24 cool 20:28:59 johnsom: The reason you need to update is that in the case of failure there is no way to go back to a good state in the db 20:29:04 Ok, so where I only get IDs, you guys have already handled the DB insert. I only need to update status when I'm done and update DB for the changes passed in the update dict. 20:29:19 correct 20:29:25 Yeah, I'm good on the update. Just wanted to make sure on the rest 20:29:39 johnsom: yes, you can always assume the object is there, its just on updates and deletes, you will need to make the update and delete calls to the db after the entire workflow has been successful 20:29:53 Perfect! 20:30:10 * TrevorV feels like johnsom didn't actually need him 20:30:18 if updates fail you rollback and the db doesn't get updated 20:30:33 what about marking ERROR? 20:30:35 still on the fence about putting the lb in an "ERROR" state in that case 20:30:41 +1 20:30:45 this is for 0.5 however 20:30:46 xgerman: i think it should be marked as ERROR, but it'll still be running 20:30:56 for 1.0 we would want to make this more robust 20:31:06 yeah thats how i see it 20:31:13 mmh, so we have ERROR = broken and ERROR=still running 20:31:13 TrevorV You mentioned API PUTs db and queue, so thought it might be related 20:31:28 It is, ha ha, my teammates just answered for me 20:31:30 or perhaps a new status like "UPDATE_FAILED" 20:31:30 :( 20:31:32 well there needs to be some way to tell the user that something bad happened and their changes did not happen 20:31:39 jorgem +1 20:31:52 again this if for 0.5 20:32:01 so we can still live with ERROR for that 20:32:05 not sure i like a lot of statuses 20:32:09 Currently I am putting ERROR in on failure 20:32:09 Do we not have a event feed planned? 20:32:11 I really want to get to something demoable ASAP 20:32:15 I like putting it into error state... since error state doesn't mean they're not serving traffic, it means something failed. 20:32:16 well, you know how bad things have a live of their own :-) 20:32:19 maybe we should add another field that can say what went wrong 20:32:38 An event feed would be better solution 20:32:41 a boolean field, called "towed" 20:32:48 ptoohill-oo: that will come in the future 20:32:57 lol 20:32:58 +1 towed 20:33:02 So add a field for now? 20:33:16 Then remove later because useless? 20:33:34 how bout just put it in ERROR for now, and improve it afetr the demo? 20:33:45 Too easy 20:33:46 I say leave as ERROR status since we are going to update the whole proivisiong error stuff in 1.0 anyway 20:33:46 I think OP_STATUS = ONLINE and PROV_STATUS = ERROR makes sense. 20:33:48 I think status codes are cheap 20:33:49 Let's get controller worker in with ERROR and revisit 20:34:00 +1 20:34:02 +1 blogan 20:34:18 again we want to have a demo in time for summit right? 20:34:19 but +1 20:34:24 xgerman: they're cheap, but feature creep likes to creep 20:34:37 Yes, we really want a demo for summit 20:34:47 6 weeks 20:34:49 4 weeks now 20:35:18 johnsom: i still need to get with you on the network driver changes, and also the amphora driver changes 20:35:25 johnsom: Was the db thing the only item you had questions on? 20:35:28 crc32 you are taking vacation? 20:35:32 bc that will change what you insert in the db, and what you call 20:35:40 jorgem, yes, that was my topic 20:35:56 blogan after this meeting chat? 20:35:57 ok, moving on? 20:36:01 johnsom: Cool let me know when I can review once you get the rest of your changes in 20:36:10 #topic Review what still needs to be completed for the end to end demo 20:36:13 johnsom: sure or i can just bring one of the items up as another topic at the end 20:36:23 +1 20:36:28 Still could use more eyes on the ssh_driver review 20:36:30 I'll link 20:36:41 jorgem you can hook up now, just no guarantee it will do the right thing yet 20:36:46 #link https://review.openstack.org/#/c/160964/ 20:37:24 blogan topic at the end works too 20:37:44 ok, so mostly we are lacking dougwig's lbaas-octavia driver 20:37:47 don't forget to review --> https://review.openstack.org/#/c/149079/ 20:38:25 k 20:38:57 so we have compute, network, amphora (ssh + hopfully soon REST) 20:39:07 controller worker, queue consumer 20:39:57 its almost end to end 20:40:21 We are close 20:40:24 +1 20:40:34 any chance HP can help accelerate horizon, so we can go from horizon to an amphora? 20:41:03 mmh, will try 20:41:12 also vijay might have that 20:42:30 #link https://review.openstack.org/#/c/149079/ 20:43:24 #topic Should Octavia use tempest or Rally for integration tests? - 2 20:43:51 should we vote? 20:44:00 did you guys have a chance to look? 20:44:00 i still believe tempest simple bc it is what openstack uses 20:44:11 +1 blogan 20:44:15 +1 20:44:22 it's not about religion... 20:44:35 +1 tempest 20:45:28 xgerman: do you have a compelling reason to switch? 20:45:32 i don't care either way REALLY, but that makes me side with tempest just because then we're not different from how the rest of Openstack operates -- does that make sense? :/ 20:45:43 I like the UI and also tempest-lib is a mess right now 20:45:56 its not, but i fear the day that we would have to refactor tests to use tempest from rally because of some rule 20:45:58 Wondering if we are asking the right question... Doesn't Rally run tempest as an action? 20:46:00 +1 cloudcafe 20:46:10 lol 20:46:12 Do we know how many openstack projects have plans to move to rally? 20:46:14 * crc32 slaps fnaval around a bit with a large trout 20:46:20 oh, i mean opencafe 20:46:51 data points: rally was just accepted as an official openstack project. also, i don't know of any plans for neutron itself to abandon tempest. 20:47:12 my gui is SSH, so i have no opinion on that point. 20:47:28 same, lol 20:47:32 your gui is OS X crap 20:47:40 i would be fine using rally if it was req and/or other projects are moving to it. But, on that note, theres nothing stopping anyone from doing rally and/or tempest is there? 20:48:20 yeah similar to what we do with opencafe/cloudcafe 20:48:25 ptoohill the only thing is that we should have consensus. If we're using rally, we should use rally. Supporting 2 different technologies to complete a test suite is a bad idea. 20:48:26 time to vote? 20:48:33 well, our jobs are running vanilla devstack-gate, which is tempest aware. but then we override it and call tox, so I guess it could run anything. 20:49:03 a vote is fine with me. 20:49:15 bad idea? 20:49:25 dougwig: it could, but tempest has the "seal of approval" for openstack, even with all its warts 20:49:33 Tell that to all the people doing the same sort of thing now because different people have different reqs 20:50:28 blogan: i said we "could". that's just sharing a fact. scroll up, and see that i'm pro-tempest. 20:50:35 ptoohill just remember when we had Cloud Cafe when it sprung up but we still had SOAP tests. It was a nightmare. I don't want something like that again. 20:50:36 not to mention people who write tests for openstack will know tempest, they may or may not know tempest, so there woudl be a learning curve for them 20:50:48 dougwig: i just like to counter everything you say 20:50:50 we migrated away from soap because they sucked 20:51:15 anything in the proximity of soap sucks. that mess infects everything near it. 20:51:16 blogan: *rally? 20:51:20 tempestI thought it was because it was SOAP 20:51:26 #link https://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler 20:51:34 they mean soapui, which was worse than soap 20:51:54 I'm all SOAPed out just from CLB 1.0 20:51:55 ptoohill: yeah, correction 20:52:02 Either way, I don't like supporting both. One or the other. 20:52:05 that was the reason we went with opencafe stuffs. My point was that if we do something in tempest because we want to follow what other openstack projects are doing theres nothing stopping another company from writing rally tests and submitting those 20:52:36 lets just vote. I'm wondering where every one stands. 20:52:57 we can always defer after the summit and see how things look there 20:53:00 I still think they are two different animals and not an either/or choice 20:53:01 rally seems to be more geared towards performance testing with the ability to do other things 20:53:04 since we have nothing to test anyway 20:53:32 rally for performance testing 20:53:36 xgerman: im fine with re-evaluating later when we actually start writing tests 20:53:42 with the ability to do other things 20:53:44 it is a bit premature 20:53:55 we can keep deferring this until german gets his UI, but ... 20:54:00 lol 20:54:35 It does make nice pointy hair complaint pictures.... 20:55:17 ok, let's defer after the summit with a preference for tempest tests 20:55:20 didn't that blog link show how to use rally to run tempest? so can't you use rally either way? 20:55:31 probably 20:55:35 yeah, so if you want to use rally, just do that? 20:55:36 i can't say as i feel strongly either way. 20:56:31 ok, I guess this is settled somewhat 20:56:46 anyone that wants to peek at a devstack fix, to make our job cleaner: https://review.openstack.org/#/c/171402/ 20:56:55 oh wait, we're not in open discussion. sorry. 20:56:56 #topic Rally automatically installs and configures Tempest, and automates running Tempest tests. 20:57:14 sorry 20:57:19 #topic: Open Discussion 20:57:23 lol nice topic 20:57:37 xgerman: back to rally vs tempest, sounds like rally would just be the test runner then 20:58:24 okay on to my topic 20:58:33 you have 2 minutes ;-) 20:58:47 just like we need a post_network_plug method in the amphora driver, we need a post_vip_plug method 20:59:19 bc when you plug a vip, you may have to do some work on the amphora (such as bringing the interface up) 20:59:33 Ok 20:59:36 but plug_vip is only called once, so post_vip_plug would only be called once 20:59:47 worst case, post_vip is "pass". 20:59:52 yep 21:00:05 which is why it would not be tagged as an abstactmethod 21:00:33 times up, game over 21:00:41 #endmeeting