Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-18
16:42:03 cdent EmilienM, bauzas: so, where are we?
16:42:18 bauzas honestly, I'm puzzled
16:42:18 EmilienM I'm currently in the matrix reading tripleo logs
16:42:30 mriedem melwitt: yeah i was looking at it this morning, n-cpu does a new rest api call to n-api to register it's host with a cell mapping
16:42:45 bauzas I'm trying to compare the req-id in nova and match it in the keystone logs
16:42:46 mriedem but there are some parts in there about storing the parent cell uuid in the main db for some reason
16:42:56 sdague mriedem: is there a reason the conductor can't just do that?
16:43:05 mriedem sdague: that's what melwitt and i are talking about
16:43:13 sdague mriedem: I'm not sure I get why n-cpu needs to make an n-api call
16:43:14 sdague ok
16:43:35 melwitt yeah, I thought it could just go through conductor via objects
16:44:04 sdague ok, got to run to lunch, biab
16:45:33 cdent mriedem, sdague, bauzas: if this merges, all the functional tests pass in python35: https://review.openstack.org/#/c/421529/
16:45:34 bauzas cdent: EmilienM: FWIW, I'll need to drop very soon, I have a meetup to go
16:45:59 mriedem so in the short-term i probably need to just look at making devstack-gate call back into the primary node at the end of the setup (before tempest) to call discover_hosts instead of doing this https://review.openstack.org/#/c/420981/
16:47:10 melwitt ah, I see
16:47:11 mriedem +W
16:47:33 cdent thanks bauzas and mriedem . dims we have arrived in the future.
16:47:51 mriedem melwitt: yeah so sean's main point is that my patch relies on the fact that it sets up the computes after the controller (i think)
16:48:00 mriedem as in i think that's the main point
16:48:12 melwitt right
16:48:48 mriedem regardless of whether or not i can rely on the db connection in nova.conf, because DATABASE_HOST is still on the subnode when it's setup so i could build my own one-off nova.conf for running discover_hosts if i wanted,
16:48:49 bauzas cdent: EmilienM: humpf, nothing looks wrong when I see the keystone logs http://logs.openstack.org/66/421366/1/check/gate-puppet-openstack-integration-4-scenario004-tempest-centos-7/f138bcc/logs/apache/keystone_wsgi_main_access_ssl.txt.gz
16:48:55 mriedem but i think that defeats the point he's making
16:49:06 bauzas cdent: EmilienM: but I can't introspect the token
16:49:15 bauzas so, honestly, I'm really stuck
16:50:37 melwitt mriedem: oh, to get to the db regardless of whether the controller is up yet? yeah
16:51:02 dims cdent : yay :)
16:51:15 openstackgerrit Anusha Unnam proposed openstack/nova: Add keypairs field to InstancePayload https://review.openstack.org/419730
16:52:40 mriedem melwitt: right. i mean i'm not sure how many deployments actually setup computes first.
16:53:32 melwitt mriedem: yeah. we didn't, computes were last/parallel after controllers
16:54:21 openstackgerrit Sujitha proposed openstack/nova: Adding auto_disk_config field to InstancePayload https://review.openstack.org/419185
17:00:11 openstackgerrit Matt Riedemann proposed openstack/nova: DNM: Test interface attach/detach for Ironic https://review.openstack.org/421638
17:03:31 mriedem why god does this fail functional tests on newton but is no different from the change on master https://review.openstack.org/#/c/416760/
17:03:38 mriedem why hast thou forsaken my backport
17:03:46 _gryf bauzas, cdent, EmilienM, does any of you was able to reproduce/isolate that error on devstack? I was spent some time yesterday, but without any luck
17:04:04 bauzas _gryf: which error ?
17:04:14 bauzas the one we discussed above?
17:04:22 alaski mriedem: the reason for the cell_info is that a compute does not know what cell it is in. But it is configured to use a specific db. So it queries the db it knows about for its cell, then calls to the API and says "hey, I'm a compute in cell 'foo', register me"
17:04:25 _gryf bauzas, yes
17:04:32 bauzas _gryf: nope
17:04:39 _gryf bummer
17:04:59 alaski mriedem: that avoids the api cell from needing to go through and discover the new host
17:05:17 _gryf I'll try to investigate it further anyway
17:09:31 mriedem alaski: so that's plumbed into discover_hosts here https://review.openstack.org/#/c/369634/1/nova/cmd/manage.py@1530 in the case that the compute_nodes list is empty?
17:09:53 mriedem i.e. if compute_nodes then we create the host mappings for them in discover_hosts, if not we provide the info into the cell db to auto-register itself when it creates the compute node
17:10:19 gabor_antal Hey there, can I have a question? In kilo, there was a config flag name "allow_migrate_to_same_host". But in liberty (and since then) it is disappeared. Why it was removed? How can I get something like that nowadays for testing?
17:10:51 mriedem gabor_antal: allow_resize_to_same_host
17:11:21 alaski mriedem: it wasn't fully fleshed out, but it was written under the assumption that discover_hosts would be run once per cell to set it up and then after that auto-registration would happen.
17:11:42 alaski mriedem: if auto-registration is the path forward finding a way to avoid the initial discover_hosts would be preferable
17:11:53 gabor_antal mriedem: thanks, checking that out.
17:12:13 mriedem alaski: yeah we were talking about a simple auto-register in the single-cell case, which most deploys will be at first in ocata
17:12:33 mriedem alaski: since we know that besides cell0, if there is just a single cell, it's the one we want the host mapping in when creating a compute node record
17:13:15 mriedem alternatively we could mark a specific cell as the 'default' cell or 'staging' cell or something like that
17:13:19 mriedem which new computes show up in
17:14:06 melwitt when you say that, it makes me think we'd need a list_cells_and_hosts that shows what hosts are mapped to what cells
17:14:06 mriedem anyway with <2 weeks to FF auto-registration is probably not going to happen this release anyway so i should probably stop thinking about it
17:14:31 cdent mriedem: I've got a few cycles to poke at https://review.openstack.org/#/c/416760/ if you like?
17:14:34 alaski mriedem: yeah, there's a fair amount to consider to get this done
17:14:50 mriedem melwitt: i think we could just do like a nova-manage cell_v2 list_hosts or something that shows which cell each host is in, and vice-versa
17:14:52 alaski melwitt: that seems generally useful anyways
17:15:03 mriedem cdent: go nuts
17:15:10 cdent jfak;fjdasopvicu9v8
17:15:12 mriedem cdent: i suspect i'm just missing something before that backport
17:15:20 melwitt mriedem: yeah
17:15:31 mriedem cdent: but i can recreate this locally http://logs.openstack.org/60/416760/1/check/gate-nova-tox-db-functional-ubuntu-xenial/f192837/testr_results.html.gz
17:15:52 cdent k
17:16:30 alaski mriedem: melwitt the thing to consider with registration/discovery is that a compute is tied to a cell by the db it's configured to use. Meaning you can only put a compute in a cell that uses the same db that it does. So registering with a default/staging cell is just configuring it for that db initially
17:16:38 alaski and then moving it requires changing the db it uses
17:18:12 melwitt alaski: excellent point. so really a compute should just list cell mappings and register with the one it matches db connection with. (you probably said that earlier)
17:18:20 mriedem well,
17:18:32 mriedem https://review.openstack.org/#/c/421885/
17:18:34 mriedem case in point ^
17:18:47 mriedem you shouldn't need CONF.database.connection in nova.conf on the compute
17:19:12 mriedem auto-registering with a default or staging cell would require being able to move those hosts into other cells later, yeah
17:19:15 melwitt oh, heh
17:19:22 melwitt yeah, that's true
17:19:56 mriedem god, i can already see this requirement: i want to be able to live migrate my instances AND hosts out of cell A into cell B
17:20:04 alaski melwitt: if not for that review mriedem just posted then yeah, when I was playing around with it I just added the necessary info to the db https://review.openstack.org/#/c/369634/
17:20:54 alaski mriedem: use what the DARE program taught you, just say no
17:21:15 mriedem oh i was doing drugs immediately so DARE failed
17:21:37 alaski well, it did teach you all about them
17:22:12 mriedem i blame video games and rock music
17:22:33 mriedem and nancy reagan
17:22:53 alaski moving instances and hosts between cells would definitely be great to have, but they need some thought and should happen after cellsv2 is actually used by most/all deployers
17:22:56 gabor_antal mriedem: can you help me? I keep getting "UnableToMigrateToSelf: Unable to migrate instance (1bad3469-0843-4ce4-82b1-321a648415e3) to current host (compute).
17:22:57 gabor_antal " error, while "allow_resize_to_same_host" is set True. It's in a unit test btw.
17:23:36 mriedem gabor_antal: you have self.flags(allow_resize_to_same_host=True) in the unit test?
17:24:22 gabor_antal mriedem: Ofc. Sorry, it's actually a notification-checker functional test.
17:24:48 mriedem gabor_antal: the flag gets set for the test the same way
17:25:24 melwitt just have to make sure it's set before the service that reads it, is started
17:25:28 gabor_antal yeah, I've already set it. But I keep getting that annoying error
17:28:36 gabor_antal mriedem: I tried to set it right after this line, https://github.com/openstack/nova/blob/master/nova/tests/functional/notification_sample_tests/test_instance.py#L32, but keep getting that ugly error :(
17:29:01 mriedem gabor_antal: do you have a stacktrace you can put into a paste and link that here?
17:29:21 mriedem gabor_antal: btw,
17:29:23 mriedem see https://github.com/openstack/nova/blob/master/nova/tests/functional/notification_sample_tests/test_instance.py#L480
17:30:53 gabor_antal mriedem: I paste it in a second. I already checked those tests, but doing live migration tests still leads me to the same error, I think we have 3 patches which is stuck on this point
17:31:57 openstackgerrit Claudiu Belu proposed openstack/nova: Adds CPUFeaturesField to ImageMetaProps https://review.openstack.org/420960
17:32:00 gabor_antal mriedem: http://paste.openstack.org/show/595439/
17:33:13 siva_krishnan tdurakov: This is regarding https://review.openstack.org/#/c/379032/2. I just replied to your comments. Please let me know what I am planning to do looks acceptable

Earlier   Later