| *** egafford has joined #openstack-sahara | 00:04 | |
| *** elmiko has quit IRC | 00:21 | |
| *** saneax has joined #openstack-sahara | 00:31 | |
| openstackgerrit | Emilien Macchi proposed openstack/puppet-sahara: acceptance: bump to Liberty release https://review.openstack.org/209296 | 00:40 |
|---|---|---|
| *** ashuk has quit IRC | 01:04 | |
| *** ashuk has joined #openstack-sahara | 01:21 | |
| openstackgerrit | Emilien Macchi proposed openstack/puppet-sahara: acceptance: bump to Liberty release https://review.openstack.org/209296 | 01:22 |
| *** ashuk has quit IRC | 01:30 | |
| *** saneax has quit IRC | 02:11 | |
| *** egafford has quit IRC | 02:40 | |
| *** hdd has joined #openstack-sahara | 03:19 | |
| *** hdd has quit IRC | 03:28 | |
| *** coolsvap|away is now known as coolsvap | 03:54 | |
| *** saneax has joined #openstack-sahara | 03:56 | |
| *** vgridnev has joined #openstack-sahara | 04:02 | |
| *** sgotliv_ has joined #openstack-sahara | 04:14 | |
| *** Poornima has joined #openstack-sahara | 04:14 | |
| *** pcaruana has quit IRC | 04:59 | |
| *** saneax has quit IRC | 05:38 | |
| *** saneax has joined #openstack-sahara | 05:40 | |
| *** vgridnev has quit IRC | 05:51 | |
| openstackgerrit | Merged openstack/sahara-image-elements: Updated from global requirements https://review.openstack.org/201211 | 05:54 |
| *** saneax has quit IRC | 05:54 | |
| openstackgerrit | Merged openstack/sahara-image-elements: hadoop: add vanilla/2.6 based on CentOS 7 https://review.openstack.org/202469 | 05:56 |
| openstackgerrit | Merged openstack/sahara-image-elements: Fix version of Centos in Mapr plugin https://review.openstack.org/206344 | 05:56 |
| *** saneax has joined #openstack-sahara | 05:58 | |
| *** Poornima has quit IRC | 06:02 | |
| *** Poornima has joined #openstack-sahara | 06:18 | |
| *** vgridnev has joined #openstack-sahara | 06:24 | |
| *** pcaruana has joined #openstack-sahara | 06:36 | |
| *** vgridnev has quit IRC | 07:01 | |
| *** esikachev has joined #openstack-sahara | 07:25 | |
| *** witlessb has joined #openstack-sahara | 07:44 | |
| *** Nikolay_St has joined #openstack-sahara | 08:13 | |
| *** esikachev has quit IRC | 08:19 | |
| *** barra204 has quit IRC | 08:25 | |
| *** esikachev has joined #openstack-sahara | 08:38 | |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara-image-elements: Support building images for new vanilla plugin https://review.openstack.org/209010 | 08:41 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: add unit test cover oozie upload workflow file function https://review.openstack.org/207923 | 08:42 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Remove test for job type in get_data_sources https://review.openstack.org/208542 | 08:42 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Add recommendation support to Cloudera plugin https://review.openstack.org/193098 | 08:44 |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [DO NOT MERGE] Workaround for mapr https://review.openstack.org/204548 | 08:47 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara-image-elements: Support building images for new vanilla plugin https://review.openstack.org/209010 | 08:54 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara-image-elements: Support building images for new vanilla plugin https://review.openstack.org/209010 | 08:55 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Make starting scripts module for vanilla 2 plugin https://review.openstack.org/208474 | 09:06 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Small refactoring for vanilla 2 https://review.openstack.org/208424 | 09:06 |
| *** esikachev has quit IRC | 09:07 | |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Update vanilla plugin to the latest version https://review.openstack.org/208510 | 09:11 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Update vanilla plugin to the latest version https://review.openstack.org/208510 | 09:12 |
| *** esikachev has joined #openstack-sahara | 09:12 | |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Support manila shares as binary store https://review.openstack.org/204690 | 09:13 |
| *** tosky has joined #openstack-sahara | 09:16 | |
| *** DWfuturetec has joined #openstack-sahara | 09:19 | |
| *** DWfuturetec has left #openstack-sahara | 09:20 | |
| *** vgridnev has joined #openstack-sahara | 09:25 | |
| *** vgridnev has quit IRC | 09:26 | |
| *** vgridnev has joined #openstack-sahara | 09:26 | |
| *** Nikolay_St has quit IRC | 09:42 | |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Add sample spark wordcount job https://review.openstack.org/207039 | 09:48 |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Support placeholders in args of job for i/o https://review.openstack.org/206094 | 09:48 |
| *** Nikolay_St has joined #openstack-sahara | 09:53 | |
| openstackgerrit | Vitaly Gridnev proposed openstack/sahara: Put missing fields to validation schema https://review.openstack.org/207244 | 09:55 |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Adding job_binary_internal_update api call https://review.openstack.org/208496 | 10:25 |
| *** saneax has quit IRC | 10:32 | |
| *** coolsvap is now known as coolsvap|away | 10:33 | |
| *** h00327910__ has quit IRC | 10:58 | |
| *** saneax has joined #openstack-sahara | 11:09 | |
| *** AndreyPavlov has quit IRC | 11:10 | |
| *** AndreyPavlov has joined #openstack-sahara | 11:10 | |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [DO NOT MERGE] Workaround for mapr https://review.openstack.org/204548 | 11:32 |
| *** hdd has joined #openstack-sahara | 11:40 | |
| *** coolsvap|away is now known as coolsvap | 11:44 | |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Adding job_update api call https://review.openstack.org/197924 | 11:48 |
| *** esikachev has quit IRC | 11:53 | |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Adding job_binary_internal_update api call https://review.openstack.org/208496 | 12:00 |
| *** Poornima has quit IRC | 12:09 | |
| *** esikachev has joined #openstack-sahara | 12:27 | |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Adding job_binary_internal_update api call https://review.openstack.org/208496 | 12:30 |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara-specs: Addding spec for Objects update support in Sahara API https://review.openstack.org/208378 | 12:32 |
| *** hdd has quit IRC | 12:44 | |
| *** hdd has joined #openstack-sahara | 12:52 | |
| openstackgerrit | Artem Osadchiy proposed openstack/sahara: Fix MapR plugin versions loading https://review.openstack.org/209507 | 13:03 |
| *** elmiko has joined #openstack-sahara | 13:03 | |
| *** vgridnev has quit IRC | 13:16 | |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Adding clusters_update api call https://review.openstack.org/195024 | 13:23 |
| *** tosky has quit IRC | 13:25 | |
| *** tosky has joined #openstack-sahara | 13:29 | |
| *** coolsvap is now known as coolsvap|away | 13:30 | |
| openstackgerrit | Chad Roberts proposed openstack/sahara: Support manila shares as binary store https://review.openstack.org/204690 | 13:35 |
| *** ashuk has joined #openstack-sahara | 13:39 | |
| *** ashuk has quit IRC | 13:40 | |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara: Adding job_update api call https://review.openstack.org/197924 | 13:47 |
| openstackgerrit | Andrey Pavlov proposed openstack/sahara-specs: Addding spec for Objects update support in Sahara API https://review.openstack.org/208378 | 13:58 |
| *** zigo has quit IRC | 14:05 | |
| *** egafford has joined #openstack-sahara | 14:06 | |
| *** zigo has joined #openstack-sahara | 14:06 | |
| _crobertsrh | SergeyLukjanov: Are we due for a python-saharaclient release anytime soon? Just asking because I have some horizon changes that will need it. | 14:15 |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [DO NOT MERGE]SHOW IMAGES https://review.openstack.org/209530 | 14:21 |
| *** saneax has quit IRC | 14:25 | |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [DO NOT MERGE]SHOW IMAGES https://review.openstack.org/209530 | 14:30 |
| *** Nikolay_St has quit IRC | 14:41 | |
| openstackgerrit | Evgeny Sikachev proposed openstack/sahara: [DO NOT MERGE]SHOW IMAGES https://review.openstack.org/209530 | 14:49 |
| elmiko | _crobertsrh, the horizon stuff uses saharaclient to do all the interaction with the sahara controller? | 14:56 |
| *** _crobertsrh is now known as crobertsrh | 14:57 | |
| crobertsrh | yep | 14:57 |
| elmiko | given the latest review that AndreyPavlov is proposing with the update method for clusters, etc. i'm wondering if it would be worth it to fix the other update methods to use PATCH instead of PUT so we can have some consistency | 14:58 |
| elmiko | that would basically be a change in the sahara controller, and a change in saharaclient. would that be it? | 14:58 |
| *** hdd has quit IRC | 14:58 | |
| *** hdd has joined #openstack-sahara | 15:00 | |
| *** tmckay has joined #openstack-sahara | 15:25 | |
| *** esikachev has quit IRC | 15:25 | |
| *** shakamunyi has joined #openstack-sahara | 15:35 | |
| *** hdd has quit IRC | 15:36 | |
| elmiko | crobertsrh, tmckay, i just posted this http://lists.openstack.org/pipermail/openstack-dev/2015-August/071469.html | 15:38 |
| elmiko | curious what you guys think about doing a quick update to those methods? | 15:38 |
| crobertsrh | nice use of "bifurcation" | 15:39 |
| elmiko | thanks ;) | 15:39 |
| tmckay | I think "Rock on, elmiko!" | 15:39 |
| elmiko | do you guys think i should just make a bug for this? | 15:39 |
| tmckay | yes | 15:39 |
| crobertsrh | Yes | 15:39 |
| elmiko | k, thanks | 15:39 |
| tmckay | YES | 15:39 |
| tmckay | beat you crobertsrh, with your capital Y | 15:40 |
| crobertsrh | you didn't have to yell, man | 15:40 |
| elmiko | the only thing i'm unsure about is the timing between the sahara patch landing and the saharaclient patch landing, but i guess i can just make one depend on the other | 15:40 |
| elmiko | lol | 15:40 |
| tmckay | yeah, you can just mark the client WIP | 15:41 |
| elmiko | i acutally saw how you make patches in different projects depend on each other | 15:41 |
| crobertsrh | oooh | 15:42 |
| elmiko | just add "Depends-On:" with the change-id of the target | 15:42 |
| elmiko | it will make gerrit not merge until the dependency does | 15:42 |
| crobertsrh | Oh, I think I've seen that before. I didn't know it actually *did* anything. | 15:42 |
| elmiko | yea, i ran into it recently because something wasn't merging and the nice folks in -infra hipped me to it | 15:43 |
| tmckay | elimiko, nice. Add it in the comment? | 15:46 |
| tmckay | commit I mean | 15:47 |
| tmckay | that is great | 15:47 |
| elmiko | yea | 15:47 |
| elmiko | i'll do the sahara PR first then make the saharaclient depend on it | 15:47 |
| elmiko | it should be a relatively small change | 15:47 |
| elmiko | but i think, if we have functional tests for the updating methods they might get broken while this is happening | 15:48 |
| tosky | not an API expert, is there a PATCH method? I though the base were the HTTP verbs and I don't remember a PATCH one | 15:51 |
| tosky | or is it something different? | 15:51 |
| elmiko | tosky, yea there is a PATCH, https://tools.ietf.org/html/rfc5789 | 15:53 |
| tosky | oh | 15:56 |
| tosky | it's recent | 15:56 |
| elmiko | i guess relatively speaking | 15:57 |
| elmiko | like, technically speaking, if you look at https://tools.ietf.org/html/rfc7231#section-4.3.4 | 15:58 |
| elmiko | PUT should be used to replace a resource full stop | 15:58 |
| elmiko | it shouldn't really be used for updating | 15:58 |
| *** Nikolay_St has joined #openstack-sahara | 16:08 | |
| *** esikachev has joined #openstack-sahara | 16:12 | |
| *** pcaruana has quit IRC | 16:26 | |
| *** openstackgerrit_ has joined #openstack-sahara | 16:30 | |
| *** melaks has joined #openstack-sahara | 16:31 | |
| tosky | elmiko: isn't this an API change? | 16:33 |
| *** hdd has joined #openstack-sahara | 17:01 | |
| *** openstackgerrit_ has quit IRC | 17:05 | |
| elmiko | tosky, technically yes | 17:19 |
| tosky | elmiko: and wouldn't it require a major API bump? | 17:20 |
| * tosky hears "2.0" somewhere | 17:20 | |
| elmiko | lol | 17:20 |
| elmiko | i don't think so, as we're not changing the endpoints just the methods | 17:20 |
| elmiko | also, iirc these updating methods have been added to our api relatively recently | 17:20 |
| elmiko | tosky, do you think it would require a version bump? | 17:21 |
| tosky | elmiko: let's put it this way: will an application using the current API, which target 1.x, work without any change? | 17:22 |
| elmiko | tosky, no, it would require a change | 17:22 |
| elmiko | but... | 17:22 |
| tosky | API break then | 17:22 |
| elmiko | it would have just changed to add these methods to begin with | 17:23 |
| *** openstackgerrit_ has joined #openstack-sahara | 17:24 | |
| elmiko | tosky, so are you saying we can't fix API issues without releasing a new version api? | 17:24 |
| *** hdd has quit IRC | 17:25 | |
| tosky | elmiko: that's my point, yes | 17:25 |
| tosky | the sad law of "plan carefully your API in advance" :) | 17:25 |
| elmiko | hmm | 17:26 |
| elmiko | i'm not sure how to address this then, we have a split in our API that, imo, needs to be addressed. it would be easier to do it now than wait for v2 | 17:26 |
| elmiko | i don't think it's proper for us to keeping adding methods that follow the broken methodology | 17:27 |
| tosky | no, really, we can't do that, or we are de-facto creating a new API | 17:27 |
| tosky | a reason more to go with 2.0 soon | 17:28 |
| *** hdd has joined #openstack-sahara | 17:28 | |
| tosky | you can add new methods, and mark the old one as deprecated (even if working) not change the existing ones | 17:28 |
| elmiko | that is another option, just have both in parallel for now | 17:29 |
| elmiko | the thing is, in order to get v2 off the ground we need to have the microversion impl in place. | 17:29 |
| elmiko | then we can iterate more frequently and signal that the api is changing | 17:30 |
| tosky | http://semver.org/ | 17:30 |
| tosky | if it's changing, is a major break -> bump major version | 17:30 |
| tosky | then the thing currently called 2.0 will be 3.0 | 17:30 |
| elmiko | yea, something akin to that | 17:30 |
| elmiko | well, i don't think this is a 2.0 -> 3.0 type change | 17:30 |
| elmiko | this is more like a 2.0 -> 2.1 | 17:31 |
| tosky | if a 2.x client does not work anymore, it's a major bump | 17:31 |
| tosky | likewise for 1.x client etc | 17:31 |
| elmiko | ironic and nova have started to implement microversions so that they can make these style changes and have a way for clients to know what they are talking to | 17:31 |
| tosky | a client targeted for x.y should work whatever x.y+n is released | 17:31 |
| elmiko | yea, but we don't have the capability to spin versioned apis like that | 17:32 |
| tosky | I think microversioning is not about major breakages, but to publish new features | 17:32 |
| tosky | I bet that what I wrote above applies also with microversioning, but I need to investigate more | 17:32 |
| elmiko | not just that, but also to indicate when certain features don't work anymore, and to allow clients to request specific versions of the api | 17:32 |
| *** hdd has quit IRC | 17:33 | |
| tosky | that's all against the semantic versioning | 17:33 |
| elmiko | http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html | 17:33 |
| elmiko | an example of microversion | 17:34 |
| tosky | but then you need microversioning before going for this change | 17:34 |
| elmiko | well, probably, but that's 2.0 stuff | 17:34 |
| tosky | then no for 1.x | 17:34 |
| *** openstackgerrit_ has quit IRC | 17:34 | |
| elmiko | ok, then i just have to be an ass about people wanting to implement new PUT methods | 17:34 |
| elmiko | =( | 17:35 |
| elmiko | because it's making a mess of the api | 17:35 |
| tosky | that's why I think is really time to push for the new version | 17:35 |
| elmiko | yea, i gotta finish that poc and get the spec up | 17:35 |
| tosky | uh, need to relocate, back in 30 minutes | 17:35 |
| elmiko | np, thanks for the critique | 17:35 |
| *** tosky has quit IRC | 17:36 | |
| *** melaks has quit IRC | 17:43 | |
| *** hdd has joined #openstack-sahara | 17:48 | |
| *** melaks has joined #openstack-sahara | 17:49 | |
| tmckay | elmiko, so can you do that Depends-On trick in a commit to allow a CR to depend on multiple different streams in the same project? | 17:50 |
| elmiko | tmckay, good question, i'm not exactly sure | 17:51 |
| tmckay | I want to depend on a croberts patch, but I also want to break it up. Instead of going multiple levels deep on the original, I wonder if I can depend on two base CRs | 17:51 |
| elmiko | i'd be curious to know as well | 17:51 |
| tmckay | hmm, maybe I should try it | 17:52 |
| *** tosky has joined #openstack-sahara | 17:53 | |
| elmiko | tosky, so what about breaking things in the body of a request, does that count as major version bump as well? | 17:56 |
| tosky | elmiko: I guess the criteria is always the same: does a unmodified client written for a previous version still works without changes? | 17:57 |
| elmiko | that depends on the nature of the client and how it deploys data to the endpoint, doesn't it? | 17:59 |
| elmiko | like, in the case of sahara cli, you could just change the json you send, then it would still work | 17:59 |
| openstackgerrit | Trevor McKay proposed openstack/sahara: Support manila shares as binary store https://review.openstack.org/204690 | 18:00 |
| openstackgerrit | Trevor McKay proposed openstack/sahara: draft commit, manila datasources https://review.openstack.org/209615 | 18:00 |
| tmckay | oops, I may have changed something I didn't mean to | 18:00 |
| elmiko | doh! | 18:00 |
| tosky | elmiko: the CLI client is not an good example, as it uses the python CLI | 18:00 |
| tmckay | too many patches in progress | 18:00 |
| elmiko | tosky, hehe, fair | 18:00 |
| elmiko | tosky, i'm trying to figure out the scope of the changes that are needed for the v2 change. i had thought we could change it in an iterative manner, but that may not be possible | 18:01 |
| elmiko | i was hoping we could use version negotiation in the headers to help guide the deployment | 18:02 |
| tosky | not with API unfortunately (unless you have microversioning, but yeah) | 18:02 |
| crobertsrh | Hmm | 18:02 |
| tosky | you could end up doing more work than implementing a new API or microversioning in 1.x | 18:02 |
| elmiko | tosky, my idea was that we implement microversions as the basis step for v2, the start to iterate on changes until we have everything we want | 18:03 |
| elmiko | but i don't think that's possible if we hold ourselves to upping the major version everytime we introduce a breaking change | 18:03 |
| elmiko | especially when you consider that we carry the major version in the URI | 18:03 |
| tosky | right, that's why APIs need proper planning, it's not something you can easily expand | 18:04 |
| elmiko | well, easy to expand, difficult to fix ;) | 18:04 |
| elmiko | here's the thing though. | 18:05 |
| elmiko | with microversions, an old client would know when it can't complete some action. so it wouldn't break, but it would request a lower version api | 18:05 |
| crobertsrh | tmckay: Did you mean to tweak https://review.openstack.org/#/c/204690 | 18:05 |
| elmiko | so, we start with 2.0.0 | 18:05 |
| elmiko | and then introduce a breaking change in 2.1.0 | 18:05 |
| tmckay | crobertsrh, I think I may have rebased it ... | 18:05 |
| elmiko | but a client could still request 2.0.0 | 18:05 |
| tmckay | not sure if it's actually messed up or not | 18:05 |
| crobertsrh | rebased in a good way, or in a bad way? :) | 18:06 |
| elmiko | and it would work until we decide to deprecate 2.0.0 | 18:06 |
| tmckay | I was trying to stash a dependent wip | 18:06 |
| tmckay | crobertsrh, in a good way. moved it to the head of the merge | 18:06 |
| elmiko | plus, the server would indicate what versions it supports | 18:06 |
| tmckay | croberts, trying to check now | 18:06 |
| crobertsrh | hmm, doesn't look right to me | 18:06 |
| crobertsrh | manila_share.py is a few revs back | 18:07 |
| elmiko | and, if we keep the older code around we still be able to handle requests for a prior api version | 18:07 |
| elmiko | i mean, we're mainly talking about changing some endpoints and method types, for now | 18:07 |
| tosky | if you have microversioning in place | 18:08 |
| tosky | (which - microversioning - I still personally think it's a broken workaround for lack of planning, but that's just me; it's available and used in openstack, so it can be used) | 18:09 |
| elmiko | i don't think that's an unfair characterization | 18:09 |
| tmckay | crobertsrh, okay, I'll checkout and resubmit | 18:09 |
| elmiko | tosky, so here's my plan, the spec for v2 will say that the first thing we change is add microversions and carry over all the endpoints as they are | 18:09 |
| elmiko | then we start to iterate and "improve" the api | 18:10 |
| elmiko | and at some point we will declare v2 to go from experimental to production | 18:10 |
| tosky | that's your call, but isn't it really possible to have a baseline API with something which won't change too much? | 18:10 |
| tosky | every time you will add a code branch to support a microversion, that will increase the code, the test matrix and the universe entropy | 18:10 |
| elmiko | fair point, and i like think that it's *our* call ;) | 18:11 |
| tosky | ... until someone has to explode the test matrix | 18:11 |
| openstackgerrit | Trevor McKay proposed openstack/sahara: Support manila shares as binary store https://review.openstack.org/204690 | 18:11 |
| elmiko | tosky, at some point we will decide to deprecate versions older than x.y.z, then the matrix can relax | 18:11 |
| tmckay | crobertsrh, okay, fixed | 18:12 |
| tosky | you are basically going to introduce parallel version of API without calling them as such | 18:12 |
| tmckay | I changed the comment :) | 18:12 |
| elmiko | tosky, i suppose that's one way to look at it | 18:12 |
| tmckay | crobertsrh, 28 and 30 show no difference now | 18:12 |
| elmiko | tosky, with the understanding that v2 related API stuff will need to be negotiated with microversions | 18:12 |
| elmiko | v1.1 still works the same | 18:13 |
| openstackgerrit | lu huichun proposed openstack/python-saharaclient: Add job execution update https://review.openstack.org/208001 | 18:14 |
| elmiko | so, the other way to do this (which sounds more like what you are proposing), is that we plan all the changes ahead of time, make them in v2, and only make additive changes to v2 at that point | 18:14 |
| elmiko | is that accurate? | 18:14 |
| tosky | elmiko: yes | 18:14 |
| tosky | elmiko: just check this: are you sure you will be able to drop older version of x.y, for y<=n, without increasing x? | 18:15 |
| elmiko | tosky, only if the client is setup to understand the microversions | 18:15 |
| crobertsrh | tmckay: ack :) | 18:16 |
| tosky | elmiko: so the test matrix won't really decrease | 18:16 |
| elmiko | tosky, at some point we would drop 1.1, then all clients would be assured to know about microversions, so why would the test matrix not decrease? | 18:16 |
| tosky | elmiko: fine for 1.1, but every microversion variation is a different combination; a client could be a plain one, or it could require 2.1, or 2.2, or 2.3, and the behavior of some method will change, so all codepaths will be supported | 18:18 |
| elmiko | tosky, true, but at some point we might deprecate 2.1 (for example), then it would decrease again | 18:19 |
| tosky | elmiko: that's the point; are we sure we can do it? I would check with other projects | 18:19 |
| elmiko | tosky, fair, and that's a good point about watching what others are doing | 18:20 |
| elmiko | tosky, overall, i think you are probably correct that we should plan to make all the changes possible and then cement the api at that point. i just envision some larger changes that i think will be more difficult to capture in a first pass at v2 | 18:22 |
| tosky | elmiko: then it will be time for 3.0 | 18:22 |
| elmiko | imo, i would keep the v2 api experimental until we decide to cement it, and then declare it as ready for production | 18:23 |
| elmiko | tosky, lol, don't get me started... ;) | 18:23 |
| *** esikachev has quit IRC | 18:24 | |
| openstackgerrit | Ethan Gafford proposed openstack/sahara: Check ACLs before adding access for Manila share https://review.openstack.org/209621 | 18:25 |
| egafford | crobertsrh: Thanks for notifying re: https://review.openstack.org/#/c/209621/ | 18:26 |
| crobertsrh | Sweet, you already have the fix. | 18:26 |
| openstackgerrit | Ethan Gafford proposed openstack/sahara: Check ACLs before adding access for Manila share https://review.openstack.org/209621 | 18:27 |
| egafford | crobertsrh: Yup, and now I have the fix addressing the right bug id. | 18:28 |
| crobertsrh | ha | 18:28 |
| elmiko | tosky, i appreciate the criticism, although it's giving me more gray hairs ;) | 18:28 |
| tosky | sorry for that, I understand the complication | 18:29 |
| elmiko | tosky, no apologies necessary, this is a difficult problem to work through | 18:30 |
| egafford | elmiko: More gray hairs just makes your beard better anyway. ;) | 18:30 |
| elmiko | egafford, lol, thanks ;) | 18:30 |
| crobertsrh | beard? I always figured that was just his back hair run amuck! | 18:31 |
| elmiko | haha, oh man... | 18:32 |
| egafford | crobertsrh: If elmiko's back hair was as amazing as his beard, I think most of us mortals would just need to go ahead and secede from masculinity as a gender. | 18:33 |
| crobertsrh | +1 | 18:33 |
| elmiko | whoa, let's not go that far | 18:33 |
| crobertsrh | He would be the Chuck Norris of back hair for sure | 18:33 |
| elmiko | haha | 18:33 |
| egafford | elmiko: :) | 18:33 |
| *** openstackgerrit has quit IRC | 18:46 | |
| *** openstackgerrit has joined #openstack-sahara | 18:46 | |
| crobertsrh | tmckay: digging the manila data source stuff so far. | 18:47 |
| tmckay | crobertsrh, cool, that was supposed to be a draft CR that nobody could see, but for some reason it wouldn't let me. I think because I was pushing dependent on you | 18:47 |
| tmckay | and it doesn't know how to sort out the flags for multiple commits, and probably wouldn't let me "draft" your existing CR | 18:48 |
| crobertsrh | Makes sense. I didn't realize draft was still an option | 18:48 |
| tmckay | elmiko, crobertsrh, egafford, if you run tox -e py27 right now on a fresh master, do you get 146 tests failed on "Plugins couldn't be loaded: vanilla" ? | 18:48 |
| crobertsrh | I thought -1 WF was our only option nowadays | 18:48 |
| tmckay | or is my env whack? | 18:49 |
| tmckay | crobertsrh, nope, git review -D should still work | 18:49 |
| crobertsrh | I have a fresh one handy, I'll give it a try. | 18:49 |
| tmckay | last I knew | 18:49 |
| elmiko | tmckay, i'll give it a shot. but yea, maybe time for a tox -r ? | 18:49 |
| egafford | tmckay: Delete sahara/plugins, then git checkout sahara/plugins. | 18:49 |
| tmckay | egafford, really? why? | 18:49 |
| egafford | You've got an old version of vanilla hanging around that's standing in the way of progress, I think. | 18:49 |
| tmckay | or just a guess? | 18:49 |
| egafford | tmckay: No, this does work. | 18:50 |
| egafford | Has to do with recent plugin deletions banging off of git's deletion handling colorfully. | 18:50 |
| elmiko | i get a bunch of errors about manilaclient... | 18:50 |
| tmckay | worked this morning :) | 18:50 |
| egafford | tmckay: Hm... | 18:51 |
| tmckay | egafford, you are correct, sir | 18:51 |
| tmckay | no doubt some crappy pyc file, or some such | 18:51 |
| egafford | elmiko: Have you recreated your tox env since python-manilaclient was added as a requirement? | 18:51 |
| tmckay | crazy devs, chaning stuff all the time, and commitin stuff | 18:51 |
| elmiko | egafford, yea, doing that now | 18:51 |
| egafford | elmiko: If that doesn't fix it, please do let me know, and I'll be confused at it until it's fixed. | 18:52 |
| elmiko | egafford, i'm sure that will fix it, i just wanted to complain >.< | 18:52 |
| egafford | elmiko: Fair. :) | 18:52 |
| elmiko | ok, now i get the plugin problem | 18:52 |
| elmiko | and yup, new checkout fixed it | 18:54 |
| crobertsrh | Mine just worked. Very fresh. | 18:55 |
| elmiko | almost too fresh... | 18:56 |
| *** esikachev has joined #openstack-sahara | 18:57 | |
| *** vgridnev has joined #openstack-sahara | 18:58 | |
| vgridnev | hey guys, I read logs of today horizon meeting, I suppose that we need more reviews for our patches in horizon to get them merged | 18:59 |
| elmiko | i did a few horizon reviews today =) | 19:00 |
| crobertsrh | Yes, we should all take a look at our reviews whenever possible. | 19:01 |
| crobertsrh | #link https://etherpad.openstack.org/p/sahara-reviews-in-horizon | 19:02 |
| crobertsrh | ^^^ good starting place | 19:02 |
| elmiko | sigh, this v2 spec is *never* going to get written ;) | 19:05 |
| *** pino|work has quit IRC | 19:05 | |
| *** pino|work has joined #openstack-sahara | 19:05 | |
| crobertsrh | elmiko: don't fret, that will be just in time for the implementation. | 19:12 |
| crobertsrh | Impl will take at least twice as long. | 19:13 |
| elmiko | crobertsrh, ouch lol /me sad panda | 19:13 |
| elmiko | that's why i was really hoping we could do it iteratively, but i think tosky just makes too much sense with his talk of test matrices and all =( | 19:13 |
| crobertsrh | Maybe we should lock everyone in a room in Tokyo and nobody leaves until it's done. | 19:13 |
| elmiko | haha | 19:14 |
| crobertsrh | Or...better yet, lock in a room in Hawaii until it's done. I bet we'll be up to v3 in about 3 hours. | 19:15 |
| elmiko | nice | 19:15 |
| crobertsrh | it's all about motivation | 19:15 |
| openstackgerrit | Trevor McKay proposed openstack/sahara: Allow Sahara native urls and runtime urls to differ for datasources https://review.openstack.org/209634 | 19:15 |
| elmiko | or lock you in a room with a bottle of woodford outside ;P | 19:15 |
| tmckay | egafford, crobertsrh, ^^ manila data source stuff | 19:15 |
| elmiko | on second thought, that's just cruel and unusual punishment | 19:16 |
| egafford | tmckay: ^5 | 19:16 |
| crobertsrh | Awesome | 19:16 |
| tosky | ehm, for Hawaii, only if the location is booked for one week and the time not spent for the API planning is free for all on the beach | 19:17 |
| tosky | then it could work | 19:17 |
| crobertsrh | tosky: yes, that is exactly my plan | 19:19 |
| elmiko | the thing is, most of the coding will be simple. just implementing new endpoint names and methods | 19:19 |
| elmiko | but, there are a few big features which could take some time | 19:20 |
| elmiko | for example, async tasks endpoint | 19:20 |
| crobertsrh | Yes, that will be a biggie | 19:23 |
| elmiko | but i guess we would need to add it in a way that would not deprecate prior features without updating the major version | 19:24 |
| elmiko | which is doable | 19:24 |
| crobertsrh | What's your guess on the odds of it making the M release? | 19:27 |
| openstackgerrit | Trevor McKay proposed openstack/sahara: Allow Sahara native urls and runtime urls to differ for datasources https://review.openstack.org/209634 | 19:27 |
| elmiko | i dunno, now is probably not a good time to speculate. i'm kinda deflated and frustrated about it | 19:27 |
| elmiko | what i'd like to see if an "experimental" v2 api start to get introduced | 19:28 |
| elmiko | and then we can improve it with the hopes of releasing for M | 19:28 |
| elmiko | like, my current poc creates a /v2 endpoint that replicates all the current functionality | 19:28 |
| crobertsrh | I'd love to see that happen. I think it makes it a less monolithic sort of thing | 19:28 |
| elmiko | but adds a microversion impl | 19:28 |
| elmiko | i'm dropping the tenant id from the URI and moving it to the headers | 19:29 |
| crobertsrh | If there was a way for it to be in there, but entirely unsupported. | 19:29 |
| elmiko | then, my idea was to add features while upping the microversion until all the features have been added | 19:29 |
| crobertsrh | Yeah, tenant id move is a pretty standard thing | 19:29 |
| elmiko | at which point we could say, 2.1.14 is the new v2 api, for example | 19:29 |
| crobertsrh | anything 2.x below that is rubbish | 19:30 |
| elmiko | but i wanted to at least start creating the /v2 endpoint now | 19:30 |
| elmiko | i was planning to put this in my spec, the idea that we start with a v2 that is identical to v1.1 with the exception of removed tenant id and microversion | 19:31 |
| elmiko | all marked as experimental | 19:31 |
| elmiko | then we just start changing endpoints and whatnot, all while bumping the microversion | 19:31 |
| elmiko | for each change | 19:31 |
| elmiko | but now, tosky has me thinking this may not be a wise approach | 19:31 |
| crobertsrh | I dunno, to me, it seems ok as long as it's known "experimental" stuff | 19:32 |
| elmiko | i probably need to think about it a little more | 19:32 |
| elmiko | yea, the "experimental" part is key | 19:32 |
| elmiko | i just need to finish my poc and get the spec up | 19:34 |
| elmiko | along with like fifty other things.... | 19:34 |
| elmiko | also, vgridnev , egafford , NikitaKonovalov, several of these horizon patches need rebases | 19:36 |
| elmiko | crobertsrh, all of yours looked ok so far | 19:36 |
| crobertsrh | Yeah, I think I took a "rebase day" awhile back | 19:37 |
| crobertsrh | just after the /contrib move | 19:37 |
| vgridnev | my patches is ok | 19:37 |
| elmiko | vgridnev, yea i was just pinging you since you brought it up ;P | 19:37 |
| *** hdd has quit IRC | 19:38 | |
| egafford | elmiko: Yeah, rebase needs to happen. I was waiting until /contrib for hope of visibility, and by then I'd just grown accustomed to it hanging out in my review set. | 19:38 |
| elmiko | egafford, ack | 19:38 |
| egafford | I'll rebase just after this interface Horizon patch I'm finishing up. | 19:38 |
| *** hdd has joined #openstack-sahara | 19:38 | |
| elmiko | no worries, i'm just going through these reviews now and noticed that more than a couple needed rebases | 19:39 |
| egafford | elmiko: Yup, utterly reasonable to point out. | 19:39 |
| *** crobertsrh has quit IRC | 19:46 | |
| *** vgridnev has quit IRC | 19:49 | |
| openstackgerrit | Trevor McKay proposed openstack/sahara: Add manila nfs data sources https://review.openstack.org/209615 | 19:57 |
| *** vgridnev has joined #openstack-sahara | 19:57 | |
| elmiko | tmckay, i dunno if you saw or not but i filed a bug with cryptography for that rsa key issue you found | 20:00 |
| elmiko | and they fixed it in like 10 minutes lol | 20:00 |
| *** vgridnev has quit IRC | 20:00 | |
| tmckay | elmiko, yeah, I saw! thanks | 20:04 |
| elmiko | tmckay, np, was gonna direct you there but then you went offline lol | 20:05 |
| tmckay | egafford, what do you think about moving manila path logic out of binary_retrievers into utils/openstack/manila? | 20:21 |
| tmckay | egafford, to be fair, utis/openstack/manila is kind of for client stuff, not Sahara canonical url handling | 20:21 |
| tmckay | but binary_retrievers seems an odd place to have it, now that I've broken out logic and will reference it from edp/job_utils. | 20:22 |
| tmckay | hmm, maybe the broken out stuff should just be in job_utils itself | 20:23 |
| * tmckay continues to talk to himself | 20:23 | |
| tmckay | yeah, that's it | 20:24 |
| *** hdd has quit IRC | 20:29 | |
| tmckay | nah, I was right the first time | 20:29 |
| *** hdd has joined #openstack-sahara | 20:29 | |
| *** esikachev has quit IRC | 20:29 | |
| *** hdd has quit IRC | 20:30 | |
| egafford | tmckay: Sorry; was afk for a few minutes. Hm; utils/openstack/manila could work. | 20:42 |
| tmckay | egafford, looking at service/shares now | 20:43 |
| tmckay | good place for path processing | 20:43 |
| egafford | service.shares could work too, if you want to centralize to the service layer and protect the client from anything that's not client. | 20:43 |
| egafford | Yeah. | 20:43 |
| tmckay | last holdout is where to put the automount method (broken out) | 20:43 |
| egafford | I like service.shares as a central logic layer for this stuff. | 20:43 |
| tmckay | automount touches the conductor, don't want to pollute stuff with the conductor. That's less general | 20:44 |
| egafford | tmckay: Fair. What packages do we currently have touching the conductor? | 20:46 |
| egafford | (That are involved in your current line of thinking?) | 20:46 |
| tmckay | edp/job_utils for one, which is where I'm adding the datasource stuff | 20:46 |
| tmckay | egafford, I'm kind of not liking the mounting as a side effect. I'm wondering if we can pull the mount back into the edp engine. | 20:47 |
| tmckay | you know, get paths back (including defaults), but basically find out what shares are not present and then mount at that point | 20:47 |
| egafford | The entire mounting process? | 20:47 |
| tmckay | so that it's explicit and on purpose | 20:47 |
| egafford | Like, have one central place for mounting and have it be in EDP? | 20:48 |
| tmckay | I mean the little routine in binary_retrievers -- currently mounts as a side effect of retrieving the path | 20:48 |
| egafford | Ah, okay. That's more tenable. | 20:49 |
| tmckay | I like the share service that does the heavy lifting | 20:49 |
| tmckay | all we need to know is "yeah, I got this path, but it's not there yet, fyi" | 20:49 |
| tmckay | I don't know, I can play | 20:49 |
| egafford | Sure. I can definitely see breaking out most of binary_retrievers.manila_share.get_file_info into a common method. | 20:50 |
| egafford | (/function) | 20:50 |
| tmckay | yeah, I did that, pretty much | 20:51 |
| tmckay | eh, maybe the side effect of generating the path is fine | 20:51 |
| tmckay | I've currently got something called "mount_share_at_default_path" | 20:52 |
| egafford | So the ideal of service.shares is that it hopes to make the question of which shares are currently mounted and which ones aren't moot. | 20:52 |
| egafford | Cool. | 20:52 |
| tmckay | right, gotcha | 20:53 |
| egafford | (Sorry; I'm trying to see your objection to a code clarity problem on code I'm not seeing, and not quite getting the issue.) | 20:53 |
| *** esikachev has joined #openstack-sahara | 20:54 | |
| tmckay | egafford, understand, np :) I should wait for the review | 20:55 |
| egafford | tmckay: (I trust that it's there, just not quite with you.) | 20:55 |
| -openstackstatus- NOTICE: Zuul has been restarted to resolve a reconfiguration failure: previously running jobs have been reenqueued but change events between 19:50-20:54 UTC have been lost and will need to be rechecked or their approvals reapplied to trigger testing. | 21:05 | |
| -openstackstatus- NOTICE: Correction: change events between 20:50-20:54 UTC (during the restart only) have been lost and will need to be rechecked or their approvals reapplied to trigger testing. | 21:11 | |
| *** chlong has quit IRC | 21:16 | |
| *** esikachev has quit IRC | 21:16 | |
| *** esikachev has joined #openstack-sahara | 21:17 | |
| *** esikachev has quit IRC | 21:21 | |
| *** chlong has joined #openstack-sahara | 21:29 | |
| openstackgerrit | Trevor McKay proposed openstack/sahara: Add manila nfs data sources https://review.openstack.org/209615 | 22:00 |
| *** tmckay has quit IRC | 22:03 | |
| *** witlessb has quit IRC | 22:04 | |
| *** tosky has quit IRC | 22:26 | |
| *** egafford has quit IRC | 22:27 | |
| *** saneax has joined #openstack-sahara | 23:05 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!