22:00:35 #startmeeting reddwarf 22:00:35 Meeting started Tue Dec 11 22:00:35 2012 UTC. The chair is hub_cap. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:00:36 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 22:00:38 The meeting name has been set to 'reddwarf' 22:00:39 i mucked it up :D 22:01:04 yo 22:01:09 yo yo yo 22:01:13 Greetings. 22:01:15 ok so lets start w/ last wks action items 22:01:16 http://eavesdrop.openstack.org/meetings/reddwarf/2012//reddwarf.2012-12-04-22.00.html 22:01:25 #topic update to action items 22:01:25 hola 22:01:55 let me start by sayign i didnt update the meeting page for reddwarf, but i think we have some stuff that got moved to chat about 22:02:03 so 22:02:08 is dkehn around? 22:02:12 dkehn is in the air, so I can give an update. 22:02:16 hello there 22:02:23 hah nice SlickNik tell us about keystone 22:02:39 (he's on an airplane :)_ 22:02:48 did yall figure out all u need about the daffy users (no pun intended) 22:03:11 there's some random picking of users in some tests that might need it. 22:03:35 So we decided that we'd create them tentatively and once we have the tests running, we would clean the list up if needed. 22:03:40 sounds good 22:03:49 next 22:03:53 gravy 22:03:58 vipul: did u file a bug in regard to tripelo image builder? 22:03:59 cool beans 22:04:15 hub_cap: I filed a blue print 22:04:22 # link https://blueprints.launchpad.net/reddwarf/+spec/migrate-to-diskimage-builder 22:04:24 ugh 22:04:26 #link https://blueprints.launchpad.net/reddwarf/+spec/migrate-to-diskimage-builder 22:04:32 hehe gotta love it 22:04:35 vipul: even better good sir 22:05:02 juice_ and kaganos are working on it 22:05:03 yes, everyone here is filing BPs these days. 22:05:05 ive approved it. id love to see it done 22:05:10 yup thats great news 22:05:16 Make hay while the lawyers let us… or something… :P 22:05:17 we did have some issues to bring up 22:05:25 maybe reserve that for later? 22:05:36 ya go head and edit the meeting adn put a space for it on the wiki 22:05:50 wiki.openstack.org/Meetings/RedDwarfMeeting 22:06:06 err on the page not wiki, lol 22:06:23 so vipul and i talked about the image stuff in regard to percona 22:06:43 since the images wont be in reddwarf, we can build any image on earth and not really worry about whats inside it 22:06:50 hub_cap, and that's something we'll need further discussion on 22:06:53 so there are no problems w/ having specialized images for companies needs 22:07:09 vipul: hmm ok sounds good, was there a change? 22:07:16 or will it still exist as it stands currently? 22:07:22 juice_, SlickNik? 22:07:29 so the idea is that... 22:07:33 Yeah, we just had a discussion with the tripleo folks and there's a change from that end... 22:07:41 my stance is as long as its not _in_ reddwarf have at it 22:07:57 Basically, they want the individual teams to own the elements (flavours) that they need built. 22:07:57 SlickNik: do tell 22:08:08 honestly i figured it woudl be that 22:08:14 it didnt really make sense that they would own the images 22:08:21 So they want the scripts/code for the image building to reside in red-dwarf. 22:08:30 so yall can have a repo/image you use and reddwarf can use stock mysql 22:08:36 and we can have one we use as well 22:09:00 only issue I have with that is we'll never be testing our imags in Openstack CI 22:09:00 there is a real subtle difference between the two flavors 22:09:03 most of it will be shared 22:09:17 so having a repo for one file is a bit over kill imho 22:09:17 vipul: ya i know, we have our own test infra to test out our stuff as well 22:09:23 SlickNik: Has image-building been generalized in Nova to the point where scripts and code to build images in Reddwarf would work with all virt drivers in Nova? 22:09:31 juice_: its not about the "overkill" 22:09:42 its about whethere we, as reddwarfers shoudl be supporting multiple flavors 22:09:47 i understand HP wants to support it 22:09:55 but reddwarf shouldnt be thought of as HP and/or rax 22:10:02 if a 3rd company comes in and says 22:10:11 Grapex: it's a work in progress, but they're getting there from what I understand. 22:10:15 i want my own flavor of mysql, johhny's mysql as a image 22:10:16 and they want their own type of flavor they should be able to do that 22:10:19 do we suppor that as well? 22:10:21 SlickNik: Wow. Cool. 22:10:24 yeah agree hub_cap 22:10:26 That'll be nice. 22:10:35 we shoudl support stock mysql 22:10:39 as deployed by ubuntu 22:10:47 yeah something as a standard 22:10:49 otherwise we eventually end up w/ pain 22:10:53 yep, completely agree, but at the same time, we need to enable that 3rd companay a way to come in and leverage existing image building tools we have in reddwarf to create their own 22:11:00 vipul: absolutely 22:11:10 so we need to think of a way to possibly generalize how we create these 22:11:11 and yall will build that path cuz u will be using percona image 22:11:16 +1 vipul 22:11:38 id love to have a way to generalize them, but again, when we run ci against it on jenkins, itll be on stock mysql 22:11:54 and a team can devote their own resources to running thier own custom images... 22:11:57 we need to have some sort of script/how-to/etc.. to make those images 22:12:09 right 22:12:24 i'd like to be able to provide a flag to Devstack or whatever, and have it run 'my' flavor or any other custom flavor 22:12:38 maybe what runs in CI is the image without that flag 22:12:41 thats not a bad idea ata ll devstack 22:12:49 *at all* 22:12:57 hub_cap: We could make a test config to choose the image run by the tests. If someone wanted to use a different image they could then run their own CI job. 22:13:06 grapex: ya that works too 22:13:18 we can work w/ monty and devstack team on that 22:13:43 just like when we run on debian, instead of ubuntu, we have to do that internally... nova def cares not about integrating w/ multiple os' 22:14:01 k, i think we need an offline discussion to further clarify things 22:14:01 and we have our own jenkins and such to run those jobs... im sure monty can work something otu for u ;) 22:14:05 vipul: def 22:14:18 lets move on 22:14:22 k 22:14:32 +1 on offline discussion, but let's move on. 22:14:34 SlickNik: default user? 22:14:46 any update to that... do yall _need_ it to be config'd? 22:15:20 Yeah, Steve and I looked at this. The reason I needed to use root was because the my_cnf was failing on my older redstack box for some reason. 22:15:46 I verified that it does run correctly now, and creates the os_admin user. 22:16:13 perfect 22:16:18 so we can squash that one? 22:16:20 We need to talk about whether those users will work for us @HP or whether we will need some other my_cnf. 22:16:25 was a bug/BP ever filed for that? 22:16:33 ok SlickNik lets leave it open then 22:16:40 yes, there was, I'll update it. 22:16:48 you can use "root" with no problem 22:16:50 #action SlickNik to discuss w/ HP about os_admin 22:17:03 as long as you enable it via the reddwarf-cli 22:17:17 hub_cap, SlickNik, steveleon: we may wnat to stick to the default user for now 22:17:35 vipul: config'ing a default user is very little work tho 22:17:43 so if u want ot do it, say the word 22:17:58 next, esp1 and grapex 22:18:00 lets talk test 22:18:02 ok 22:18:10 that default user cannot be "root"... root is already a user automatically 22:18:18 so we can just leave it as "os_admin 22:18:21 for now 22:18:43 yep I got some good feedback from you and grapex regarding tests 22:18:44 yep, should wait til we get some tests for guest agent 22:18:51 and are ready to implmeent some features before changing users 22:19:01 Re: tests. I've had fairly bad luck getting an active instance. 22:19:30 grapex: yeah I can only use flavor 1 to work currently. 22:19:46 esp1, grapex: i think there was an effort by esp1 to start a new set of integration tests, since the existing ones have a ton of dependencies and assumptions 22:20:02 New set? I think it was just a new group 22:20:11 it's just a new group 22:20:24 But anyway, you might not want to do that. I recently pushed a commit that took the MGMT API out of the "blackbox" group of tests. 22:20:43 was going to name it simple-blackbox-group or something less exciting 22:20:52 grapex, esp1: a new group being a subset of all the tests that are all ready there? 22:21:01 So now, if we run "./redstack int-tests --group=blackbox --stop" it should only run tests we expect to work. 22:21:25 so do those work at this piont? 22:21:32 or are there other things we need to debug through 22:21:36 The MGMT API being used in the tests was one of the biggest problems, but it turns out they were already well seperated from the other tests. 22:21:38 cp16net sort of. I currently have about 60 tests running in a consistent way for reddwarf-int 22:21:49 esp1: ok 22:21:54 vipul: I can't get an active instance so right now only a handful work for me. :( 22:22:00 But in theory all of them should run 22:22:13 keep in mind ATM the instance created by a test doesn't have a volume either 22:22:41 ok good info 22:22:49 how come weve dropped support for volume grapex? especially if vipul fixed it :D 22:22:51 So all it does it create a volume-less instance, and then run some actions against it such as resize. It seems like a goal we should be able to hit. Then we can turn on the creation of the volume in the test config. 22:22:56 do the tests still fail w/ volume? 22:22:59 grapex: if it helps I have my configs with volume support set to False. 22:23:26 hub_cap: I think so but I need to run those tests again to make sure. 22:23:30 hub_cap: We turned it off awhile ago. I noticed a failure in the taskmanager logs, but my VM isn't on par at the moment. 22:23:35 Maybe we can turn it back on. 22:23:37 hub_cap, grapex: I did verify that we can boot wiht volume support on 22:23:42 after that fix 22:23:46 sweet lets first get them runnin 22:23:51 and then readd volume tests 22:23:53 sound good? 22:24:00 so not sure if there are subtle differences in the tests usage of volumes 22:24:00 yep 22:24:02 id like to get them gating 22:24:17 hub_cap: yea good plan 22:24:21 well we will support default iscsi volumes vipul 22:24:52 supported by ubuntu's openiscsi version (Whateve that is :D ) 22:25:00 esp1, grapex: are you guys sync'd up? 22:25:04 okey, thats great work grapex esp1 22:25:14 ya we dont want duplication 22:25:34 #reddwarf is still a barren chat wasteland, lets try to use it more 22:25:44 I believe so 22:25:53 good deal, moving on! 22:26:04 so ill knock out both of mine 22:26:14 mgmt api-no progress, still on my list 22:26:20 working on oslo updates still 22:26:25 grapex: feel free to yell at me later if you want to compare configs 22:26:36 and ovz, we will have a resource devoted begin of yr so says the mgr folk here 22:26:44 esp1: Will do. 22:26:53 nice 22:26:59 ya itll be super awesome 22:27:05 cool.. 22:27:11 i really want to get it in the public 22:27:16 ive been pushing here 22:27:21 trying to get it bumped higher 22:27:45 yep, looks like the critical things are in place now 22:27:49 such as a keernel that support ovz 22:28:04 so let us know when you guys are ready - we can possibly get someone here to help 22:28:04 yup vipul that is super awesome thats _the_ critical thing for sure 22:28:22 vipul: cool! i know we have the driver 90% done so im not sure what we will need to do 22:28:32 but i _do_ know once we push it that there will need to be work done to it 22:28:53 so its less rax specific... we could have a goofy default or formula here or there that works well for us but maybe not everyone 22:29:07 k sounds good 22:29:14 so quotas.... has anyone talked to the openstack gurus on high about quota support? 22:29:18 i have _not_ 22:29:21 nope 22:29:34 nope 22:29:41 still pending 22:29:46 #action check with openstack folks on commonized quotas 22:29:53 cool. i will say its not super high prio for us right now 22:29:58 we will likely be using repose 22:30:17 repose does quotas too? 22:30:20 or just rate limits 22:30:48 hmm i thought it did do quotas 22:30:58 not sure.. 22:31:34 hmm ive been told it does, maybe its internal 22:31:35 if so thats weak 22:31:42 and we need support for it publicly 22:31:56 yea everything i see seems to be a high-level authz filter and rate limits 22:32:36 #action hub_cap to find out whats up w/ repose in regard to quotas 22:32:39 ill figure it out 22:33:09 so vipul did u ever set up a roadmapping session w/ your team? 22:33:18 Yeah, that's what the wiki at openrepose.org seems to think... no info on quotas... 22:33:19 should we wait till the new yr? 22:33:24 no, i think this may need to wait 22:33:36 yep, we've only got 1 more week and a shutdown 22:34:08 ok lets wait then till new yr 22:34:30 its prolly easiest anyway to wait till we are all avail, we shut down too here :P 22:34:43 ok then we are DONE w/ action items, woot! 22:35:17 looking@ the meeting it seems there is not much more that we dont have ironed out alrady, sans what vipul talked about earlier 22:35:52 but we talked about that _kinda_ right vipul? 22:36:10 im ok w/ discussing it more here if there is nothing else to talk about 22:36:12 I just wanted to give an update on the devstack integration piece... 22:36:17 yes 22:36:24 let's update on things that weren't brought up 22:36:33 #link https://github.com/dkehn/devstack 22:36:48 ok cool 22:36:58 #topic devstack integration 22:37:06 Don and I got reddwarf API and taskmgr up and running under devstack. 22:37:11 very nice! 22:37:25 are we lib/reddwarf? 22:37:30 Yes! :) 22:37:44 :D very nice 22:37:59 SlickNik, i think we're close to pushing upstream.. any ETA 22:38:04 We're still working out how we're going to build the guest-image, but that's the discussion we're going to have. 22:38:30 ya we will prolly need to do the guest-image stuffs before we push upstream right? 22:38:32 gj SlickNik 22:38:35 yup. 22:38:57 thatll be a fun one! any progress on the guestimage stuff to date? 22:39:13 We still need to figure out where to pull the right "elements" from, but we've got the tripleo disk-imagebuilder integrated… 22:39:30 define elements plz sir 22:39:43 for those of us (like me) who arent familair w/ tripelo imagebuilder 22:39:49 Basically flavors for disk-imagebuilder. 22:39:50 components that are composed together to make up a single image. 22:40:14 think of them as toppings ? 22:40:22 mmmmm toppings 22:40:34 the example the d-i-b folks use is some bizarro driver & centos. 22:40:45 lol, I've heard them called at least 4 different things today :P 22:40:46 combine the two together & you get centos for your crazy setup. 22:40:53 ok cool. so one thing that we shoudl try to solve is do we put the reddwarf-guest _in_ the image 22:40:58 or do we inject somehow on boot 22:41:06 it's pretty fluid, but think 'elelment' will be around for at least another week :) 22:41:09 right now redstack scp's it over in a very ghetto way 22:41:31 that worked great for development when i was drinking 64oz of coffee at 4am coding it 22:41:40 I think we need the guest in there, to be able to really call it s 'reddwarf' element 22:41:56 yup. we might stay ghetto-ish in the vein of getting it in. 22:41:56 ok given that does it need to be packaged somehow? 22:42:07 and it is also nice for development in that you can make a change without baking another image 22:42:11 we can keep it rsync for now 22:42:18 vipul: yes sir it is 22:42:24 durnas: cool, im ok w/ that 22:42:36 as long as we dont ahve to bake a new image for small guest updates when we dev 22:42:39 i think for a production deploy though, we'll both need some other packaged agent 22:42:45 def vipul we do that 22:42:52 Yeah, I'm good with rsync for now. Maybe PyPi later? 22:43:07 well pypi would assume latest is always there 22:43:08 we can create another flavor (err element) that has it baked in 22:43:22 it'll be like cheese stuffed crust 22:43:23 juice_: is that chicken b4 the egg? :D 22:43:43 vipul: at some point, it might make sense for guest-agent to be a separate build/package 22:43:52 hub_cap: more like a turducken 22:43:58 mmmmmmmmmm turducken 22:43:58 we should talk about that.. durnas 22:44:07 durnas: ours is a separate pkg, it works nicely 22:44:11 hub_cap: any thoughts on moving guest agent out of reddwarf repo? 22:44:11 yep. 22:44:12 put it in the image and start deploying 22:44:19 vipul: not opposed in any way :) 22:44:45 #action vipul to move guest agent bits out of Reddwarf into reddwarf-guestagent 22:44:46 vipul: Any reason to move it out? 22:44:54 but i would be opposed to putting pkg scripts in to it fo the sake of imaging :D 22:45:00 vipul: I'd rather not 22:45:02 I think for testing, packaging it makes sense for it to be self-contained 22:45:06 haah grapex no like distributed projects 22:45:21 i dont blame him we have a lot of "instrumenting" to do here 22:45:27 w/ the 900 projects we have goin 22:45:28 we can make changes to guest_agent without affecting reddwarf and vice-versa 22:45:31 If we can keep the reference agent where the reddwarf code is, when we add new features we can keep the reference agent close to the other changes 22:45:51 right, but the theory is that we'll have redstack-vm-gate anyway 22:45:58 so you'll always be testing tip of everything 22:45:58 its true. but you can also control that with build rules 22:46:26 grapex: Are there any dependencies on shared components between guest-agent and rest of reddwarf/common? 22:46:35 or hub_cap... 22:46:37 SlickNik: Totally. 22:46:42 SlickNik, grapex: that's a good point 22:46:48 ya we might have to have a reddwarf-common ;) 22:46:48 there's a ton of Oslo suff that's shared 22:46:50 We'd have to duplicate a lot of code to move the reference agent out 22:47:17 vipul: there is much less now thats in our repo, but the wsgi one is a big one (which the guest doent need) 22:47:37 Is HP planning on using the reference agent? 22:47:37 grapex: yes, that is the plan 22:47:37 sweet 22:47:49 well im not sure we need to solve this now 22:47:58 we'd like to put some of our maxwell bits in down the road, but first get geust agent a bit more solidified 22:48:09 so we're adding unit tests, etc to it now 22:48:11 we _know_ that the guest shoudl be 1) easily avail for development and 2) distributable in a way for deployments 22:48:26 Ok. I'm sure we're all smart enough to make it work even if it was 57 repos. OpenStack is a large enough project that the manpower is out there. I do think though that when new features are introduced it would be nice to show the reference guest code in the same commit as the reddwarf code. 22:48:27 we can meet those req's in a bunch of diff ways i bet 22:48:56 grapex, hub_cap: Yep, let's hold off on the move, i think we need to think of the implications a bit more 22:49:03 we can make guest-agent into its own repo with all the oslo stuff in it. We can refine it later 22:49:13 #action do not do move guest-agent out yet 22:49:22 steveleon: the oslo stuff is not 100% of what we have in reddwarf.common sadly 22:49:34 steveleon: yes, but then we'd need to keep them in sync also 22:49:43 shouldn't it be more like #no-action do not move guest-agent out yet.. heh... 22:49:45 there is def more too it, but im trying to get most of it merged into oslo 22:49:47 so upgrades need to be coordinated between reddwarf and agent 22:49:49 agree 22:49:52 lol SlickNik 22:50:11 thats true.. with keeping in sync 22:50:25 ok so seems like we should discuss that more off line 22:50:33 and we also need to discuss the image builder offline 22:50:36 yes. 22:50:37 id like to bring mordred in on it 22:50:45 when is a good time to talk about those? 22:50:52 im always in #reddwarf 22:50:54 yes. 22:51:06 but im really watching between 9~4 cst 22:51:08 k let me coordinate on our end here, and we'll meet with those guys in #reddwarf 22:51:14 vipul: yup 22:51:18 thatd be great 22:51:31 and we can talk about turducken and sprinkle toppings 22:51:34 :D 22:52:12 with elements it would be "image-create turkey duck chicken" to get your turducken image, I think… :) 22:52:26 lolz 22:52:30 nice :) 22:52:32 #action hub_cap SlickNik vipul to discuss w/ mordred the implications of multiple images housed in reddwarf and how we woudl do it 22:52:37 SlickNik: haha 22:53:02 so i guess that brings us to the freeform jazz portion of the meeting 22:53:08 #topic open discussion 22:53:19 steveleon: how are the guestagent unit tests coming? 22:53:19 anyone have anything to add here? 22:54:06 we have been tackling down class by class 22:54:21 guestagent? as well as reddwarfclient? 22:54:23 sweet! 22:54:42 we are starting with MySqlAdmin first 22:55:00 Then annashen and I will divide and conquer 22:55:14 hub_cap, just guestagent 22:55:18 steveleon: do yall have a BP in regard to this? 22:55:25 ddemir is working on the reddwarf-client 22:55:49 BP, meaning blueprints? no 22:55:50 sure im just elated that yall are doing the unit test stuff!!!! 22:55:52 hub_cap: not yet, will work on BP 22:55:57 annashen: <3 22:56:18 lets try to make the commits small, we all knows what happens when u push a huge commit ...cough cough... oslo updates 22:56:27 GROSS 22:56:36 once u get MySqlAdmin up, lets gerrit review it 22:56:40 cp16net: lol 22:56:48 yeah there is no nice way to see the diffs between patch sets... 22:56:48 steveleon: yeah, BP == blueprint, proposal basically 22:56:53 yes. We will be committing each unittest class as they are ready 22:56:56 just checking it all out locally... 22:57:02 awww ya steveleon awesome 22:57:13 become ready* 22:57:15 cp16net: ya so that is annoying, diffing patchsets is not supported in gerrit 22:57:28 should open a bug 22:57:33 :-P 22:57:38 so if u have > 1 patchset try to put whats in the newest or what u fixed in a comment 22:57:50 i did that for _only_ the last patchset of mine...sry 22:57:53 yes that would be a good practice 22:58:26 no sure if i was looking in the right place, but it seems that we dont have much unit tests 22:58:34 #info diffing patchsets in gerrit is not implemented. try to put a comment w/ what you did on each patchset after the first one 22:58:44 steveleon: we dont have much at all 22:58:45 all the tests under reddwarf.tests seem to be integration tests 22:59:01 i started writing them a while ago but we lost track of them and focused on integration 22:59:23 steveleon: yep, i think we'll need to spend some more time on getting some more unit test coverage all around 22:59:38 Let's focus on the coverage missing right now. 22:59:52 yup and we can make new features gate on unit tests as well, and bugfixes once we get to > 8% coverage :D 22:59:58 ok.. cool.. just wanted to make sure if there were any unit tests already there 23:00:08 steveleon: sadly no /sadface 23:00:14 is that all we have right now? 8%? 23:00:20 78% 23:00:24 ok 23:00:25 34.85% of statistics are made up cp16net 23:00:32 cool.. we will start by attacking the guest agent first... since it seems to be the most isolated component 23:00:39 REALLY? 23:00:42 :P 23:00:43 i'll believe that 23:00:47 78 seemss kinda high :) 23:01:00 lol... 23:01:17 78 is our integration tests says grapex 23:01:24 unit is non existing :D 23:01:28 ah ok 23:01:29 hence the 8% :P 23:02:05 anything else anyone? 23:02:21 ya 23:02:24 id like to discuss oslo 23:02:35 So is the idea to gate just on "unit" tests? 23:02:47 I think so... 23:02:54 Nope, unit + integration I think... 23:02:55 grapex: no no, gate on unit + live integration tests 23:03:02 Ok, I concur. 23:03:03