| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-30 | |||
| 13:28:08 | dims | bauzas : http://169.254.169.254//openstack/2012-08-10/meta_data.json shows the ("name": "\u00dcmlauts rule!") | |
| 13:29:18 | dims | bauzas : the ec2 metadata format does not have anything else i could use | |
| 13:29:45 | bauzas | dims: what I don't know is which API resource is calling openstack server show | |
| 13:30:13 | bauzas | because the only GET /servers/<server> takes an UUID AFAIK | |
| 13:30:27 | bauzas | https://developer.openstack.org/api-ref/compute/#show-server-details | |
| 13:30:46 | bauzas | so I guess it's calling the list command https://developer.openstack.org/api-ref/compute/#list-servers | |
| 13:31:02 | bauzas | wait, looking at the code | |
| 13:32:49 | bauzas | https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L434 | |
| 13:33:43 | dims | bauzas : gotcha. thanks for the pointer, i will go look further and get back if i need something else | |
| 13:34:30 | bauzas | dims: I can look at the OCS code | |
| 13:34:36 | bauzas | OSC | |
| 13:35:02 | dims | bauzas : no worries, i can do that | |
| 13:35:21 | cdent | fried_bunny: if you're cruising through my stuff at the moment, hold off on the forbidden traits, I'm fixing the pep8 issue right now, should be fixed in mere moments | |
| 13:35:47 | fried_bunny | cdent: Okay, was just commenting on that. Bizarre one - did we just instate that rule or something? | |
| 13:35:58 | fried_bunny | I've never seen pep complain about redef of a var before. | |
| 13:36:14 | cdent | I've had a few new things show up lately, so I'm guessing flake8 had an update recently | |
| 13:36:15 | fried_bunny | my IDE complains about it | |
| 13:36:34 | fried_bunny | Mm. And/or possibly we moved to using py3 for pep now? | |
| 13:36:42 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Filter allocation candidates by forbidden traits in db https://review.openstack.org/556660 | |
| 13:36:42 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Filter resource providers by forbidden traits in db https://review.openstack.org/556472 | |
| 13:36:43 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Support forbidden traits in API https://review.openstack.org/556820 | |
| 13:36:43 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Parse forbidden traits in query strings https://review.openstack.org/556819 | |
| 13:36:48 | cdent | there go | |
| 13:37:44 | bauzas | dims: https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/v2/server.py#L1964 | |
| 13:38:15 | dims | bauzas : perfect! you have been very helpful | |
| 13:38:22 | bauzas | looks like it calls list | |
| 13:38:44 | bauzas | but I could be wrong | |
| 13:39:10 | fried_bunny | cdent: All done, looking clean. | |
| 13:39:14 | dims | bauzas : will run it in debug and find the urls it is hitting | |
| 13:39:36 | bauzas | dims: if that's calling the GET /servers directly for a list command, then look at the API doc https://developer.openstack.org/api-ref/compute/#list-servers | |
| 13:39:55 | bauzas | dims: for 'hostname', it says " Filter the server list result by the host name of server. This parameter is only valid when specified by administrators. If non-admin users specify this parameter, it is ignored." | |
| 13:40:05 | bauzas | dims: I guess you're keystone-admin'd | |
| 13:40:07 | bauzas | ? | |
| 13:40:12 | dims | bauzas : yep | |
| 13:40:19 | bauzas | k, wanted to make sure | |
| 13:40:42 | bauzas | but then, it takes the real instance hostname, not the sanitized one | |
| 13:40:45 | bauzas | hence the 404 | |
| 13:41:10 | bauzas | what you could do is to query on the private IP | |
| 13:41:37 | dims | good point | |
| 13:42:03 | bauzas | dims: there is also a 'name' param that support regexes | |
| 13:42:51 | bauzas | anyway, /me goes reviewing things now | |
| 13:44:53 | dims | thanks much bauzas ! | |
| 13:49:42 | figleaf | fried_bunny: you win the good casual friday nick contest! | |
| 13:50:07 | fried_bunny | figleaf: Thanks. It was a tossup between that and good_fried_ay, but I wanted people to still be able to find me. | |
| 13:50:45 | fried_bunny | figleaf: Also this one expresses subtle disdain for the various institutions that make this day different from any other. | |
| 13:51:06 | bauzas | oh shit | |
| 13:51:26 | bauzas | tss tss | |
| 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... | |