Earlier  
Later
New Search
Posted Nick Remark
#openstack-sdks - 2019-03-28
16:04:18 elmiko hehe =)
16:04:38 elmiko maybe we could re-state our position about guidelines growing out of needs in the community where gaps are found?
16:04:54 elmiko a call to action for anyone who might have a need
16:04:54 ricolin edleafe, #2 it's still something we encourage people to put in since that doc itself just recently created
16:05:33 edleafe ricolin: as elmiko mentioned, we don't have a lot of activity that we undertake
16:06:06 edleafe We are here these days mostly for clarification of existing guidelines, filling in missing things, and adjudicating API disputes
16:06:38 edleafe We've tried to act as a guiding force for SDKs, but none have really stepped up to work with us
16:07:03 ricolin The help most needed also can point to some features/help that you think it's really really important but just can't get projects to join
16:07:39 elmiko imo, the help most needed might just be a call for more folks to consider what the sig has done and reach out to us if questions arise
16:07:42 edleafe ricolin: sure, but as elmiko said, we are more of a responsive group to the community
16:08:19 elmiko i'm fine with pushing more a message as the "what do we need help with" as opposed to asking for direct help on something that doesn't quite exist
16:08:25 edleafe If the community isn't clamoring for API guidance, well, we aren't going to just do things to keep busy
16:08:32 elmiko ++
16:08:53 edleafe elmiko: sounds like you're volunteering to add something for #2
16:09:04 elmiko i'll give it my best =)
16:09:38 elmiko assuming ricolin is ok with the approach i am talking about
16:09:59 edleafe As far as #3 is concerned, I don't really see our work as being suitable for a community goal. Thoughts?
16:10:04 ricolin edleafe, I don't think to list out needed most means you have to put yourself in that action. It might be some statement/goal for other teams to know that the community should reach
16:10:53 elmiko community goal is definitely for folks to know about the guidelines, and how to reach out for help when needed
16:11:06 elmiko so, i could see 2 and 3 intermingling a little
16:11:14 ricolin elmiko, yes, I'm totally okay:) this should be whatever SIG itself needs or a suggestion goal from SIG to community
16:11:29 elmiko ok, cool
16:11:51 edleafe I see community goals as something that the TC is leading because OpenStack needs to do it. Moving to Python3 is a great example. But we've clearly stated that we do not expect teams to change their existing APIs to match the guidelines; in fact, we would consider that a very bad thing
16:12:31 elmiko ++, awareness and spreading knowledge have always been our pillars, we don't advocate for action in the project teams
16:12:49 elmiko (unless asked)
16:14:18 elmiko well, i guess, edleafe should you and i take some actions to get these filled out by next week?
16:14:25 mordred edleafe, elmiko: with the exception of when there is something _Additional_ we'd like for everyone to add to their api that can be done in a backwards compatible manner
16:14:49 elmiko that's a good call out mordred
16:15:00 mordred (that being a time when a community goal *could* emmanate from api-sig work - but I generally agree, it's not the primary or normal output
16:15:06 edleafe preach, brother mordred!
16:15:48 gtema ++
16:16:07 elmiko hahaha
16:24:04 elmiko ricolin: looking at https://etherpad.openstack.org/p/community-goals i am really not feeling that our group's activity merit an entry there
16:24:26 openstackgerrit Merged openstack/openstacksdk master: Add image.service_info resources https://review.openstack.org/638227
16:25:01 elmiko i feel like our community goal is "make sure everyone knows where the api guidelines are at and how to get help" does not seem to fit the same level of completion that the others have
16:25:41 ricolin elmiko, That's fine if we don't think any of API SIG goal match community goal (request #3)
16:26:55 elmiko ricolin: i will read through the "help most needed" list to see if we have an addition to propose
16:27:45 elmiko edleafe: you are going to reply with the info from item 1 ?
16:28:03 edleafe elmiko: typing it up as we speak
16:28:09 elmiko edleafe++
16:30:53 edleafe Sent!
16:31:05 edleafe ...and we're only halfway through the office hour! :)
16:31:27 elmiko so productive!
16:31:30 ricolin edleafe, that's quick:)
16:32:12 cdent api-sig, can you guys help me automate translating the placement api to graphql or grpc? this http rest-like stuff is too old
16:32:17 edleafe Hey, we don't mess around!!
16:32:37 cdent or soap
16:32:49 elmiko whoo-boy, that's a big ask cdent
16:33:05 mordred cdent: grpc ftw
16:33:17 elmiko might i propose a binary socket with completely custom message types? have you considered that approach?
16:33:21 cdent I only want it if I can automate
16:33:25 dustinc so I have been working on moving Nova-Ironic interaction from using the ironicclient to using the SDK and have found a lot of funkiness in field mapping between client/SDK/API
16:33:28 edleafe cdent: first print it out onto punched cards...
16:33:44 mordred dustinc: you can blame me for a lot of that
16:34:01 dustinc good to know, but not here to lay blame :)
16:34:05 mordred dustinc: :)
16:34:10 elmiko cdent: i do have a project for arbritrary code generation from openapi specs
16:34:19 dustinc just hoping to get some insight on how best to solve this
16:34:56 dustinc http://paste.openstack.org/show/bKnExS60mZXtsBAFgSgJ/
16:34:59 dustinc those are my notes
16:35:54 elmiko what are the issues you are having trouble with?
16:35:56 dustinc my main concern is that currently we pass kwargs off to the client with any keys we didn't pick up, which means that somewhere there may be existing code using the key names in client that would cause issues if we dropped in SDK without some sort of wrapper or something to fix the key names
16:36:14 mordred dustinc: for things where the sdk is missing something, it's easy - we should add the things that are missing
16:37:01 dustinc there are basically 2 or 3 things missing from SDK, but the issue I am seeing is the mismatched key names
16:37:05 dustinc *biggest
16:37:07 mordred for things where the names are different ... that's a bit trickier and we should probably think about the best way to handle it
16:37:10 dtantsur edleafe: sorry, has to run to the post office to fetch the lost delivery
16:37:14 dustinc https://www.irccloud.com/pastebin/M8AuozRG/
16:37:26 mordred but basically dtantsur can solve all of the problems just by being magical
16:37:32 elmiko good luck dtantsur !
16:38:31 dustinc I *could* just put use a map to convert them, but that's obviously not ideal
16:38:38 dustinc and really shouldn't make it through code review ;)
16:39:14 mordred yeah - it's a thing where I'd love to be able to capture things appropriately if it's a general problem
16:39:44 dtantsur Things like instance_id vs instance_uuid and maintanance vs is_maintenance are by design..
16:39:51 mordred in general, the sdk already knows how to map the server-side names of things to the sdk property name (has to be able to do a bi-directional mapping to be able to deal with the server json)
16:39:52 dustinc are they?
16:39:56 mordred yes
16:40:31 dtantsur I mean, it sucks that ironic uses uuid where many services use id.. but it's a bit too late to change.
16:40:33 dtantsur "a bit"
16:40:48 dtantsur and SDK-level consistency is the very reason openstacksdk exists and we're migrating to it
16:40:52 dustinc ok that is good to know...I am pretty new to stack and didn't even realize those were different
16:40:57 mordred the sdk strives for consistent parameter names across the sdk vs. being consistent with the remote json names - so for instance booleans start with verbs - and then the ironic id vs. uuid thing
16:41:02 mordred yeah. what dtantsur said in less words
16:41:12 dustinc ok I see
16:41:21 edleafe dtantsur: you could be like nova that uses both a uuid and an id :)
16:41:46 mordred but - since I think the sdk already knows how to deal with remote server-side names, if you're dealing with **kwargs things we shold PROBABLY be able to figure out some way to have the sdk understand what you're wanting to do
16:41:52 dtantsur edleafe: does it? O_o
16:42:06 mordred edleafe: you're purposefully trying to hurt our brains :)
16:42:42 edleafe Unfortunately, that got carried into placement as well. :(
16:43:31 dtantsur \o/
16:44:01 mordred dustinc: we may not be helping a ton here
16:45:30 dtantsur I'm not sure it really blocks the migration, but I do agree it can be confusing
17:00:44 elmiko catch ya later folks, have a good weekend =)
17:03:01 openstackgerrit Artem Goncharov proposed openstack/openstacksdk master: Cleanup split of openstackcloud https://review.openstack.org/648435
17:26:45 openstackgerrit Ian Y. Choi proposed openstack/openstacksdk master: DNM - Start building pdfs of docs https://review.openstack.org/601659
17:54:15 openstackgerrit Merged openstack/openstacksdk master: Make PATCH a first class operation and support it for baremetal https://review.openstack.org/647730
18:30:09 elmiko edleafe++ i like your response to the email
18:30:41 edleafe elmiko: well sure, because I spelled your nick correctly. :)
18:34:56 elmiko LOL
20:23:12 dustinc ubnt 8-port

Earlier   Later