| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-07-04 | |||
| 09:09:10 | carthaca | Yes, let's start with that | |
| 09:09:32 | carthaca | Gilles is the one, who started it | |
| 09:10:07 | carthaca | He mentioned it in of the Mails that Flanders distributed, that's how I found it | |
| 09:10:25 | carthaca | And I was immediately in love :D | |
| 09:10:45 | seanhandley | The README sounds very promising | |
| 09:11:00 | carthaca | It provides, what we were missing from fog | |
| 09:11:15 | seanhandley | I've been involved with Fog for a number of years now, and it's been the most mature OpenStack SDK in Ruby for a long time | |
| 09:11:21 | carthaca | you only have to authenticate once and can talk to all services | |
| 09:11:36 | seanhandley | ok - so is it fully compatible with all APIs? | |
| 09:11:50 | carthaca | so this means less calls to keystone, more performance | |
| 09:12:09 | carthaca | and API adoption is much faster, because it is much more lightweight | |
| 09:12:20 | seanhandley | Yeah, the auth stuff in openstack-fog sucks :) | |
| 09:13:30 | carthaca | compatability looks really good, though I didn't make it to the nasty stuff, yet | |
| 09:13:38 | seanhandley | Ok | |
| 09:14:07 | seanhandley | I'm happy to get involved and to champion misty as the Ruby SDK of choice for OpenStack in the long term so long as we're not losing out. The advantages of Fog is that it has momentum, community, and support for a lot of APIs. | |
| 09:14:59 | seanhandley | I think it'd be useful to get a to-do list in the form of Github issues or something | |
| 09:15:25 | seanhandley | then we can see where the gaps are and start filling them :) | |
| 09:15:47 | seanhandley | Did you get a chance to read the service endpoint spec that Flanders linked? | |
| 09:16:17 | carthaca | yes, sounds reasonable | |
| 09:16:32 | carthaca | valid service types have to be defined somewhere | |
| 09:17:16 | seanhandley | Yes - Monty proposes we have a json file on openstack.org | |
| 09:17:19 | seanhandley | which can be cached | |
| 09:19:10 | flanders_ | I'm here! Having dinner | |
| 09:19:30 | carthaca | so we at SAP already decided to move away from fog to misty, basically we are the 4 other contributors you see in misty | |
| 09:20:46 | seanhandley | Aha I see | |
| 09:21:31 | carthaca | what fog offers, that we don't need is the models - do you know how widely the other consumers of fog consume the models? | |
| 09:21:31 | seanhandley | Can you describe the problems with Fog as you perceive them at SAP? | |
| 09:21:49 | seanhandley | heh well I was going to mention the models layer | |
| 09:22:25 | flanders_ | Whom rise do we need in the fog community to look at Misty so it can be conjoined with fog? | |
| 09:22:44 | carthaca | on thing I already mentioned, it's the auth - you cannot re-use on fog object, but have to create a new one for every service you talk to | |
| 09:23:09 | seanhandley | and that causes performance issues carthaca ? | |
| 09:25:03 | carthaca | yes in two ways: 1. fog is always calling keystone to check the token you provided + 2. fog is calling keystone for every service you use again | |
| 09:25:21 | flanders_ | Doh! | |
| 09:25:35 | seanhandley | I ran into a similar issue in the early days of integrating our app using Fog | |
| 09:25:36 | seanhandley | https://gist.github.com/seanhandley/8589520ab7e8bffda78c8cdf11d30402 | |
| 09:25:49 | seanhandley | I used to memoize those Fog objects ^ | |
| 09:26:01 | seanhandley | so in theory the auth wouldn't happen multiple times | |
| 09:26:25 | seanhandley | but in practice I found the Fog re-auth code was buggy once the token had expired :( | |
| 09:27:08 | carthaca | yes we initially did the same and stumbled over weird re-auth issues :( | |
| 09:27:39 | carthaca | that directly leads me to another issue we see: fog is doing its own error-handling and sometimes swallows errors, that we would like to bubble up properly instead | |
| 09:27:56 | flanders_ | Does Monty's service discovery support re Keystone auth address this? | |
| 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 | |