| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-22 | |||
| 18:49:05 | melwitt | so our only way of communicating errors for asynchronous operations is basically ERROR state and 'server events' | |
| 18:49:11 | sean-k-mooney | ya i would guess heat did not check the responce | |
| 18:49:28 | sean-k-mooney | i think attach is blocking so it should have been return to heat | |
| 18:49:33 | melwitt | yeah, I mean, heat could probably do something. but I don't know that much about heat | |
| 18:50:07 | gregwork | the heat behavior is it sits there | |
| 18:50:20 | gregwork | no errors, just waiting | |
| 18:50:30 | gregwork | it eventually times out when its auth token expires | |
| 18:51:13 | melwitt | we don't put the instance into ERROR because it's in a perfectly healthy state, it's just the attach didn't work, which sucks, but it doesn't mean the instance is broken or unusable. so that's why we don't do ERROR state. other than that, the API is async so return code will be 202 ACCEPTED but it can obviously fail after that point after the request goes async | |
| 18:51:46 | sean-k-mooney | melwitt: which api is async? | |
| 18:52:04 | melwitt | sean-k-mooney: is attach not async? | |
| 18:52:32 | sean-k-mooney | its respocne code is listed as 200 | |
| 18:52:36 | sean-k-mooney | which would imply not | |
| 18:52:36 | melwitt | I assumed it must be based on the behavior. gregwork did you call volume attach or something else? | |
| 18:53:10 | sean-k-mooney | https://docs.openstack.org/api-ref/compute/?expanded=attach-a-volume-to-an-instance-detail#attach-a-volume-to-an-instance | |
| 18:53:12 | gregwork | i create a data volume with os::cinder::volume then attach it using ::volumeattach | |
| 18:53:33 | sean-k-mooney | gregwork: are you attaching via nova or cinder | |
| 18:53:38 | gregwork | cinder | |
| 18:53:38 | sean-k-mooney | oh heat | |
| 18:53:39 | melwitt | yeah it shows as a cast | |
| 18:53:41 | gregwork | via heat | |
| 18:53:51 | melwitt | attach_volume is a cast (async) | |
| 18:53:57 | gregwork | i mean i assume os::cinder::herpderp means its talking to cinder ? | |
| 18:54:14 | gregwork | (heat that is) | |
| 18:54:14 | sean-k-mooney | the we are returning the wrong responce code it should be a 202 as you said | |
| 18:54:21 | melwitt | fun | |
| 18:54:40 | gregwork | i try and bring only quality bugs to these channels :) | |
| 18:55:00 | melwitt | THANKS gregwork | |
| 18:55:39 | gregwork | heh np :P | |
| 18:55:43 | melwitt | sigh, yeah that sucks. I dunno why that's not a 202 | |
| 18:56:11 | melwitt | gregwork: I think probably it's (heat) creating the volume in cinder and then calls nova to attach | |
| 18:56:14 | sean-k-mooney | i guess its calling https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=attach-volume-to-a-server-detail#attach-volume-to-a-server | |
| 18:56:28 | sean-k-mooney | that one does return a 202 | |
| 18:56:47 | melwitt | oh what? I didn't know that cinder had an api to attach to instance. it must just call us | |
| 18:57:04 | melwitt | I don't remember any of this stuff | |
| 18:57:14 | sean-k-mooney | all the proxy apis lol | |
| 18:57:28 | melwitt | can we achieve a full mesh proxy to one another | |
| 18:57:48 | sean-k-mooney | that is the dream | |
| 18:58:09 | sean-k-mooney | also i grab the curl command form osc via --debug | |
| 18:58:10 | sean-k-mooney | http://paste.openstack.org/show/786587/ | |
| 18:58:31 | sean-k-mooney | i adde a valid token and that is what we get form the nova api | |
| 18:59:08 | melwitt | yeah but you need to do that with the instance actions api | |
| 18:59:15 | melwitt | it works fine in the legacy client | |
| 18:59:28 | melwitt | so there's something buggy with how osc is calling instance actions api | |
| 18:59:42 | sean-k-mooney | right so osc is first hitting the /server endpoing for some reason | |
| 18:59:57 | melwitt | oh, yeah. that was my assumption that it does something like that across the board | |
| 19:00:19 | melwitt | which will break nova commands that are supposed to work on deleted things | |
| 19:00:22 | sean-k-mooney | right so its makeing an extra api call before trying to call the events api | |
| 19:00:25 | melwitt | right | |
| 19:00:35 | sean-k-mooney | but it does not pass the --delete flag or query arg | |
| 19:00:44 | sean-k-mooney | so that fails and it never does the thing we asked | |
| 19:00:50 | melwitt | I guess the bug fix might be to see if that extra call can be removed selectively for the server event commands | |
| 19:00:57 | melwitt | right | |
| 19:01:17 | melwitt | there might already be a storyboard open for this issue. I can't imagine we're the first to run into it | |
| 19:01:40 | sean-k-mooney | when was the last time you tried to get server event? | |
| 19:02:09 | sean-k-mooney | but ya it might already be open | |
| 19:02:19 | sean-k-mooney | i would not be surpised if it was not however | |
| 19:02:34 | melwitt | me? never (with osc). but I know that (was it huawei?) were making a lot of use of the apis. maybe their end users not using it through osc though. I dunno | |
| 19:04:17 | melwitt | I'll chase it up though bc this is going to need to be a normal part of users workflow | |
| 19:05:35 | sean-k-mooney | oh we added user and projec to migration last cylce not instance actions but we did mention the isntace action as an alternitive in the spec | |
| 19:05:37 | sean-k-mooney | https://specs.openstack.org/openstack/nova-specs/specs/train/approved/add-user-id-field-to-the-migrations-table.html | |
| 19:06:29 | melwitt | it's already in instance actions. in osc --long | |
| 19:06:55 | melwitt | I saw it | |
| 19:07:40 | sean-k-mooney | ya it is | |
| 19:07:47 | sean-k-mooney | i was just getting confused with that spec | |
| 19:07:53 | melwitt | ok | |
| 19:08:03 | sean-k-mooney | where we added to migration and said the alternitve was to find the instnace action | |
| 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 | |