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