| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-05-15 | |||
| 20:03:25 | cfriesen | incidentally, I opened up https://bugs.launchpad.net/python-openstackclient/+bug/1690902 while digging around for this issue. I think nova.csv isn't quite right in the "host-meta" case. | |
| 20:03:25 | openstack | Launchpad bug 1690902 in python-openstackclient "doc/source/data/nova.csv is inaccurate for host-meta" [Undecided,New] | |
| #openstack-sdks - 2017-05-16 | |||
| 02:08:19 | openstackgerrit | Merged openstack/keystoneauth master: Updated from global requirements https://review.openstack.org/464392 | |
| 02:30:22 | chenyb4 | med_, please help me review https://review.openstack.org/#/c/462818/ this patch, thaks | |
| 02:31:15 | openstackgerrit | Merged openstack/keystoneauth master: Fix V3ADFSPassword retrieval of scoped token https://review.openstack.org/463212 | |
| 02:46:45 | openstackgerrit | Takashi NATSUME proposed openstack/python-openstackclient master: List/show all server migration types https://review.openstack.org/450119 | |
| 03:14:32 | chenyb4 | Qiming, please help me review https://review.openstack.org/#/c/462818/ this patch about 'senlin service list', thaks | |
| 05:13:20 | Qiming | chenyb4, done. | |
| 05:40:53 | openstackgerrit | Divya K Konoor proposed openstack/keystoneauth master: Re-use token passed in for v3 Token https://review.openstack.org/464934 | |
| 08:36:52 | LuigiOpenstack | Hi..is this the right IRC for development practice of Openstack and Luigi workflows? | |
| 08:45:09 | LuigiOpenstack | anybody has an idea of how to leverage luigi with Openstack ? | |
| 09:48:20 | openstackgerrit | Divya K Konoor proposed openstack/keystoneauth master: Re-use token passed in for v3 Token https://review.openstack.org/464934 | |
| 12:48:20 | LuigiOpenstack | Can anyone assist me with Python code ? | |
| 13:49:07 | mordred | LuigiOpenstack: hi! I'm not sure what a luigi is. this is the right channel to discuss OpenStack SDKs though | |
| 14:41:20 | edleafe | mordred: it's a module to handle plumbing a series of tasks together. Mario Bros. reference | |
| 14:48:19 | elmiko | edleafe: lol | |
| 14:48:39 | elmiko | or were you referring to the actual luigi package | |
| 14:49:20 | cdent | elmiko: how doing after two solid weeks of conferencing? | |
| 14:49:34 | elmiko | cdent: almost fully recovered =) | |
| 14:49:43 | elmiko | finishing the last of my expense reports now lol | |
| 14:50:32 | cdent | I got home yesterday around 11am and just want to sleep | |
| 14:50:41 | elmiko | wow | |
| 14:50:55 | elmiko | hope you're feeling rested now =) | |
| 14:53:19 | edleafe | elmiko: both | |
| 14:53:40 | edleafe | cdent: go to sleep. | |
| 14:54:06 | edleafe | cdent: elmiko: btw, I'll be in Portland on Thursday for the start of PyCon, so I won't be at the meeting | |
| 14:54:14 | cdent | i slept most of yesterday, but it hasn't helped yet | |
| 15:00:49 | elmiko | edleafe: ack, also enjoy pycon! =) | |
| 15:03:13 | edleafe | elmiko: oh, I will! | |
| 15:03:58 | cdent | edleafe: make sure you come back with lots of ideas to change everything | |
| 15:04:28 | edleafe | cdent: yeah, that always goes over well in this community. | |
| 15:04:31 | edleafe | :) | |
| 15:04:41 | cdent | exactly why it is critical | |
| 15:05:33 | elmiko | re-write all services in ruby after visiting pycon? XD | |
| 15:07:11 | edleafe | elmiko: bite your tongue! | |
| 15:07:49 | openstackgerrit | Blake Covarrubias proposed openstack/keystoneauth master: Allow setting EndpointReference in ADFSPassword https://review.openstack.org/463432 | |
| 15:38:43 | mordred | edleafe: somehow last week - several sessions ended up with the outcome "mordred will write a spec" ... | |
| 15:38:50 | mordred | edleafe: so, youknow - sorry in advance | |
| 15:39:22 | mordred | edleafe, cdent: speaking of - dhellmann mentioned someting in one of the sessions that I think bears thinking about deeply and making a plan for | |
| 15:40:25 | mordred | with some of the new things we're writing up - we're winding up with 3 audiences for some of these API related specs- OpenStack Developers writing API services, Deployers registering things in such a way that affects API consumers, and API Consumers using the API services the OpenSTack Developers have written | |
| 15:41:27 | mordred | so I _think_ I understood that dhellmann suggested we maybe make three different outputs that we publish - so we can point deployers at the info that's relevant to them without them needing to read about implementation internals or whatnot | |
| 15:41:30 | mordred | or - something similar | |
| 15:42:42 | edleafe | mordred: that sort of meshes with the feeling I had reviewing your discovery docs (besides the dizziness) | |
| 15:42:57 | mordred | the dizziness means it's working | |
| 15:43:04 | mordred | soon I will have the mind control overyou! | |
| 15:43:05 | edleafe | mordred: that these aren't API guidelines, but more like deployment guidelines | |
| 15:43:06 | mordred | wait | |
| 15:43:10 | mordred | sssh. I didnt' say that | |
| 15:43:24 | edleafe | or something like that | |
| 15:43:38 | mordred | edleafe: exactly. I mean - they're API guidelines in as much as we want the API to behave in a way, and the deployers have to participate on a few topics | |
| 15:43:39 | edleafe | I didn't hear that. I hear only what the master tells me to hear | |
| 15:43:44 | mordred | edleafe: :) | |
| 15:44:31 | edleafe | I think of these guidelines as helping the OpenStack developers make good choices when creating APIs | |
| 15:44:46 | edleafe | These seem... different | |
| 15:45:32 | mordred | do you think they seem different enough to put into a separate source repo? my original thought was "no" - since the corpus is about OpenStack REST APIs ... | |
| 15:45:49 | mordred | but I am more than happy to agree with whatever opinions y'all have on that topic | |
| 15:46:46 | edleafe | mordred: not really sure. I'd like to get cdent and elmiko to weigh in on this | |
| 15:47:39 | mordred | cdent, elmiko: ^^ ? | |
| 15:47:58 | cdent | I think putting creation and consumption in the same place is a good idea because it is more contextualized | |
| 15:54:37 | dtroyer | ++ separate sections in the same repo would be good with me, but having to look in multiple places to find thw whole story is just painful. More than a few of us fit multiples of those categories | |
| 15:55:55 | dhellmann | mordred : we're working through whether it makes sense to have separate guides in the discussion with asettle about the future of docs | |
| 15:56:09 | dhellmann | mordred : one option is to have 1 sphinx job that publishes nicely organized docs, but only one thing | |
| 15:56:22 | dhellmann | another option is to have separate jobs, publishing different sets of docs to different places | |
| 15:57:19 | dhellmann | there's more of a legacy concern there, because we want to deal with redirects if we change how things are published | |
| 15:57:20 | dhellmann | if this is new content, you don't have that concern | |
| 15:57:34 | dhellmann | so a single sphinx project publishing nicely organized content is more appealing | |
| 15:57:44 | dhellmann | edleafe, cdent, dtroyer : ^^ | |
| 15:58:48 | cdent | ideally we'd see more places linking into the guidelines, and that makes even more sense if we're covering both creation and consumption | |
| 16:01:02 | edleafe | cdent: +1 | |
| 16:04:52 | elmiko | mordred: edleafe, just saw the ping. reading back | |
| 16:06:46 | elmiko | mordred: so, i more or less agree with cdent, edleafe and dtroyer. seems more useful to have things in a place that is easier to find | |
| 16:07:22 | elmiko | i'm not sure what shape that would take, but i like the idea of being able to navigate between the different guideline types in a convenient fashion | |
| 16:10:21 | mordred | sweet | |
| 16:11:28 | edleafe | The only one that seems out of place a bit is the version discovery algorithm | |
| 16:11:45 | edleafe | but in the context of the others, it fits | |
| 16:12:00 | mordred | dhellmann: there is also at least one thing in the service-types-authority consumption spec that assumes we can publish the service-types-authority data to a location that will be solid/stable/well-known. It's currently written up as "https://specs.openstack.org/service-types.json" - which I think a job in s-t-a to publish post-merge should be easy enough to implement | |
| 16:13:00 | dhellmann | mordred: it feels a little odd to publish machine-readable data to the root of the specs site, but I think I get it | |
| 16:13:28 | mordred | dhellmann: yah - we could also spin up a new domain/web root for that I imagine too | |
| 16:13:55 | cdent | i think specs could very well be fine: it's sort of like a spec | |
| 16:14:10 | dhellmann | yeah, it's just a new precedent | |
| 16:14:11 | cdent | and helps give it some ooomph | |
| 16:14:31 | mordred | edleafe: maybe if we re-org that doc slightly more cleanly into "develop/deploy/consume" portions rather than "this is all the information you need about consuming versions - oh, also, deployers please take note of this bit" it'll be easier to read too? | |
| 16:19:27 | edleafe | mordred: or maybe "here's where we are", "here's why we are in the state we are", and "here's where we really want to be" | |
| 16:20:21 | mordred | edleafe: yes. "this is the description of the idea state" - "this is description of the complete current state including the ideal state" - "these are recommendations for people who would like to achieve future perfection" | |
| 16:20:41 | mordred | edleafe, cdent, elmiko: WHILE I'VE GOT YOUR ATTENTION ... | |
| 16:23:57 | mordred | most of the services I've found in openstack with microversions implementations use the nova form of version/min_version rather than the API-WG recommendation of max_version/min_version ... including nova, cinder, manila and ironic - although it seems magnum and zun have the min_version/max_version form | |
| 16:24:39 | mordred | I'm mostly curious about the decision to recommend min/max (since I wasn't paying attentoin then) and how much effort we think should go in to adding max_version to the services which just have version? | |
| 16:25:42 | mordred | (I started a patch to add a "collections" link as from the version discovery thing just to see how bad it was (not) which is what got me thinking about this specifically) | |
| 16:25:45 | elmiko | iirc, some of these projects were impementing microversion while we were still arriving at the guideline, that combined with the "nova effect" (copy what nova did) did not help | |
| 16:26:35 | elmiko | it would be cool to bring the project up to speed with the guideline, but i don't have a strong handle on how interested in taking on the tech debt they would be | |
| 16:26:58 | elmiko | we don't get strong participation on a good day, it's just tough to know how the individual projects would feel about it | |
| 16:27:15 | sdague | well nova, ironic, and manila were out the door before there ever was an api-wg recommendation | |
| 16:27:17 | elmiko | my gut feeling is that it will be like herding a small pack of cats | |
| 16:27:20 | mordred | I mean, from a consume perspective, any consumer is going to have to handle both choices no matter what for the forseeable future so it's not a super big deal there | |
| 16:27:26 | elmiko | sdague: exactly | |
| 16:27:28 | mordred | sdague: yah | |
| 16:28:00 | edleafe | does anyone use max_version? | |
| 16:28:04 | mordred | yes | |
| 16:28:12 | elmiko | imo, it would be nice, but we (api-wg) don't exactly have a habit of chasing folks down to implement the guidelines | |
| 16:28:18 | mordred | magnum and zun at least - I haven't taken full catalog yet | |