17:00:25 <devananda> #startmeeting ironic
17:00:26 <openstack> Meeting started Mon Nov 30 17:00:25 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:29 <openstack> The meeting name has been set to 'ironic'
17:00:37 <NobodyCam> o/
17:00:42 <TheJulia> o/
17:00:45 <mjturek1> o/
17:00:46 <betherly> o/
17:00:46 <devananda> hello everyone!
17:00:57 <NobodyCam> good morning
17:00:58 <pas-ha> o/
17:00:59 <NobodyCam> :)
17:01:02 <mgould> o/
17:01:08 <devananda> as usual, our agenda can be found on the wiki page here: https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:01:11 <yuriyz|2> o/
17:01:22 <JayF> o/
17:01:25 <dtantsur> o/
17:01:31 <devananda> today is a bit light, but I'll start with the announcements
17:01:42 <vdrok> o/
17:01:47 <cdearborn> o/
17:01:48 <rpioso> o/
17:02:02 <devananda> also - for those who were out last week, welcome back from thanksgiving holiday :)
17:02:05 <devananda> #topic announcements
17:02:12 <sambetts> o/
17:02:21 <rloo> o/
17:02:23 <devananda> jroll is out pretty much all week
17:02:48 <devananda> he's asked me to handle the M1 milestone and release, which I'll be doing by Thursday
17:03:16 <jroll> hi, I'm sort-of-not-really-here for a few :)
17:03:17 <devananda> so let's focus on stability this week -- fixing bugs and not landing any half-baked or risky features
17:03:23 <devananda> jroll: ohhai!
17:03:30 <devananda> #chair jroll
17:03:30 <openstack> Current chairs: devananda jroll
17:03:30 <jroll> thanks for running things :D
17:04:06 <devananda> second announcement is that we've moved away from launchpad for release notes generation, and are already using the new Reno project
17:04:07 <cinerama> o/
17:04:56 <jroll> (still need to move to reno for IPA, and ironicclient)
17:04:58 <dtantsur> devananda, not for ironicclient yet, right?
17:05:04 <dtantsur> yeah, and ironic-lib :)
17:05:08 <jroll> ^^
17:05:12 <devananda> yep
17:05:42 <devananda> jroll: we're not planning a release of IPA or ironicclient this week though, correct?
17:05:50 <rloo> we probably should move to reno for all -- volunteers? :)
17:05:53 <jroll> devananda: correct
17:06:55 <devananda> tldr; when you write a patch (or review a patch) that completes a feature, bug fix, or impacts anyone running ironic, please make sure it includes a release note update.
17:07:15 <devananda> #topic subteam status reports
17:07:26 <devananda> I'll give everyone a few minutes to look over the whiteboard ... :)
17:07:31 <NobodyCam> #link http://docs.openstack.org/developer/reno/usage.html#creating-new-release-notes
17:07:35 <NobodyCam> just fyi
17:07:39 <rloo> is IPA a subteam report any more? Wondering if we should remove it
17:07:39 <devananda> NobodyCam: ty
17:07:53 <krtaylor> o/  sorry I'm late
17:08:14 <dtantsur> rloo, IPA is everyone now ;)
17:08:44 <dtantsur> yeah, ++ for removing
17:08:45 <rloo> dtantsur: yeah, i was wondering what would go there, but we have IPA like we have ironic-inspector so I guess yes, it should stay in.
17:09:08 <dtantsur> rloo, inspector is much more independent
17:09:33 <dtantsur> IPA now is even more important than ironicclient now
17:09:56 <rloo> dtantsur: ++ for importance of IPA!
17:10:27 <rloo> the multiple compute hosts work is dependent on the node filter api/claims work, right?
17:11:05 <devananda> rloo: yah
17:11:28 <rloo> wrt the spec for node filter API..., are there any major blockers?
17:11:35 <devananda> we've discussed doing an API-only POC for the claims/filtering, so that the nova driver work can start in earnest
17:11:46 <devananda> but the API itself is blocked in discussions in the spec
17:12:29 <devananda> I'll try to spend some time this week with penick to resolve his concerns
17:12:41 <rloo> devananda: ok thx.
17:13:15 <rloo> ilo has 3rd party CI? Anyone know the status of that?
17:13:33 <dtantsur> there is a post on the ML, they just introduced it
17:13:51 <NobodyCam> last I heard they were working on getting external networkaccess
17:13:52 <devananda> dtantsur: with a release coming later this week, I see you've noted a few bugs that should be prioritized
17:14:05 <sambetts> it also got added as non-voting initally and was blocking the gate earlier today I believe
17:14:06 <NobodyCam> rloo: I can follow up on that
17:14:14 <sambetts> I think jroll fixed it
17:14:15 <jroll> right - fyi, they aren't supposed to be announcing those on the dev list, if someone told them to do that please don't in the future :)
17:14:19 <jroll> re ilo ^
17:14:24 <dtantsur> ilo announcement: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080806.html
17:14:42 <rloo> jroll: what are they supposed to do?
17:14:44 <dtantsur> devananda, yeah, at least worth taking a look. one of them is the reason of big rant among tripleo folks :)
17:14:55 <dtantsur> jroll, why?
17:15:10 <devananda> sambetts: you mean ilo 3rd party ci was blocking the gate, or something else was?
17:15:19 <jroll> dtantsur: rloo: I'm not sure, but the instructions are in third party CI docs... anteaya is replying to that mail about it
17:15:19 <sambetts> devananda: yes
17:15:29 <sambetts> the ilo ci
17:15:35 <devananda> sambetts: :-/
17:15:55 <rloo> jroll: if anteaya is replying, she'll set us all straight :)
17:16:00 <jroll> yep :D
17:16:08 <anteaya> how was a ci system blocking the gate?
17:16:21 <anteaya> ci systems vote verified on a patch at best
17:16:26 <jroll> sambetts: devananda: I don't believe ilo ci was ever blocking the gate
17:16:26 <jroll> think that was a false alarm
17:16:28 <anteaya> that does not block the gate
17:16:30 <jroll> it *looks* to be voting but does not block
17:16:31 * dtantsur asks
17:16:42 <devananda> jroll: ok, that's what I would expect
17:16:44 <sambetts> ooo thats good then, sorry for the noise
17:16:52 <anteaya> even a ci system voting -1 verified on a patch does not block the gate
17:16:56 <devananda> I'm looking at a recent run right now and it seems fine
17:17:26 <rloo> yeah, I think it was a false alarm (that the 3rd party CI was affecting the gate)
17:17:27 <jroll> ya
17:17:27 <anteaya> reviewers are free to disregard any third party ci results when they review
17:17:36 <jroll> ilo CI suddenly appearing makes me so happy \o/
17:17:42 <dtantsur> \o/
17:17:45 <devananda> indeed!
17:17:51 <rloo> anteaya: but jroll sez that 3rd party CIs shouldn't be announced on dev list?
17:17:56 <sambetts> Yup :D
17:17:57 <anteaya> correct
17:18:08 <dtantsur> anteaya, +1 to question, I've repeated it on the ML
17:18:14 <dtantsur> where should I get such announcements?
17:18:15 <anteaya> #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080808.html
17:18:36 <anteaya> #link https://wiki.openstack.org/wiki/ThirdPartySystems
17:18:46 <sambetts> the ironic QA subteam/meeting has an etherpad here for status updates so that we can discuss them in the Ironic QA meeting on Wednesday's at 5 UTC
17:18:51 <sambetts> https://etherpad.openstack.org/p/IronicCI
17:18:55 <anteaya> if you feel the need to have announcements you may announce in the ironic meeting
17:19:08 <anteaya> most projects get tired of that fairly quickly but suit yourselves
17:19:08 <dtantsur> anteaya, these links do not seem to answer our question..
17:19:10 <rloo> anteaya: but I think it is fine to announce them in [ironic]
17:19:24 <rloo> anteaya: as well as doing all that other stuff you have pointed out :)
17:19:35 <anteaya> rloo: in the channel fine, please not on the mailing list
17:19:51 * dtantsur disagrees
17:19:55 <devananda> I think it is reasonable for each driver team, if they want to announce it in the meeting, to do so on the whiteboard section for their driver. we'll all see that in the weekly meeting
17:20:08 <devananda> but it will avoid spamming the whole openstack list
17:20:18 <anteaya> devananda: +1
17:20:19 <jroll> I agree there's no need on the ML
17:20:33 <jroll> I'm going to go continue my vacation, have a good week y'all and thanks for running things devananda :)
17:20:37 <devananda> anyway, we can discuss that further at another time. let's move on with the meeting
17:20:45 <devananda> jroll: np! enjoy your vacation :)
17:20:57 <devananda> #topic stuck specs
17:21:09 <devananda> #link https://review.openstack.org/#/c/224022/
17:21:17 <devananda> rloo added this to the agenda
17:21:22 <devananda> I gave it a review just before the meeting
17:22:32 <rloo> devananda: i think yuiko wants an API that will tell them, for a particular node, what actions they can do next
17:23:03 <devananda> yuikotak_: around?
17:23:05 <rloo> devananda: cuz it looks like they want to present some sort of GUI
17:23:13 <yuikotak_> devananda, yes
17:23:14 <devananda> krotscheck: also, I think you had an interest in this work as it relates to building a UI
17:23:41 <devananda> rloo: that could be done muchmore efficiently by requesting the full set of states+verbs
17:24:25 <rloo> devananda: well, someone could write something to get the full set of states/verbs, and get the list of nodes-with-provision-states, then write the mapping between the two.
17:24:30 <devananda> fetching that data and dispaying the relevant item for each node in the client UI is much more efficient than fetching it for every node in a given display
17:24:36 <devananda> rloo: right
17:24:38 <rloo> devananda: or should we provide the mapping?
17:24:53 <rloo> devananda: i have no idea whether this is something that lots of folks want or not.
17:25:11 <rloo> devananda: my objection was to adding node.allowed_transitions :)
17:25:14 <devananda> the mapping may change in different versions of the server, so, yes, the server should expose the mapping
17:25:25 <devananda> rloo: I agree with your objection, fwiw
17:26:12 <rloo> devananda: ok, then we're good for that part. I guess yuikotak_ and others will have to convince devananda for some endpoint to show the allowed transitions for a particular node.
17:27:01 <rloo> devananda: or did you mean it would be OK to have an endpoint to show the info for a particular node, vs an endpoint to show the possible states/transitions in the FSM?
17:27:24 <devananda> rloo, yuikotak_: as I understand the problem statement, there are two situations where this info is needed
17:27:43 <devananda> * client requested a state change, got an error, and wants to know what is allowed next
17:28:12 <devananda> * client wants to display the potential actions for a lot of nodes without having to request an action first
17:28:52 <devananda> #1 is fixed by simply having better error messages. #2 would be fixed by adding a new general endpoint that returns the state machine as a dict
17:29:07 <devananda> does that work?
17:29:24 <yuikotak_> devananda, yes, exactly. thanks.
17:29:33 <devananda> great :)
17:30:00 <rloo> thx yuikotak_, glad that handles your problem!
17:30:03 <rloo> thx devananda too :)
17:30:27 <yuikotak_> rloo, thanks :)
17:31:00 <devananda> last week was somewhat light, so that's it for the agenda today.
17:31:08 <devananda> #topic open discussion
17:31:52 <devananda> anyone have stuff to discuss? :)
17:32:12 <vdrok> I've had a question about adding new service under ironic umbrella, and would like to hear your thoughts about it :)
17:32:23 <vdrok> We're considering adding new hardware compositor service under ironic umbrella
17:32:34 <devananda> vdrok: great - tell me about this service pls
17:32:39 <vdrok> There is this thing called intel racj scale architecture - http://www.intel.com/content/www/us/en/architecture-and-technology/rack-scale-architecture/intel-rack-scale-architecture-resources.html
17:32:46 <vdrok> Which supports creating servers on demand, based on redfish, e.g. you can post a request with some hw requirements and it will create this "node" if possible, and return the link to it
17:33:10 <vdrok> maybe there are similar things from other vendors
17:33:43 <vdrok> The current idea is that nova will use it to compose new nodes if there are no bm servers available and then register them in ironic
17:34:16 <vdrok> ironic may use it too, e.g. free the resources on node-deletion
17:34:51 <vdrok> so the idea is to have some generic api that will be able to work with intel rsa and other alike services
17:35:08 <devananda> vdrok: it sounds sort of like a new driver that, when a node is enrolled, actually does some interaction with the rack to "create" the hardware
17:35:11 <devananda> or s/create/compose/
17:35:15 <krtaylor> why wouldn't that be a redfish driver for ironic, what is extra
17:35:49 <devananda> vdrok: fwiw, there are several folks (myself included) interested in creating a generic redfish driver
17:36:03 <krtaylor> ++
17:36:23 <devananda> bcornec and I started hacking on a python redfish client about a year ago
17:36:26 <sambetts> I think this is more similar to something I'd like to see which is letting flavors decide the hardware not the other way around
17:36:29 <vdrok> yeah, but the idea is that nova can create it too, if e.g. no machines match the flavor
17:36:32 <devananda> perhaps its time to get more folks working on that
17:36:36 <dtantsur> by the way, enrolling hooks is something that people definitely want
17:36:48 <devananda> sambetts: right
17:37:00 <devananda> anyone from the oneview team here?
17:37:38 <sambetts> it doesn't look like it but we talks about that at the summit because that was something they are looking out for
17:37:58 <devananda> I think they were talking about something similar at one point, where the nova flavor is used to inform or customize the hardware
17:37:58 <NobodyCam> devananda: I would also toss out there the ablity to create a "active" node
17:38:06 <vdrok> this is all just an idea for now, what is a preferred way to gather feedback, as in meeting seems to be too short on time?
17:38:24 <vdrok> should it be a spec that describes everything in detail>
17:38:28 <devananda> vdrok: yea, meeting is a good way to bring it up and raise the topic, but we should follow it up in long-form on the ML
17:38:37 <vdrok> or blueprint, or ml post?
17:38:47 <sambetts> I was actually thinking that the claims API might be a good place to put the logic for something like this, because we'd be injesting the whole flavor
17:39:03 <devananda> vdrok: if you have a design in mind, a spec is a good idea. but if you're still gathering ideas (wnat to see what other vendors need) then the ML is a good next step
17:39:13 <krtaylor> vdrok, I am wondering why nova would be handling BM directly at all when that is what ironic is for
17:40:00 * krtaylor is curious, learning
17:40:10 <vdrok> krtaylor, well, this is not a "hardware" when nova does the request to it
17:40:14 <devananda> krtaylor: nova holds the concept of a flavor. the ironic virt driver could determine that a request came in but doesn't match any existing hardware, and then go "compose" that hardware and enroll it in Ironic
17:40:28 <devananda> krtaylor: at least that is what I htink folks are suggesting
17:40:35 <vdrok> devananda, yep :)
17:40:40 <sambetts> :)
17:40:55 <krtaylor> ah, ok, interesting, thanks for the clarification
17:41:05 <dtantsur> devananda, that would make nova aware of our drivers, right?
17:41:22 <devananda> dtantsur: good point ....
17:41:28 <sambetts> not if it was through the claims API ;)
17:41:28 <rloo> although the nova-ironic driver would have to get that new composed node into 'available' state to be able to use it right away.
17:41:40 <devananda> dtantsur: if it were a new interface or service, then no?
17:41:59 <dtantsur> devananda, or just internal part of claims API?
17:42:10 <devananda> rloo: right. and it may take some time for the hardware to become available, so such a request may be much slower ...
17:42:13 <dtantsur> I see value in not sharing too many details with nova
17:42:18 <devananda> dtantsur: ++
17:42:40 <devananda> dtantsur: I'm trying to imagine how this fits in the claim API and struggling, perhaps because that API isn't well defined yet
17:43:09 <devananda> the claims API that I proposed at least, is essentially just a search API with an extra field saying "reserve N of these if you find them"
17:43:21 <devananda> but it could express non-equality as well
17:43:31 <devananda> so it isn't a good fit for "make me a server with X, Y, Z"
17:43:34 <dtantsur> good point about non-equality, yeah
17:44:08 <devananda> it seems like a closer fit to the enroll->manageable transition
17:44:29 <devananda> could reach out and "create" the hardware according to the specifications, as long as the mgmt info is good
17:44:35 <dtantsur> mmmmm, right
17:44:49 <dtantsur> yeah, so we can enroll virtual (wannabe) nodes
17:44:55 <sambetts> but then thats not being driven by the nova/flavor right?
17:44:55 <dtantsur> and them materialize them
17:44:58 <devananda> vdrok: so, I do think there are other vendors interested in this
17:45:05 <devananda> sambetts: not right now, but it could be
17:45:18 <devananda> SoftLayer folks demo'd something similar in Tokyo
17:45:52 <devananda> where a nova-scheduler plugin they wrote enrolled nodes in Ironic in order to satisfy requests
17:46:25 <devananda> it had nothing to do with composable hardware, but the effect (add a new server to ironic between "nova boot" and the virt driver taking over) was similar
17:46:36 <NobodyCam> I could see a case for this in both claim and enroll api,
17:46:50 <sambetts> did it call out to a separate system to check for avalible resources?
17:46:56 <devananda> sambetts: yah
17:47:30 <sambetts> hmmm, thats cool /me adds postit note to go dig up that presentation
17:47:51 <vdrok> so ok, will put something up in ml discussion till tomorrow, thanks :)
17:48:31 <devananda> vdrok: thanks! good discussion
17:48:40 <sambetts> vdrok: thanks for bring it up
17:49:52 <devananda> any other topics folks want to discuss?
17:49:57 <derekh> before the end I'd like to draw people attention the a mail I sent earlier today http://lists.openstack.org/pipermail/openstack-dev/2015-November/080796.html
17:50:05 <derekh> essentially I'd like to turn tripleo ci back on for ironic, it would be great if ye could take a look at the mail and weigh in etc...
17:50:20 <NobodyCam> as this is my first meeting back I wanted to thank every one for the well wishes when I was out.. Thank you all :)
17:50:47 <rloo> derekh: i was just replying. i don't understand - would the tripleo be voting or non voting?
17:50:54 <devananda> NobodyCam: welcome back :)
17:51:03 <NobodyCam> :)
17:51:11 <rloo> welcome back NobodyCam!
17:52:21 <derekh> rloo: it would be the exact same way as it used to be but I would aks you now to ignore the results when pressing approve
17:52:27 <devananda> derekh: are changes in ironic causing frequent breakages in tripleo's gate?
17:52:30 <derekh> *aks
17:52:33 <derekh> *ask
17:52:45 <rloo> derekh: you mean 'not ignore' :)
17:52:56 <derekh> rloo: yup
17:53:37 <derekh> devananda: not frequently, now that we are not currently running trunk its hard to know for sure
17:53:54 <rloo> derekh: why not make it vote then? or do we want to try it as you suggest and see what happens?
17:53:55 <devananda> derekh: running those jobs on ironic's gate cascadingly affects other projects' gate (nova, etc) as well
17:54:29 <derekh> devananda: you wouldn't be running it in the gate, it would be a check job run when the patch is proposed
17:54:36 <devananda> derekh: so any instability in any tripleo projects' gates will have a compounding effect on the merge queue, especially during release crunches
17:54:42 <devananda> derekh: oh
17:55:17 <devananda> derekh: hm, ok. wdyt about adding it as a third-party system to ironic? that may be a terrible idea, just throwing it out there :)
17:55:27 <derekh> devananda: this is the same thing ironic used to have
17:55:45 <devananda> derekh: at one point, dib was voting in our gate IIRC
17:55:52 <rloo> devananda: what does it matter if it is a 'third-party system' or not?
17:55:54 <devananda> so that's what I thought you were suggesting at first
17:56:10 <devananda> rloo: the way in which it gets reported. it affects jenkins
17:56:14 <derekh> devananda: I don't think it can be a 3rd party system as its being run by infra, but its only a cosmetic thing
17:57:01 <derekh> devananda: you may have had some DIB job in your gate but it wasn't the tripleo job, tripleo jobs were never in the gate
17:57:18 <devananda> derekh: right
17:57:52 <devananda> when I was active in tripleo, we had discussed with infra running those as third-party jobs. a lot has changed since then ...
17:58:21 <devananda> in any case, a voting check job that fails will effectively prevent a patch from merging
17:59:18 <NobodyCam> *time*
17:59:20 <devananda> rloo: whereas a third-party vote will not prevent a patch from merging
17:59:21 <derekh> devananda: it doesn't and core can approve and ignore the result, all I would be asking is that you don't ignore the result unless you have a good reason not to
18:00:05 <devananda> derekh: non-voting job seems fine to me, but I still think it would get more visibility as a third-party job
18:00:09 <devananda> anyhow, time..
18:00:13 <betherly> Thanks :)
18:00:15 <devananda> thanks everyone!
18:00:20 <devananda> #endmeeting