| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-28 | |||
| 09:29:37 | ebbex | But the post returns 202 accepted, so I'm guessing it's not written to the database yet. | |
| 09:31:13 | artom | ebbex, instance create is async, so as you rightly point out, it returns accepted instead of OK | |
| 09:31:27 | artom | Then the instance goes through various states until it's active | |
| 09:32:36 | openstackgerrit | Lucian Petrut proposed openstack/nova master: test patch - do not merge https://review.openstack.org/478449 | |
| 09:33:41 | ebbex | Ok, so I've changed the setup on the loadbalancer... "10.224.0.157:3030 compute.api 202 "POST /v2.1/servers", then "10.224.0.157:3030 compute.api 404 "GET /v2.1/servers/18ab1ab2-d4a7-4aad-a032-84fd618959d4" | |
| 09:35:15 | ebbex | so now both request go to same api1. | |
| 09:40:41 | artom | ebbex, and you're still hitting the same problem? I'm out of ideas then | |
| 09:45:16 | ebbex | artom: thanks, i'll dig a little deeper and get back when I find more clues. | |
| 09:45:39 | ebbex | Think it might be some misconfiguration in the cell_mappings in nova_api. | |
| 09:50:02 | artom | ebbex, sorry I couldn't be of more help, good luck! | |
| 09:58:16 | openstackgerrit | Naichuan Sun proposed openstack/nova master: os-xenapi: Exception Error logs shown in Citrix XenServer CI https://review.openstack.org/478437 | |
| 09:58:41 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: Exception Error logs shown in Citrix XenServer CI https://review.openstack.org/478437 | |
| 10:12:30 | openstackgerrit | Chason Chan proposed openstack/nova master: import installation guide pages from openstack-manuals https://review.openstack.org/477488 | |
| 10:24:13 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: add traits support to get resource_providers with shared https://review.openstack.org/478464 | |
| 10:24:59 | alex_xu | bauzas: edleafe jaypipes ^, give a try on adding traits support | |
| 10:39:00 | sfinucan | Lots of doc patches incoming | |
| 10:39:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Switch to openstackdocstheme https://review.openstack.org/477751 | |
| 10:39:16 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Remove cruft from conf.py https://review.openstack.org/478468 | |
| 10:39:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Remove dead plugin https://review.openstack.org/478469 | |
| 10:39:17 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Remove dead files https://review.openstack.org/478470 | |
| 10:39:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Create directory structure for docs migration https://review.openstack.org/478471 | |
| 10:39:18 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'cli' section https://review.openstack.org/478472 | |
| 10:39:19 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'configuration' section https://review.openstack.org/478473 | |
| 10:39:19 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'contributor' section https://review.openstack.org/478474 | |
| 10:39:20 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'user' section https://review.openstack.org/478475 | |
| 10:48:46 | Dinesh_Bhor | Hi all, is there a way to get instances based on system_metadata? | |
| 10:50:27 | artom | Dinesh_Bhor, you've asked that before, what exactly are you looking to do? | |
| 10:51:15 | artom | You said it's not included in the nova show output... | |
| 10:51:35 | artom | Are you asking if there's a way to change that and include system_metadata in the nova show output? | |
| 10:54:34 | Dinesh_Bhor | artom: My aim is to get the instance which is having some particular system_metadata set. But with "nova list" it gives me "invalid filter system_metadata". | |
| 10:54:45 | Dinesh_Bhor | artom: and with "nova show" I just checked that whether I am getting system_metadata in response but it's not. It is ignored in view_builder. | |
| 10:57:05 | artom | Dinesh_Bhor, I don't think system_metadata is return by the rest API, is it? | |
| 10:57:20 | artom | https://developer.openstack.org/api-ref/compute/?expanded=show-server-details-detail#show-server-details | |
| 10:57:41 | artom | If it's isn't there's not much you can unless you have access to the db and want to run SQL queries | |
| 10:58:17 | artom | If what you're looking for is in there you can bypass the python client and hit the API directly with curl, for example | |
| 10:59:12 | openstackgerrit | Chason Chan proposed openstack/nova master: import installation guide pages from openstack-manuals https://review.openstack.org/477488 | |
| 11:01:32 | Dinesh_Bhor | artom: no I don't have access to db. Do you think that we can returning system_metadata in show call ? | |
| 11:01:49 | Dinesh_Bhor | s/ returning/return | |
| 11:02:52 | artom | Dinesh_Bhor, there would be a lot of overhead (spec, api microversion) if we were to implement that, and I suspect it'll get shot down | |
| 11:03:30 | artom | Dinesh_Bhor, why are you looking for specific system metadata though? Maybe there's another way to accomplish what you're trying to do | |
| 11:09:44 | sdague | sfinucan: because you were handling a bunch of these deprecations, can you look at https://bugs.launchpad.net/nova/+bug/1698010 | |
| 11:09:44 | openstack | Launchpad bug 1698010 in OpenStack Compute (nova) "dhcp-domain is deprecated, but required for correct FQDN behavior" [Undecided,New] | |
| 11:12:23 | openstackgerrit | Chason Chan proposed openstack/nova master: import the admin guide content from openstack-manuals https://review.openstack.org/477497 | |
| 11:13:06 | Dinesh_Bhor | artom: Instance can be resized in two vm_states "active" and "stopped". I want to find out what is the previous vm_state of an Instance before it was resized through API. | |
| 11:13:18 | Dinesh_Bhor | artom: I can see that while reverting resized instance it gets the instance "old_vm_state" from instance system_metadata [1] and depending on it nova puts that instance back to that old_vm_state. | |
| 11:13:29 | Dinesh_Bhor | artom: [1] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4022 | |
| 11:14:29 | sfinucan | sdague: will do | |
| 11:18:42 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova master: Format NIC features using os-traits definitions https://review.openstack.org/466051 | |
| 11:20:56 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: Exception Error logs shown in Citrix XenServer CI https://review.openstack.org/478437 | |
| 11:35:59 | artom | Dinesh_Bhor, instance_actions might help you | |
| 11:36:42 | artom | (Using "might" in the literal sense - ie, look into it, but I'm not sure) | |
| 11:43:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'user' section https://review.openstack.org/478475 | |
| 11:43:06 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Switch to openstackdocstheme https://review.openstack.org/477751 | |
| 11:43:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'reference' section https://review.openstack.org/478484 | |
| 11:43:07 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Rework index page per new sections https://review.openstack.org/478485 | |
| 11:43:08 | openstackgerrit | Stephen Finucane proposed openstack/nova master: fixup! doc: Populate the 'reference' section https://review.openstack.org/478486 | |
| 11:43:24 | sfinucan | jaypipes, sdague: Those docs patches should be easy reviews and have to get in this cycle. Would appreciate it if either of ye could take a look sometime this week | |
| 11:43:34 | sfinucan | Will ping mriedem too once he's about | |
| 11:43:52 | jaypipes | will do sfinucan | |
| 11:44:12 | sfinucan | ta | |
| 11:44:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'user' section https://review.openstack.org/478475 | |
| 11:44:28 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Switch to openstackdocstheme https://review.openstack.org/477751 | |
| 11:44:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Populate the 'reference' section https://review.openstack.org/478484 | |
| 11:44:29 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Rework index page per new sections https://review.openstack.org/478485 | |
| 11:44:33 | alex_xu | jaypipes: hope this is helpful https://review.openstack.org/478464 | |
| 11:47:48 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/477091 | |
| 11:48:56 | jaypipes | alex_xu: thx! reviewing now. BTW, I can't figure out why https://review.openstack.org/#/c/475448/ is failing that one functional test (about the traits sync...) | |
| 11:49:19 | jaypipes | alex_xu: it's passing locally and the version of os-traits in requirements.txt is the same. | |
| 11:49:29 | jaypipes | alex_xu: perhaps you might take a look? | |
| 11:50:04 | ebbex | artom: so we've possibly traced it down a bit further, on "server create" we see inserts into request_spec, build_requests and instance_mappings. But the GET we see right after has a SELECT from instances. But we don't see what is inserting the uuid into this table. Any idea how something ends up in the "instances" table? | |
| 11:50:12 | alex_xu | jaypipes: yea, let me try | |
| 11:51:03 | jaypipes | alex_xu: if I can't figure it out, I can revert to trying to create MISC_SHARES_VIA_AGGREGATE manually, like we do here currently: https://github.com/openstack/nova/blob/master/nova/tests/functional/db/test_resource_provider.py#L2533-L2546 | |
| 11:51:36 | jaypipes | alex_xu: edleafe had asked me to use Trait.get_by_name() in the new patch now that we have os-traits 0.3.1 in the requirements. | |
| 11:51:42 | ebbex | Is that table populated by something else via rpc? nova-scheduler maybe? | |
| 11:51:59 | alex_xu | jaypipes: ok, got it, will let you know whehter I can found something | |
| 11:52:04 | jaypipes | cheers | |
| 11:52:13 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add BDM to InstancePayload https://review.openstack.org/448779 | |
| 11:52:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add key_name field to InstancePayload https://review.openstack.org/463002 | |
| 11:52:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add keypairs field to InstanceCreatePayload https://review.openstack.org/419730 | |
| 11:53:17 | jaypipes | ebbex: the instance UUID is generated in the nova-api server and placed in the instance_mappings table before scheduling. i.e. we pre-create the instance's UUID when we create the request spec. | |
| 11:56:16 | jaypipes | ebbex: the first time the cell DB's instances table is written to (and populates the instances.uuid field) is here: https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L964 | |
| 11:56:58 | jaypipes | ebbex: you'll note that is after the scheduler has selected the destination host to attempt the build on and before the compute service is notified to build the instance (line 999) | |
| 11:57:17 | jaypipes | ebbex: hope this helps. | |
| 11:57:53 | ebbex | jaypipes: so it is nova conductor that places the instance in the instance table, right? But.. as this is done via rpc, am I correct in assuming nova-api is not waiting for a reply from conductor (instance inserted in instances table) before returning 202? | |
| 11:58:23 | sdague | sfinucan: I just went through most of that stack, I've got some concerns by some of the changes. | |
| 11:58:56 | sfinucan | sdague: Anything in particular, or is it all in Gerrit? | |
| 11:59:10 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459 | |
| 11:59:11 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297 | |
| 11:59:22 | jaypipes | ebbex: no, the (super)conductor writes the instances record to the cell DB on line 964 *before* RPC'ing the compute service. | |
| 11:59:33 | jaypipes | ebbex: and that write is synchronous. | |
| 12:00:09 | sdague | sfinucan: it's all in gerrir | |
| 12:00:12 | sdague | gerrit | |
| 12:00:20 | ebbex | jaypipes: but then how come the select on the instances table _after_ nova-api has returned 202 on to the create instance call returns no match? | |
| 12:01:22 | jaypipes | ebbex: nova-api returns a 202 when it creates the *build request*. The build request is in the API database (top-level DB). The instances table is in the cell DB and is written to after scheduling has selected a target host (and therefore a target cell). | |
| 12:01:36 | jaypipes | ebbex: nova-api calls nova-conductor after passing a 202 back to the user. | |
| 12:01:42 | ebbex | jaypipes: there must be a race condition here, and even tho we are using galera, we (currently) send all of nova*'s sql connections to a single galera instance (trying to eliminate "slave-lag" problems) | |
| 12:02:23 | jaypipes | ebbex: nova-conductor then calls nova-scheduler, which selects the host and returns that selection back to the conductor, which then writes the instances record to the cell DB and sends the launch instance RPC call to the target compute host. | |
| 12:02:50 | jaypipes | ebbex: it's not a race condition. it's working as intended :) | |
| 12:03:15 | jaypipes | ebbex: the instances table of the cell DB will not have a record for the instance with that UUID until the scheduler selects a host. | |
| 12:03:31 | jaypipes | ebbex: the UUID you get back is the one from the build_requests table in the top-level API database. | |