Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-08
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
13:33:01 mordred yeah
13:34:04 cdent \o/
13:34:12 mordred sometimes setup takes a little more work - but you get to test "does this payload from the server result in the correct object behavior in the client" - which is, of course, the thing you actually care about
13:34:27 mordred "Does layer 1 call hidden method 2" is completely useless to know
13:34:58 cdent that's the same spirit that drives gabbi, on the other side
13:35:27 mordred ++
13:35:28 dtantsur this file is awful indeed
13:36:32 mordred dtantsur: I keep wanting to rip out all of the unittests using it and replace them with requests-mock based tests- but it took us about 8 months to do that with shade and it was MINDNUMBING so I haven't gotten angry enough to do it with these yet
13:36:45 dtantsur right
13:37:30 dtantsur we could start with replacing it with mocking Session. it's not perfect, but tests much more.
13:37:41 dtantsur as you know, I tend to write my unit tests like that
13:38:41 mordred yeah - althuogh we've already got a Session in each unit test that is set up with requests-mock - like, the plumbing is all there, so we don't really even have to mock session
13:40:08 mordred with auth and catalogs already even! :)
13:40:24 mordred I think the real issue is that we need to dig in to "What is this test supposed to be testing"
13:54:43 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add logger to Proxy object https://review.openstack.org/650901
13:54:43 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Support microversion 2.61 for nova flavors https://review.openstack.org/650902
13:54:44 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: WIP Use resource layer for compute flavors https://review.openstack.org/650903
13:54:59 mordred that stack is a bit of a mess still - but it's getting close
14:47:45 elmiko dtantsur: hey, just saw the conversation
14:48:03 elmiko i would need to read more about mdns before giving an opinion, but is it something we want to promote across openstack?
14:48:16 dtantsur I don't think I want to promote it :)
14:48:20 elmiko lol
14:48:46 elmiko i guess that's my position re: new guidelines, is it something we think everyone /should/ be doing?
14:49:46 dtantsur I don't think everyone should. My thought was: if ppl other than ironic do it, maybe they should do it consistently.
15:07:38 elmiko ok, i can definitely get behind that
15:08:10 elmiko so perhaps this is more us setting a good example through the guidance to help generate consistency if needed?
15:13:15 dtantsur yeah
15:21:47 elmiko dtantsur: given all that, i think you've made a good case for writing something about it. no objection from me =)
15:22:09 dtantsur cool :) I'll try to be brief
20:23:55 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Support microversion 2.61 for nova flavors https://review.openstack.org/650902
20:23:56 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Use resource layer for compute flavors https://review.openstack.org/650903
20:24:26 mordred Shrews: look! ^^ using the resource layer for flavors!
#openstack-sdks - 2019-04-09
07:47:36 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Update compute.server resource https://review.openstack.org/650868
09:27:53 gtema mordred: in the image is it intended/desired (currently, and not in shade) to keep owner_specified.openstack.md5 in the root of the image, or under properties?
09:28:22 gtema it is currently done in the root of the image, but I guess make sence to move it under properties
09:29:00 gtema otherwise my change for allowing extending resource is required to properly use resource in the proxy layer
09:30:29 openstackgerrit Vishakha Agarwal proposed openstack/keystoneauth master: Update the min version of tox https://review.openstack.org/651149
10:43:59 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Update compute.server resource https://review.openstack.org/650868
11:09:50 openstackgerrit Thomas Bechtold proposed openstack/openstacksdk master: baremetal: Add support for mkisofs and xorrisofs for configdrive https://review.openstack.org/651193

Earlier   Later