| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-22 | |||
| 19:08:16 | melwitt | ah | |
| 19:08:37 | sean-k-mooney | have i mentioned lately i hate trying to find things in storyboard | |
| 19:08:46 | melwitt | man I hate storyboard | |
| 19:09:19 | melwitt | the search is a lot worse than launchpad, it doesn't have per stable branch tracking ability | |
| 19:09:25 | sean-k-mooney | i have set the list option to 1000 result and im now using ctrl-f in my brower instead | |
| 19:09:46 | melwitt | launchpad forever | |
| 19:10:07 | sean-k-mooney | as far as u can tell there isnt a story open | |
| 19:10:32 | melwitt | ok. actually let me look for mriedem's mega etherpad of osc issues, I wonder if it's on there | |
| 19:11:03 | sean-k-mooney | this seams related https://storyboard.openstack.org/#!/story/2006761 but its sperate | |
| 19:11:15 | efried | I'm sure if you asked, they would say you can totally track stable branches, by creating a bunch of separate tags and tasks and ... | |
| 19:11:28 | efried | ...in ways that are specific to your project... | |
| 19:12:01 | melwitt | yeah not specifically mentioned https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc | |
| 19:12:01 | sean-k-mooney | efried: im just happy you have not tried to adopt it for nova | |
| 19:12:24 | melwitt | efried: yeah, true | |
| 19:12:47 | efried | To be fair, I don't love LP either. But sb is nowhere near mature enough to replace it for something of the scope of nova. | |
| 19:12:52 | sean-k-mooney | the other part of it are proably fine. its the search that kills me | |
| 19:13:03 | efried | maybe it will be some day | |
| 19:13:09 | melwitt | I used to complain about lp before storyboard | |
| 19:13:16 | melwitt | and now I appreciate it a lot more | |
| 19:13:33 | sean-k-mooney | i used to complain about lanchpad before bugzilla | |
| 19:13:48 | melwitt | I actually love bugzilla. which I know is weird | |
| 19:14:19 | sean-k-mooney | but serisly how is the colision in bugzilla actully a thing in 2019 | |
| 19:15:02 | melwitt | yeah but meh, it never trashes what I wrote when that happens | |
| 19:15:44 | melwitt | I guess if you change a bunch of metadata, then yeah true you have to do over | |
| 19:15:45 | melwitt | so yeah, that's really annoying | |
| 19:16:51 | sean-k-mooney | ya i usally am doing both so i end up copy pasting my comment then revert to the latest version set everything again and paste my comment and hope the bot does not change something inbetween | |
| 19:17:18 | mriedem | what is the osc question? | |
| 19:17:46 | sean-k-mooney | when you use osc to list the server events of a deleted server | |
| 19:17:55 | sean-k-mooney | it first tries to get the server which failes | |
| 19:18:00 | mriedem | --os-compute-api-version whatever | |
| 19:18:09 | sean-k-mooney | yep even with that set | |
| 19:18:23 | mriedem | b/c it's looking by name and not finding it, are you using the id? | |
| 19:18:40 | mriedem | KeithMnemonic opened a similar osc bug recently | |
| 19:18:51 | sean-k-mooney | yes useing the uuid | |
| 19:18:52 | sean-k-mooney | http://paste.openstack.org/show/786587/ | |
| 19:19:09 | sean-k-mooney | that is the curl command it produce with the token replaced | |
| 19:19:27 | mriedem | https://storyboard.openstack.org/#!/story/2006761 | |
| 19:19:41 | sean-k-mooney | that was form "openstack --debug --os-compute-api-version 2.21 --os-cloud openstack server event list cef12383-3f43-44cf-be52-218a4da30c0a" | |
| 19:19:50 | melwitt | mriedem: https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server-event.html#server-event-list claims that you can see events for a deleted server with 2.21 but you really can't bc osc is doing a lookup without --deleted essentially | |
| 19:20:34 | melwitt | mriedem: ok yeah that story is similar | |
| 19:20:38 | mriedem | yeah it's an osc bug with the server id lookup | |
| 19:20:54 | melwitt | same problem, different command | |
| 19:21:21 | mriedem | open an osc story bug thing but no one will work on it unless one of you do | |
| 19:21:38 | mriedem | does https://docs.openstack.org/python-novaclient/latest/cli/nova.html#nova-instance-action work? | |
| 19:21:41 | sean-k-mooney | ya and there is no --deleted flag for event list so we cant signle what to do | |
| 19:21:51 | sean-k-mooney | mriedem: yes | |
| 19:22:05 | melwitt | I'm willing to work on it bc we need the action list to be part of a normal user workflow especially now | |
| 19:22:26 | melwitt | or rather, I would prioritize it a lot higher than I usually would | |
| 19:22:32 | mriedem | "especially now" is a bit heavy | |
| 19:22:34 | sean-k-mooney | adding a --delete to the event list might just be the simpelest option | |
| 19:22:46 | sean-k-mooney | mriedem: well we need it for resize not right | |
| 19:22:58 | sean-k-mooney | welli guess not for deleted instnaces | |
| 19:23:09 | mriedem | we changed one api from a call to a cast which might have failed with NoValidHost (MaxRetriesExceeded) after the api had already given you a 202 | |
| 19:23:20 | mriedem | if resize rescheduling fails | |
| 19:23:22 | melwitt | "especially now" is based on my own personal experience at the org where I worked and how openstack was used there. there was no need to look at action events unless you were the auditing | |
| 19:23:36 | melwitt | -the | |
| 19:24:02 | melwitt | I recognize that other orgs end users could/are already using the api heavily | |
| 19:24:26 | mriedem | or not, | |
| 19:24:50 | mriedem | my point is just that it's not like there was a sudden tectonic shift on how nova works that makes caring about instance actions a big deal now | |
| 19:25:00 | mriedem | *in how | |
| 19:25:15 | melwitt | maybe not, but it's an end user perception and I think that's what really matters | |
| 19:25:32 | mriedem | what is an end user perception? | |
| 19:25:44 | melwitt | and again, disclaimer, I don't know how every end user in the world uses nova | |
| 19:26:26 | melwitt | I was an end user of nova on a daily basis at my last company. and I never needed the actions api for anything. if a server action failed, I looked at the server fault. that was it | |
| 19:26:31 | mriedem | if users didn't care about instance actions before, nothing has really changed recently that makes them have to start caring | |
| 19:26:37 | melwitt | that was my perception as an end user | |
| 19:26:54 | mriedem | probably b/c back in havana/icehouse/juno we put the server into error status every time anything failed | |
| 19:27:10 | melwitt | I think there is. if a resize used to fail with a 400, then how would you know to look at actions suddenly to know your resize failed scheduling? | |
| 19:27:32 | melwitt | I think that's quite different. again, just MHO | |
| 19:27:55 | melwitt | as someone who has used nova. that would have surprised me | |
| 19:27:56 | mriedem | resize could have failed *before* after you got a 202 and the first host resize claim failed and rescheduled and got NoValidHost | |
| 19:28:01 | mriedem | to know that, you'd have to know about instance actoins | |
| 19:28:07 | melwitt | *shrug* | |
| 19:28:15 | melwitt | whatever, just saying my opinion | |
| 19:28:48 | melwitt | everyone else can think whatever they want | |
| 19:31:11 | dansmith | my feeling is that things should be as async as possible because that involves the least amount of tying architecture to api behavior, | |
| 19:31:15 | mriedem | i'm not trying to argue, i'm just saying nothing has dramatically changed - things have been this way for years wrt instance actions | |
| 19:31:20 | dansmith | which bit us in the ass with the cells conversion | |
| 19:31:39 | dansmith | right now we have a big mix, with some assumed behaviors from the users (i.e. that 200 from resize means something specific) | |
| 19:31:54 | dansmith | actions have been there a long time, with lots of useful information | |
| 19:32:02 | melwitt | no, I agree that more async is good. I'm just saying that to me, in my own perception, it's a shift from the past habit | |
| 19:32:26 | dansmith | if the users don't know about it, then we probably have some doc gaps, but I don't think that really changes anything | |
| 19:32:27 | melwitt | my habit was not to use instance actions. my habit will be to use instance actions from now on, now that I know | |
| 19:32:38 | dansmith | and I also don't think that actions are some obscure corner of the nova world | |
| 19:32:41 | mriedem | the shift happened years ago then, is my point | |
| 19:32:57 | melwitt | ok, mine didn't, and I figured maybe I'm not the only one | |
| 19:32:59 | dansmith | I think that some people might never go looking for it and just infer what they can from status, return codes, etc, but they're missing part of the story | |
| 19:33:01 | mriedem | after yesterday's meeting i have a todo to write a doc about using actoins | |
| 19:33:16 | mriedem | but i'm still working on this resize/cold migrate doc for artom | |
| 19:33:27 | dansmith | I totes don't see how this is a shift | |
| 19:33:39 | melwitt | I get that you guys don't | |
| 19:33:46 | dansmith | when actions became a thing, there was more information available, that's not a shift, that's just more | |
| 19:33:54 | artom | mriedem, I'll handle the sequence diagram, fwiw | |
| 19:34:18 | dansmith | inferring things from api behavior is.. a thing I guess, and over time those inferences will have to change because they're based on assumptions | |
| 19:34:45 | dansmith | so there is a shift in those inferences I guess, but not in like fundamental behavior of how one uses nova or anything | |
| 19:34:51 | melwitt | it was a shift for me as a user, that's all I'm saying. and the only reason this came up is that, it's a shift for me, I see how important it is, so therefore I have a new interest in fixing the osc command for it | |
| 19:35:43 | melwitt | it means I will change my habit in how I use nova and it might change others too | |
| 19:35:52 | mriedem | artom: i'm about to push it | |
| 19:36:00 | mriedem | artom: i don't want you putting rebuild in the diagram somewhere | |
| 19:36:04 | mriedem | ZING | |