| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-30 | |||
| 13:51:36 | figleaf | fried_bunny: true, true. It's the imagery that I like | |
| 13:51:40 | cdent | the french police are coming to arrest bauwser for working on an official holiday | |
| 13:51:41 | bauwser | with a 's' please | |
| 13:51:42 | figleaf | fried_bunny: moreso than a figleaf | |
| 13:51:53 | bauwser | cdent: it"s not a holiday here | |
| 13:51:55 | bauwser | so I'm sane | |
| 13:52:11 | fried_bunny | zorry bauwzer | |
| 13:52:24 | bauwser | YES, NOT ALL CELEBRATIONS ARE DAY OFF IN FRANCE | |
| 13:52:32 | fried_bunny | Only French ones. | |
| 13:52:37 | bauwser | well, actually, it's untrue | |
| 13:52:46 | bauwser | part of our country is off today | |
| 13:52:50 | cdent | I got so much crap from a german colleague yesterday because I was unaware that today was commonly a holiday in europe | |
| 13:52:55 | cdent | part? that's bound to be confusing | |
| 13:53:16 | bauwser | only the Alsace region ;) | |
| 13:53:31 | bauwser | we're a very centralized country except for Alsace :) | |
| 13:53:34 | cdent | that explains it: this person is in the german part near there | |
| 13:54:09 | bauwser | well, I live 100 kms away from Swiss | |
| 13:54:15 | bauwser | should I take that day off then ? | |
| 13:54:32 | dims | bauwser : ask long ask you can ski :) | |
| 13:54:36 | bauwser | after all, it's near | |
| 13:54:44 | bauwser | dims: planned for Monday \o/ | |
| 13:54:49 | bauwser | because Monday will be off for me | |
| 13:54:50 | dims | haha | |
| 13:55:07 | bauwser | last chances for a decent skiing session | |
| 13:58:08 | bauwser | fried_bunny: https://review.openstack.org/#/c/557065/ so I guess you're asking me to use a specific YAML file just for that ? :( | |
| 13:58:19 | bauwser | fried_bunny: have you seen my counter proposal ? | |
| 13:59:30 | bauwser | honestly, given the lack of consensus around a conf option (which I didn't expected at the beginning), I feel I'm about to make the pre-creation of a mediated device a prerequisite for supporting multiple types | |
| 14:00:02 | bauwser | if config management systems feel like it's difficult, then we could spec up again on a common format | |
| 14:00:29 | fried_bunny | bauwser: Yes, a YAML file which, for now, will contain *some* kind of specification from which you can glean which PCI addresses correspond to allowable devices (so, a whitelist) and which type (eventually types) they support. This will expand as needed to incorporate anything libvirt-device-related. | |
| 14:01:00 | bauwser | fried_bunny: out of oslo.config then | |
| 14:01:07 | fried_bunny | bauwser: Absolutely. | |
| 14:01:15 | fried_bunny | As I stated, oslo_config for JSON/python dicts is ick. | |
| 14:01:42 | fried_bunny | bauwser: So if by counter-proposal, you mean the other oslo_config-based JSON format you suggested - yes, I saw it, and it doesn't change my mind :) | |
| 14:02:01 | bauwser | fried_bunny: okay, let's wait for a couple of other folks to chime in on the spec (and in particular, leave dansmith voice on your counter proposal), and see what we agree on | |
| 14:02:20 | fried_bunny | bauwser: Sounds like a plan. | |
| 14:02:40 | bauwser | if we can't settle down on a consensus around a format, I'll abandon my spec and make pre-creations of mediated devices a necessary prerequisite for multiple types support | |
| 14:03:12 | bauwser | that would suck for many operators, but we could engage a conversation about the best formatting for them at the Summit | |
| 14:04:20 | fried_bunny | bauwser: Part of my dislike for doing this in conf options is based on my exerience trying to understand pci_passthrough_whitelist. It took me weeks of trial and error to figure out the punctuation/formatting to make it work. And I never got to a point where I actually *understood* what I was doing - just to a point where I had something that worked for my use case. | |
| 14:04:47 | fried_bunny | I'll grant you that's an extreme case... but what you're proposing is going to get to that point of complexity very quickly anyway. | |
| 14:04:55 | bauwser | fried_bunny: I agree | |
| 14:05:36 | fried_bunny | bauwser: We did begin discussions of this YAML thing in Denver, so it's not completely out of left field. | |
| 14:05:38 | bauwser | you know, proposing that spec with that proposal is like when you have a terrible kid but you still love it | |
| 14:05:52 | bauwser | because it's your kid | |
| 14:06:06 | fried_bunny | I know *exactly* what you mean. | |
| 14:06:23 | bauwser | so I'm not like super excited by any solution to a problem that is unrelated to nova | |
| 14:06:38 | leakypipes | fried_bunny: a YAML file eh? sounds suspiciously like my provider-config-file proposal. | |
| 14:06:48 | bauwser | leakypipes: context is https://review.openstack.org/#/c/557065/ | |
| 14:06:54 | bauwser | leakypipes: I mentioned your spec :) | |
| 14:07:09 | fried_bunny | leakypipes: Well, IIRC you were the one who said YAML in Denver for device spec files. So I call no coincidence. | |
| 14:07:36 | bauwser | that's also in the gerrit comments, with appropriate credits ;) | |
| 14:08:09 | fried_bunny | leakypipes: I'm glad to give you the affirmation that IMO it's an excellent idea. | |
| 14:08:10 | bauwser | fried_bunny: unrelated, using unregistered IRC nicks is dangerous :p | |
| 14:08:31 | fried_bunny | bauwser: Like actually dangerous? Cause the only one I have registered is efried... | |
| 14:08:50 | fried_bunny | Oh, *that* kind of dangerous? Meh, I can live with that. | |
| 14:08:58 | bauwser | ok, so fried_rice is registered, good. | |
| 14:09:04 | fried_bunny | oh, is it, cool. | |
| 14:09:16 | fried_bunny | It might not be registered to me, actually. | |
| 14:09:21 | fried_bunny | shrug | |
| 14:09:41 | fried_bunny | Anyone pretending to be me... deserves what they get :D | |
| 14:10:16 | bauwser | indeed, it's not registered to your main account | |
| 14:11:05 | bauwser | but fried_chicken isn't ;) | |
| 14:11:29 | bauwser | oops, I meant fried_bunny | |
| 14:12:19 | fried_bunny | bauwser: fried_bunny is just for today. Maybe through Monday (that's still an Easter thing, right?) | |
| 14:12:42 | bauwser | Easter for us is on Monday | |
| 14:13:00 | bauwser | Good Friday has nothing to do with egs | |
| 14:13:02 | bauwser | eggs | |
| 14:18:38 | fried_bunny | claudiub: in case you're still around, just posted some comments on https://review.openstack.org/#/c/141219/ which should be easy to rev. | |
| 14:20:02 | fried_bunny | bauwser: Oh, you see, in the US, the entire month preceding Easter Monday gets completely overrun with bunnies and eggs and garish plastic grass and hideous pastel colors. It's how we capitalist pigs roll. | |
| 14:22:19 | bauwser | haha | |
| 14:25:58 | leakypipes | bhagyashris: you do not want to specify parent_provider_uuid for your compute node. | |
| 14:26:11 | leakypipes | bhagyashris: the shared storage pool is not the parent of the compute node. | |
| 14:26:54 | leakypipes | bhagyashris: the relationship between the shared storage pool and the compute node is via the aggregate, not via a parent-child relationship. | |
| 14:27:31 | leakypipes | bhagyashris: I'm not sure that we support "re-parenting", so you may need to delete the resource provider records in your placement DB entirely and start over. | |
| 14:27:52 | bhagyashris | leakypipes: ok. through aggregate also i have tried and tested but still it's not taking DISK_GB from shared resource provider | |
| 14:27:59 | leakypipes | bhagyashris: alternately, you could just execute an UPDATE statement directly in the placement DB to fix the provider records up. | |
| 14:28:46 | leakypipes | bhagyashris: UPDATE resource_providers SET parent_provider_id = NULL, root_provider_id = $INTERNAL_ID_OF_COMPUTE_NODE WHERE id = $INTERNAL_ID_OF_COMPUTE_NODE; | |
| 14:29:54 | leakypipes | bhagyashris: allocations definitely do not yet work when nested providers are present. there may be a bug regarding sharing resource providers, but let's eliminate the nested scenario for starters, ok? | |
| 14:33:28 | bhagyashris | leakypipes: you mean to say I will need to update the compute node resource provider | |
| 14:34:09 | leakypipes | bhagyashris: correct. | |
| 14:35:40 | bhagyashris | leakypipes: and on current master the shared resource provider provider is not implemented completely i mean to say that is not taken into account when user rquest to boot the instance | |
| 14:36:09 | leakypipes | bhagyashris: yes, it should be. | |
| 14:36:56 | leakypipes | bhagyashris: or at least, if the *only* provider of DISK_GB is the shared storage pool (and the compute node doesn't itself have local disk), then everything should work... | |
| 14:37:26 | leakypipes | bhagyashris: there is currently a bug where if both the local compute node and a shared pool have DISK_GB resources, that we will always pick the local compute node. | |
| 14:38:11 | leakypipes | bhagyashris: tetsuro has been fixing that bug in this patch: https://review.openstack.org/#/c/533396/ | |
| 14:38:36 | bhagyashris | leakypipes: aI have debug the code as well and observed that the when user request the boot server then only the compute node resource provider allocation_candidates are return so from that it seems like the shared resource provider is not taken into account while scheduling. | |
| 14:40:11 | leakypipes | bhagyashris: when both the compute node and the shared pool have inventory of DISK_GB, right? | |
| 14:40:23 | leakypipes | bhagyashris: and I'm saying that that is a known bug. | |
| 14:40:30 | leakypipes | bhagyashris: being addressed in https://review.openstack.org/#/c/533396/ | |
| 14:40:41 | bhagyashris | leakypipes: yes | |
| 14:41:38 | bhagyashris | leakypipes: ok. this patch will help me to success my test scenario :) | |
| 14:42:12 | leakypipes | bhagyashris: would be awesome if you were able to apply that patch locally and see if that resolves your issues. | |
| 14:42:16 | leakypipes | bhagyashris: :) | |
| 14:42:37 | claudiub | fried_bunny: done, thanks. :) | |
| 14:43:46 | leakypipes | stephenfin, mriedem, dansmith, fried_bunny, melwitt: reviews on the three bottom patches of the patches here from tetsuro would be appreciated: https://review.openstack.org/#/c/533396/ | |
| 14:43:59 | fried_bunny | leakypipes: ack | |
| 14:44:05 | leakypipes | danke | |
| 14:44:16 | leakypipes | fried_bunny: 10-4 good bunny. | |
| 14:44:27 | fried_bunny | leakypipes: I'm +1 on the bottom one already FYI | |
| 14:45:08 | leakypipes | cool, thanks | |
| 14:45:30 | fried_bunny | claudiub: have you posted the rev yet? | |