Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-23
15:32:31 dansmith bauzas: yes, we're on the same marker :)
15:33:02 edleafe jroll: cdent is away ATM, but I'll pick his brain when he gets back
15:33:10 openstackgerrit Maciej Szankin proposed openstack/nova: conf: Resolve TODOs in 'database' https://review.openstack.org/393695
15:33:30 jroll edleafe: yeah, fair, thanks
15:34:07 bauzas dansmith: since you're working on a new PS, maybe writing this scenario into a unittest could be nice to me
15:34:36 bauzas dansmith: like, create 3 cells, iterate over 1 and then the 2nd, add a new instance to cell1 and make sure that it's never read
15:35:02 bauzas dansmith: because I think that it could be something important for operators wanting to have multi-cells
15:35:17 bauzas and they could come to us and say 'why can't I see my new instances?"
15:35:18 dansmith bauzas: ...really?
15:35:32 bauzas dansmith: well, at least documenting it then
15:35:33 dansmith bauzas: but it's a marker/limit query and that situation exists today
15:35:45 bauzas something saying that we know our limitations
15:36:05 dansmith but it's exactly the way it behaves today :)
15:37:17 sfinucan So I'm clear, the marker is applied before the limit, right?
15:37:43 bauzas dansmith: okay then nevermind
15:37:49 vladikr dansmith, I have reworked the "sriov-pf-passthrough-neutron-port-vlan" series according to your suggestion to get the vlan from the info_cache, could you please take a look when you have the time, before it hits the code freeze ? https://review.openstack.org/#/q/topic:bp/sriov-pf-passthrough-neutron-port-vlan
15:37:50 sfinucan I'm curious what would happen if there was nothing matching the marker in the first cell but we hadn't indexed any others yet. I'm guessing '_get_instances_by_filters' will return nothing and limit wouldn't be deprecated, but just making sure :)
15:41:04 cdent jroll, edleafe: re [t 22sr] no catepillars, just maggots
15:41:04 purplerbot <edleafe> jroll: unless that butterfly laid some eggs in cdent's brain, yet [2017-01-23 14:52:19] [n 22sr]
15:41:23 jroll :|
15:41:31 edleafe cdent: so extra_specs is all we got?
15:42:13 cdent I vaguely recall this being discussed in a review and that extra_specs was the way to go for now because we hadn't had a chance to kill flavors
15:42:15 edleafe cdent: and do we have the code in place to convert 'resource_class' in extra_specs to an actual ironic request?
15:42:24 cdent but I wouldn't want to be held to that version of the truth
15:43:28 edleafe god, extra_specs is some special kind of suck
15:43:50 openstackgerrit Balazs Gibizer proposed openstack/nova: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
15:44:01 cdent it doesn't look like it, but my understanding was that for this cycle we weren't planning to. all we were caring about was getting the inventory right, not using it (in the ironic case)
15:44:27 amrith andreykurilin, looks like https://review.openstack.org/#/c/423086/ is trying to fix something related to what you are addressing; I've set that one to depend on your change; let's see how all three together do
15:45:03 edleafe cdent: so what jroll needs is to be able to write the guidance for ironic operators for ocata so that they are in a good place when pike rolls out
15:45:05 dansmith sfinucan: ah, we probably need to skip NotFound if we have a marker and limit!=0
15:45:06 cdent edleafe, jroll I'm sorry I don't know more. My devious plan to get people to correct me when I'm wrong or leave things out in the rp updates has been a fail
15:45:15 dansmith sfinucan: that's what the intent is, otherwise the marker would always have to be in cell1
15:45:26 dansmith which wouldn't be the case after we can have multiple
15:45:43 jroll cdent: and my plan to make sure that's in a good place has been undermined by a million other things to do
15:46:02 cdent plans suck, or something
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 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: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: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)

Earlier   Later