21:02:58 <vishy> #startmeeting nova
21:02:58 * Vek was about to say...
21:02:59 <openstack> Meeting started Thu Nov  1 21:02:58 2012 UTC.  The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:03:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:03:01 <openstack> The meeting name has been set to 'nova'
21:03:01 <comstud> :)
21:03:14 <russellb> i was triaging bugs ;)
21:03:17 * Vek waves
21:03:18 <dansmith> <-- present
21:03:20 <Vek> heh.
21:03:24 <jk0> o/
21:03:24 <rmk> here
21:03:27 <sdague> <- here
21:03:29 <comstud> i was getting cells reviews up last minute!
21:03:35 <cburgess> <-- present
21:03:36 <vishy> #topic Agenda http://wiki.openstack.org/Meetings/Nova
21:03:37 <mtreinish> I'm here
21:03:41 <Vek> comstud: that explains all those emails...
21:03:49 <vishy> #topic Nova Cells
21:03:50 <comstud> ;)
21:03:55 <vishy> comstud: updates?
21:03:56 <comstud> woo, cells
21:03:57 <russellb> reviews are up!
21:03:59 <comstud> 10 reviews are up
21:04:13 * russellb will start reviewing
21:04:13 <comstud> the 2nd one is still rather large
21:04:16 <markmc> hey
21:04:20 <comstud> the main one
21:04:42 <comstud> and I'll see what I can do about splitting it more.. but I'm not sure it's possible
21:04:55 <russellb> it's ok, but it will definitely be held against you
21:05:01 <comstud> it's +4688, -23
21:05:03 <Vek> heh.
21:05:05 <sdague> ooof
21:05:06 <comstud> sure thing! ;)
21:05:24 <comstud> hey, that -23 is meaningful with the +4688
21:05:27 <russellb> nah, looking forward to helping review and get it in
21:05:29 <comstud> it means i barely changed any core code
21:05:31 <Vek> well, that's OK; vish did a -17000 the other day :)
21:05:36 <sdague> :)
21:05:39 <comstud> true
21:05:58 <russellb> i'm happy to see it went from 1 to 10 patches
21:05:59 <comstud> so
21:06:05 <comstud> this is rebased against another patch I have up
21:06:11 <comstud> to add some hooks into service.start()
21:06:16 <russellb> so markmc left some comments on the last pass at this ... has any of that been addressed?
21:06:20 <sdague> how helpful would it be to be to land the devstack changes during this review? those are out there as of a day or so ago
21:06:20 <comstud> which cleans up a bit of code in cells manager
21:06:26 <russellb> rpc versioning stuff is what i remember
21:06:31 <comstud> and another review that went in recently that hard coded some binaries in service.py
21:06:42 <comstud> russellb: there's rpc vesioning in here, yes
21:06:46 <comstud> versioning
21:06:50 <russellb> k
21:06:53 <comstud> It's at 1.0.. i dunno if that should be bumped to 2.0
21:07:06 <comstud> to match other managers
21:07:08 <russellb> the compute api?  i guess i need to read the code
21:07:12 <comstud> it's not compute api
21:07:15 <russellb> or is its own API?
21:07:15 <comstud> cells rpcapi
21:07:17 <russellb> ok.
21:07:19 <russellb> then 1.0 is fine
21:07:24 <comstud> I'd think so.. cool.
21:07:29 <markmc> so, it's possible to update child cells before parent cells?
21:07:36 <markmc> or the other way around?
21:07:42 <comstud> it depends.
21:07:45 <russellb> heh
21:07:57 <comstud> it depends on how you change the compute_api signatures
21:07:58 <comstud> if you do
21:08:06 <comstud> there's no versioning on those :)
21:08:23 <comstud> I do not really like that the child cell has to re-call compute_api, TBH
21:08:42 <russellb> oh right, that's where you hook in, you replace the API class?
21:08:56 <comstud> I have longer term ideas there... that kinda go along with separating the nova-compute daemon
21:08:59 <comstud> yes
21:09:00 <comstud> at the top level
21:09:02 <russellb> i guess that's convenient ... just problematic since we do *nothing* to ensure API compatibility from one commit to the next
21:09:15 <comstud> correct
21:09:18 <comstud> and I don't like it, really
21:09:26 <comstud> It was the best way to be non-invasive for now
21:09:34 <russellb> i can probably talk more intelligently after I do a pass of the code ...
21:09:53 <comstud> what would be really nice is...
21:10:03 <comstud> we can just proxy compute manager calls via cells
21:10:13 <comstud> so we can just sub out the rpcapi class
21:10:18 <russellb> so action for this week, make good review progress, and have clear things identified that need to be addressed so work can continue
21:10:45 <vishy> russellb: sounds good
21:10:46 <comstud> Yeah, I suspect there'll be a lot of complaints about some ugliness.. which is fine
21:10:48 <russellb> would you sub it out, or just override the topic?
21:10:54 <vishy> lets move on we have lots to cover
21:10:58 <russellb> topic and server i guess ...
21:11:00 <russellb> k
21:11:04 <comstud> russellb: Good question ;)
21:11:12 <vishy> #action http://wiki.openstack.org/Meetings/Nova
21:11:14 <comstud> future brainstorming.
21:11:22 <vishy> #action action for this week, make good review progress, and have clear things identified that need to be addressed so work can continue
21:11:40 <vishy> #topic The state of the baremetal driver
21:12:15 <rmk> who is working on that?
21:12:19 <vishy> is anyone else reviewing
21:12:25 * devananda waves
21:12:27 * russellb hasn't touched it :-/
21:12:32 <vishy> I approved the first patch but no one else seems to be helping
21:12:34 <vishy> :(
21:12:48 <dansmith> I've looked, but got a little nauseous
21:12:54 * russellb looks at markmc
21:13:04 <markmc> I'll review the first one tomorrow morn at least
21:13:06 <russellb> he showed a lot of interest in it before at least :-)
21:13:09 <rmk> It's just such a different model than everything else is probably why and really not much pull for it (that I've seen at least)
21:13:11 <russellb> cool
21:13:12 <markmc> "interest"
21:13:23 <russellb> markmc: yes.
21:13:25 <devananda> i posted reviews on 2 of their patches today asking for small changes
21:13:42 <markmc> devananda, yeah, that looked like good stuff
21:13:52 <devananda> the baremetal db patch needs a lot of small work IMO
21:14:14 <russellb> devananda: nice, thanks.  your db session was great btw.
21:14:20 <devananda> thanks
21:14:36 <devananda> going to be talking more about that here in 3hr :)
21:15:03 <devananda> a bunch of us are developing a toolchain for testing the baremetal patches right now
21:15:11 <devananda> probably a month away from handing that to the CI team
21:15:14 <devananda> (maybe less)
21:15:38 <devananda> suffice to say, NTT's fork _does_ work but it's kinda fragile
21:15:57 <devananda> we're pushing patches back to them, which they're incorporating pretty quickly, when we fix things
21:16:20 <devananda> i'd really like to see unit tests added to their reviews....
21:16:57 <devananda> <done>
21:17:04 <vishy> devananda: it sounds like you are helping a lot with that stuff
21:17:21 <vishy> devananda: do you mind taking the lead on helping them get through fixes and reviews?
21:17:23 <markmc> vishy, they're actually running it, which is kinda shocking :)
21:17:32 <russellb> and people that help get gold stars
21:17:34 <vishy> markmc: ikr
21:17:36 * russellb hands out gold stars to the room
21:18:10 <devananda> we've got a bunch of people who just joined us specifically for baremetal
21:18:18 <devananda> vishy: nope happy to help NTT guys with this
21:18:18 <vishy> devananda: awesome
21:18:23 * markmc googles 'ikr'
21:18:33 <russellb> markmc: i know right
21:18:39 <markmc> russellb, ikr
21:18:52 <vishy> #action devananda to help shepherd baremetal patches
21:19:03 <vishy> markmc needs to spend more time hanging out with teenagers
21:19:15 <russellb> o.O
21:19:16 <vishy> #topic Nova Bugs
21:19:29 <russellb> vishy: i think that came out wrong
21:19:32 <Vek> heh
21:19:33 <russellb> bugs!
21:19:40 <russellb> http://webnumbr.com/untouched-nova-bugs
21:19:42 <russellb> 36 untouched
21:19:44 <vishy> #link http://webnumbr.com/untouched-nova-bugs
21:19:46 <vishy> :)
21:19:47 <russellb> still reasonable
21:19:55 <vishy> yes we seem to be doing ok there
21:20:03 <russellb> with triage at least
21:20:05 <vishy> any comments on bug handling?
21:20:14 <russellb> fix more
21:20:16 <russellb> kthx
21:20:18 <comstud> i approve of it
21:20:20 <dansmith> I added some
21:20:21 <comstud> handle them
21:20:32 <dansmith> (I mean, I'm assuming I did)
21:20:34 <vishy> #topic Nova Coverage for Tempest
21:20:46 <sdague> mtreinish you're up
21:20:58 <mtreinish> So, I've been working on enabling tempest, or another external program, to be able to generate coverage reports for nova. So that tempest can see what parts of nova it is exercising.
21:21:07 <mtreinish> The nose coverage plugin doesn't report on nova's coverage when it is enabled for tempest. (obviously)
21:21:18 <mtreinish> The first idea that I had was to use an api extension that can use the coverage api to start and stop coverage reporting and generate reports.
21:21:29 <mtreinish> I have a WIP of this approach up on gerrit at: https://review.openstack.org/14468
21:21:41 <mtreinish> I'm just trying to get a consensus on this approach and whether it's the best way to go about this, or if there is a better way to do it.
21:22:30 <markmc> mtreinish, will that only report coverage for the api server?
21:22:37 <Vek> hmmm...I do sorta like the concept...
21:22:45 <markmc> mtreinish, something like eventlet_backdoor would make more sense to me, I think
21:23:07 <mtreinish> markmc: I think that it should report coverage for everything that is being run
21:23:32 <markmc> mtreinish, hmm, how does that work?
21:23:33 <dansmith> mtreinish: even across the message queue?
21:24:00 * markmc assumes coverage just reports the current process
21:24:27 <Vek> I'm fairly certain markmc is correct
21:24:37 <markmc> Vek, in general? :)
21:24:44 <vishy> well
21:24:45 <dansmith> heh
21:24:48 <mtreinish> markmc: it's still a bit of voodoo to me on how the actual coverage module works. I had a sample report generated but I lost it
21:24:49 <Vek> (and I'd go with a slightly different pattern on the exclude ;)
21:24:51 <vishy> we couldu use nova-all
21:25:00 <Vek> markmc: well, as long as you agree with me, we're in agreement
21:25:04 <vishy> that would get coverage on everyhing
21:25:07 <markmc> heh
21:25:11 * vishy can't type
21:25:48 <markmc> vishy, it'd be nice if this worked in e.g. smokestack and devstack too
21:26:12 <vishy> markmc: true, I was just going for quick and dirty version ;)
21:26:23 <markmc> another eventlet_backdoor command could work, right?
21:26:33 <vishy> mtreinish: do you have enough to go on for the next step?
21:26:51 <vishy> sounds like prototyping a backdoor version is it
21:26:57 <Vek> *nod*
21:27:11 <mtreinish> vishy: sure I'll give that a go
21:27:47 <markmc> mtreinish, cool stuff, it'd be awesome to have this
21:27:59 <vishy> #topic Action items from the live upgrade track
21:28:10 <dansmith> So, I sent the email,
21:28:14 <dansmith> saw no comments or complaints
21:28:26 <russellb> which email, heh
21:28:30 * russellb drowns in email
21:28:30 <dansmith> aside from the one we're giving to westmaas, I figure I'll make blueprints of the items
21:28:40 <dansmith> #link http://lists.openstack.org/pipermail/openstack-dev/2012-October/001969.html
21:28:55 <dansmith> heh, I guess I can't #do things
21:29:11 <sdague> this topic and the next one are pretty linked, as the next topic is the action items from api
21:29:44 <russellb> FWIW, all those action items in the email sound good to me
21:29:47 <sdague> if people could get on the list and take a look, assuming no complaints, we'll get those into blueprints
21:29:59 <dansmith> alrighty
21:30:00 <vishy> yeah blueprints would be great
21:30:19 <dansmith> say, how much do we paid for blueprints these days?
21:30:22 <markmc> all sounds good to me
21:30:24 <russellb> not sure how the rpc-version-control thing will work out, could get messy
21:30:32 <russellb> but anyway, still sounds good to have on "the list"
21:30:36 <markmc> russellb, yeah
21:30:39 <Vek> yeah, no kidding...
21:30:39 <dansmith> yup and yup
21:30:44 <vishy> is the next one basically the same?
21:30:46 <vishy> #topic Action items from the api consistency track
21:30:50 <sdague> vishy: yep
21:30:53 <sdague> #link http://lists.openstack.org/pipermail/openstack-dev/2012-November/002109.html
21:31:06 <russellb> dansmith: you get tons of launchpad karma, which are worth like 3.4 internets
21:31:06 <sdague> same approach, just content from another session
21:31:21 <dansmith> russellb: oh boy!
21:31:25 <Vek> by the way, I never heard what, if anything, was decided about XML?
21:31:45 <dansmith> Vek: XML continues to be in the tree so we have something to hate
21:31:46 <russellb> we're going to embrace XML and add SOAP
21:31:46 <sdague> Vek: I think the general agreement is that it stays at this point
21:31:57 <dansmith> russellb: damn, way better :)
21:31:58 <Vek> sdague: ugh.  Oh, well.
21:32:05 <Vek> russellb: :P~~~
21:32:07 <russellb> it stays, and like most things that are there, we should make it work and stuff
21:32:10 * vishy trips and accidentally beheads russelb with his katana
21:32:16 <russellb> eeeep
21:32:22 <sdague> Vek: v3 is specifically a minor set of changes, so dropping a data format seems extreme in that
21:32:25 <vishy> * russellb
21:32:30 <sdague> v4, well thats for others to decide :)
21:32:43 <russellb> i don't see any reason to drop it
21:32:47 <Vek> I'll keep lobbying for the removal of XML :)
21:33:13 <Vek> have we at least decided on changes to the XML to make it easier to generate from the JSON?
21:33:25 * markmc gives XML a hug
21:33:32 <vishy> sdague: do we have a place to collect suggestions for what belongs in v3
21:33:42 * Vek watches marcmc cut himself on all the sharp edges
21:33:48 <sdague> vishy: not yet, that's on that todo list, blueprint and wiki page off it
21:33:50 <vishy> Vek: not in v3
21:33:56 <sdague> I'll get to it over the next couple of days
21:34:12 <vishy> sdague: i think that is the next big thing. If we want any chance of producing v3 by grizzly
21:34:17 <sdague> again, wanted at least general head nodding before ploughing ahead
21:34:20 <sdague> vishy: agreed
21:34:26 <russellb> markmc: how nice of you ... XML does get abused.
21:34:27 <vishy> ok next topic
21:34:35 <vishy> #topic 3rd Party APIs
21:34:52 <vishy> so we had a summit discussion about proposing to the TC to allow 3rd party apis in
21:35:03 <vishy> I'm supposed to draft an email explaining the proposal
21:35:23 <vishy> but aside from support by people in nova-core I think the TC is not going to go for it
21:35:30 <vishy> so I wanted to discuss alternatives.
21:35:44 <markmc> vishy, you know, I think the TC decision could be interpreted as allowing gce in
21:36:09 <markmc> vishy, i.e. "projects should strive for a performant, stable API which 3rd party APIs can build on"
21:36:26 <markmc> vishy, we don't have that, and IMHO the implication is 3rd party APIs are welcome until we do have it
21:36:42 <russellb> and until someone shows up to do the work to make it possible ...
21:36:45 <vishy> i have this crazy idea of taking a weekend and making ec2 proxy all calls to compute_api through novaclient.
21:36:48 <Vek> heh
21:36:51 <jog0> markmc:  GCE api is in beta12  so its not stable yet
21:36:51 * sdague wonders if markmc was a lawyer in a past life
21:37:06 <russellb> vishy: so you'd reinvent an ec2 -> OS proxy?
21:37:09 <russellb> :(
21:37:21 <jog0> markmc: beta13
21:37:24 <dansmith> "no can really be interpreted as yes if you merely change all the letters"
21:37:43 <vishy> russellb: yeah I'm not super happy with that but at least we have proof that 3rd party apis can work
21:38:01 <Vek> russellb: actually, it might not be a bad idea.  At the very least, as a proof of concept, it should help us understand what features OS is missing to make such things possible.
21:38:31 <vishy> i was debating whether to modify ec2/cloud.py to use novaclient
21:38:47 <russellb> sounds like a giant distraction from things that this group would be better off working on
21:38:47 <sdague> yeh, if we are cracking v3 to do consistency, now would be the time to figure out if 3rd party APIs can actually build on it, and what we have to fix to do it
21:38:50 <Vek> dansmith: Look up the gilbert and sullivan operetta "Iolanthe" sometime; the conflict is resolved by the addition of a single word to a low :)
21:39:08 <vishy> or to make a version of compute.API that actaully proxies through the client like we did with cinder
21:39:12 <jog0> vishy: how do you handle metadat aservices?
21:39:23 <vishy> jog0: it will have to be plugins
21:39:49 <dansmith> Vek: heh....alright :)
21:39:54 <vishy> russellb: well the problem is we haven't delivered on "projects should strive for a performant, stable API which 3rd party APIs can build on"
21:40:05 <vishy> so we have nothing for GCE
21:40:28 <vishy> I don't think it is really acceptable for us to just ignore that
21:40:46 <markmc> I think we've enough problems without tackling that
21:40:49 <jog0> vishy:  anyway we can leverage the RPC versioning work here?
21:40:55 <russellb> no
21:41:01 <russellb> the rpc stuff is a few layers deep
21:41:02 <jog0> too bad
21:41:08 <jog0> I was afraid of that
21:41:34 <russellb> i mean, it's software, a new rpc API could be added
21:41:38 <vishy> so should i go ahead with proposing to the TC that we allow in other apis?
21:41:42 <markmc> vishy, committees can say "projects should strive for foo" all day long, projects still need to prioritize stuff
21:41:45 <russellb> but the existing one wouldn't work for solving this
21:42:08 <vishy> or maybe markmc, the lawyer, wants to draft a proposal?
21:42:09 <russellb> vishy: that's my opinion at least ... we can vote if you'd like
21:42:13 <markmc> vishy, I can do that
21:42:18 <russellb> nice
21:42:22 <vishy> markmc: :)
21:42:30 <russellb> delegation ftw!
21:42:52 <jog0> how much work would be involved in versioning and stabilizing the compute.API?
21:42:55 <vishy> #action markmc to take over drafting a proposal to the TC regarding 3rd party apis
21:43:06 <vishy> jog0: infinite
21:43:06 <russellb> jog0: it's other APIs too, right?
21:43:10 <vishy> :o
21:43:11 <russellb> a non-zero amount
21:43:31 <vishy> #topic Grizzly blueprints
21:43:35 <jog0> russellb:  yeah
21:43:35 <markmc> jog0, it's like versioning the DB models and everything
21:44:14 <russellb> version the world
21:44:29 <russellb> so, blueprints!  we should have some of those
21:44:30 <vishy> we have 90+ blueprints
21:44:37 <Vek> there goes our hope for performant APIs...
21:44:43 <sdague> and more soon...
21:44:54 <jog0> I just made two blueprints this morning
21:44:55 <vishy> #link https://blueprints.launchpad.net/nova
21:45:07 <russellb> Vek: the APIs are performant, they're just not stable.
21:45:13 <vishy> i don't think we need to version db models
21:45:56 <Vek> russellb: just commenting that the more complex we make APIs (for versioning), the less performant those APIs will be
21:45:58 <vishy> to solve the 3rd party api thing anyway
21:46:07 <markmc> good god, that's a lot of blueprints
21:46:07 <Vek> anyway...
21:46:09 <russellb> Vek: ah, perhaps..
21:46:15 <vishy> ok so I could use help targetting blueprints
21:46:18 <vishy> I've done a bunch
21:46:26 <vishy> and i've obsoleted some leftover ones from folsom
21:46:46 <dansmith> vishy: get rid of that no-db-compute one.. it's bogus and nothing but trouble
21:46:54 <vishy> there are a bunch that are simple approves
21:47:25 <russellb> others probably need some sanity checking and research to figure out wtf it was
21:47:35 <russellb> blueprints don't really provide a way to comment or discuss i guess ...
21:47:51 <russellb> try to contact submitter, CC openstack-dev if needed?
21:48:19 <vishy> i usually just comment on the whiteboard
21:48:24 <russellb> k
21:48:51 <russellb> "db-cleanup", that's pretty bold :-)
21:49:17 <vishy> also could use help here: https://etherpad.openstack.org/summit-summary
21:49:25 <vishy> linking the blueprints in
21:49:36 <vishy> to the summit sessions
21:49:54 <jog0> russellb: even if  only 20% of it is completed its better then nothing
21:50:18 <russellb> jog0: sure, it's good stuff.
21:51:18 <sdague> vishy: I'll update the etherpad for relevant sessions I ran
21:51:42 <vishy> sdague: cool thx. If you fill in summary, keep it short and sweet
21:51:46 <sdague> will do
21:51:50 <russellb> markmc: this seems like something to drive through openstack-common - https://blueprints.launchpad.net/nova/+spec/basic-client-library
21:52:02 <sdague> I'll follow your lead there on formatting and brevity
21:52:16 <vishy> i'm doing this hopefully to help us make sure we didn't forget any blueprints
21:52:25 <markmc> russellb, there is a common client effort, dhellmann did a session on it at the summit
21:52:52 <markmc> russellb, https://etherpad.openstack.org/grizzly-common-unified-cli
21:53:07 <russellb> markmc: yeah.  this description acts like that's different, but maybe it's not.  this is about the openstack-common equivalent for client libraries (not the CLI itself)
21:53:18 <russellb> is that a common library for all APIs as well?
21:53:20 <Vek> markmc: blueprint points out that that's a CLI, whereas this blueprint reads more for an API
21:53:23 <russellb> or is it just using the existing libs?
21:53:51 <markmc> I assume it's a common library for all APIs and CLI builds on that
21:53:59 <vishy> volunteers to help with bps?
21:54:01 <russellb> well that would do it then.
21:54:10 <vishy> you need to be on nova-drivers to approve and target
21:54:13 <russellb> vishy: i will help ... hope i'm not volunteering for too much
21:54:22 <russellb> i've volunteered for enough to ensure i don't code again for the next week
21:54:58 <Vek> russellb: what a relief!  *duck*
21:55:04 <russellb> but looks like i'm not in that team
21:55:05 <sdague> I hesitate to volunteer until I've got all the rest of my blueprints up and the v3 docs bits in place
21:55:06 <russellb> Vek: nice.
21:55:16 <Vek> ;)
21:55:38 <russellb> thanks vishy
21:55:43 <vishy> you are now!
21:55:50 <russellb> huzzah
21:55:56 <Vek> heh :)
21:55:59 <russellb> so right now we're just targeting to grizzly as appropriate
21:56:02 <russellb> not specific milestones
21:56:04 <russellb> ?
21:56:06 <vishy> right
21:56:09 <vishy> and setting priority
21:56:13 <russellb> ack.
21:56:15 <vishy> and hitting all the approved fields
21:56:21 <russellb> with a hammer?!
21:56:25 <vishy> yup
21:56:30 <russellb> excellent.
21:56:34 <vishy> if anyone else feels like helping ping me
21:56:45 <vishy> (and putting them in the summit-summary etherpad
21:56:55 <vishy> #topic open discussion
21:57:20 <Vek> I made a start on Boson
21:57:34 * russellb googles Boson
21:57:44 <Vek> the CERN guys are very interested in it, which is good, because I have to shelve it for a little while to work on some higher-priority internal stuff
21:57:53 <russellb> Vek: how appropriate
21:58:00 <Vek> http://wiki.openstack.org/Boson
21:58:18 <jog0> I have a patch to disable quotas by default  -- and was hoping to get some feedback if thats a good idea or not
21:58:22 <Vek> yeah, they commented on the appropriateness of the name when they first saw my list email about it :)
21:58:24 <russellb> oh, nice
21:58:32 <devananda> jog0: ++
21:58:48 <Vek> ironically, I actually wasn't referring to the Higgs.  Further irony is that my bachelor's is in Physics
21:59:47 <Vek> any way, very long term goal is to replace quota systems in OpenStack with Boson
22:00:21 <devananda> i posted a doc outlining better ways to use sessions and transactions. review #14966
22:00:21 <Vek> and I'd like some help with it, if anyone's interested (https://github.com/klmitch/boson for now)
22:00:32 <Vek> devananda: OK, cool
22:00:35 <devananda> if there's a better place to put that, just let me know
22:00:40 <russellb> devananda: i wonder where the best place is to put that ...
22:00:43 <russellb> ha
22:00:48 <devananda> or if someone disagrees / etc
22:00:50 <devananda> russellb: :)
22:00:52 <jog0> devref ?
22:01:16 <russellb> well thing is, it applies beyond nova
22:01:25 <markmc> wiki sounds good, then
22:01:30 <devananda> iirc, at the summit vishy suggested sticking it in api.py or such
22:01:34 <russellb> though we talked about moving this particular code to openstack-common
22:01:40 <devananda> well, no
22:01:50 <devananda> this is more "how to use session.py"
22:01:52 <russellb> so it's not such a bad place to put it for the moment ...
22:02:26 <devananda> erm, so maybe it is better in common :)
22:02:54 <russellb> well code isn't there yet
22:03:00 <russellb> presumably your docs would move with it once it is
22:03:37 <devananda> presumably
22:03:44 <russellb> annnnyway, yay for docs
22:03:52 <sdague> agreed, nice work
22:04:04 * clarkb sneaks in his draft change for running nova unittests under testr. https://review.openstack.org/#/c/15078/ its a draft I can either add people to it or publish it and change it to WIP
22:05:09 <sdague> clarkb: make in wip please, just easier to let people see things
22:05:51 <clarkb> sdague: done
22:06:17 <markmc> vishy, #endmeeting ? :)
22:06:30 <russellb> thanks vishy !
22:06:34 <vishy> #endmeeting