Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-18
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
17:34:06 mriedem jroll: i'm having a hard time understanding where this change https://review.openstack.org/#/c/364413/22/nova/virt/ironic/patcher.py is used in the rest of that patch
17:35:52 jroll mriedem: we moved the binding of the neutron port into ironic, since we do weird things with timing on that https://github.com/openstack/ironic/blob/e72e68eb38c4325bb868a504106be097251c3b5e/ironic/drivers/modules/network/flat.py#L68
17:36:56 jroll mriedem: rather than sometimes passing back the host id to the compute manager (to bind it then), and sometimes passing None back (to bind it later in ironic)
17:37:05 jroll now we just always bind it in ironic
17:37:22 jroll "binding it" meaning give it binding:host_id, which triggers ML2 stuff to actually connect it
17:37:51 mriedem ok so now when creating a node you need to provide the instance.host
17:37:54 mriedem and this patcher thing does that
17:38:24 jroll yeah, that patcher thing passes info we need from nova
17:38:41 mriedem ok https://github.com/openstack/ironic/blob/e72e68eb38c4325bb868a504106be097251c3b5e/ironic/drivers/modules/network/flat.py#L68 clears it up
17:38:42 mriedem thanks
17:38:44 jroll I agree with vasyl we should clean that up later and just use the node uuid
17:38:46 jroll np
17:40:24 mriedem also, docs people want you guys to specifically say 'ironic' instead of 'Ironic'?
17:40:26 mriedem that seems weird
17:40:49 mriedem i'd think that would be confusing to people new to openstack
17:40:55 cdent mriedem: this https://review.openstack.org/#/c/416761/ needs to come before https://review.openstack.org/#/c/416760/ in that stack of fixes
17:41:17 mriedem cdent: ah, well that's easy enough
17:41:36 cdent mriedem: docs people want lower case project names, I've never seen the reason why, but I also though they wanted service names instead of project names in docs?
17:42:10 mriedem yeah the idea is Compute service, Bare Metal service, Networking service, etc
17:42:19 mriedem what happens when they get to Monitoring service :)
17:42:28 cdent everyone runs and hides
17:42:35 mriedem Image Repository Service
17:43:57 cdent mriedem: you want me to reorder that stuff, or you got it?
17:44:21 mriedem cdent: i'll get it, i have to rebase the last 2 in the series anyway now due to merge conflicts
17:44:29 cdent ✔
17:46:37 mriedem jroll: ok so begins the elusive hunt for that 2nd core https://review.openstack.org/#/c/364413/
17:55:28 gabor_antal mriedem: Did you have any time to think about my problem or so? If it would be better, I can commit what I've done on the patchset, but it is not mine, just wanted to review.

Earlier   Later