| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2019-04-08 | |||
| 10:49:08 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Improve error message for version_kwargs mismatch https://review.openstack.org/650845 | |
| 10:49:15 | mordred | dtantsur: ^^ fixed your suggestion in a followup | |
| 10:52:39 | ITD27M01 | mordred: Thank you, I am in the process of understanding. | |
| 10:54:52 | openstackgerrit | Monty Taylor proposed openstack/openstacksdk master: Fix get_server to work with use_direct_get https://review.openstack.org/540389 | |
| 11:03:07 | gtema | mordred: I'm currently working on switching Image in OSC from glanceclient to SDK and found, that OSC has a use-case to only create "placeholder" for image without data. | |
| 11:03:13 | dtantsur | thanks mordred | |
| 11:03:33 | gtema | we currently do not "support" that in SDK. Any thoughts? Simply implement? | |
| 11:06:39 | mordred | gtema: you can't just create an Image resource? | |
| 11:06:53 | mordred | gtema: oh - you mean a remote image without uploading data to it yet? | |
| 11:07:06 | gtema | well, you can, but currently with a deprecated warning | |
| 11:07:29 | gtema | yes. We have create_image method, but it throws deprecated warn | |
| 11:07:49 | gtema | coming from cloud restruct | |
| 11:08:43 | mordred | yeah - I don't see any reason to not support doing that | |
| 11:08:55 | gtema | ok, will implement it then | |
| 11:08:57 | mordred | that said -upload image should be the deprecatred one and create_image should be the good one | |
| 11:09:38 | gtema | P.S. would be then very good to get it released soon not to block OSC switch | |
| 11:09:49 | mordred | ++ | |
| 11:10:11 | gtema | ack. In work :D | |
| 11:13:56 | ITD27M01 | gtema: If I understand it correctly the "metadata" of server currently cannot be used for API-side filtering. Only those items that described at the link I have provided. Is your question about this? | |
| 11:14:58 | gtema | I mean I understood your message, that you miss some filtering capabilities in nova. I was asking - which. If you only mean 'metadata' - ok | |
| 11:16:52 | ITD27M01 | gtema: Yes, metadata. | |
| 11:17:16 | gtema | ok, got it | |
| 11:39:17 | openstackgerrit | LIU Yulong proposed openstack/openstacksdk master: Add floating IP port forwarding related methods https://review.openstack.org/650063 | |
| 11:43:07 | mordred | gtema: do we have support in Resource for listing two different remote keys that a field MIGHT be? | |
| 11:43:52 | gtema | not as I know | |
| 11:44:12 | mordred | ok. fiddle. | |
| 11:44:35 | gtema | you mean sdk_name vs remote_name? | |
| 11:44:44 | mordred | I mean over time there are two possible remote names | |
| 11:45:00 | mordred | for instance, extra_specs vs. OS-FLV-WITH-EXT-SPECS:extra_specs | |
| 11:45:20 | gtema | btw, wait with server - I will push in a minute refresh with new attrs, complete query_params | |
| 11:45:23 | mordred | OS-FLV-WITH-EXT-SPECS:extra_specs being teh old name from an old nova extension - extra_specs being the current name | |
| 11:45:39 | mordred | gtema: cool. | |
| 11:45:49 | mordred | gtema: I'm going to start thinking about the caching layer soon | |
| 11:46:04 | gtema | ah, so you mean basically multiple remote attr names for single sdk attr | |
| 11:46:24 | gtema | great | |
| 11:46:25 | mordred | yeah. obviousl will only work sanely for read - not for write | |
| 11:46:34 | gtema | sure | |
| 12:06:58 | openstackgerrit | Artem Goncharov proposed openstack/openstacksdk master: Update compute.server resource https://review.openstack.org/650868 | |
| 12:41:44 | mordred | gtema: left a couple of comments - only the microversion one is important (and dtantsur|brb - check me that I'm right about that) | |
| 12:42:31 | gtema | mordred: ok, thanks | |
| 12:48:50 | dtantsur | mordred: you're right about that | |
| 12:49:39 | dtantsur | API SIG folks, mordred, cdent, elmiko, edleafe, would you be interested in a guideline on discovering openstack API endpoints with mdns? | |
| 12:50:49 | cdent | dtantsur: are you using that? | |
| 12:51:01 | edleafe | dtantsur: um, I don't have a lot of experience (read: any experience) with mdns. What would be the main advantage? | |
| 12:51:05 | dtantsur | cdent: I have an ask to add discovery of ironic API via mdns | |
| 12:51:46 | dtantsur | it could replace endpoint_override for standalone inter-service interaction, but my use case is a bit more specific: | |
| 12:52:00 | cdent | \o/ | |
| 12:52:12 | dtantsur | we have a ramdisk in ironic that has to talk back to ironic and/or ironic-inspector on booting | |
| 12:52:31 | cdent | it does rather make sense in that context | |
| 12:52:40 | dtantsur | to do that, it needs to know ironic URL (keystone service catalog is out of question, we don't have credentials, and probably don't have access to keystone at all) | |
| 12:52:42 | cdent | but in others, now so sure | |
| 12:52:53 | cdent | s/now/not/ | |
| 12:53:28 | dtantsur | currently we pass the ironic URL via kernel command line when PXE booting. works, but is somewhat annoying. | |
| 12:53:55 | dtantsur | now people want to do things like pre-flashing ironic ramdisk to hard drives or using a flash drive with ironic or something | |
| 12:54:04 | dtantsur | no PXE here, no way to pass kernel params | |
| 12:54:23 | dtantsur | okay, this was the background. the question for this channel is whether it's something we're interested to provide guidance one | |
| 12:54:38 | cdent | I think I'd wait | |
| 12:55:02 | cdent | if you get two people wanting to do something, then's the time for guidance? | |
| 12:55:12 | dtantsur | right, okay | |
| 12:55:16 | edleafe | It does sound more like a "how to" than a guideline | |
| 12:55:33 | dtantsur | well, there is at least a question of providing a standard service fqdn | |
| 12:55:50 | dtantsur | e.g. ironic._http._tcp or openstack-baremetal._http._tcp or something more complex | |
| 12:56:04 | dtantsur | (I'm still looking at subtypes to have something like baremetal._http._tcp._openstack) | |
| 12:56:14 | dtantsur | TheJulia: if you're curious ^^^ | |
| 12:56:48 | TheJulia | curious and interested... and have 3 hours of meetings ahead of me | |
| 12:56:57 | dtantsur | ouch :( | |
| 12:57:05 | edleafe | OK, the fqdn does sound like a good candidate for guidance, so that various services don't implement contrary designs | |
| 12:57:18 | dtantsur | right | |
| 12:58:41 | cdent | I'm still curious if we can up with a situation where something other than Ironic would find this useful (I suspect we can, but I'm not thinking of it off the top of my head) | |
| 12:59:12 | cdent | That is: it's not something we'd want to encourage as "the other way of getting endpoints" because having two ways would be tireseome, presumably? | |
| 12:59:28 | mordred | oh my- many scrollbacks | |
| 12:59:45 | cdent | nope, I got nothing | |
| 13:00:41 | mordred | dtantsur: hrm. interesting | |
| 13:01:42 | mordred | dtantsur: so - we've got the well-known url entry (Which we really need to advertise more) for finding the keystone auth_url - I don't think that helps here though. .. HOWEVER | |
| 13:02:51 | mordred | if we built off of that so that the base URL/domain one would be doing a well-known url check on would similarly be the domain on which the SRV record would be looked up on - then that might not be super terrible | |
| 13:03:16 | mordred | I'd _definitely_ go with service-type keys rather than name though - baremetal._http._tcp vs ironic | |
| 13:04:00 | mordred | dtantsur: also - jamielennox started some work in keystoneauth AGES ago to be able to look things up optionally using dns | |
| 13:04:36 | cdent | (yeah, I was kind of taking service-type (not name) for granted) | |
| 13:05:25 | mordred | https://review.openstack.org/#/c/223429/ | |
| 13:05:49 | dtantsur | mordred: but how do we know *any* URL? (esp. if we don't have keystone, but we can assume we do for the sake of the exercise) | |
| 13:06:11 | mordred | dtantsur: ^^ might be worth looking at - it's more about finding auth_url - and we wound up using well-known for that | |
| 13:06:52 | dtantsur | ah, so you lookup for _openstack_keystone | |
| 13:06:55 | mordred | dtantsur: yeah - totally - I could see using mDNS for finding a root domain for local things - but sort of just thinking through it | |
| 13:07:51 | dtantsur | btw why _openstack_keystone, not just _openstack? | |
| 13:08:03 | mordred | yeah - but I agree - there's a different use case for "I'm inside of a firewall looking for the local ironic" - and "I'm looking for the auth_url to a cloud that I know is over there" | |
| 13:09:04 | mordred | dtantsur: agree. I think since the well-known url location is /.well-known/openstack/api ... then finding the auth_url via SRV record, if we supported that, would want to jst look for _openstack | |
| 13:09:44 | mordred | but then, I think given your usecase, a SRV record for _baremetal._openstack would be potentially nice - but it still requires pre-knowing a domain | |
| 13:10:35 | mordred | which would be where an mDNS option would come in I'd guess | |
| 13:12:30 | mordred | dtantsur: I think this _is_ a thing where we should consider a holistic design - because for sanity sake client-side support for it as an alternate endpoint finding method would want to go into keystoneauth | |
| 13:12:41 | mordred | given where in the stack doing these actions happens | |
| 13:13:16 | mordred | which means at the very least agreeing to and defining a protocol for it - even if ironic is the one one that implements it server-side for now | |
| 13:13:40 | dtantsur | our ramdisk doesn't use keystoneauth, otherwise I agree | |
| 13:14:15 | dtantsur | I will think more about it when I don't have to listen to a meeting :( | |
| 13:16:22 | mordred | dtantsur: fair enough re: ramdisk | |
| 13:16:50 | mordred | dtantsur: it sounds like a thing that would be a nice usability feature for ironic users anyway though - so I think definitely worth more discussion | |
| 13:27:24 | mordred | zomg | |
| 13:29:55 | dtantsur | ++ | |
| 13:32:34 | mordred | there is some really complicated testing that the mock system mocks the things that were mocked and some really tiny slices of the behavior work correctly when the rest of the stack is mocked out | |
| 13:32:59 | mordred | *basically* I think that's used to verify that self._list is called | |
| 13:32:59 | cdent | it's a sickness, a bit like heroin addiction | |