Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-23
15:46:30 andreykurilin amrith: it should fix only tests...
15:46:50 amrith andreykurilin, I don't even understand that test
15:46:55 sfinucan jroll: And review all the code, like a good core :)
15:47:04 jroll sfinucan: I'll think about it
15:47:06 jroll :)
15:47:11 amrith why it makes sense for a test to inspect some internal attributes of the nova client object I know not
15:47:16 sfinucan heh :)
15:47:20 andreykurilin amrith: heh
15:47:21 amrith seems like that test would be more appropriate if it were in nova
15:47:26 amrith but this is a test in trove :)
15:47:41 amrith the fix seems to correct for the fact that the variable is no longer context.user but why should trove care?
15:47:47 amrith my 2c worth
15:48:00 amrith let's see if it passes tests; I'll fix the test a different way if it does and dep on your change
15:48:00 cdent jroll, edleafe: I reckon for the guideance the thing to do at this stage is establish a pattern of people setting the resource class on the ironic side so that the inventory setting, established in this patch: https://review.openstack.org/#/c/404472/ can happen
15:48:32 jroll cdent: I agree, I just don't think we can require that for a pike upgrade, if people can't transition their flavors in ocata
15:49:04 cdent Unfortunately I can't really comment on that: I don't have enough of a picture of all the pieces
15:50:18 edleafe jroll: I can't imaging flavors being nuked any time soon - they're just too entrenched to kill without splattering their guts all over
15:50:45 edleafe jroll: so I would recommend going the extra_specs route for the foreseeable future
15:50:57 edleafe jroll: it sucks bigly, but that's all we have to work with
15:51:32 jroll edleafe: if we're only tracking resources the new way (as we just said we wanted to in pike), then the existing flavors (which include cpu/ram/gb) won't work. which means we need to be able to make new flavors (with only resource classes) in ocata, and those need to work (I think?).
15:53:24 mriedem buenos dias
15:55:36 edleafe mriedem: that's not how you vacation!
15:55:54 mriedem it's how *i* vacation
15:56:07 ildikov mriedem: hi
15:56:13 ildikov mriedem: are you on vacation today?
15:56:44 mriedem ildikov: yes
15:57:08 openstackgerrit Maciej Szankin proposed openstack/nova: conf: Resolve TODOs in 'database' https://review.openstack.org/393695
15:57:11 ildikov mriedem: oh nice, then I'll not harass you to come to the meeting :)
15:57:34 ildikov mriedem: BTW, would any other day at the same time work for you in general?
15:57:54 ildikov mriedem: there are a few folks with collisions so I'm trying to find another slot that can work
15:58:19 ildikov mriedem: no other questions before saying Happy Vacations! :)
16:00:11 mriedem ildikov: the time slot itself in general works for me
16:00:28 ildikov mriedem: great, thanks!
16:09:10 cdent edleafe: since you committed to rebasing the nested resource providers, shall I do the customer resource classes? https://review.openstack.org/#/q/topic:bp/custom-resource-classes+status:open
16:09:49 edleafe cdent: I was gonna do them both, but if you're bored...
16:10:10 cdent edleafe: go for it, definitely not bored
16:12:33 BobBall Is there a way to set per-driver defaults for config values? For example, ram_allocation_ratio defaults to 1.5 - but this does not make sense for XenServer since the driver doesn't enable over-commit.
16:13:03 mriedem gibi: http://logs.openstack.org/45/403745/11/gate/gate-nova-tox-db-functional-ubuntu-xenial/76b1646/console.html#_2017-01-23_15_02_47_382251
16:13:12 mriedem BobBall: nope
16:13:19 sfinucan BobBall: Not that I'm aware off, I'm afraid. That would probably be something for your deployment tool
16:13:22 sfinucan *of
16:13:23 BobBall Well, poohsticks.
16:13:33 mriedem BobBall: i'd expect different virt drivers to be configured on different compute hosts
16:14:07 BobBall Of course - admins can set ram_allocation_ratio in the config file, I was just trying to reduce their work by making the defaults make sense :)
16:15:40 mriedem BobBall: well...you could possibly do something fancy on startup if you know which virt driver is used and if the user has explicitly set the config rather than just picking up the default,
16:15:48 mriedem i.e. change the default in code based on which driver is used at runtime
16:16:05 mriedem but i don't think there is anything in oslo.config to tell you if the option was loaded from config or defauls
16:17:29 jroll mriedem: BobBall: couldn't you use set_default? http://docs.openstack.org/developer/oslo.config/configopts.html#oslo_config.cfg.ConfigOpts.set_default
16:20:07 mriedem jroll: yeah maybe when loading up the compute driver
16:20:19 bauzas f****, we have a shit ton of tests that are having 'fake-mini' as hypervisor_hostname
16:20:22 bauzas :(
16:21:15 bauzas cdent: mriedem: dansmith: I think we have a very important problem with our unique constraint about the RP name being unique :/
16:21:25 jroll mriedem: oh, that config is in the scheduler process, isn't it, maybe not then
16:21:46 cdent bauzas: do tell?
16:22:08 erlon andreykurilin: hey andrey, I have found out that service_catalog is not part of novaclient anymore
16:22:29 erlon andreykurilin: how suppose a client to use it now?
16:22:36 erlon andreykurilin: do you have any good example?
16:22:56 bauzas cdent: https://review.openstack.org/#/c/424110/ tries to avoid hitting -1 from functional tests because https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api_models.py#L294-L295
16:23:28 erlon andreykurilin: this removal breaks Cinder migration and some other features
16:23:29 BobBall jroll: I thought it had to be on the compute since the scheduler could be managing different computes with different ratios?
16:23:44 BobBall jroll: "This configuration specifies ratio for RamFilter which can be set
16:23:47 BobBall per compute node"
16:23:51 bauzas cdent: when you run 2 'compute' services in a functional test, it then runs the FakeDriver but with the same hypervisor_hostname so we're trampled by the placement engine giving us a 409
16:23:59 bauzas when creating the RP for the 2nd compute
16:24:01 BobBall (sorry - thought I could delete the linebreak after paste)
16:24:11 jroll BobBall: not sure, I'm not a nova+virt expert :)
16:24:14 andreykurilin erlon: yes. service_catalog was a custom implementation for thing that should be done by keystoneclient. service_catalog is now available in keystone session object
16:24:24 cdent bauzas: so the problem is not so much that the constraint exists, but that existing fixtures weren't prepared for it?
16:24:31 bauzas cdent: zactly
16:24:53 erlon andreykurilin: hmm, ok, thanks
16:24:56 bauzas cdent: I'm not saying it's due to the UC, just that the problem is popping up now because all our computes have 'fake-mini'
16:25:01 BobBall jroll: OK - my reading is that I think that setting the default per-compute will work as the scheduler reads from the host_state rather than using a default value from the config file.
16:25:22 bauzas cdent: I fixed that in https://review.openstack.org/#/c/424110/ but that blows up, probably because it makes a shit ton of assumptions
16:25:31 jroll BobBall: ah, then yeah, conf.set_default in the driver's initialization would probably work out
16:25:37 jroll I guess it's easily tested
16:25:43 BobBall I'm already hacking it up to test :)
16:25:56 cdent bauzas: your use of the phrase "very important" made it sound like it would be hard to fix and might impact actually using the system, but it sounds more like it is something we need to address (and may be hard to address) but once addressed, not a problem?
16:26:18 bauzas cdent: it's a show-stopper for merging the scheduler upcall
16:26:25 bauzas tbc
16:26:27 edleafe bauzas: thinking about real-world deployments: are we requiring operators to give every compute node a unique name?
16:27:07 bauzas edleafe: well, I think we made this hypothesis a while ago because you can get_by_name a RP
16:27:20 bauzas now, it's part of the world
16:27:33 bauzas and we can't easily go against that way
16:28:03 edleafe bauzas: ok, so how likely is it that a deployment with thousands of compute nodes has named them all uniquely?
16:28:42 bauzas edleafe: well, that's certainly a good point, but you're advocating of removing that UC, then ?
16:28:48 bauzas sounds a big deal to me
16:29:01 edleafe bauzas: not advocating - more like thinking aloud
16:29:23 edleafe bauzas: as someone who hasn't ever managed a large deployment
16:29:47 bauzas edleafe: AFAIR, libvirt is taking the hostname as the hypervisor_hostname
16:29:57 bauzas edleafe: and that goes the same for other drivers
16:30:05 edleafe bauzas: causing tests to fail is bad. Causing deployments to fail is... worse
16:30:24 bauzas edleafe: given it's based on the service hostname, that looks not difficult to me to have different hostnames :)
16:31:31 sfinucan DinaBelova: Quick question - if I run something like 'tox -e py27 nova.tests.unit.scheduler.filters.test_numa_topology_filters', is it expected that the os_profiler test be run?
16:32:00 openstackgerrit Eric Fried proposed openstack/nova: Introduce base PowerVM driver (disk drv) https://review.openstack.org/409401
16:32:11 edleafe bauzas: ok, that's reassuring
16:33:07 cdent bauzas: so sounds like the first thing to do is fix the fixtures and the functional tests? Do you need/want help with that?
16:33:40 bauzas cdent: http://logs.openstack.org/10/424110/1/check/gate-nova-tox-db-functional-ubuntu-xenial/e2972f1/testr_results.html.gz
16:33:48 mriedem so rp.name is optional
16:33:57 mriedem is it the resource tracker that's setting it to hypervisor_hostname?
16:33:57 bauzas cdent: giving you a sense of what I call "a shit ton of assumptions"

Earlier   Later