17:01:19 #startmeeting ironic 17:01:21 Meeting started Mon Jun 29 17:01:19 2015 UTC and is due to finish in 60 minutes. The chair is devananda. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:22 o/ 17:01:22 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:24 The meeting name has been set to 'ironic' 17:01:34 \o/ 17:01:34 o/ 17:01:36 o/ 17:01:38 good morning/afternoon/evening/night, everyone 17:01:43 o/ 17:01:43 hi 17:01:43 as usual, our agenda is here: 17:01:45 #link https://wiki.openstack.org/wiki/Meetings/Ironic 17:01:54 o/ 17:02:26 #chair nobodycam 17:02:27 Current chairs: devananda nobodycam 17:02:33 #chair NobodyCam 17:02:34 Current chairs: NobodyCam devananda nobodycam 17:02:43 #topic announcements 17:02:46 :) 17:02:59 first things first -- the location for the midcycle is confirmed 17:03:16 \o/ 17:03:28 many thanks to BadCub and devananda for getting that confirmed 17:03:37 Along with 6,000 statisticians at the convention center ;) 17:03:40 sorry that it took so long -- I had been emailing folks in the Seattle office to try to arrange it, but basically had to go into the office in person to finish things 17:04:01 which wasn't possible while travelling the last few weeks 17:04:06 so anyway, it's done now. 17:04:14 #link https://www.eventbrite.com/e/openstack-ironic-sprint-august-2015-tickets-17533862254 17:04:31 please RSVP there so that I can keep track of who and how many are coming 17:04:37 ugh.. sorry for dropping in late 17:05:08 devananda: do you have agenda for the sprint? 17:05:34 Sukhdev: nope. let me start an etherpad 17:05:51 #link https://etherpad.openstack.org/p/ironic-liberty-midcycle 17:06:03 ^^^ from white board 17:06:05 devananda: I am wondering if Ironic-neutron folks should attend as well - 17:06:06 oh 17:06:12 NobodyCam: great, ty 17:06:24 Sukhdev: it would be great to have one or two, yea 17:06:45 devananda: cool - will discuss with the management and let you know 17:07:15 #info midcycle sprint is the week before LinuxCon NA, in the same city -- just FYI for those who may be attending both events 17:07:52 any other announcements? 17:08:21 that covers mine 17:08:27 #topic subteam status reports 17:08:49 #link https://etherpad.openstack.org/p/IronicWhiteBoard 17:09:18 jroll: how 'close' are we, wrt the neutron/ironic specs 17:09:26 oh yah - dtantsur recently revamped his bug dashboard page 17:09:32 :) 17:09:35 ya looks very good ! 17:09:53 rloo: we mostly have agreement from the subteam working on it 17:10:29 jroll: any progress on the nova/ironic stuff we talked with jaypipes last week about? need me to dive into that again this week at all? 17:10:39 jroll: awesome wrok.. thanks to every one on the team! 17:10:43 jroll: nice. and i thought there was talk about possibly needing a nova spec? no need? 17:11:01 rloo: nova folks tell me we shouldn't need one 17:11:18 devananda: I've been out since tuesday, will be picking it up today/tomorrow 17:11:29 devananda: needs a quick update, nothing major 17:11:33 jroll: good news wrt nova 17:11:36 jroll: ok, cool. 17:11:48 rloo: for now, until someone decides they want one :) 17:12:02 jroll: didn't you get sign off on that? :D 17:12:22 rloo: :P 17:13:20 jlvillal: are there any urgent testing things that ought to be done before you get back in AUg? 17:13:20 jroll: I dont see the multihost nova-compute spec on hte whiteboard, adding it under the nova section 17:13:33 devananda: sounds good 17:13:36 oh ya 17:13:42 jlvillal: is gone for a month 17:14:24 when is the nova deadline for specs? 17:14:35 rloo: last week I think 17:14:58 NobodyCam: oh. so that multihost nova-compute spec won't make it in liberty? 17:14:59 rloo, I'm not sure about urgent testing things. 17:15:07 rloo: spec submission deadline was last week 17:15:21 rloo: not sure when freeze is, and if this falls in priority or non-priority 17:15:30 jroll: oh, submission deadline. phew. 17:16:12 rloo: jay pipes and dan smith agreed to hack on this at the nova midcycle, I think we can do it this cycle 17:16:14 I dont know where it falls in nova's priority queue either, but it has two nova cores backing it already 17:16:26 rloo, I don't think there is anything urgent, in regards to testing. At the moment my management fully supports me working on functional testing. So I believe I will be able to resume work when I return. 17:16:45 nice, any ironic folks attending the nova mid-cycle? 17:16:49 as long as we keep moving forward on it with them, I think there's a good chance to get it done 17:16:56 jlvillal: thx 17:16:56 lucasagomes: I am, idk about anyone else 17:17:00 and the upside is, there's very little work needed in Ironic 17:17:10 jlvillal: have you handed any open items off tosomeone else and if so who? 17:17:24 just so we know to to ping 17:17:31 jroll, ack, yeah should be enough would be good to have at least 1 core 17:17:44 lucasagomes: yeah, though hoping someone else shows up :) 17:17:52 lucasagomes: though it's the same week as OSCON 17:17:53 lucasagomes: nova midcycle is the same week as OSCON, which I already planned to attend. 17:18:13 NobodyCam, I don't know of any open items regarding functional testing except for the main open item, which is add more functional tests. 17:18:16 so unfortunately I will not make hte nova midcucle 17:18:19 devananda, jroll I see... yeah that complicate things indeed 17:18:23 jlvillal, when you return, I'd like to start talking about CI testing also 17:18:33 krtaylor, Great! 17:18:52 jlvillal: main item on my mind re: functional testing -- move it into our tree and out of tempest 17:19:49 devananda, I agree. 17:19:55 I'm going to timebox the subteam discussion to another 2 minutes 17:20:03 also, we haven't talked about drivers at all 17:20:15 which is part of this section of hte meeting 17:20:27 looks like the iRCM driver is ready for reviews 17:20:30 there's nothing in the drivers section except "I need reviews" afaict 17:20:34 *iRMC 17:20:36 yea 17:20:43 and we've know that for quite some time :) 17:20:51 how's the refactoring of boot / deploy coming? 17:20:52 yeah iRMC seems ready indeed, gotta review it again this week 17:21:11 devananda, ive tested the boot deploy split, it works found some minor problems 17:21:17 devananda: I posted the first patch set. after that I am yet to refactor other stuffs. 17:21:19 reported in the patch itself 17:21:31 devananda: I am yet to work on issues reported by lucasagomes 17:21:35 *issue 17:21:43 cool - so they're progressing well 17:21:48 everything is not caught in gate :( 17:22:08 rameshg87: how many patch sets deep is it now // do you think it's going to take? 17:22:32 after this may be 3-4 17:22:45 agent and rest of virtual media drivers 17:22:50 #link https://review.openstack.org/#/c/166513/ 17:22:54 after this, it should be getting easier rather 17:23:14 at least I hope so .. 17:23:17 rameshg87: ah, that's not too bad. please make sure they all have the same gerrit topic, and could you add a link to the whiteboard in the "drivers" section 17:23:32 devananda: sure. 17:23:37 I'd like us to track something that big which affects all the drivers in the weekly meetings 17:23:40 thanks much 17:24:05 moving on, because time 17:24:13 #topic node names 17:25:04 this seems kinda minor, but it could have a noticeable impact 17:25:08 quick background. the node names were meant to allow for host names only, and then got changed to host-names.domain. 17:25:24 but the code doesn't really detect hostnames properly so chris submitted a patch. 17:25:33 but there was already a bug/ask to relax the names. 17:25:40 #link https://review.openstack.org/#/c/193587 17:25:42 so... we should just decide what-to-do 17:25:57 probably it was a wrong idea to go with name=host name 17:26:04 if we fix existing hostname, it means a microversion bump 17:26:16 e.g. I would be surprised to not be able to use underscore in any "name" 17:26:33 rloo, every API change means microversion bump, but this is also a breaking change 17:26:43 +1, I was surprised 17:26:45 I think I would prefer names to be relaxed, I find hostnames a bit misleading since that name is not used to determine the instance hostname 17:26:45 dtantsur: I agree. I see a use case for only numbers too 17:26:57 dtantsur: yeah, so when i first saw the patch, i thought why fix it, let's just relax the name. 17:27:10 dtantsur: i mean, if we have to do a microversion bump anyway, etc 17:27:12 Somewhat as a tangent. But it seems like the host name valid code might be better in something like oslo.utils. 17:27:23 the original requirement for this functionality was that we allow a way to reference Nodes by a human-readable name 17:27:57 we've gone fairly far afield from that along the way. I'm not sure where the FQDN requirement came in that introduced "." separators, eg, https://bugs.launchpad.net/ironic/+bug/1433832 17:27:57 Launchpad bug 1433832 in Ironic "Fix is_hostname_safe for RFC compliance" [Medium,Fix released] - Assigned to Michael Davies (mrda) 17:28:26 jlvillal: I agree w.r.t. moving the RFC-complicancy-checking bits to oslo.utils, fwiw 17:28:35 * dtantsur does not remember either, Kilo cycle was messy.. 17:29:08 ahh, i think that was jroll (but i could be wrong). I mean, jroll added a patch and mrda fixed it to be 'right'... 17:29:08 I agree with relaxing too. 17:29:18 rloo: my isue with completely relaxing the name is that it is a resource identifier, so it must match RFC3986 17:29:21 #link https://tools.ietf.org/html/rfc3986#page-11 17:29:44 rloo: I don't believe I did? 17:29:46 devananda, yeah it's exposed in the URL so should be compatible with that 17:29:47 devananda: so if we relax it to conform to RFC3986? 17:30:01 rloo: that's fine with me 17:30:03 lucasagomes, devananda, sorry, I'm not sure I understand you. everything may be encoded in a URL... 17:30:12 using %.. notation obviously 17:30:15 dtantsur: yup 17:30:15 dtantsur, yes compatible == url encoded 17:30:35 s/that's fine with me// 17:30:54 dtantsur: how about typing it on the command line? 17:31:04 everything can be quoted and escaped in bash, too 17:31:35 I'm not advocation allowing weird thing btw. I'm not even suggestion allowing Russian :) 17:31:40 * suggesting 17:31:58 but support for underscores is not something I feel comfortable using 17:32:06 what if we just allowed anything ascii? 17:32:43 note that I pretty much imagine people wanting local languages, but that might go too far 17:33:03 jroll, ASCII == chr(0)..chr(127)? 17:33:14 dtantsur: yeah, something like that 17:33:18 yeah we can come up with something reasonble I believe, like alphanumerics + special symbols in 17:33:34 ++ 17:33:35 list being = ( '-', '_', '.') 17:33:52 lucasagomes: let's not invent our own standard (again) 17:34:01 per rfc" unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" 17:34:28 thus my suggestion we stick to the RFC :) 17:34:39 ++ 17:34:44 which is fair enuff 17:35:00 * dtantsur is lost, which part of RPC? host names? domains? 17:35:17 rfc3986 17:35:40 I think rfc3986, the 'characters' part? 17:35:41 which is basically anything... url encoded 17:35:42 dtantsur: https://tools.ietf.org/html/rfc3986#page-11 is what was linked earlier 17:36:18 ah, sorry, I finally understood this unreserved thing :) +1 17:36:39 so it'll need a spec, right? (for whoever does it. don't know if chris has given up on us or not) 17:36:46 let's continue discussing this on the bug report here 17:36:49 #link https://bugs.launchpad.net/ironic/+bug/1434376 17:36:49 Launchpad bug 1434376 in Ironic "Node name rule relaxation" [Wishlist,In progress] - Assigned to Chris St. Pierre (stpierre) 17:37:13 I hope this doesn't need a spec -- it's either a bug fix, or we shouldn't be doing it at all 17:37:29 devananda: well, the spec mentions hostname I believe. 17:37:38 devananda: or hostname.domain. can't recall now. 17:37:49 devananda: and we can't change the original spec. 17:38:02 rloo: sure. but that spec != live documentation of the state of hte project today 17:38:23 devananda: fine with me. i like bugs better. 17:38:28 i think bug should cover us here 17:38:35 that spec was implemented last cycle, and that code released. we need to understand that folks will be using that code for several years to come 17:39:06 so what ever non-standards-compliant type checking we released in Kilo is exactly what some operators will be stuck with for a while 17:39:33 anyway, before I rant on that, let's move on to the next topic 17:39:43 ++ 17:39:44 * rloo was hoping for a rant 17:39:47 heh 17:39:51 actually, going to skip one and come back to it 17:39:55 #topic release model spec 17:40:04 ohai 17:40:09 #link https://review.openstack.org/#/c/185171/ 17:40:11 jroll: hi there! 17:40:16 so I've had lots of feedback on this spec 17:40:24 all good stuff, and I think I've incorporated it all 17:40:34 so I'd like to get eyes on this, land it, and get back to releasing software 17:40:45 jroll, was looking at it right now, I remember we talked about re global requirements 17:41:02 to have somehting like a "-2 LGTM" in the projects/requirements 17:41:02 lucasagomes: yeah, there's a thing in there 17:41:17 I see that dhellmann and ttx both gave you feedback -- that's fantastic -- and you've just posted a new rev, which I haven't read yet 17:41:47 jroll, yeah not sure if u want to mention that in the spec tho, plus we would need somehow to not break gate-ironic-requirements job 17:41:48 in gate 17:41:54 jroll: any specific changes worth calling out? 17:42:10 since right now any update to the requirements.txt in the ironic tree that is not in gr will cause gate to fail 17:42:35 devananda: nothing major, just some clarifications and corrections from ttx's comments 17:42:43 lucasagomes: oh, hrm :/ 17:42:51 lucasagomes: I don't think that's true unless that's new 17:43:23 I think it's there for a while 17:43:24 e.g https://review.openstack.org/#/c/196010/ 17:43:34 gate-ironic-requirements http://logs.openstack.org/10/196010/1/check/gate-ironic-requirements/68a3886/ : Incompatible requirement found; see https://wiki.openstack.org/wiki/Requirements in 16s 17:43:49 lucasagomes: urgh 17:43:58 I mean it can be worked out, I just pointing out in case u want to put in the spec 17:44:18 yeah, idk 17:44:24 if you want it in the spec, add it 17:44:28 er, review it 17:44:38 yeah I will add a comment about it 17:44:39 I don't know it needs to be there, this is more about process IMO 17:44:46 yeah sure 17:45:12 *15 minutes left 17:45:47 jroll: changes LGTM, though I may want to discuss (separately) about the spec tree structure changes 17:46:02 devananda: sure 17:46:08 jroll: but that detail isn't a critical part of the spec 17:46:23 added 17:46:28 devananda: agree 17:47:28 cool. well, let's get a few more eyes on it this week and try to land it by next monday if we can 17:47:46 ++ 17:47:59 and then make the changes to semver version numbres -- I'd love to be able to tag our first release in this model before OSCON 17:48:23 #topic liberty priorities 17:48:32 #topic how about we just call them priorities 17:48:35 :) 17:48:39 tl;dr that spreadsheet is not updated 17:48:59 I started put some stuff there, other people helped too, but yeah need more work 17:49:10 devananda: priorities is fine with me :) 17:49:29 lucasagomes: yea, i put a few things up, but agree -- it needs more work. since the rush at the end of kilo, we all sort of stopped tracking priorities well 17:49:30 rloo, devananda: +1 17:49:38 devananda: basically, wanted to get an idea of our priorities, since i know that we're itchin' for a release soon :) 17:49:48 which has been the normal fall-out from the end of cycle crunch period 17:49:55 yeah 17:50:14 * devananda renames the tab to Current Priorities 17:50:46 #link https://docs.google.com/spreadsheets/d/1Hxyfy60hN_Fit0b-plsPzK6yW3ePQC5IfwuzJwltlbo 17:51:42 fwiw, I don't like using a google spreadsheet -- but it's better than launchpad for quickly seeing what's going on 17:52:21 lucasagomes: so actually -- what "big effort items" are missing from this? 17:52:40 release model ? 17:52:51 tho it doesn't involve code, we need review 17:52:53 eh, that's not code 17:53:16 would name relaxtion be a BIG effort item 17:53:26 NobodyCam: oh gawh i hope not 17:53:31 :) 17:53:41 yeah I gotta go through the specs that have been merged and is in the queue and put it there 17:54:22 what about adding more functional tests? 17:54:31 krtaylor: totally important 17:54:37 +1 17:55:09 * 5 minute warnning bell * 17:55:24 is the ironic-lib refactoring important? 17:55:34 but we've used this spreadsheet in the past to track feature implementation status for big ticket / high priority items, during the crunch leading up to a release 17:55:54 rloo: imo yes, enables partition images in agent drivers 17:55:55 perhaps we should, with the release model changing, rethink how we track that ongoing work slightly 17:56:02 Should drivers go in the spreadsheet too? We have the OneView one we want done for Liberty. 17:56:03 rloo: big missing feature me thinks 17:56:14 I also see it as a way not to forget things we agreed on on the summit :) 17:56:26 #action devananda to think about the ways we have/should track and communicate major project priorities 17:56:26 gabriel-bezerra, yes 17:56:32 #topen discussion 17:56:40 #topic open discussion 17:56:44 :) 17:57:05 I can't edit the spreadsheet. How does it work? 17:57:19 maybe we can talk about that patch from JoshNang that allows exposing "fail" provision state in the api 17:57:27 gabriel-bezerra: difference there is, one team is working on adding a new driver. it's great, but not affecting other teams. 17:57:33 gabriel-bezerra: iirc cores can only update the spreadsheet 17:57:35 I gave it a go today, but, it requires some stuff such as breaking the lock 17:57:44 * lucasagomes grabs the link 17:57:56 #link https://review.openstack.org/#/c/196229/ 17:58:11 yeah i think there are quite a few caveats in that patch 17:58:35 yeah, I put some comments there... but I like the idea 17:58:46 we def need something like that 17:58:55 JoshNang: i also had an idea -- s/fail/abort/ because that's a better verb to express the intent 17:59:03 ++ for abort 17:59:07 yeah 17:59:18 one thing tho DEPLOYWAIT already supported "deleted" 17:59:24 which is kinda like an abort for DEPLOYWAIT 17:59:31 so we may have some duplication there 17:59:32 devananda: I see. 17:59:43 * last minute * 17:59:43 jroll: OK. 17:59:44 anyway we got 1 min and we won't be able to solve it in that time 17:59:47 lucasagomes: yep, which is either inconsistent, or a breaking API change 17:59:50 rloo: thanks for adding it. 18:00:04 devananda, yeah 18:00:05 we should anyway start with a spec, I guess.. 18:00:19 Great meeting Thanks to Everyone! 18:00:20 good meeting, thanks everyone 18:00:26 cheers, thanks all! 18:00:39 #endmeeting