Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-04-08
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 cdent it's a sickness, a bit like heroin addiction
13:32:59 mordred *basically* I think that's used to verify that self._list is called
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: Support microversion 2.61 for nova flavors https://review.openstack.org/650902
13:54:43 openstackgerrit Monty Taylor proposed openstack/openstacksdk master: Add logger to Proxy object https://review.openstack.org/650901
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
11:19:13 openstackgerrit Thomas Bechtold proposed openstack/openstacksdk master: baremetal: Add support for mkisofs and xorrisofs for configdrive https://review.openstack.org/651193
12:44:35 openstackgerrit Dmitry Tantsur proposed openstack/api-sig master: Add guideline on DNS-based service discovery https://review.openstack.org/651222
12:44:40 dtantsur mordred, elmiko, cdent, edleafe, and here we go ^^^
12:44:58 mordred dtantsur: I was hoping it would be one line "use dns"
12:45:06 dtantsur lol
12:45:18 edleafe dtantsur: thanks - will get to it soon
12:45:42 dtantsur mordred: I think it covers both regular DNS and mDNS pretty nicely and in line with IETF
12:47:36 mordred dtantsur|brb: ooh - I likey
12:47:56 mordred dtantsur|brb: thanks for writing that - it's very clear and not at all hard to understand
12:48:40 elmiko dtantsur|brb: ack, i will take a look
12:50:00 gtema yey, like it also
13:12:27 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?
13:12:41 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Update compute.server resource https://review.openstack.org/650868
13:12:51 gtema and basically any other unknown property
13:13:14 mordred gtema: I'm more of a fan of putting it into properties
13:13:27 mordred gtema: even though I know the v2 api puts unknown stuff in the root of the image
13:14:16 gtema I also like this approach, but then I would need to mess around with finding unknown props and doing "lots" of changes in tests
13:14:30 gtema good, will go this way then
13:14:53 mordred cool. let me know if I can help poke at the magic :)
13:15:09 gtema ;-)
13:15:09 mordred I think there is a comment in Resource about "should we do something with these unknown things"
13:15:48 gtema yeah, I think it would make sense to return back list of unmapped props to know them in the caller
13:17:20 gtema hmm, does it make sense to implement this in general in Resource to put everything unknown under properties (if such prop exists)?
13:20:39 gtema mordred: or at least creating special flag to do this?
13:22:29 mordred gtema: yes - I think so - it would make it easier for the cloud-layer integration which does this already
13:22:47 gtema oki
14:38:09 openstackgerrit Thomas Bechtold proposed openstack/openstacksdk master: baremetal: Add support for mkisofs and xorrisofs for configdrive https://review.openstack.org/651193
14:53:16 openstackgerrit Dmitry Tantsur proposed openstack/api-sig master: Repair building guidelines https://review.openstack.org/651260

Earlier   Later