Earlier  
Posted Nick Remark
#openstack-nova - 2019-11-22
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
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

Earlier   Later