17:00:03 <jroll> #startmeeting ironic
17:00:04 <joanna> :D
17:00:04 <openstack> Meeting started Mon Feb  6 17:00:03 2017 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:05 <dtantsur> o/
17:00:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:06 <NobodyCam> o/
17:00:07 <soliosg> o/
17:00:07 <mat128> o/
17:00:07 <openstack> The meeting name has been set to 'ironic'
17:00:08 <mariojv> o/
17:00:09 <xavierr> o/
17:00:11 <joanna> o/
17:00:13 <jroll> hey everyone
17:00:15 <aslezil> o/
17:00:15 <yuriyz|2> o/
17:00:15 <vdrok> o/
17:00:28 <galyna2> o/
17:00:30 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:00:34 <jroll> the agenda, as usual
17:00:39 <rloo> o/
17:00:41 <mgoddard_> o/
17:00:46 <rpioso> o/
17:00:48 <lucasagomes> o/
17:00:51 <jroll> #topic announcements and reminders
17:01:00 <jroll> big week this week
17:01:21 <jroll> #info ptl voting has 35 hours left. go vote!
17:01:29 <JayF> o/
17:01:30 <jroll> (side note, this is my last meeting as ptl!)
17:01:43 <crushil> \o
17:01:44 <csmart> \o morning all
17:02:03 <jroll> also, we plan to release stable/ocata for ironic, ironic-python-agent, and ironic-inspector this week
17:02:06 <TheJulia> o/
17:02:13 <jroll> as well as bifrost, ironic-ui.... I think that's it
17:02:15 <joanna> jroll: did you bring cake?
17:02:28 <lucasagomes> joanna, ++ for cake
17:02:30 <rloo> thx jroll, for all your meetings as PTL! bring on the bubbly.
17:02:39 <jroll> we're shooting for thursday on those releases, but can be flexible
17:02:46 <jroll> let's be sure to focus and finish things out strong
17:02:53 <jroll> joanna: that's ptl-next's job
17:02:54 <jroll> :)
17:02:57 <jroll> rloo: :)
17:03:06 <TheJulia> joanna: And to give jroll a beer :)
17:03:15 <jroll> ++
17:03:17 <jroll> anyone else have announcements or reminders?
17:03:19 <joanna> :)
17:03:20 * JayF notes that he's running on an anti-gluten platform
17:03:27 <JayF> no beer or cake ;)
17:03:37 <TheJulia> lol
17:03:40 <mat128> JayF: we can get some no-gluten cake for you
17:03:42 <xavierr> lol
17:03:43 <clarkb> JayF: they make gf beer that isn't too bad :P
17:03:56 <krtaylor> o/
17:04:19 <jroll> alright, subteam stuff
17:04:23 <jroll> #topic subteam status reports
17:04:37 <jroll> also the last one of these for the cycle
17:04:46 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:04:49 <jroll> starts at line 66
17:05:17 <rloo> there's a hi nova bug. anyone know if it needs to be looked at asap?
17:05:48 * jroll looks
17:05:54 <jroll> if it's the one I'm thinking of, it's mostly mitigated
17:06:01 * lucasagomes looks too
17:06:08 <jroll> yeah
17:06:11 <jroll> #link https://bugs.launchpad.net/nova/+bug/1661258
17:06:11 <openstack> Launchpad bug 1661258 in OpenStack Compute (nova) "Deleted ironic node has an inventory in nova_api database" [High,In progress] - Assigned to Chris Dent (cdent)
17:06:26 <rloo> i know that we don't view docs as important but... portgroups folks, i hope you have docs written soon!
17:06:39 <JayF> Docs are important :)
17:06:39 <jroll> there's a band-aid on it by now, the real fix is going to take some work (as in, let's do it soon"ish" and backport, but not a huge rush)
17:06:41 <vdrok> rloo: writing right now :)
17:07:04 <rloo> jroll: it is being addressed, good.
17:07:10 <rloo> vdrok: thx!
17:07:22 <jroll> rloo: yeah, on my radar, have somewhat of a plan for 'real' fix by now
17:07:27 <jroll> er, already
17:08:00 <rloo> nice that we have non-voting UEFI job! thx to all!
17:08:15 <JayF> Where is the image coming from for that job, if anyone knows?
17:08:28 <jroll> JayF: daily builds, iirc
17:08:31 <lucasagomes> JayF, yeah, it's a cirros image from daily builds
17:08:35 <JayF> nice
17:08:37 <jroll> it's pinned though
17:09:35 <jroll> so, looking at these things, I think we can leave priorities as is
17:09:41 <jroll> and hopefully add some bugs there
17:10:23 <rloo> jroll: so looks like soft power off/NMI support is done!
17:10:34 <jroll> rloo: tis :)
17:11:17 <rloo> jroll: wrt driver comp, are there any that *have* to merge in ocata?
17:11:28 <milan> o/
17:11:52 <jroll> rloo: other than saving backport work, I don't think so. if I was going to pick one it'd be devstack/CI
17:11:54 <rloo> jroll: given how big a change it is, if we don't get docs in in time, we should backport
17:11:59 <jroll> agree
17:12:10 <dtantsur> yeah
17:12:30 <rloo> jroll: the node.resource_class doc has been deferred, right? i'm going to delete from our priorities
17:12:51 <jroll> rloo: yeah
17:13:26 <rloo> jroll: gone. should we just review the doc patches that are in the priorities?
17:13:52 <jroll> rloo: as in "only those doc patches"?
17:13:53 <rloo> i'm not sure we'll get to the nice-to-have's
17:14:09 <jroll> sure, let's do what we can
17:14:16 <rloo> jroll: yes, as only those doc patches.
17:14:35 <rloo> jroll: we should put bugs in there too. vdrok listed some under the Bugs section.
17:15:22 <rloo> vdrok: at this point, maybe we should only focus on high bugs?
17:15:27 <vdrok> these are the ones that are open and were reported since last april or so, was not able to go further
17:15:27 <jroll> rloo: yes, added a pointer
17:15:34 <rloo> high bugs with a chance of merging soon :)
17:15:56 <vdrok> yeah, no objections :) as we have only like 3 days
17:16:13 <rloo> vdrok: exactly. maybe we can look at bug patches at ptg if we have nothing else to do :)
17:16:17 <vdrok> everything else can be backported later if needed
17:16:25 <dtantsur> "if we have nothing else to do" LOL
17:16:34 <TheJulia> dtantsur: +1
17:16:39 * dtantsur counts the number of proposed topics
17:16:40 <rloo> I mean, i know beer is a high priority...
17:16:51 <TheJulia> but not everyone drinks beer....
17:17:00 <dtantsur> 22 topics for 2.5 days, hmm :)
17:17:06 <lucasagomes> (-:
17:17:08 <rloo> oh. side track from this subteam thing -- should we review ptg proposals next meeting?
17:17:21 <jroll> maybe?
17:17:23 <TheJulia> I think we should
17:17:24 <dtantsur> maybe even start today, if we have time left
17:17:29 <rloo> I guess that is up to new ptl...
17:17:31 <jroll> I think we should just prioritize and cut
17:17:39 <jroll> so maybe leave comments on that sort of thing
17:17:49 <jroll> (since we don't have a fixed number of sessions)
17:18:26 <TheJulia> maybe just prioritize, and generate a short high priority list, and go to the lower priority stuff if we have time?
17:18:33 <rloo> fwiw, i'm good with subteam reports, since i seem to have caused us to side track :)
17:18:34 <jroll> yeah that was my thought
17:18:38 <jroll> heh
17:18:55 <jroll> yeah we should move on, have a couple of topics this week, can come back in open discussion
17:19:08 <jroll> #topic Making [DEFAULT]cleaning_network obligatory for flat network interface
17:19:15 <jroll> #link https://bugs.launchpad.net/ironic/+bug/1661082
17:19:15 <openstack> Launchpad bug 1661082 in Ironic "Raise DriverLoadError if using flat network with cleaning enabled and cleaning_network is not set" [Low,Triaged] - Assigned to Vladyslav Drok (vdrok)
17:19:16 <jroll> vdrok: this is you
17:19:50 <jlvillal> o/
17:19:52 <vdrok> yup, so, in the last release, I added a todo to make cleaning_network parameter to be required for flat network interface
17:19:56 <dtantsur> just don't do it in Ocata please :)
17:20:22 <dtantsur> well, I've *just* switched tripleo to using a dummy network name by default, in case we land that..
17:20:25 <rloo> my question is why do we want to make it mandatory?
17:20:46 <rloo> if eg someone uses flat network but doesn't do any cleaning
17:20:51 <vdrok> we have a way to disable automated clean, but not manual, so to guarantee it works, it may be better to fail loading flat network interface, or fail on some pre-validation
17:21:08 <TheJulia> or they don't need a separate network in their flat network configuration...
17:21:11 <rloo> vdrok: can we fail on start of manual cleaning?
17:21:11 <JayF> Does manual cleaning fail if unset
17:21:16 <dtantsur> well, it also assumes everyone is cool with creating network in the middle of openstack deployment, which I'm not
17:21:20 <JayF> or do you just clean on the provisioning network?
17:21:40 <dtantsur> hence I wrote "dummy" network, I have to invent a non-existing name just to make ironic happy on start up...
17:21:52 <jroll> TheJulia: that config isn't necessarily about a separate network, just so ironic knows what network things should be on (since nova won't pass us a cleaning port)
17:22:08 <rloo> dtantsur: how do you feel about that? i mean, having to write dummy network etc? do you think operators will be happy about doing that too?
17:22:10 <vsaienk0> jroll: I wondered why flat network interface  requires cleaning_network to be set?
17:22:10 <vdrok> rloo: yeah, we can fail on start of cleaning
17:22:22 <jroll> vsaienk0: so ironic knows what network things should be on (since nova won't pass us a cleaning port)
17:22:43 <lucasagomes> JayF, I would prefer it to fail if not set, to fallback to provisioning seems dodgy (unless cleaning_network also points to the same network as provisioning, so that should be ok)
17:23:02 <dtantsur> rloo, I'm definitely not overly happy.. I had to write quite detailed documentation on this bit in TripleO
17:23:26 <rloo> dtantsur: so would it be better to leave the warning that we have now, and for cleaning to fail when (if) cleaning is invoked?
17:23:28 <dtantsur> well, I'm not happy with putting openstack object UUIDs in configuration files at all
17:23:39 <dtantsur> but it seems to be my personal thing :)
17:23:46 <TheJulia> jroll: I know, but I'm not really sure it should be required in the configuration
17:23:52 <lucasagomes> rloo, I like that
17:23:57 <TheJulia> dtantsur: I think this goes back to make it configurable at the node level
17:24:03 <lucasagomes> warning + fail upon a request (if not set)
17:24:04 <jroll> TheJulia: just pointing that out for clarity, not agreeing or disagreeing with you
17:24:06 <dtantsur> TheJulia, this is my view on it
17:24:06 <mat128> dtantsur: I understand where you're coming from, mixing config and data
17:24:15 <mat128> lucasagomes: +1
17:24:18 <dtantsur> mat128, exactly, at least this is how I see it
17:24:39 <rloo> vdrok: you ok with that? we'll just delete the TODO then?
17:24:41 <JayF> if automatd clean enabled; fail at startup if cleaning network unset, if automated clean disabled; fail manual cleaning when attempted
17:24:48 <JayF> is that's what's being proposed?
17:24:54 <vdrok> ok then, a warning in init, and fail to start cleaning if requested
17:25:07 <mat128> JayF: I would just fail whenever the cleaning network is required, to keep it simple
17:25:10 <dtantsur> JayF, this is the previous plan, that not everyone likes
17:25:19 <rloo> vdrok: do you know if it will fail cleaning as described here?
17:25:32 <rloo> vdrok: or do we need to add code to do so? (i guess we should check)
17:25:40 <JayF> I am not sure I'm fond of allowing the conductor to fail late if automatic cleaning is enabled
17:26:01 <vdrok> OK yeah, what JayF proposes is better
17:26:02 <lucasagomes> JayF, for automatic I think we should fail at startup too
17:26:06 <JayF> because you could be in for a nasty surprise as a deployer when your entire capacity is in clean failed after deletes
17:26:10 <lucasagomes> because we know it's going to fail
17:26:12 <rloo> JayF: the conductor won't fail? just cleaning will fail. or did i miss something?
17:26:17 <dtantsur> for the record: for me it's mostly the same as deploy kernel/ramdisk, so I'm not sure why we treat them differently..
17:26:20 <vdrok> rloo: condcutor
17:26:30 <vdrok> if auto clean is enabled
17:26:37 <dtantsur> JayF, you won't end up with nodes in "available" state, if cleaning is broken, right?
17:26:41 <JayF> exactly
17:26:43 <JayF> it's a DoS
17:26:50 <JayF> because your nodes all get stuck in clean failed
17:26:52 <rloo> vdrok: what? the conductor should never fail *after* it has been started up?
17:26:58 <mat128> JayF: presuming you haven't even tried it once
17:27:12 <vdrok> rloo: it is going to happen in that init_host bit :)
17:27:25 <rloo> vdrok: that's ok, that's part of the start up of the conductor.
17:27:28 <mat128> What happens if the network uuid referenced is deleted after startup?
17:27:29 <dtantsur> JayF, I mean, you can't have "a nasty surprise as a deployer when your entire capacity is in clean failed after deletes" because you won't have instances to delete
17:27:46 <mat128> dtantsur: he meant you wont have available nodes afterwards
17:27:48 <JayF> dtantsur: ooooh. because you have to traverse cleaning to get to available
17:27:49 <vdrok> mat128: that is handled by validate() method of the interface
17:27:54 <JayF> dtantsur: so it is still an "early" fail
17:27:58 <dtantsur> kind of
17:28:19 <mat128> vdrok: but the case described by JayF will still happen
17:28:23 <dtantsur> mat128, and I'm reminding that we run cleaning after enrolling nodes before they're available the first time in their life
17:28:35 <TheJulia> But if validate fails, then the node can't be deployed in the first place
17:28:44 <dtantsur> so for this case to be real, you have to drop cleaning_network from ironic.conf after the instances are provisioned
17:29:00 <JayF> if automatic cleaning is enabled and can't succeed, you'd never have available nodes to schedule to
17:29:02 <jroll> TheJulia: oh it can :)
17:29:09 <JayF> that makes sense, and I hadn't thought about it
17:29:17 <jroll> TheJulia: I think nova only checks deploy interface validate()
17:29:18 <vdrok> TheJulia: network interface validate is not called all the time I think
17:29:31 <TheJulia> jroll: unless the explicit validate call has been removed from our nova plugin, nova instances shouldn't be deployed.
17:29:36 <TheJulia> vdrok: okay, that makes me sad
17:29:38 <JayF> so I'm OK with failing on attempt in both cases, with that in mind (I'm also OK with failing at startup in the automated_clean=True case), either way is fine
17:30:12 <TheJulia> jroll: I could have sworn it was the same as node-validate on the command line
17:30:17 <vdrok> TheJulia: in nova, I think only power and deploy are validated
17:30:34 <jroll> TheJulia: https://github.com/openstack/nova/blob/master/nova/virt/ironic/driver.py#L822-L825
17:30:37 <jroll> yeah, deploy/power
17:30:45 <dtantsur> we should also decide if we want cleaning_network to be set per node. if we do, we can't make it mandatory in configuration, I guess.
17:30:47 <jroll> I'm okay with doing this at runtime and not startup
17:30:58 <jroll> dtantsur: I think we've agreed that before, but nobody did the work
17:31:05 <TheJulia> jroll: thx, I feel sad now
17:31:12 <dtantsur> jroll, yeah, we have an RFE hanging around
17:31:17 <rloo> jroll, dtantsur: do we have an rfe for that?
17:31:25 <TheJulia> truthfully, we need to add network to that list :(
17:31:26 <rloo> dtantsur: thx :)
17:31:26 <dtantsur> I remember creating one :)
17:31:35 <jroll> TheJulia: ehhh, we should add network maybe, but we don't want to give up if e.g. inspect fails validation
17:31:52 <TheJulia> jroll: yeah
17:31:56 <dtantsur> https://bugs.launchpad.net/ironic/+bug/1614876
17:31:56 <openstack> Launchpad bug 1614876 in Ironic "[RFE] Allow setting {provisioning,cleaning}_network_uuid in node driver_info" [Wishlist,Confirmed]
17:32:01 * mat128 reocates
17:32:13 <jroll> ok I feel like we should timebox this a bit
17:32:23 <rloo> i think we're done.
17:32:32 <jroll> does anyone loudly disagree with failing things at runtime and not failing at startup?
17:32:58 * rloo can't parse that but thinks she understands
17:33:01 <vdrok> i'd still prefer startup if auto clean enabled, but fine with both
17:33:14 <mat128_> +1 to failing at runtime, ideally In validate
17:33:17 <JayF> vdrok: yeah, I'm less worried about that TBH now that I remember it won't work anyway :)
17:33:36 <jroll> okay cool, let's move on
17:33:41 <jroll> #topic do we need microversions/deprecation for this patch?
17:33:48 <rloo> since we have to change something, it is simple enough to do what vdrok suggested (fail if auto clean enabled)
17:33:53 <jroll> #link https://review.openstack.org/315766
17:34:12 <vdrok> that's me again. rloo and JayF  were concerned about that patch
17:34:38 <vdrok> this one was done a while ago https://review.openstack.org/314514 bu we didn't get to the other two
17:34:43 <JayF> rloo: the thing is apparently we want to eventually support per-node provisioninig || cleaning uuid (bug #1614876), which would mean we can't fail at lack of the config opt without omitting other possible valid configs
17:34:43 <openstack> bug 1614876 in Ironic "[RFE] Allow setting {provisioning,cleaning}_network in node driver_info" [Wishlist,Confirmed] https://launchpad.net/bugs/1614876
17:34:44 <mariojv> what's the disadvantage to the version bump?
17:35:09 <rloo> JayF: good point!
17:35:15 <JayF> mariojv: == my opinion about it. a new version is cheap, so I don't understand why we shouldn't bump it on even a minor change
17:35:23 <mariojv> yeah
17:35:35 <vdrok> mariojv: as it seems to me, it is a bug, we have not ever advertised it's possible, and it brings issues with naming nodes/ports etc.
17:35:37 <rloo> wrt the bug/microversion. what isn't clear to me, is what APIs are being prevented, and are any of them 'reasonable' apis that someone might have been using
17:36:04 <vdrok> if microversion, we'll have to support old buggy behaviour forever :(
17:36:13 <TheJulia> vdrok: +1
17:36:14 <jroll> rloo: https://review.openstack.org/#/c/315766/22/releasenotes/notes/fix-more-url-collisions-a047f468c260cd23.yaml
17:36:19 <jroll> they don't appear to be reasonable APIs to me
17:36:35 <rloo> jroll: why doesn't someone put that info in the actual commit?! :)
17:36:43 <jroll> rloo: ask the committer :)
17:36:44 <mariojv> vdrok has a decent point about supporting old buggy endpoints i think
17:36:52 <JayF> FWIW, I'm not strongly opinionated that this should be behind a microversion. I just wanted this conversation to happen with a larger audience :)
17:36:54 <rloo> what does/did those invalid urls return?
17:36:55 <mariojv> forgot about that piece
17:37:19 <lucasagomes> I think I agree with vdrok here, even if it's cheap to bump the version I don't like the idea of being "backward bug compatible"
17:37:25 <rloo> alternative is to deprecate them, and delete them in next cycle+3months blah blah
17:37:30 <dtantsur> ++ to question whether they returned something meaningful at all
17:37:33 <lucasagomes> I would prefer to defects like that to be fixed on all versions
17:37:53 <jroll> oh, interesting, we're changing a tempest test here
17:37:56 <TheJulia> Nor do I like the idea of backwards compatible bugs.  I think we should do it without a version bump if we're not changing the prescribed/documented interface
17:37:56 <JayF> I got the impression from the patch/bug that you could use /v1/nodes/ports the same as /v1/ports
17:38:01 <jroll> that means these were tested
17:38:02 <vdrok> dtantsur: yeah, these endpoints work as the proper ones do
17:38:27 <JayF> And that's a mistake it'd be relatively trivial for someone tomake using the API, and think it was the "right thing" when it worked
17:38:28 <dtantsur> so, one can e.g. create a port with them? hmm, this is bad
17:38:47 <JayF> I also think saying "it's not an endpoint we documented" isn't a great argument, because we haven't always had comprehensive API docs
17:39:15 <TheJulia> True
17:39:33 <dtantsur> yeah, and we even covered one of these with tests :)
17:39:37 <TheJulia> The alternative is to version bump to indicate the change, but break compatability
17:39:57 <TheJulia> or, just keep the buggy behavior forever in v1
17:40:23 <rloo> no to buggy behaviour. i'd prefer a microversion bump to buggy behaviour
17:40:46 <jroll> this assumes that it's a fact that this is "buggy behavior"
17:40:55 <jroll> it was clearly unexpected to most of us
17:41:13 <jroll> but e.g. one thing this changes is disabling /v1/nodes/states/console?node_ident=foo
17:41:16 <dtantsur> it's not really buggy, just not quite restful
17:41:17 <rloo> is it worth asking the api working group for their recommendation?
17:41:26 <vdrok> rloo: a problem with microversion is, we change the way routing works there, doing backwards compat may be not trivial there
17:41:26 <jroll> which is only a bug because we didn't intentionally put it there
17:41:36 <rloo> vdrok: sigh.
17:41:50 <jroll> also, I take back what I said about these not being reasonable, they seem reasonable to me
17:42:09 <JayF> I can't imagine we don't break at least a few users of the API if we push this without a microversion
17:42:12 <jroll> s/they seem/some seem/
17:42:36 <rloo> JayF: even if we push with a microversion, i suspect we'll break someone. who really looks...
17:42:54 * dtantsur hopes we don't use it in ironicclient :D
17:42:54 <JayF> rloo: they'll have to request latest || newer microversion for new feature
17:43:13 <JayF> rloo: and will get the notification then, during development, rather than beings urprised at something not working mid/post upgrade
17:43:27 <JayF> rloo: that's how we expect all microversion changes to "trickle down" to users, right?
17:43:31 <vdrok> sambetts: are you around?
17:43:41 <rloo> JayF: right, so if we remove this, we should 'at least' microversion it...
17:43:55 <JayF> okay, then we agree :)
17:44:03 <sambetts> vdrok: hi
17:44:04 <dtantsur> that's why we introduced microversions in the beginning :)
17:44:07 <jroll> I almost feel like it isn't worth removing
17:44:15 <vdrok> sambetts: your patch discussed :)
17:44:25 <TheJulia> jroll: I was just about to say something similar but with way too many words
17:44:27 <dtantsur> jroll++ maybe just document/test it as a non-recommended alias
17:44:32 <vdrok> sambetts: this chain https://review.openstack.org/316149
17:45:17 <vdrok> ok, so, seems like most people are in favour of microversion.
17:45:41 <jroll> I'm in favor of just leaving it alone
17:45:44 <TheJulia> perhaps we should vote
17:45:49 <rloo> so the only things we gain with removing those endpoints: 1. cleaner/more understandable code; 2. ??
17:45:50 <jroll> but would be fine with a microversion
17:46:08 <rloo> i'm still trying to understand the pros/cons of this
17:46:16 <mat128_> Document them as being available since version X and you're done
17:46:17 <JayF> rloo: if I name a node "port", it will be usable via node.name post-fix but not pre-fix
17:46:21 <jroll> rloo: 2) less duplicate API paths, 3) you could now name a node "ports", "states", etc
17:46:31 <TheJulia> mat128_: You know, you have a good point there
17:46:31 <sambetts> So I think this ties into the api rework conversations we were having at the summit, I'm not sure where that conversation lead
17:46:32 <JayF> the namespace pollution is the worst part of the bug, tbh
17:46:51 <jroll> JayF: s/worst/only/
17:46:53 <jroll> :)
17:47:02 <JayF> jroll: sure
17:47:26 <mariojv> is there anything preventing someone from naming a node "ports" today ?
17:47:31 <rloo> so if it is easy to implement (remove) via microversion, i say do that. otherwise, leave as is.
17:47:39 <mariojv> maybe the fix is to disallow that and hide behind microversion
17:47:40 <vdrok> with the amount of logic we have in api, I think I'd prefer leaving as is instead of microversion :)
17:47:58 <dtantsur> mariojv, it's sad, but yeah, we should fail early
17:48:09 <sambetts> I think lucasagomes added code to block that
17:48:13 <JayF> mariojv: that's a solid suggestion. Just ban names for nodes that overlap "special" ironic api words like node, port, state, etc
17:48:20 <lucasagomes> yeah there are some names that are blacklisted
17:48:23 <lucasagomes> because they didn't work
17:48:24 <dtantsur> HTTP 400 "we're brilliant in desiging APIs, so please do not call your nodes 'ports" :D
17:48:31 <mariojv> lol
17:48:37 <mat128_> 500? :)
17:48:39 <vdrok> the problem is as I said, routing is changed a bit, so allowing both cdepending on microversion won't be easy
17:48:39 <TheJulia> lol
17:48:41 <lucasagomes> like ports, it would redirect you to the v1/ports instead of the name called ports :-)
17:48:44 <vsaienk0> :)
17:49:07 <vdrok> dtantsur: +++ :)
17:50:01 <TheJulia> Note: 10 minutes remaining.
17:50:05 <jroll> ^
17:50:09 <jroll> do we need to vote on this?
17:50:26 <rloo> only if someone thinks we should not leave things as is
17:50:38 <dtantsur> maybe first investigate how hard it is to microversion it?
17:50:42 <mariojv> i think we should at least block colliding node names
17:50:52 <mariojv> agreed that this is hard to microversion with a glance at the patch
17:51:18 <TheJulia> I agree with both dtantsur and mariojv
17:51:28 <jroll> heh, ditto
17:51:28 <mariojv> if we voted, what would the options be? leave as-is, keep the patch as-is, hide patch behind microversion, and block colliding node names?
17:51:39 <lucasagomes> dtantsur, heh yeah it's terrible... but in fairness, we had no idea about rest APIs when we started
17:51:47 <lucasagomes> (nor wsme for what maters)
17:51:49 <lucasagomes> :-/
17:52:02 <vdrok> pecan brings surprises as well :)
17:52:03 <mariojv> this is something we can fix in v2 api also
17:52:11 <lucasagomes> vdrok, true
17:52:12 <dtantsur> my vote is 1. microversion it, if it's reasonable, 2. block colliding names with a microversion if it's not
17:52:26 <mariojv> dtantsur: +1
17:52:40 <mariojv> 2 can be a compromise until v2 api
17:52:50 <TheJulia> I agree
17:52:59 <jroll> +1
17:53:07 <rloo> i dunno, can't we just block colliding names, or do we need the microversion in case they already exist?
17:53:19 <mariojv> yes ^
17:53:34 <dtantsur> rloo, it depends on how usable such nodes are
17:53:48 <mariojv> ooh, that's a good point actually - what's the behavior today when those nodes are used ?
17:54:00 <dtantsur> I didn't investigate. if literally everything is broken with them, there is no use in microversioning
17:54:14 <vdrok> mariojv: they are not usable by name I suppose
17:54:32 <mariojv> so for dtantsur option 2, condition microversion bump on whether those nodes are usable by name today
17:54:46 <dtantsur> s/by name//
17:54:53 <mariojv> sure
17:54:54 <jroll> keep in mind node-create can't be called twice with the same name
17:54:57 <rloo> sambetts: you good with the above discussion? (not that you have to make the changes, just want to be sure you're ok)
17:55:01 <TheJulia> 5 Minute warning.
17:55:13 <dtantsur> if they can create such node, and can use it with UUID, we should not block it without microversions
17:55:18 <jroll> so... can't really break a workflow unless someone is constantly doing installations with these names
17:55:31 <jroll> dtantsur: we should only block setting the name, nothing else, imo
17:55:41 <dtantsur> jroll, this blocks node-create
17:55:46 <sambetts> rloo: yeah, I think we need to continue the v2 discusions at the PTG though
17:55:50 <dtantsur> even if they end up never using it by name at all
17:56:12 <rloo> sambetts: ok.
17:56:12 <jroll> ok let's take this to channel to leave room for open discussion
17:56:24 <jroll> #topic open discussion
17:56:36 <joanna> I have something :)
17:56:48 <joanna> https://bugs.launchpad.net/ironic/+bug/1650347
17:56:48 <openstack> Launchpad bug 1650347 in Ironic "ironic-conductor should not exit 0 on failure" [Medium,Incomplete] - Assigned to Joanna Taryma (jtaryma)
17:57:05 <mariojv> aNuposic had a fix for that i thought
17:57:24 <mariojv> launcher.wait() returns correct status code, i think, so we just have to pass that to sys.exit
17:57:39 <mariojv> i guess the code for that isn't up yet
17:57:48 <joanna> I started thinking, if it's good that all the processes we start in devstack are actually executed in background and piped so original return codes are overwritten
17:57:49 <vsaienk0> please review ironic standalone tests https://review.openstack.org/#/c/423556/ so we can remove at least 4 jobs when consider they are stable enough
17:58:03 <rloo> i humbly request that the new PTL send email to the dev list this week about PTG etherpad, what folks should be putting in that and what we will do in monday's meeting (if anything) wrt that.
17:58:34 <TheJulia> rloo: +1
17:58:35 <jroll> joanna: hrm, dunno, but that's a discussion to have with the qa team, I think
17:58:37 <jroll> rloo: ++
17:58:47 <aNuposic> mariojv: yes launcher.waits() returns correct code but return codes are overwritten
17:59:12 <rloo> vsaienk0: is that part of the CI work (in subteam? if so, maybe add that link to our etherpad.)
17:59:15 <mat128_> When are results going to be announced?
17:59:19 <jroll> 45 seconds for anything last minute
17:59:21 <joanna> mariojv: not really - status code is 1 when exception is raised, yet the whole command returns 0 from echo/tee
17:59:25 <mat128_> I can just look it up :)
17:59:25 <mariojv> mat128_: i had that question too
17:59:25 <jroll> mat128_: after the election ends :P
17:59:34 <mat128_> Jroll yeeeah
17:59:36 <jroll> mat128_: https://governance.openstack.org/election/
17:59:38 <jlvillal> joanna: Might be able to change our devstack code in openstack/ironic/devstack/lib/ironic
17:59:39 <vsaienk0> rloo yes
17:59:48 <mariojv> joanna: oh - i saw the bug as more about the ironic process than devstack
18:00:03 <mariojv> joanna: but i agree, that should be brought up with qa team - maybe have a separate bug for it ?\
18:00:07 <jroll> ok we're done
18:00:10 <jroll> #endmeeting