| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-03 | |||
| 21:50:37 | dansmith | oh, I guess it does check both | |
| 21:50:42 | dansmith | the comment only says anti-affinity | |
| 21:51:10 | dansmith | mriedem: so yes, your second comment is right, except that: | |
| 21:51:23 | mriedem | so before multi-cell, you'd reschedule until you find the right host or fail, | |
| 21:51:24 | dansmith | 1. for anti-affinity it doesn't matter since anything it doesn't find is clearly not on the same host and, | |
| 21:51:37 | dansmith | 2. the problem is we can't upcall to get the members, not just that we can't see them in our db | |
| 21:51:37 | mriedem | after multi-cell, we might not even see the problem | |
| 21:51:52 | dansmith | right but with multi-cell #2 gets you anyway | |
| 21:51:53 | mriedem | agree with 1 yes, anti-affinity is totes fine | |
| 21:51:55 | dansmith | because of the upcall | |
| 21:52:42 | mriedem | if the cell isn't configured to hit the api db, then yes we can't upcall to iterate the cells to find hosts for all members in the group | |
| 21:53:08 | mriedem | this https://github.com/openstack/nova/blob/0ef3c685b9d2e0049f38fcf1a268870e69a5b9cf/nova/objects/instance_group.py#L473 | |
| 21:53:09 | mriedem | yeah? | |
| 21:53:38 | dansmith | well, | |
| 21:53:45 | dansmith | we won't iterate cells anyway, but yeah | |
| 21:58:34 | mriedem | so the only way to really fix this is for the scheduler to be aware of the location of the group members at the time of picking a host, and that has to be global, so placement, | |
| 21:58:59 | mriedem | and we likely need to model affinity (distance) for the group members using....provider aggregates? i know this is a rathole, | |
| 21:59:05 | mriedem | i keep thinking of cells as a provider aggregate | |
| 21:59:45 | dansmith | well, this is why I've been punting the problem because placement affinity is better for lots of reasons | |
| 22:00:04 | mriedem | melwitt: anyway, i think the functional change in your patch is ok, my main issue / concern is with the test | |
| 22:00:23 | melwitt | mriedem: yeah, in the middle of replying now | |
| 22:00:30 | mriedem | melwitt: a functional test with real services would be ideal | |
| 22:00:57 | melwitt | well, I think we need the unit test to cover all the weird paths, unless I'm just not thinking creatively enough | |
| 22:01:32 | mriedem | the majority of the work in a functional test for stuff like this is in the setup, | |
| 22:01:34 | melwitt | I'm gonna try to take a step back and see if I can come up with a real world scenario(s) that will take all of the paths that we can verify | |
| 22:01:37 | mriedem | after that it's just running scenarios and asserting stuff | |
| 22:02:07 | mriedem | https://review.openstack.org/#/c/565886/6/nova/tests/functional/test_nova_manage.py@357 is an example with 2 working cells | |
| 22:03:39 | melwitt | this is weird because there are two steps: 1) look up the hosts for members of the requested group 2) look up the hosts for members of the group the instance is a member of | |
| 22:04:38 | melwitt | and I was trying to test that both of those queries do the multi-cell thing. but yeah, probably could set this up for a functional test. I'll try it | |
| 22:05:37 | mriedem | with complicated changes like this, i find it's easier to write the functional test to setup the environment like the user would run a use case | |
| 22:05:48 | mriedem | using the actual APIs | |
| 22:05:53 | mriedem | to create the groups and add members to them and such | |
| 22:06:16 | mriedem | otherwise it's too easy to fake things out in the db that aren't accurate | |
| 22:07:17 | melwitt | for whatever reason, I did not expect it would be easy to do a functional test. I agree it would be a lot better to reason about too | |
| 22:07:29 | mriedem | mostly just copy/paste the setup | |
| 22:07:31 | mriedem | pretty easy | |
| 22:08:07 | mriedem | the one thing with multi-cell functional and having different hosts in different cells, you'll need https://review.openstack.org/#/c/558160/ | |
| 22:08:19 | mriedem | otherwise the computes all get created in the default cell1 | |
| 22:08:44 | mriedem | but that's approved now so shouldn't be a problem - you just need to specify the cell you want the compute in when you create it | |
| 22:09:25 | melwitt | I know, I tried to solve that problem with my CellDatabases patch months ago but people weren't okay with it because I did the ServiceWrapper thing | |
| 22:09:25 | mriedem | i've been told i need to go workout because i've become somewhat of a troll, so ttyl | |
| 22:23:03 | openstackgerrit | Jay Pipes proposed openstack/nova master: process groups individually and merge candidates https://review.openstack.org/566180 | |
| 22:52:34 | openstackgerrit | Merged openstack/nova master: Handle @safe_connect returns None side effect in _ensure_resource_provider https://review.openstack.org/566096 | |
| 22:58:45 | openstackgerrit | Merged openstack/nova master: Fix the request context in ServiceFixture https://review.openstack.org/558160 | |
| 23:07:57 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718 | |
| 23:33:50 | idlemind | http://paste.openstack.org/show/720326/ | |
| 23:34:02 | idlemind | I need those database connections to be updated to .9 not .11 ... what's the best way to do that? | |
| 23:34:25 | idlemind | can i just drop the cells (delete) and they'll get recreated? | |
| 23:34:42 | idlemind | or should i update them | |
| 23:46:08 | openstackgerrit | Oliver Walsh proposed openstack/nova stable/pike: Handle @safe_connect returns None side effect in _ensure_resource_provider https://review.openstack.org/566164 | |
| 23:48:57 | openstackgerrit | Arvind Nadendla proposed openstack/nova-specs master: Handle rebuild of instance with new image https://review.openstack.org/560718 | |
| #openstack-nova - 2018-05-04 | |||
| 00:54:00 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Add tests for alloc_cands with member_of https://review.openstack.org/561399 | |
| 00:54:01 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Fix member_of with sharing providers https://review.openstack.org/561400 | |
| 00:54:02 | openstackgerrit | Tetsuro Nakamura proposed openstack/nova master: Expand member_of functional test cases https://review.openstack.org/566011 | |
| 01:05:26 | mrjazzercise | idlemind: you've got 2 cell1s, so probably drop the one with the wrong URL | |
| 01:05:36 | mrjazzercise | and update the cell0 one using nova-manage cell_v2 update_cell | |
| 01:06:05 | mrjazzercise | some services cache the cells so you'll have to restart some services, check the man page on update_cell | |
| 01:06:21 | mrjazzercise | nova-api, nova-conductor and nova-scheduler i think | |
| 02:09:08 | idlemind | mrjazzercise thx | |
| 04:31:51 | openstackgerrit | jichenjc proposed openstack/nova master: WIP:[doc]Move configuration to admin subfolder https://review.openstack.org/566212 | |
| 05:43:56 | openstackgerrit | jichenjc proposed openstack/nova master: [doc]Move configuration to admin subfolder https://review.openstack.org/566212 | |
| 05:45:35 | nsingh | any command or way to confirm which services running on compute nodes??? | |
| 06:48:25 | openstackgerrit | zhangyangyang proposed openstack/nova master: Remove the function get_back_port() https://review.openstack.org/566219 | |
| 07:37:39 | bauzas | good morning Nova | |
| 07:37:39 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova stable/ocata: libvirt: Make `cpu_model_extra_flags` case-insensitive for real https://review.openstack.org/565672 | |
| 07:37:47 | bauzas | let me put a Friday swag | |
| 08:17:17 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: WIP new migration threads control https://review.openstack.org/563505 | |
| 08:24:44 | bauwser | andreykurilin: remind me, if I'm using novaclient python bindings for calling Nova, if I'm not providing a specific microversion request, then I get v2.1, right? | |
| 08:25:04 | bauwser | contrary to when using the nova CLI, when we ask for nova.latest microversion, right? | |
| 08:25:30 | bauwser | gibi: if you remind as well ^ | |
| 08:29:11 | bauwser | I mean, when I do a Client('2'), I should only get v2.1 | |
| 08:29:30 | bauwser | actually, I should get /v2 which maps to /v2.1 to be precise | |
| 08:31:14 | bauwser | yeah, confirmed https://github.com/openstack/python-novaclient/blob/master/novaclient/api_versions.py#L233-L234 | |
| 08:31:35 | bauwser | do we have any novaclient specialists here ? | |
| 08:31:42 | bauwser | just to confirm | |
| 08:46:06 | openstackgerrit | Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802 | |
| 08:49:32 | giblet | bauwser: I don't know | |
| 08:49:53 | bauwser | no worries, I think I have all that I want | |
| 08:49:58 | giblet | OK | |
| 08:50:06 | bauwser | we discover the versions with the shell | |
| 08:50:16 | bauwser | but we don't with the python bindings directly | |
| 09:51:44 | rabel_ | hi there. I just saw that add-floating-ip action is deprecated in compute api. but how is a floating ip associated to an instance then? | |
| 09:55:48 | rabel_ | found it. network api https://developer.openstack.org/api-ref/network/v2/#floating-ips-floatingips | |
| 10:48:42 | openstackgerrit | Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290 | |
| 10:49:20 | finucannot | jaypipes, giblet: OK, I think that spec is good to go now. I've clarified a lot of the physnet/provider net stuff and fixed the diagrams https://review.openstack.org/541290 | |
| 10:55:42 | giblet | finucannot: looking | |
| 11:01:59 | openstackgerrit | Surya Seetharaman proposed openstack/nova stable/queens: Make association_refresh configurable https://review.openstack.org/566288 | |
| 11:08:37 | giblet | finucannot: your spec looks good to me | |
| 11:50:03 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: any traits in allocation_candidate query https://review.openstack.org/565730 | |
| 11:50:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | |
| 12:02:40 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits https://review.openstack.org/565741 | |
| 12:06:22 | jmccarthy | Hmm I still have this issue where after a cold migration, a disk.info file shows up in instance dir and is left on source host | |
| 12:06:43 | jmccarthy | I'm using kolla stable/queens - does this log seem right ? | |
| 12:06:45 | jmccarthy | http://paste.openstack.org/show/720358/ | |
| 12:07:13 | jmccarthy | It's when the resize/migration is confirmed that it shows up | |
| 12:09:40 | jmccarthy | This part looks good CMD "rm -rf /var/lib/nova/instances/371e669b-0f15-49f2-9a84-bd1e89f34294_resize" returned: 0 | |
| 12:10:00 | jmccarthy | But then a lock is acquired on disk.info *after that ? and it's left there .. | |
| 12:21:22 | jmccarthy | After migrating an instance, is /var/lib/nova/instances/371e669b-0f15-49f2-9a84-bd1e89f34294/disk.info supposed to written out on the source host ? | |
| 12:21:46 | jmccarthy | s/After/After cold-/ | |
| 12:31:19 | openstackgerrit | Merged openstack/nova master: libvirt: Drop BAD_LIBVIRT_CPU_POLICY_VERSIONS https://review.openstack.org/564012 | |