05:00:47 <devananda> #startmeeting ironic
05:00:48 <openstack> Meeting started Tue Jun 23 05:00:47 2015 UTC and is due to finish in 60 minutes.  The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot.
05:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
05:00:51 <openstack> The meeting name has been set to 'ironic'
05:00:52 <devananda> who's around?
05:00:54 <mrda> o/
05:00:57 <jroll> ohai \o
05:01:04 <naohirot> o/
05:01:29 <devananda> the agenda, as usual, is here:
05:01:31 <devananda> #link https://wiki.openstack.org/wiki/Meetings/Ironic
05:01:39 <devananda> it is oddly empty
05:02:08 <jroll> I won't complain :)
05:02:10 <devananda> I'll wait a few more minutes and see who shows up
05:02:14 * mrda hopes everything going swimmingly then
05:02:19 <rameshg87> o/
05:02:30 <devananda> mrda: I've been on the road for, um, several weeks >_<
05:02:31 <wanyen> o/
05:02:42 <jroll> I have a couple things of note at some point
05:02:47 <mrda> devananda: you must be glad to be home then
05:02:56 <devananda> mrda: very much so
05:04:24 * devananda continues waiting to see if we get any more cores in the room
05:04:53 <jroll> devananda: 2 is enough to decide anything, right? :)
05:04:59 <devananda> jroll: lol
05:05:21 * jroll merges everything
05:05:49 <mrda> "jroll merges all the things"
05:05:54 <devananda> all right ... 5 minutes in and we've got 3 cores ...
05:05:55 <mrda> that could be a meme
05:06:11 <jroll> heh
05:06:23 <devananda> #info only 3 cores present, and no agenda on the wiki.
05:06:26 <devananda> #topic open discussion
05:06:30 <jroll> oh, I missed rameshg87, hi rameshg87! be louder :)
05:06:46 <jroll> so I have some things for open discussion
05:06:48 <rameshg87> hi jroooooollllllll
05:06:53 * rameshg87 gets louder :)
05:07:16 <jroll> first off, this neutron integration spec has rough consensus from the subteam. I hate asking for reviews, but we need reviews :)
05:07:18 <jroll> #link https://review.openstack.org/#/c/187829/
05:07:30 <mrda> Cool!
05:07:49 <rameshg87> great .. :)
05:08:04 <jroll> maybe that's it, I thought I had something else but it's late and it isn't coming to mind :P
05:08:39 <devananda> jroll: nova stuff?
05:08:48 <jroll> aha yes
05:09:07 <jroll> I put up a spec today for fixing our nova-compute model of the world
05:09:09 <jroll> #link https://review.openstack.org/#/c/194453/
05:09:14 <jroll> pls to check it out :)
05:09:27 <mrda> Thanks jroll - I will take a look
05:09:39 <jroll> awesome.
05:09:46 <rameshg87> oh i was about to ask if someone was working on it :)
05:09:47 <jroll> it's roughly what we decided in vancouver
05:09:56 <jroll> and jay pipes, devananda and myself chatted about it today
05:10:01 <mrda> That'll be a nice piece of work, if we get agreement
05:10:24 <jroll> indeed. I for one am excited.
05:10:57 <mrda> Ok, I have something to raise, if we're done with that
05:11:05 <mrda> I feel I should mention "Bare metal" or "Bare Metal" and https://review.openstack.org/#/c/194230
05:11:06 <devananda> mrda: we should go to vegas. jaypipes and I agree on something :)
05:11:17 * naohirot jroll, I need to discuss with you regarding the #link https://review.openstack.org/#/c/187829/
05:11:23 <mrda> devananda: Is the midcycle fixed for SEA? :P
05:11:36 <devananda> mrda: I'm *STILL* waiting on facilities :(
05:11:43 <devananda> and getting quite grumpy about it
05:11:44 <jroll> devananda: boooooo
05:11:47 <mrda> devananda: well, maybe then
05:12:01 <devananda> I am actually going into the office tomorrow and will sort this out
05:12:04 <mrda> Anyhow, "Bare metal" vs "Bare metal" in docs
05:12:11 <mrda> Sorry Bare Metal
05:12:13 <rameshg87> mrda: does it actually matter somewhere ? Bare Metal or Bare metal ?
05:12:22 <rameshg87> for docs, is it ?
05:12:26 <mrda> Except it's work to be done with little value
05:12:26 <jroll> naohirot: go ahead? I don't have anything to say I haven't said in that discussion
05:12:44 <mrda> I don't want us to be seen as bike shedders
05:12:55 <mrda> Do we really need to change it?
05:13:03 <naohirot> jroll: Okay, the point I need to discuss is the problem description,
05:13:05 <mrda> Opinions?
05:13:14 <jroll> naohirot: so the discussion here. https://review.openstack.org/#/c/187829/3/specs/liberty/network-provider.rst
05:13:18 <jroll> right?
05:13:43 <rameshg87> mrda: i am +0 on it unless it matters somewhere :)
05:13:49 <naohirot> jroll: yeah, right
05:14:13 <mrda> I just want to keep docs on-side.  My preference is pretty much +0 too
05:14:33 <jroll> naohirot: what isn't clear about "ironic provisions servers on the same network that tenants use"?
05:14:43 <jroll> anyone else, is there something unclear about that, that I am not seeing
05:14:47 <naohirot> naohirot: As I commented in the gerrit, sufficient or not only can be judged by reader.
05:15:05 <mrda> I guess I'm hoping the other two cores here will chime in
05:15:41 <naohirot> jroll: for instance, if developer thought it's good product, but customer didn't think so
05:15:53 <devananda> mrda: see the last comment and link to the ML re: capitalization of Proper Names
05:15:55 <jroll> naohirot: what?
05:15:59 <naohirot> jroll: developer cannot deny the customer
05:16:00 <devananda> mrda: I think things will go in that direction
05:16:42 <mrda> devananda: so ML discussion will decide then?
05:16:48 <jroll> naohirot: I have no idea what a customer has to do with this
05:16:53 <naohirot> jroll: That customer felt so, that is fact, it's not denyable.
05:17:07 <devananda> naohirot: a great many of the developers in this case are also users
05:17:23 <naohirot> jroll: customer is a reader in this case.
05:17:41 <devananda> naohirot: i dont understand why you're arguing about this
05:17:50 <naohirot> jroll: reader felt it is not sufficient to understand the problem
05:17:52 <devananda> naohirot: you didn't understand something. you do now. let's move on.
05:18:16 <devananda> naohirot: dialogue occurred. knowledge was shared. what's the problem?
05:18:52 <naohirot> devananda: but it's not only me, other new conributer likely to have same question
05:19:04 <devananda> naohirot: also, a design spec IS NOT DOCUMENTATION. the intended audice of https://review.openstack.org/#/c/187829/3/specs/liberty/network-provider.rst are existing contributors familiar with the code
05:19:22 <devananda> naohirot: who are themselves then able to judge the merits and drawbacks of the proposed changes
05:19:37 <jroll> the goal is to make the problem disappear, so nobody needs to understand that problem description.
05:19:41 <devananda> naohirot: a new contributor is not able to make that judgement in the same way because they lack the context and knowledge
05:19:49 <naohirot> devananda: if review comment is ignored by unreasonable reason, the whole review process is wast of time
05:20:10 <devananda> naohirot: the review process is not a waste of time
05:20:13 <devananda> naohirot: i'm sorry you feel that way
05:20:18 <jroll> naohirot: so is this your review comment or your customer's review comment?
05:20:45 <jroll> naohirot: also, define "customer". developer, deployer, ironic user, nova user?
05:20:46 <naohirot> devananda: I made a comment it's not sufficient, why is it ignored?
05:21:07 <devananda> naohirot: if your feedback was on documentation -- that some section of documentation was not understandable, or lacked context, and was hard to understand or ambiguous -- then we should clearly update that documentation
05:21:38 <naohirot> devananda: then I proposed sentence to Jim.
05:22:26 <devananda> naohirot: the current wording is perfectly clear to me
05:22:31 <naohirot> devananda: I proposed concrete sentence how to update for reader who is not knowlegable
05:22:48 <devananda> "Ironic currently provisions servers on the same (flat) network that tenants use."
05:22:51 <naohirot> devananda: sure, you are core and know details.
05:22:52 <devananda> I know exactly what that means
05:23:20 <naohirot> devananda: but are we writing the spec for only such people like you?
05:23:30 <jroll> honestly, I'm tempted to say that anyone who does not already understand the problem does not need to review that spec. why does someone care about fixing it if they don't know it's a problem?
05:23:49 <jroll> if a flat network is fine, then don't review it
05:24:23 <jroll> if you don't even know that ironic uses a single flat network, I don't believe you are a developer/deployer/operator/user of ironic?
05:24:23 <devananda> naohirot: the author of a patch has every right to change their spec as they see fit
05:24:35 <devananda> naohirot: you don't get to insist that jroll changes his document in the way that you want
05:24:39 <naohirot> jroll: i think neutron integration is important for cloud provider
05:24:41 <rameshg87> naohirot: i guess point jroll was having was the problem is same regardless of it's single/multiple conductors or nova/standalone deployment
05:25:05 <rameshg87> naohirot: so honestly i don't feel that change is required too
05:25:07 <naohirot> jroll: that's the reason I'm reviewing and trying to understand the problem
05:26:03 <devananda> naohirot: reviewing a design proposal for new work is not the place to stop someone else's work and ask them to help you understand the current problem
05:26:06 <naohirot> rameshg87: again I know that core know about it, I don't deny it.
05:26:09 <rameshg87> in a team/community project, voice of community > voice of individuals. so i guess if more people agree on one side, we should just stick with it.
05:26:10 <rameshg87> right ?
05:26:14 <devananda> naohirot: that is valuable feedback for documentation, NOT for design work
05:26:30 <naohirot> rameshg87: I'm talking about people, ordianry people
05:26:46 <devananda> naohirot: and again, a design spec is intended for those people already involved in a project to evaluate the proposed changes.
05:26:59 <jroll> ordinary people don't know what a network is
05:27:05 <devananda> naohirot: if the documentation is not clear, please provide feedback on ways we can improve it (or -- better yet, a patch to improve it)
05:27:20 <jroll> so going back to square one.
05:27:26 * rameshg87 has one item to discuss
05:27:36 <jroll> naohirot: now that you (presumably) understand the problem, is it still unclear to you?
05:27:47 <naohirot> devananda: again I commented a concrete sentence how we should explain the problem in the gerrit.
05:28:06 <jroll> rameshg87: I hear you, don't let us forget :)
05:28:11 * Nisha has capabilities to be discussed
05:28:31 <rameshg87> :)
05:28:34 <devananda> naohirot: even now, you are not understanding me. let's move on.
05:28:37 <devananda> Nisha: go ahead :)
05:28:38 <naohirot> jroll: Yes I understood the problem, but why don't we record the essense in the spec.
05:28:43 * rameshg87 takes the mic
05:28:49 <jroll> rameshg87 was first
05:28:57 <devananda> jroll: thanks. rameshg87 -- the floor is yours :)
05:28:57 <Nisha> rameshg87, :)
05:29:03 <Nisha> yes jroll :)
05:29:06 <jroll> naohirot: because the spec is not documentation about how ironic works.
05:29:08 <rameshg87> i have a patch here to refactor pxe as boot interface - https://review.openstack.org/#/c/166513/
05:29:26 <jroll> \o/
05:29:32 <mrda> :)
05:29:48 <rameshg87> there is no time left for liberty-1 anyway, but it will be good if we can get much of the work done in liberty-2
05:30:08 <devananda> rameshg87: whoa! nice
05:30:10 <rameshg87> i am planning to put up patches one after another
05:30:22 <devananda> rameshg87: hm. isn't there a bp/spec for that? it's not tagged on the commit header
05:30:23 <rameshg87> people are welcome to review and more importantly to try it
05:30:34 <rameshg87> to make sure we don't break anything
05:30:47 * rameshg87 forgot
05:30:52 <devananda> :)
05:30:56 <rameshg87> devananda: will add bp to next patch
05:31:02 * jroll personally would like to stop talking about liberty-1 etc :)
05:31:05 <rameshg87> it is still W-1 as i need to add some documentation
05:31:20 <jroll> I'd love to do a release when the boot/deploy split is done
05:31:21 <rameshg87> i mean docstrings
05:31:30 <rameshg87> \o/
05:31:51 <jroll> rameshg87: I suggest you remove the WIP, otherwise some people won't review it
05:31:52 <rameshg87> jroll: so that may be the first release :)
05:32:07 <jroll> rameshg87: if someone merges it by accident we can follow up with docstring patches :)
05:32:13 <mrda> :)
05:32:16 * rameshg87 removed now
05:32:22 <jroll> woot.
05:32:25 <devananda> jroll: if we can sort the release details out w/ dhellmann before this lands ... it would make an interesting first go at it
05:32:27 <jroll> thanks for taking this work on :)
05:32:51 <devananda> rameshg87: my biggest concern with this is ofc how does it affect out of tree drivers
05:32:57 <jroll> devananda: I don't think there's much contention there, if I wasn't going on vacation I'd hope to do it this week :)
05:33:18 <rameshg87> devananda: it doesn't, there is no change to how conductor sees drivers now
05:33:37 <rameshg87> devananda: it's just an understand between boot and deploy interfaces of drivers that is driving this change
05:33:40 <devananda> rameshg87: what if this file  https://review.openstack.org/#/c/166513/7/ironic/drivers/pxe.py,cm were split into multiple changes?
05:33:42 <jroll> rameshg87: so the deploy driver calls to the boot driver, right?
05:33:43 <rameshg87> *understanding
05:33:49 <rameshg87> jroll: yes
05:34:05 <devananda> rameshg87: not asking that it necessarily be done that way, but it would be a good way to prove that it works
05:34:10 <jroll> cool, so I agree probably doesn't affect out-of-tree drivers unless they're relying on deploy_utils etc
05:34:47 <rameshg87> devananda: how does it prove it ? i didn't get
05:34:58 <jroll> yeah, not seeing it either
05:35:08 <devananda> eh, it's late. maybe i'm wrong
05:35:32 <rameshg87> okay, i tested with pxe_vbox and jenkins tested with pxe_ssh, so reasonably it should work with other drivers :)
05:35:45 <jroll> so as this is, a completely out of tree driver should be fine. one that relies on some of our helper functions may break
05:35:47 <rameshg87> other drivers of form pxe_* :)
05:36:02 <devananda> oh - nope, i'm not wrong
05:36:06 <jroll> and I think I'm okay with that, we don't guarantee anything explicitly about those methods
05:36:14 <jroll> devananda: famous last words :)
05:36:20 <devananda> drivers/modules/pxe.py: PXEDeploy class is removed in this patch
05:36:28 <rameshg87> jroll: do we really promise them stuffs like deploy_utils are not changed ?
05:36:37 <devananda> so if I had another driver that inherited from that -- boom
05:36:50 <jroll> rameshg87: we don't promise it explicitly, no
05:37:07 <devananda> (that's not part of our driver API -- but it's still a thing someone may have done downstream)
05:37:13 <jroll> devananda: while I'm all about not breaking out of tree things... is that part of our contract?
05:37:15 <jroll> yeah
05:37:20 <rameshg87> devananda: but upstream drivers have mostly unit tests, so going by that it will fail
05:37:36 <jroll> I mean, we should at a minimum mail a list about this
05:37:45 <jroll> I'm not sure if we should do more :)
05:38:03 <devananda> jroll: we totally have to do a mailing about this before it lands
05:38:13 <devananda> this one line change sums up my concern: https://review.openstack.org/#/c/166513/7/ironic/drivers/modules/amt/vendor.py,cm
05:38:13 <jroll> +1
05:38:22 <rameshg87> devananda: may be it's time to have something written down in wiki about contract
05:38:38 <devananda> anyone who may have an out of tree driver that is extending or inheriting from one of our current driver CLASSES is going to get broken
05:38:48 <devananda> even though the API contract itself is not broken
05:38:54 <jroll> yep
05:39:00 <devananda> so we're technically fine -- a completely original out of tree driver will not be affected
05:39:17 <rameshg87> devananda: afaik we only have contracts about interfaces that publish explicity
05:39:23 <devananda> rameshg87: you're correct
05:39:41 <rameshg87> devananda: may be mailing list is a good place to communicate ?
05:40:02 <rameshg87> because we need that to be broken down in any case :)
05:40:05 <devananda> but this will break my out-of-tree driver :P
05:40:06 <devananda> https://review.openstack.org/#/c/193767/1/ironic/drivers/pxe.py,cm
05:40:22 <devananda> so I know it will affect anyone else who's doing something similar
05:40:45 <rameshg87> petitboot
05:40:52 <rameshg87> i already commented on that review
05:40:52 <jroll> yeah, agree we should mail a list
05:40:53 <devananda> yup -- that too
05:41:10 <jroll> is there anythign more we should do though?
05:41:15 <jroll> sounds like we're in agreement
05:41:23 <devananda> rameshg87: please send an email to both openstack-dev and openstack-operators lists
05:41:36 <devananda> and let's wait a minimum of 7 days after that before we land it
05:41:43 <rameshg87> devananda: sure
05:42:02 <jroll> do we want to -2 or anything to enforce that?
05:42:04 <devananda> realistically, we'll all probably be fighting to land it as soon as 7 days have passed, because this is fantastic
05:42:11 <jroll> heh
05:42:14 <devananda> but waiting is the right thing to do
05:42:36 <rameshg87> okay ..
05:42:45 * rameshg87 hands microphone over to Nisha
05:42:48 <devananda> jroll: just W-1 ?
05:42:54 <jroll> yeah, seems fine
05:43:22 <naohirot> devananda: can we discuss another topic regarding liberty-1?
05:43:26 <rameshg87> devananda: do you want me to W-1 again ?
05:43:49 <jroll> ok, Nisha and naohirot both have items to discuss, should we risk taking them in parallel? :)
05:44:05 <jroll> naohirot: what's the general subject, out of curiousity?
05:44:08 <Nisha> devananda, we agreed earlier for boolean capabilities. My ques is where do we define them? in each driver? or a centre place in ironic?
05:44:08 <Nisha> Do we require a spec to just define all the possible capabilities
05:44:46 <naohirot> jroll: I'm fine if we can discuss my topic in the ironic channel, go ahead to Nisha's topic
05:44:48 <devananda> Nisha: eeeeh. yea, I think this needs to be defined across all drivers (iow, in the conductor) so we need to define the set of supported capabilities
05:45:04 <jroll> at a glance I think I agree
05:45:06 <devananda> Nisha: has Nova team agreed to the way you want to expose them?
05:45:07 <mrda> Nisha: My personal opinion is that we have a spec for this
05:45:12 <jroll> and then maybe drivers can indicate which they support
05:45:17 <devananda> jroll: exactly
05:45:32 <jroll> cool
05:45:39 <Nisha> devananda, they have agreed for boolean capabilities but i didnt get any further reviews on the spec from them
05:45:42 <jroll> see, 2 cores can get stuff done :)
05:45:54 * jroll +A
05:46:01 <Nisha> mrda, but the spec will just contain all the capabilities so far
05:46:21 <mrda> I think that's a good start
05:46:27 <devananda> rameshg87: W-1 needs to be applied at every revision. you could also -2 your own patch :)
05:46:44 <Nisha> mrda, ok :)
05:46:51 * naohirot jroll , devananda , my topic is irmc vmedia, and maybe related to new feature release model
05:46:53 <Nisha> #link https://review.openstack.org/182934, with this spec i have proposed capabilities to be a new field in node table which can accept key:value pair.
05:47:02 <jroll> Nisha: I think that's fine, additional capabilities can be covered in the spec that adds the feature
05:47:28 <devananda> Nisha: if we were to allow each driver to expose arbitrary capabilities, we'll have no consistency between drivers -- and thus defeat much of the purpose of capabilities. so yea, I think we need a spec to define the set of ironic-supported capabilities
05:47:39 <mrda> I think that's good.  Question is for a driver writer to know what capabilities there are, and which ones they should support
05:47:45 * rameshg87 does that
05:47:48 <devananda> Nisha: and if we need to add to that list over time, we'll need some aceptance from >1 driver/vendor that they can support it
05:47:48 * jroll makes a motion to #agreed
05:48:02 <Nisha> jroll ques was where do we have the set of supported capabilities
05:48:09 <Nisha> devananda, +1
05:48:15 <jroll> Nisha: ironic/common/capabilities.py? :)
05:48:21 <devananda> Nisha: list of ... yes, in python ^
05:48:37 <Nisha> devananda, jroll ok
05:48:52 <devananda> this could be discovered by ironic-inspector and the node record updated
05:48:56 <devananda> or $soemthing
05:48:59 <Nisha> so do we agree that capabilities shall be a new field in node table
05:49:01 <mrda> Do we see the need to have a required minimum set for each class of driver?
05:49:03 <Nisha> yes
05:49:12 <Nisha> devananda, i was coming to above point
05:49:14 <devananda> mrda: supports_power_management :)
05:49:32 <mrda> :)
05:49:41 <jroll> Nisha: I think I'd rather a separate table, didn't we agree on that part already?
05:50:02 <Nisha> jroll, i actually didnt understand the need for a new table
05:50:04 <devananda> much like node.properties, we will need to search based on capabilities at some point in the near future
05:50:19 <jroll> Nisha: to be able to index it. can't index lists in mysql.
05:50:23 <devananda> Nisha: so that we can efficiently create INDEX(key, value) on that table
05:50:30 <devananda> and do queries such as ...
05:50:57 <Nisha> let me summarize the flow i think would be feasible (from nova to ironic)
05:51:01 <devananda> SELECT node.uuid FROM nodes JOIN node_caps ... WHERE node_caps.key='boot_mode' AND node_caps.value='secure';
05:51:02 <jroll> devananda: your dark past is about to show, I think :)
05:51:04 <jroll> yep.
05:51:08 <devananda> jroll: yup
05:51:22 <rameshg87> :)
05:51:36 <Nisha> devananda, so do we need end point for capabilities if nova doesnt require it
05:51:53 <devananda> because trying to mimic that query outside of the database is just insanity -- and there, in a nutshell, is one of my biggest problems with the nova scheduler today
05:51:58 <devananda> Nisha: yes
05:52:01 <rameshg87> i would still vote for a capabilities endpoint
05:52:03 <devananda> Nisha: but don't worry about that in this spec
05:52:27 <Nisha> Ok...
05:52:39 <devananda> just add the capabilities table, a decent initial set to the conductor, and REST API to change them
05:52:52 * rameshg87 notes 8 minutes left
05:52:53 <devananda> we'll worry about the query API after that
05:53:06 <Nisha> devananda, sorry a trivial ques but what shall be the fields of this table
05:53:07 * mrda thinks we'll still need one though
05:53:09 * jroll nods at rameshg87
05:53:12 <devananda> because I also want to refactor the node.properties JSON field into its own table, that has the same structure and same index
05:53:16 <Nisha> i was unable to think on that
05:53:27 <Nisha> k
05:53:36 <devananda> and then create a REST endpoint like: GET /v1/search?field=value&another=value&....
05:53:37 <jroll> Nisha: node_uuid, key, value? or node_uuid, capability, supported.
05:54:04 <jroll> Nisha: not super important right now, I think, we can review in the spec
05:54:21 <Nisha> jroll thanks for the pointer
05:54:24 <Nisha> that helps
05:54:31 <jroll> Nisha: welcome :)
05:54:40 <devananda> node_id INT UNSIGNED, capability VARCHAR(nn) NOT NULL, PRIMARY KEY (node_id, capability)
05:54:43 <devananda> that's it
05:54:54 <Nisha> ok will change the spec and post it
05:55:03 <Nisha> devananda, thanks
05:55:05 <devananda> that's it, I think, because the presence of a row means "supported" and lack of a row means "unsupported" ?
05:55:10 <devananda> I think that's good enough
05:55:17 <devananda> but at least it's a starting point
05:55:34 <devananda> Nisha: thanks much for working through all this! I know it's taken a long time
05:55:50 <Nisha> devananda, :) thanks for the guidance
05:56:09 <rameshg87> okay, 5 minutes left, any other topic ?
05:56:12 <jroll> shall we give the last 5 minutes to naohirot ?
05:56:27 <wanyen> deva and nisah, should conductor just get a list of supported capabilities from drivers?
05:56:41 <devananda> naohirot: the floor is yours
05:56:41 <naohirot> jroll: I need more than 5 mins :)
05:56:56 <jroll> hm
05:57:05 <naohirot> devananda: can we disucss in the ironic channel?
05:57:07 <devananda> wanyen: no. see my previous comments. tldr; that will be a leaky API and essentially unsupportable
05:57:09 <jroll> just take it to the channel then?
05:57:10 <devananda> naohirot: sure
05:57:13 <wanyen> That's way when driver added supported capabilities then we don't need to change conductor
05:57:16 <jroll> cool
05:57:35 <devananda> wanyen: every vendor will be different, there will be no way to do common scheduling, and users will suffer
05:58:09 <naohirot> devananda: thanks!
05:58:25 <wanyen> devananda, forcommon capabilities we should standaridize capbility name but for vendor specific capability we should allow them too
05:58:45 <devananda> wanyen: I disagree. we shouldn't support vendor-specific capabilities
05:58:58 <wanyen> deva, why not?
05:59:06 <devananda> wanyen: if a functionality can not be expressed in a common way, it belongs in /vendor_passthru/
05:59:37 <mrda> +1
05:59:39 <devananda> as long as it can be expressed in a common way, the implementations can be wildly different
05:59:43 <devananda> but the API can be the same
05:59:44 <wanyen> deva, yea,vendor pass through but it needs capability
05:59:49 <Haomeng|2> +1
05:59:50 <devananda> and there is a tremendous value in that consistency
06:00:06 <jroll> whoa whoa whoa, consistency between drivers?!?!
06:00:14 <devananda> jroll: inoright? :P
06:00:20 <devananda> anyway, we're out of time ... thanks all!
06:00:20 <wanyen> it relies on Nova to pass capabilities info to ironic driver
06:00:36 <jroll> thanks everybody.
06:00:39 <devananda> #endmeeting