| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-12 | |||
| 13:47:42 | kashyap | sean-k-mooney: If it were "trivial", why would they write that tool? | |
| 13:47:55 | sean-k-mooney | it does not do persistence but at the time i also looked into doing it with systemd | |
| 13:48:34 | sean-k-mooney | kashyap: because they felt like it? just because its trivial to do does not mean you dont have to do it alot and still want to automate it | |
| 13:49:41 | openstackgerrit | Merged openstack/nova master: Make get_provider_by_name public and remove safe_connect https://review.opendev.org/664062 | |
| 13:50:18 | rafaelweingartne | Hello guys, is there an "openstack server event list" command like that is able to list the events for deleted VMs? | |
| 13:52:04 | sean-k-mooney | im not sure that is what that is for | |
| 13:52:14 | rafaelweingartne | no? | |
| 13:52:41 | sean-k-mooney | i think it list the life cycle events a server has undergone | |
| 13:52:49 | sean-k-mooney | i dont think you can use it to wait for an event | |
| 13:53:02 | rafaelweingartne | It looks like it is presenting he vents I need/want such as attaching something, and or creating the vm | |
| 13:53:07 | rafaelweingartne | ah | |
| 13:53:11 | rafaelweingartne | no, I do not want to wait | |
| 13:53:29 | kashyap | sean-k-mooney: It's not "they felt like it"; there's a proper rationale there. | |
| 13:53:39 | kashyap | [quote] | |
| 13:53:40 | kashyap | everyone's needs on the first pass, but maybe we'll solve enough and | |
| 13:53:40 | kashyap | provide something and see where it goes. I doubt we'll solve | |
| 13:53:40 | kashyap | is largely left as an exercise for the user. This is an attempt to | |
| 13:53:40 | kashyap | Currently mediated device management, much like SR-IOV VF management, | |
| 13:53:41 | rafaelweingartne | I just want to list all events that already happened to a VM | |
| 13:53:42 | kashyap | provide helpers for the rest. Without further ado, I'll point to what | |
| 13:53:45 | kashyap | I have so far: | |
| 13:53:47 | kashyap | [/quote] | |
| 13:54:28 | rafaelweingartne | sean-k-mooney: I think your reply was not meant for me | |
| 13:54:32 | rafaelweingartne | sorry ;) | |
| 13:54:36 | sean-k-mooney | kashyap: sure but its proably not the first attempt to do that either | |
| 13:55:15 | sean-k-mooney | rafaelweingartne: no it was | |
| 13:55:55 | sean-k-mooney | i was stating that cli command is to show the list of event that server has undergon. but im currently confiming | |
| 13:56:09 | rafaelweingartne | ah o | |
| 13:56:10 | rafaelweingartne | ok | |
| 13:56:16 | rafaelweingartne | but that is actually what I want/need | |
| 13:56:26 | rafaelweingartne | to list everything that has already happened to a VM | |
| 13:56:36 | rafaelweingartne | the problem is that it only works for VMs that have not beeing deleted | |
| 13:56:51 | rafaelweingartne | or at least, I was not able to use it for deleted VMs | |
| 13:58:06 | sean-k-mooney | deleted or soft deleted | |
| 13:58:36 | rafaelweingartne | the difference is not that clear to me | |
| 13:58:42 | rafaelweingartne | deleted | |
| 14:01:44 | sean-k-mooney | this is basically showing the events form the instance action log | |
| 14:02:18 | sean-k-mooney | i did not think we removed that when we deleted an instace provided you have not archive teh deleted instances or purged them form the db | |
| 14:02:30 | sean-k-mooney | but maybe we do not allow you to retrive the info | |
| 14:03:03 | rafaelweingartne | that is what I thought | |
| 14:03:10 | rafaelweingartne | is this implemented in Nova API? | |
| 14:03:33 | rafaelweingartne | or is it somewhere else? where I can take a look and maybe propose a method to retrieve data for deleted VMs as well | |
| 14:04:24 | sean-k-mooney | i think its hitting this endpoint https://developer.openstack.org/api-ref/compute/?expanded=list-server-usage-audits-detail | |
| 14:05:37 | sean-k-mooney | actully no that is not correct | |
| 14:06:33 | sean-k-mooney | its hitting the server action endpoint | |
| 14:06:35 | sean-k-mooney | https://developer.openstack.org/api-ref/compute/?expanded=list-server-usage-audits-detail,list-actions-for-server-detail#list-actions-for-server | |
| 14:07:51 | rafaelweingartne | cool thanks | |
| 14:08:11 | rafaelweingartne | I was looking for "/servers/{server_id}/events"... | |
| 14:08:20 | rafaelweingartne | now I know why I did not find it | |
| 14:08:42 | rafaelweingartne | What does this "Action information of deleted instances can be returned for requests starting with microversion 2.21." mean? | |
| 14:08:53 | rafaelweingartne | Nova version? | |
| 14:09:02 | rafaelweingartne | Nova-compute* | |
| 14:09:35 | sean-k-mooney | the nova api support microversion form v2.1 on | |
| 14:09:43 | sean-k-mooney | but the openstack client does not use them | |
| 14:09:47 | sean-k-mooney | it default to 2.1 | |
| 14:10:08 | sean-k-mooney | so if you want to get it to work you have to pass a a microverion of at lest 2.21 | |
| 14:10:14 | sean-k-mooney | one sec | |
| 14:11:39 | sean-k-mooney | add --os-compute-api-version 2.21 to the request | |
| 14:11:50 | sean-k-mooney | *command | |
| 14:16:03 | rafaelweingartne | something like? "openstack server event list 9b82ae8f-ac7e-47e9-819c-24105631df80 --os-compute-api-version 2.21" | |
| 14:16:39 | rafaelweingartne | I just checked the code, and aren't the instances removed from "instance_mappings" table when they get deleted? | |
| 14:29:04 | efried | sean-k-mooney: First blush, adding the allocations from placement to the Instance object sounds like a solid idea. | |
| 14:34:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Fix double word hacking test https://review.opendev.org/664940 | |
| 14:34:43 | stephenfin | efried: f*** me that was a rabbit hole and half ^ | |
| 14:35:08 | efried | stephenfin: no doubt. Looking... | |
| 14:35:23 | stephenfin | tl;dr: I can't decide if either the Python patch or pycodestyle is broken, but it's the edgiest of edge cases that we'd only really see in tests, so we can work around it | |
| 14:37:51 | mriedem | rafaelweingartne: no, | |
| 14:37:58 | rafaelweingartne | hmm | |
| 14:37:59 | mriedem | the instance mappings are cleaned up when you archive | |
| 14:38:07 | mriedem | nova-manage db archive_deleted_rows | |
| 14:38:35 | mriedem | rafaelweingartne: 2.21 is about instance actions / events | |
| 14:39:07 | mriedem | rafaelweingartne: https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server-event.html | |
| 14:39:08 | gibi | stephenfin: what a detective work! | |
| 14:42:46 | dansmith | mriedem: can you quickly weigh in on this? I thought you might care about the use of a sentinel value in nova-manage. Otherwise I'm good with it: https://review.opendev.org/#/c/662383/5 | |
| 14:45:40 | mriedem | ew | |
| 14:47:11 | dansmith | before you shame him, note that it was my idea :) | |
| 14:48:53 | mriedem | i'm just trying to think of alternatives, | |
| 14:49:19 | mriedem | i saw melwitt pointed out https://review.opendev.org/#/c/603998/ but i'm not sure what that change is doing, | |
| 14:49:27 | mriedem | with takashi's change, | |
| 14:50:10 | mriedem | if you specify one but not the other it's an error, | |
| 14:50:38 | mriedem | i was thinking, what if we change the logic such that if you specify one but not the other, we just don't read from the config for the other (don't set/update the other) | |
| 14:50:48 | mriedem | if you don't specify either, we use config, | |
| 14:50:54 | mriedem | if you specify both, we set/update both, | |
| 14:50:56 | dansmith | that just seems confusing to me | |
| 14:50:59 | mriedem | if you only provide one, we only use one | |
| 14:51:14 | mriedem | i think that's more in line with how osc set commands work | |
| 14:51:27 | dansmith | I was actually expecting to have a --transport_url=(keep|config|[url]) sort of thing, but.. | |
| 14:52:02 | dansmith | the confusing bit is that we do the magic config thing if we don't specify either.. if we specify one, then we do a totally different set of things | |
| 14:52:32 | mriedem | i'm assumine when this was written, we expected people were either using all of the command options or none to let config handle it | |
| 14:52:33 | mriedem | not a mix | |
| 14:52:39 | dansmith | this has tripped up more than one person who was surprised by one or the other behaviors | |
| 14:52:54 | dansmith | well, | |
| 14:53:06 | dansmith | I think it actually came from create, where that makes more sense | |
| 14:53:14 | dansmith | and we imported the same behavior for update where it does not | |
| 14:54:39 | mriedem | yeah ok i can see that, | |
| 14:54:57 | mriedem | so in that case i think it makes more sense to only update the field provided via the option if only one option is provided, and ignore the other (don't use config) | |
| 14:55:46 | dansmith | le sigh | |
| 14:57:58 | mriedem | hey, you asked me | |
| 14:58:03 | mriedem | anyway, i commented | |
| 14:58:16 | mriedem | if we need a tie breaker i vote that we ask dean to weigh in | |