17:00:30 <devananda> #startmeeting ironic
17:00:32 <openstack> Meeting started Mon Aug 10 17:00:30 2015 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:33 <dtantsur> o/
17:00:35 <openstack> The meeting name has been set to 'ironic'
17:00:36 <devananda> hi folks!
17:00:39 <devananda> #chair NobodyCam
17:00:40 <openstack> Current chairs: NobodyCam devananda
17:00:48 <jlvillal> o/
17:00:52 <devananda> The agenda, as usual, is here: https://wiki.openstack.org/wiki/Meetings/Ironic
17:01:07 <devananda> also - reminder - our midcycle is this week (starting in ~2 days)
17:01:11 * dtantsur put some stuff on agenda, so it's not empty today :)
17:01:15 <devananda> so it's possible some folks are travelling today
17:01:17 <natorious> \o
17:01:19 <devananda> dtantsur: woot!
17:01:31 <devananda> I'll give everyone a few minutes to join ...
17:01:34 <JoshNang> o/
17:01:35 <rloo> o/
17:01:46 <krtaylor> o/
17:02:01 <NobodyCam> also please note that the location has been updated for the mid-cycle
17:02:14 * krtaylor wishes he could go
17:03:18 <devananda> #topic announcements
17:03:50 * devananda lost his link ...
17:04:14 <devananda> reminder: midcycle new address: Renaissance Seattle Hotel, 515 Madison Street, Seattle, Washington 98104
17:04:32 <devananda> anyone else have announcements?
17:04:34 <jlvillal> Start time 9am on Wednesday?
17:04:37 <devananda> yep
17:04:39 <NobodyCam> yep
17:04:59 <rloo> meeting time -- is it official, we're going to hold it weekly at this day/time?
17:05:13 <NobodyCam> yep
17:05:14 <devananda> rloo: oh yes, thanks!
17:05:21 <thiagop> great news
17:05:22 <devananda> I'll send out hte email and get the openstack calendar updated
17:05:29 <rloo> thx devananda
17:05:34 <NobodyCam> awesome TY
17:05:40 <sergek> tx
17:05:54 <devananda> ok, moving on
17:05:55 <jlvillal> devananda: If you like I can do the openstack calendar patch.
17:05:58 <devananda> #topic subteam status reports
17:06:18 <devananda> jlvillal: that'd be great, ty
17:06:24 <jlvillal> I will add you as reviewer
17:07:05 * jroll updates neutron subteam status
17:07:06 <NobodyCam> devananda: seems to have dropped
17:07:43 <NobodyCam> hey hey jroll here?
17:07:47 <jroll> hi
17:08:00 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:08:00 <rloo> jroll: wrt neutron. what does it mean to miss the nova boat? we get the rest of the code done anyway and wait?
17:08:03 <jroll> for the status reports
17:08:14 <devananda> aaand i'm back
17:08:16 <NobodyCam> hey hey happen to want to give a update on the ml2
17:08:18 <jroll> rloo: yeah, missed feature freeze, so we'll get everything else done and land it in L
17:08:27 <NobodyCam> looks like we missed the nova timeline
17:08:28 <jroll> NobodyCam: just updated the whiteboard :)
17:08:35 <NobodyCam> :)
17:08:42 * jroll finding link for patches
17:09:07 <jroll> this updates the data model and APIs to add portgroups etc https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/ironic-ml2-integration,n,z
17:09:13 <jroll> could use reviews
17:09:29 <NobodyCam> #link https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bp/ironic-ml2-integration,n,z
17:10:03 <devananda> jroll: thanks
17:10:15 <devananda> jlvillal: welcome back from vacation :)
17:10:18 <rloo> jroll: no hurry on those patches though cuz we'll have to wait for M anyway?
17:10:25 <jlvillal> devananda: Thanks :)
17:10:29 <jroll> rloo: I'd like to land the ironic stuff in Liberty
17:10:36 <jroll> and nova just won't support it yet
17:10:36 <devananda> rloo: yea, the ironic side should be landable anyway
17:10:49 <rloo> jroll: ok. (just want to understand Liberty priorities.)
17:11:04 <devananda> TheJulia: any updates on bifrost?
17:11:28 <devananda> dtantsur: do you have a dashboard showing hte history of gate-ironic-inspector-dsvm-nv ?
17:11:39 <dtantsur> nope, which is pretty unfortunate
17:11:47 <devananda> dtantsur: also, what project(s) is it running against at the moment?
17:12:01 <dtantsur> non-voting on ironic, ironic-inspector, python-ironic-inspector-client
17:12:25 <NobodyCam> TheJulia: want to chat about the work around group-var refactoring for bifrost?
17:12:27 <devananda> dtantsur: once you're comfortable with it, we should enable voting on ironic-inspector and python-ironic-inspector-client
17:12:42 <dtantsur> devananda, yeah, I'm planning on it. I even have a patch with -1 from jenkins :)
17:12:52 <dtantsur> (patch to project-config)
17:13:19 <devananda> dtantsur: wdyt about having it vote on ironic? -- my sense is that's not necessary. Ironic changes should never break it, and if we do, we should revert that patch because we would have just broken other users too
17:13:49 <dtantsur> yeah, definitely not a requirement for now
17:13:53 <devananda> cool
17:14:36 <devananda> I see only one update in the driver section
17:15:02 <devananda> naohirot has proposed a spec for NMI / soft power off work that should be doable by most power/management drivers
17:15:17 <jroll> #link https://review.openstack.org//#/c/186700
17:15:18 <jroll> for that one
17:15:34 <jroll> which needs some updates but is getting there
17:15:35 <devananda> would like to get other driver maintainers to look at it ^^
17:16:14 <devananda> #info driver authors / maintainers, please review https://review.openstack.org//#/c/186700 -- "Enhance Power Interface for Soft Reboot and NMI"
17:16:25 <devananda> any other updates from folks?
17:17:12 <devananda> ok, thanks all, let's move on
17:17:18 <devananda> #topic node tagging spec
17:17:22 <devananda> #link https://review.openstack.org/#/c/192935/
17:17:42 <devananda> I'm not sure who put this on the agenda, but I'm happy to talk about it for 10 minutes
17:19:14 <thiagop> quite silent...
17:19:17 <devananda> actually, i'm not sure why this is on the agenda ...
17:19:18 <devananda> dtantsur:  ?
17:19:34 <rloo> what's the question (for the tagging spec)?
17:19:36 <dtantsur> yeah, sorry
17:19:53 <devananda> yea, I just reviewed the spec again and I dont see what ht equestion is ...
17:20:01 <dtantsur> oh not, that one wasn't me, but I'm ready to chat on it :)
17:20:06 <rloo> let's move on then.
17:20:13 <devananda> ramki left a review comment "Still not clear why we are avoiding the FK constraint. May be rationale needs to be explained."
17:20:19 <NobodyCam> why drop from length from 255 to 64?
17:20:26 <rloo> whoever added it to the agenda should have indicated why.
17:20:30 <devananda> rloo: indeed
17:20:45 <devananda> ok, let's move on
17:20:51 <dtantsur> I'd chat on it, but we have more pressing questions IMO
17:21:07 <dtantsur> let us start with ironic-lib?
17:21:15 <devananda> sure
17:21:17 <devananda> #topic ironic-lib
17:21:27 <dtantsur> so, we've synced some code, and we need to release it
17:21:27 <devananda> this seems to have stalled for a while ...
17:21:34 <devananda> oh great! let's do a release
17:21:53 <rloo> +1 for a release of ironic-lib
17:21:58 <dtantsur> yeah, otherwise we'll be syncing code forever :)
17:21:59 <TheJulia> devananda: no, sorry for the delay, basically just trying to clean things up so we can get ansible 2.0 working and post the roles
17:22:11 <dtantsur> after the release we need to add a dsvm job for ironic-lib pretty quickly
17:22:12 * TheJulia is a call at the moment
17:22:17 <dtantsur> we may even do it in advance IMO
17:22:33 <rloo> also need to add to global requirements
17:22:46 <dtantsur> yeah, good catch
17:23:11 <rloo> and update ironic to use the lib quickly before things get out of sync again
17:23:16 <jroll> yeah, my opinion would be dsvm -> release -> global-reqs -> update ironic
17:23:29 <gabriel-bezerra> does this ironic-lib impact the drivers' code?
17:23:32 <dtantsur> jroll ++
17:23:48 <dtantsur> gabriel-bezerra, it will impact iSCSI deploy implementation
17:23:53 <devananda> jroll: ++ ... dsvm job should come before release
17:24:04 <dtantsur> though it won't test anything :)
17:24:11 <jroll> dtantsur: and thus could probably affect other drivers
17:24:13 <dtantsur> but yeah, we should do it asap anyway
17:24:17 <jroll> mmm, good point
17:24:33 <dtantsur> Having noop dsvm sounds good to me
17:24:35 <jroll> so do we care about backwards compat for out-of-tree drivers using this?
17:24:45 <jroll> (because it's certainly possible)
17:24:52 <devananda> jroll: oh
17:24:58 <dtantsur> tbh we never cared when moving around code...
17:25:03 <jroll> it's fairly easy to solve with just some dummy functions in the old place that copy to the new
17:25:18 <devananda> jroll: I would say, yes, we care about that
17:25:37 <gabriel-bezerra> dtantsur, jroll thanks. what kind of changes should happend in drivers to cope with the new library?
17:25:43 <jroll> I tend to agree, especially with it being easy
17:25:49 <jroll> gabriel-bezerra: we're figuring that out now :P
17:25:56 <devananda> the libraries we currently include within ironic, eg. utils, etc, is something we encourage driver authors to use
17:26:12 <dtantsur> devananda, it's an interesting observation because up to now we were just changing code without thinking about it
17:26:13 <devananda> ie, we do have a responsibility to anyone consuming it
17:26:33 <rloo> but dtantsur is correct in that we never cared before when we modified those functions w/i ironic.
17:26:48 <devananda> let's approach this first by replacing the methods we're moving into ironic-lib with shims that call ironic-lib
17:26:55 <devananda> so we don't need to make changes even to the in-tree driver
17:27:07 <NobodyCam> devananda: ++
17:27:17 <dtantsur> should we eventually define "the driver SDK"?
17:27:22 <devananda> dtantsur: ++
17:27:27 <gabriel-bezerra> sounds good to me
17:27:32 <dtantsur> good topic for M summit
17:27:33 <rloo> devananda: will the shims be temporary?
17:27:38 <NobodyCam> mmm yes
17:27:47 <gabriel-bezerra> rloo: i hope so
17:27:51 <devananda> off hand, I would say the API defined in drivers/base as well as all the methods in drivers/utils
17:28:12 <devananda> rloo: yes. we could add a deprecation warning in those shims during L
17:28:17 <devananda> and remove them in M
17:28:30 <rloo> devananda: +1 then
17:28:36 <gabriel-bezerra> devananda: +1
17:28:41 <NobodyCam> ++ giving folks time to update any out of tree things
17:28:46 <devananda> that will give out of tree driver authors clear notice (in the log files their drivers generate) that hey, this library is changing, here's what you need to do
17:28:52 <dtantsur> and let us add versioning to these functions
17:28:54 * dtantsur hides
17:29:00 * jroll chases dtantsur
17:29:06 <devananda> lol
17:29:07 <rloo> sure, cuz dtantsur loves versioning!
17:29:13 <dtantsur> :D
17:29:14 * devananda notices that conductor/utils also forms part of our driver API
17:29:29 <jroll> dtantsur: wait. ironic-lib IS adding versioning :D
17:29:31 * BadCub is a tad bit more than "fashionably late" today
17:29:37 <dtantsur> BadCub, o/
17:29:44 <devananda> relatedly, I think we should move node_power_action and node_set_boot_device from conductor/utils to driver/utils
17:29:44 <NobodyCam> heheh emornign BadCub :)
17:29:47 <dtantsur> jroll, fair point
17:30:10 <devananda> because those are effectively part of the driver api
17:30:17 <dtantsur> devananda, what about explicitly calling it something like ironic.driver.sdk? so that people understand what they should and should not use?
17:30:30 <dtantsur> I mean, call the module
17:30:37 <devananda> dtantsur: "sdk" is the wrong term here IMO, but yes, i agree that a good name will hlep
17:30:51 <devananda> ironic.drivers.base for the interfaces
17:30:59 <rloo> so ironic-lib is only going to include stuff that drivers use?
17:31:07 <devananda> ironic.drivers.utils for the utility methods
17:31:08 <devananda> ^^ what we have now
17:31:16 <NobodyCam> ddk "Driver development kit"
17:31:29 <dtantsur> rloo, we started it because we needed to share code between ironic and agent
17:31:30 <thiagop> lol
17:31:37 <dtantsur> NobodyCam, LOL
17:31:53 <rloo> dtantsur: oh. so maybe ironic-driver-lib?
17:32:05 <jroll> NobodyCam: https://en.wikipedia.org/wiki/DDK
17:32:06 <devananda> dtantsur: I would move several methods or modules from ironic.drivers.modules.* into ironic.drivers.utils
17:32:08 <jroll> it's actually a thing
17:32:25 <jroll> .b 60
17:32:28 <jroll> oops
17:32:50 <NobodyCam> :)
17:33:05 <devananda> ddk isn't a bad name, except usually one releases a ddk separately from the drivers themselves ... at least in my previous experience
17:33:15 <dtantsur> devananda ++ for moving
17:33:19 <jroll> ok, so we're going to shim the things, going to do the ironic-lib thing, sounds like we have a plan?
17:33:21 <devananda> anyway, we coulan bikeshed on names another time :)
17:33:31 <devananda> jroll: yep. sounds like a plan
17:33:54 <devananda> there were 4 steps in your plan
17:33:55 <jroll> cool
17:34:00 <devananda> first was a dsvm job -- who's doing that?
17:34:04 <NobodyCam> do we want a # agreed on this?
17:35:35 * devananda drops a pin
17:35:42 <devananda> wow, it's quiet in here :p
17:35:43 <dtantsur> devananda, I can propose a job
17:35:44 <thiagop> (though I didn't saw anybody disagreeing)
17:35:59 <devananda> dtantsur: thanks much
17:36:00 <NobodyCam> dtantsur: awesome TY
17:36:02 <rloo> but we need to know the name(s) since it affects the library
17:36:15 <devananda> rloo: name of?
17:36:19 <jroll> the library already has a name...
17:36:35 <rloo> the library and the ironic.drivers.modules stuff (or is that ok as is)?
17:36:56 <dtantsur> the former is more or less settled, the latter can be decided later IMO :)
17:37:01 <devananda> tangent - do oslo libs have dsvm jobs on them?
17:37:03 <rloo> or maybe i wasn't paying attention. if the library is good to go then fine.
17:37:04 * devananda checks
17:37:16 <NobodyCam> :)
17:37:25 <dtantsur> devananda, they do
17:37:33 <dtantsur> (at least those I contributed to)
17:38:03 <devananda> some do, some don't
17:38:13 <NobodyCam> fyi two topics and 22 minutes on the clock
17:38:28 <devananda> so, my thinking is that this lib should not be in the global gate
17:38:35 <devananda> so we shouldn't put it into the pipelines that ARE in the gate
17:38:45 <jroll> we can give it a different name to block any chaining
17:38:50 <devananda> it should, however, be in ironic's gate
17:38:52 <devananda> jroll: exactly
17:39:14 <dtantsur> not sure I get what your guys discuss...
17:39:21 <dtantsur> * you
17:39:37 <devananda> #agreed new devstack job for ironic-lib should be created and added to ironic's gate, but not any of the global gate pipelines
17:39:53 <devananda> dtantsur: a change in nova should not trigger this test run
17:39:55 <jroll> dtantsur: I'll show you outside of this meeting
17:40:10 <dtantsur> ack thanks :)
17:40:30 <devananda> once that's landed, pls poke me and I'll do a 0.1.0 release
17:40:35 <devananda> then we can start with the refactoring / creating shims
17:40:37 <devananda> in Ironic
17:40:39 <NobodyCam> :)
17:41:12 <devananda> #note in the meantime - do not land any changes to iSCSI code, or other code that's going into ironic-lib. let's not have to sync it again
17:41:17 <dtantsur> ack
17:41:18 <devananda> moving on
17:41:27 <devananda> #topic introducing retry-after header?
17:41:39 <devananda> #link https://review.openstack.org/209207
17:41:47 <JoshNang> so for caching in zapping, we might hit a point where we don't have all the data necessary
17:41:51 <devananda> dtantsur: that's you
17:41:59 <dtantsur> that's more JoshNang :) go ahead
17:42:05 <devananda> oh, ok :)
17:42:33 <devananda> JoshNang: could you clarify that?
17:42:37 <JoshNang> and we need a way to indicate to the client that they need to wait X amount of time. we landed the spec saying we'd use the retry-after header, and the RFC says you should return a 503
17:42:48 <JoshNang> devananda: sure
17:43:50 <JoshNang> if you're using the agent for cleaning/zapping, it generates a list of steps when it boots. when a new node is added, it won't have the complete list of steps available until the agent starts and ironic queries it
17:43:59 <JoshNang> in all other cases, ironic should cache the steps from the agent to avoid this
17:44:32 <JoshNang> s/agent/IPA/
17:45:03 <devananda> that seems reasonable
17:45:18 <devananda> re: 503, the service won't know exactly when it will know that, however
17:45:19 <JoshNang> the main question is how do we indicate to the client 'try again in X seconds' while ironic boots IPA and gets the list of steps?
17:45:42 <devananda> https://tools.ietf.org/html/rfc7231#section-6.6.4
17:45:56 <devananda> indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay.
17:46:15 <devananda> this header may be used by any proxy service between the client and server to rate limit traffic to that URL
17:46:26 <devananda> ie, it may affect requests for the whole endpont
17:46:34 <devananda> not just that node
17:46:46 <JoshNang> right. so maybe we use a different header and a 406 as dtantsur suggested?
17:47:03 <devananda> https://tools.ietf.org/html/rfc7231#section-6.5.6
17:47:36 <devananda> that should be returned if a client asks for an XML representation of our JSON objects
17:47:40 <devananda> it's not supported
17:47:45 <devananda> ie, the request is not acceptable
17:48:00 <dtantsur> I probably meant 409..
17:48:08 * dtantsur always confuses these 2
17:48:21 <devananda> 409 CONFLICT is what we already use for NodeLocked (and agreed we need to reduce/change)
17:48:33 <devananda> and thta's a client error
17:48:46 <dtantsur> yeah, we're abusing it a lot
17:48:50 <devananda> there's not a good error code because, well, it's not an error
17:48:55 <dtantsur> actually it should be some kind of 3xx code...
17:48:56 <devananda> "server does not yet have the info you want"
17:48:59 <jroll> devananda: so, we've been through all of this before
17:49:02 <devananda> isn't an error in the server or in the client
17:49:11 <jroll> basically I think we've determined there's no good return code for this
17:49:17 <jroll> and this agenda item is "wat do"
17:49:17 <devananda> an empty body is what we actually have
17:49:43 <dtantsur> jroll, ++
17:49:54 <devananda> so perhaps the problem is that we're avoiding the problem right now by trying to use an HTTP error code
17:50:16 <devananda> instead of returning an empty BODY and a custom header
17:50:41 <rloo> wrt retry-after, looks like it is OK to use for eg 3xx: https://tools.ietf.org/html/rfc7231#section-7.1.3
17:50:43 <devananda> with an HTTP 200 code
17:51:05 <devananda> or a 204 NO CONTENT
17:51:07 <dtantsur> maybe 202 accepted?
17:51:10 <dtantsur> or 204, yeah..
17:51:38 <devananda> though 204 is usually used for PUT requests ...https://tools.ietf.org/html/rfc7231#section-6.3.5
17:51:51 <gabriel-bezerra> The 202 (Accepted) status code indicates that the request has been
17:51:53 <gabriel-bezerra> accepted for processing, but the processing has not been completed.
17:51:56 <devananda> does anyone have a problem with using 200 with an empty body?
17:52:13 <dtantsur> I think 202 is the closest
17:52:14 <devananda> gabriel-bezerra: right. both 202 and 204 are in relation to PUT or POST requests
17:52:25 <devananda> but we're talking about a GET request here, right?
17:52:31 <dtantsur> while it's weird to use 202 for get
17:52:38 <dtantsur> I think using just 200 is even more confusing
17:52:54 <gabriel-bezerra> idk, all I know comes from this meeting
17:53:06 <dtantsur> at least "requested has been accepted for processing" sounds precise to me
17:53:21 <devananda> ie, GET /v1/nodes/NNN/cleaning/all_steps
17:53:22 * jlvillal wonders if this is a good topic for further discussion at the mid-cycle
17:53:25 <devananda> JoshNang: ^ ?
17:53:26 <jroll> well
17:53:32 <JoshNang> devananda: correct
17:53:34 <rloo> agree with dtantsur, 202 seems to make most sense
17:53:43 <jroll> so what do we do for POST /v1/nodes/NNN/start/some/clean/step
17:53:45 <devananda> 202 ACCEPTED doesn't make any sense for a GET request ....
17:53:49 <dtantsur> why?
17:54:02 <devananda> because GET doesn't indicate an action
17:54:10 <NobodyCam> jlvillal: good point ... it is in three days
17:54:13 <dtantsur> then maybe it's NOT a GET actually?
17:54:15 <gabriel-bezerra> devananda ++
17:54:19 <devananda> dtantsur: uh, it is ...
17:54:24 <jroll> ok, let's back up
17:54:27 <devananda> dtantsur: the client is trying to request (GET) some data which the server doesn' thave yet
17:54:32 <jroll> is this ONLY a problem for "get list of steps"
17:54:37 <JoshNang> yes
17:54:39 <jroll> or is it also a problem for "run this step"
17:54:42 <NobodyCam> 5 minutes
17:54:50 <devananda> jroll: that is my understanding -- only a problem for 'get list of steps
17:54:56 <JoshNang> nope, only get. the put to start a step is expected to take some time
17:55:00 <jroll> because I assume "run this step" requires ironic to know the step exists
17:55:01 <jroll> ok
17:55:08 <gabriel-bezerra> the return then is Either DontHaveYet or List()
17:55:09 <devananda> 404 not found could also work
17:55:19 <dtantsur> 404 is usually not retriable
17:55:26 <dtantsur> though maybe..
17:55:27 <devananda> ie, /v1/nodes/NNN  exists but /v1/nodes/NNN/cleaning doe snot yet exist
17:55:38 <devananda> because that resource is not known yet
17:55:47 <devananda> 404 does not imply that the resource will never exit
17:55:49 <devananda> just that it doens't right now
17:56:03 <devananda> anyway, we have 4 minutes left, so i'm tabling this for now
17:56:05 <dtantsur> 404 with retry-after header... well, maybe
17:56:08 <devananda> #topic open discussion
17:56:15 <NobodyCam> gosh 503 seems to make sense for this
17:56:15 <devananda> because we should have some time for open discussion :)
17:56:19 <dtantsur> we had one more topic on schedule as well :)
17:56:24 <dtantsur> * agenda
17:56:28 <jlvillal> FYI: The doc job in the gate is no longer broken.
17:56:30 <JoshNang> wfm. feel free to discuss on the spec: https://review.openstack.org/#/c/209207/
17:56:41 <dtantsur> wanna flame war about which API version to leave in client? ;)
17:56:45 <jroll> dtantsur: lol if you think that topic can happen in 3 minutes
17:56:48 <jroll> :)
17:57:02 <dtantsur> no chance
17:57:50 <rloo> honestly, i couldn't even figure out from the mailing list what we had decided, if anything
17:57:53 <devananda> dtantsur: 2.0 :-P
17:58:05 <devananda> rloo: neither could I
17:58:15 <jroll> we didn't make a decision on the client afaik
17:58:23 <dtantsur> that's a normal state of things with versioning in ironic :-P
17:58:24 <devananda> in IRC last week we did reach a decision re: the server
17:58:29 <devananda> I haven't seen any objections on the ML
17:58:53 <devananda> jroll: want to do a release of the server today? or wait till wednesday when we can all go offline immediately afterwards and get a drink? ;)
17:59:07 <rloo> devananda: oh, what was the decision in IRC wrt server?
17:59:16 <NobodyCam> lol
17:59:16 <devananda> rloo: last week? ya
17:59:24 <jroll> devananda: yeah, I like wednesday
17:59:25 <thiagop> LOL
17:59:30 <devananda> jroll: cool
17:59:37 <dtantsur> rloo, NOT to do anything about already landed ENROLL version 1.11
17:59:50 <jroll> rloo: http://lists.openstack.org/pipermail/openstack-dev/2015-August/071361.html
17:59:51 <NobodyCam> and *beep* time
18:00:07 <dtantsur> thanks, that was a productive meeting
18:00:12 <rloo> dtantsur, jroll: ok
18:00:13 <devananda> beeeeeep :)
18:00:13 <jroll> thanks all
18:00:15 <devananda> thanks all!
18:00:24 <devananda> see (most of) you in a couple days!
18:00:26 <gabriel-bezerra> thank you
18:00:27 <jlvillal> Ciao!
18:00:30 <devananda> #endmeeting