Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-07
15:36:24 bauzas gibi: you can look at it to see that we don't support some specific pGPU if the asked type by the configuration is not actually used by the pGPU
15:36:25 gibi gmann: yes, the WIP patch works for me
15:36:44 gibi bauzas: ack, I will get back to that tomorrow.
15:37:42 gmann gibi: ok, apart from rackspace usecase, if we allow empty string in query which is disallowed now still need microversion as it change the interface
15:38:12 gmann for interoperability
15:38:13 gibi gmann: we cannot filter for servers without config drive today, it is a bug
15:38:45 gmann humm
15:39:09 gibi as that filter would look like: ?config_drive=
15:39:21 gibi as the db contains empty value for the no config drive case
15:40:18 gmann i was thinking to fix it with GET reponse and DB to have false in case of no config drive(empty string)
15:41:05 gibi gmann: that is DB migration + microversion on the API (due to the rsp change) so that is someting I wouldn't start at the week of FF
15:41:22 gibi also it has a rackspace crazyness to it
15:41:53 gibi but on the long term this might be the good way
15:42:02 gibi for API consistency
15:42:11 gibi so I agree to add this to the API cleanup etherpad
15:42:24 gmann but i am thinking if changing query things is ok without microversion as it can create interop issue
15:43:03 gibi yeah, so I have to find a way now to unblock the 2.83 client patch without the need to change the query string semantic
15:43:59 gibi I can say that we have a nova bug but the client patch does not make it worse it just keep passing what it gets from the user to the nova API, and as soon as we fix the nova API we can stricten the client code too
15:44:12 gmann ok. I will check that, i think we can keep error there as it get from API
15:44:16 gmann yeah, ditto
15:44:28 gmann i will add that on etherpad and we can discuss the best possible solution.
15:44:34 gibi gmann: cool. thanks.
15:45:00 gmann thanks. we might have few more field like that
15:46:11 gmann gibi: done, L86 - https://etherpad.openstack.org/p/nova-api-cleanup
15:46:17 gibi ack
15:46:18 gibi thanks
15:54:01 sean-k-mooney gibi: this is what i was thining of by the way https://bugs.launchpad.net/python-novaclient/+bug/1314395 https://github.com/openstack/python-novaclient/commit/adf6c351a05d205573be4f00db1e53aa2615a593
15:54:03 openstack Launchpad bug 1314395 in python-novaclient "Documentation for config_drive boot parameter is incorrect" [Undecided,Fix released] - Assigned to Jason Dunsmore (jasondunsmore)
15:54:42 sean-k-mooney gibi: many many many moons ago e.g. like essex it used to take a volume id too
15:54:52 artom stephenfin, so, I know I said the NUMA LM tests can wait until after FF
15:54:59 artom But with https://review.opendev.org/#/c/715362/4, I'd kinda want to see them merge first?
15:55:02 gibi sean-k-mooney: thanks for the reference
15:55:18 artom I'd be the only place where we test the fancier live migration stuff
15:57:34 stephenfin Hmm, that's a fair point. I'll try dig back into it tomorrow morning
15:58:30 sean-k-mooney ah the uuid was only for nova v1 api and was droped in https://review.opendev.org/#/c/10934/ damb that was a long time ago. im surprise we only update the docs in rocky
15:59:25 artom stephenfin, I've addressed your hatred of the weird 3/2 split, FWIW, hopefully it's easier to understand now
16:01:21 artom stephenfin, also, https://review.opendev.org/#/c/687856/24/nova/compute/manager.py@7672
16:01:27 artom Am I being overly dramatic?
16:01:58 stephenfin artom: You need to have a guest NUMA topology to use vPMEM
16:02:37 artom stephenfin, ah, doh.
16:17:40 dansmith gmann: around?
16:17:57 gmann dansmith: hi
16:18:15 dansmith gmann: I need some help understanding the policy tests so I can rebase this patch
16:18:28 gmann sure
16:18:30 dansmith gmann: https://review.opendev.org/#/c/711194/13/nova/tests/unit/policies/test_volumes.py@240
16:19:15 dansmith gmann: that test is running with system_foo_context and validating that policy fails..
16:19:51 dansmith gmann: so I'm guessing whatever system_policy_context is does not have admin to do swap, and is not owner for update?
16:21:04 gmann dansmith: yeah system_foo_context does not have admin. these are all context defined - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/tests/unit/policies/base.py#L54
16:21:50 dansmith oh, so system_foo is "some random other user" ?
16:22:06 sean-k-mooney stephenfin: artom well wehn you use vpmem it creates an implict numa toplogy like cpu pinning or hugepages
16:22:09 dansmith gmann: so that should fail for both reasons... "not admin and not owner" right?
16:22:20 gmann dansmith: yeah, basically checking 'foo' role has access or not
16:22:26 gmann true
16:22:28 artom sean-k-mooney, yeah, I got it completely wrong and panicked for nothing
16:22:45 sean-k-mooney artom: hehe k
16:23:17 dansmith gmann: okay, so the next test after that.. is changing the policy it looks like?
16:23:22 gmann dansmith: i think we should test those policy against each context. we can hack the first policy check to allow-all to verify the second.
16:24:01 gmann dansmith: yeah changing the first policy, so that we can verify the second enforced policy
16:24:06 sean-k-mooney im going to see if my second attempt to get shopping without spenindg 30 mins queing to get in to the shop works so ill be back in an hour too since ill be cooking dinner in ither case
16:24:07 dansmith gmann: I'm not checking both, I'm checking one or the other.. maybe I should just push up what I have for discussion and work on the tests after we agree?
16:24:28 gmann dansmith: yeah, because those tests are with old order of policy
16:24:56 gmann once we have correct order of policy enforcement then we can better judge how to tests
16:25:03 dansmith right okay.. let me remove that last test since it's testing the serial checking of policy anyway
16:25:04 dansmith ack
16:27:32 openstackgerrit Merged openstack/nova master: Add test coverage of existing flavor_manage policies https://review.opendev.org/714814
16:28:30 sean-k-mooney oh while i think if it we have a but with how we do validation of numa paramater if we have an automatic numa toplogy. ill try an file it when i get back but basically we ignore the hw:nuam_cpu and hw:numa_mem options if you dont have multiple numa nodes to you can set things that refer to cells that dont exist e.g hw:numa_mem.1=512 when you only have one numa node(node 0) or possible no numa nodes i
16:28:32 sean-k-mooney havent fullly check how broken it is.
16:29:11 sean-k-mooney i think the code that reads that extra spec just does not run if you dont have hw:numa_nodes>=2
16:29:46 stephenfin lyarwood: You have two merge conflict issues in the https://review.opendev.org/#/q/topic:bp/virt-bfv-instance-rescue series, fyi https://review.opendev.org/#/q/topic:bp/virt-bfv-instance-rescue
16:30:48 lyarwood stephenfin: looking
16:31:06 lyarwood how on earth
16:35:32 openstackgerrit Balazs Gibizer proposed openstack/python-novaclient master: Microversion 2.83 - Add more filters for the nova list command https://review.opendev.org/713089
16:36:50 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212
16:36:50 openstackgerrit Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.87 allowing boot from volume rescue https://review.opendev.org/701430
16:36:51 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Support boot from volume stable device instance rescue https://review.opendev.org/701431
16:37:40 openstackgerrit Dan Smith proposed openstack/nova master: Separate update and swap volume policies https://review.opendev.org/711194
16:38:32 gibi stephenfin, gmann, brinzhang: made --config-drive a pass through option in https://review.opendev.org/713089 to decuple that change from the bugfix https://bugs.launchpad.net/nova/+bug/1871409
16:38:34 openstack Launchpad bug 1871409 in OpenStack Compute (nova) "cannot filter the list servers to show only those that does not have config drive" [Medium,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
16:40:06 stephenfin gibi: What kind of values can the user actually pass through at the moment?
16:40:20 gibi stephenfin: API schema allows any string
16:40:28 gibi stephenfin: and matches it against the DB value
16:40:43 gibi which is also a String(255)
16:41:01 gibi (the API schema does not allow empty string though)
16:41:09 stephenfin right, but what values will do something meaningful? Do we only ever store a string-ified True/False value in there?
16:41:39 gibi stephenfin: we definitely store "True" and "", but I'm not sure if we store other values
16:42:36 gibi at some point in the past we allowed to store a uuid there
16:42:47 gibi https://bugs.launchpad.net/python-novaclient/+bug/1314395
16:42:49 openstack Launchpad bug 1314395 in python-novaclient "Documentation for config_drive boot parameter is incorrect" [Undecided,Fix released] - Assigned to Jason Dunsmore (jasondunsmore)
16:43:07 gibi so in some crazy old deployment the db could contain a uuid
16:43:24 gibi old, mean existed for a long time but upgraded to new nova code
16:44:56 stephenfin gibi: We haven't let you create such a server in quite some time though https://github.com/openstack/nova/blob/bae8b1306eb/nova/compute/api.py#L532-L545
16:45:11 stephenfin What I'm getting at is that it doesn't seem like there's much point allowing the user to pass through an arbitrary string, since the users that can use it are vanishingly small
16:45:33 stephenfin So I wonder if we should just allow true/false and add a TODO that false doesn't actually work until that bug is fixed?
16:45:59 stephenfin specifically, we should use a '--[no-]config-drive' option pair
16:47:04 gibi the API allows now to send in any string in the query param config_drive, when we fix that we need to bump the API microversion. I guess that will be a good signal to change the client to only allow true/false to be passed
16:48:12 stephenfin True. The client doesn't have to match the server 100% though. We could limit the user client side, even if it's currently a free-for-all server side
16:48:39 gibi true
16:49:02 stephenfin I just think allowing '--config-drive foo' is daft, since no ones going to use it, and '--config-drive [True|False]' is worse than '--[no-]config-drive'
16:49:54 gibi I have to finish for today and we have like 2 days to land the client patches. I can look at it tomorrow again
16:50:20 stephenfin Yeah, me too. The dog's not going to walk itself :)

Earlier   Later