| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-07-04 | |||
| 09:28:52 | seanhandley | I think it's a separate issue flanders_ | |
| 09:29:10 | seanhandley | ultimately the problem was bad design in the fog-openstack code | |
| 09:29:16 | flanders_ | Aok | |
| 09:29:48 | seanhandley | So to give a bit of backstory on how I currently use Fog in my app | |
| 09:30:01 | carthaca | reacting to token-expiry got better in fog, but still it is a bit of work you would have to do on top | |
| 09:30:03 | flanders_ | Just making sure we shouldn't be highlighting any issues up to the API user team a la Clarke and Rocky. | |
| 09:30:24 | seanhandley | I find the model layer is useful as it lets me represent OpenStack resources as Ruby objects and so my client code is a lot cleaner | |
| 09:30:45 | seanhandley | the problem with dealing with JSON directly is you end up wrangling the nested data structure | |
| 09:30:59 | seanhandley | so it's nice to have a model layer that knows how to parse those structures | |
| 09:31:22 | seanhandley | Though I guess it'd be possible to use OpenStruct for that? | |
| 09:32:47 | carthaca | well to the API on expired tokens: I sometimes see an "401 not authorized" and sometimes a "404 token not found" from the services, I would have to look up the details where that comes from, but its inconsistent at least | |
| 09:34:29 | carthaca | yes in the end we constructed our own models as well xD, would be easier if we could better extend and re-use the fog ones without monkey patching | |
| 09:35:05 | seanhandley | Well I think it's a matter of taste to some extent - if the object is simply a data container we can subclass OpenStruct | |
| 09:35:10 | seanhandley | https://gist.github.com/seanhandley/3517abaad013eadb21923b10ae68c2d3 | |
| 09:35:35 | seanhandley | The issue I think is when we do mutative calls | |
| 09:35:53 | seanhandley | Fog lets you say things like "server.restart" | |
| 09:37:04 | seanhandley | the way Misty is architected you'd currently do "cloud.compute.reboot_server_reboot_action uuid" or something similar | |
| 09:38:47 | seanhandley | I'd love to get Monty involved here because his Shade SDK does a lot of UX niceness for the user regarding the model layer | |
| 09:39:26 | flanders_ | +1 @mordred | |
| 09:39:29 | seanhandley | raw API call wrappers and JSON responses are fast and simple but his vision is for a codebase that has sane defaults and makes client code able to care as little as possible about the details | |
| 09:40:31 | seanhandley | I think you're onto something with integrating Misty in Fog flanders_ | |
| 09:40:33 | flanders_ | But needs to incorporate ProgLang paradigms... | |
| 09:40:39 | carthaca | that's right - when I first started using fog I liked a lot how easy it is to use | |
| 09:41:19 | seanhandley | if Misty is to be a lightweight SDK that gets you hooked into the API quickly then changing the fog models to refer directly to it as a dep might be the best way forward | |
| 09:41:31 | flanders_ | Fog/Misty must be usable to Ruby native Devs, not OpenStack Devs. | |
| 09:41:38 | seanhandley | then Fog benefits from the improved performance without losing the syntactic niceness of the model layer | |
| 09:41:46 | seanhandley | indeed flanders_ | |
| 09:42:04 | seanhandley | Hi gildub :) | |
| 09:42:11 | carthaca | yes, we thought of doing the rework directly in fog, too - but it needs a lot of effort. so we chickened out a bit and moved to the new tiny misty :D | |
| 09:42:23 | seanhandley | I don't blame you - there's a lot of baggage | |
| 09:43:17 | seanhandley | At any rate, I think that model layer of UX niceness can learn a lot from Shade | |
| 09:43:25 | seanhandley | wherever it ultimately ends up residing | |
| 09:45:35 | seanhandley | carthaca gildub: Do you think it makes sense to leave the model layer out of Misty as a hard architectural decision? | |
| 09:45:55 | seanhandley | or could there be a Misty::Model namespace ? | |
| 09:47:01 | carthaca | I'm not sure, do we want to end up with both misty and fog or do we want to rework one of the two to get all benefits? | |
| 09:48:21 | seanhandley | I think I'd prefer for it all to live in Misty - that way it can be developed in line with Shade and the current community thinking on how best to make an OpenStack SDK from an app dev perspective | |
| 09:48:30 | seanhandley | it lets us free ourselves of legacy | |
| 09:48:44 | seanhandley | but the decision, ultimately, is down to you guys - it's your project :) | |
| 09:49:55 | seanhandley | I'd love to get gildub's input on this too | |
| 09:50:44 | seanhandley | I'm happy to contribute my time to this btw | |
| 09:50:48 | carthaca | I agree it would make it easier to get rid of the legacy :) | |
| 09:51:37 | carthaca | But yeah, it's up to gildub. It's his baby | |
| 09:52:41 | flanders_ | Would be great if we could do a big announce re misty+fog integration at Sydney summit?! | |
| 09:53:19 | flanders_ | I could wrangle marketing to support, though kowtow to gildub. | |
| 09:53:19 | seanhandley | looking at the code, it seems pretty mature so far flanders_ - I don't think adding a nice UX model layer on top would be hard, just a little bit of a slog coding wise | |
| 09:53:54 | seanhandley | ultimately I'm happy to create a higher-level Shadesque Ruby SDK that uses Misty under the hood also | |
| 09:54:15 | flanders_ | Do we need to get y'all in the same space to hammer out face to face, or what can I help do to make happen? | |
| 09:54:59 | seanhandley | Figuring if Gilles is at the PTG (or wants to be) is a good first step I guess. We'll hopefully see when he has some time today | |
| 09:55:15 | flanders_ | Decision anon pending input from @mordred @gildub | |
| 09:55:30 | seanhandley | +1 | |
| 09:55:41 | seanhandley | Well, thanks for your time flanders_ and carthaca :-) | |
| 09:55:58 | seanhandley | I guess we'll pick this up again soon | |
| 09:56:09 | carthaca | Same to you | |
| 09:56:12 | seanhandley | flanders_: Do you know if the SDK WG does regular IRC meetings? | |
| 09:57:49 | flanders_ | Not yet, but I'm keen to push forward | |
| 09:58:02 | flanders_ | Perhaps via PublicCloud-WG? | |
| 09:58:02 | seanhandley | ok | |
| 09:58:21 | seanhandley | Well, we do have a meeting at 2pm UTC tomorrow | |
| 09:58:31 | seanhandley | maybe a bit late for your TZ | |
| 09:58:36 | seanhandley | but could work ok for mordred | |
| 09:58:40 | flanders_ | The chairs might be keen to have useable SDK their customers can use? | |
| 09:58:52 | seanhandley | definitely flanders_ | |
| 09:59:19 | seanhandley | I think Gophercloud is a good one to focus on as well - given that Terraform uses it | |
| 09:59:22 | flanders_ | +1 re pulling @mordred into publicCloud-WG call! | |
| 09:59:33 | seanhandley | Mike from SuperGiant.io is interested in chatting btw so feel free to ping him an email | |
| 09:59:47 | flanders_ | +1 re GopherCloud, chatting with Joe Tpjian next! | |
| 10:00:00 | seanhandley | I think he's mike [at] supergiant [dot] io | |
| 10:00:10 | seanhandley | cool cool :) | |
| 10:00:17 | flanders_ | @seanhandley: thanks re SuperGiant intro! | |
| 10:00:36 | flanders_ | Have a good day o/ | |
| 10:00:38 | seanhandley | np - keeping count on those beer IOUs :D | |
| 10:00:45 | seanhandley | Have a nice eve o/ | |
| 10:02:20 | openstackgerrit | NidhiMittalHada proposed openstack/python-openstackclient master: image-list should support filters 'name','status' https://review.openstack.org/479670 | |
| 10:03:32 | carthaca | Good bye | |
| 10:39:24 | kuzko | hey people, i'm currently trying the openstack sdk and got a weird sslv3 issue, can I have someone pointing me in the right direction? | |
| 10:41:32 | kuzko | trace : https://pastebin.com/4k0tnKX4 .. am I missing libs or something? | |
| 10:57:07 | seanhandley | kuzko: When you say "SDK" can you be more specific ? | |
| 10:57:14 | seanhandley | i.e. where did you download it from | |
| 10:57:26 | seanhandley | that backtrace refers to indus-demo-eric/SDK-Nuabee | |
| 10:58:05 | kuzko | yup that's my project path, but it uses openstack libraries | |
| 10:58:18 | kuzko | installed with pip | |
| 10:59:49 | kuzko | https://pastebin.com/4teuNX12 that's the way I import those libs, should I use something else? | |
| 11:01:59 | kuzko | I followed this : https://dev.cloudwatt.com/fr/doc/sdk/sdk-python.html | |
| 11:07:36 | kuzko | seanhandley : I don't even know if i'm in the right place to ask shuch question, google is not helpful, requests lib is intalled with [security] ... | |
| 11:24:47 | flanders_ | @kuzko: have a look at shade sdk | |
| 11:29:35 | kuzko | ok, well, that's another sdk, I get it, but this doesn't really help on that issue, did you guys never had connexion issues? | |
| 11:34:59 | seanhandley | Sure kuzko | |
| 11:35:17 | seanhandley | But without familiarity of the code in question it's hard for us to help :) | |
| 11:36:09 | seanhandley | Judging by the cloudwatt link you shared, this code is using the individual openstack client libraries | |
| 11:37:18 | seanhandley | Can you share your code online somewhere? | |
| 11:37:34 | seanhandley | and also your connection details for openstack (except for username/password) | |
| 12:10:01 | kuzko | hang on I'm gonna ask if I can share part of the code, but, yes the code is using the individual client libraries... is ther antoher way? (except for that shade thing ^^) | |
| 12:17:10 | seanhandley | Yeah, I recommend Shade | |
| 12:17:27 | seanhandley | It's very nicely designed | |
| 12:19:07 | seanhandley | if you're doing simple operations then it's perfect (create an instance, give it an IP, destroy it etc) | |
| 12:20:02 | seanhandley | https://github.com/openstack-infra/shade/blob/master/README.rst | |
| 13:14:14 | mordred | morning seanhandley ! | |
| 14:54:21 | openstackgerrit | Javier Peña proposed openstack/python-openstackclient master: Fix man page build https://review.openstack.org/480218 | |
| 17:46:35 | openstackgerrit | OpenStack Proposal Bot proposed openstack/cliff master: Updated from global requirements https://review.openstack.org/480277 | |
| 19:28:41 | openstackgerrit | Merged openstack/python-openstackclient master: Fix man page build https://review.openstack.org/480218 | |