Hive
  1. Hive
  2. HIVE-7010

templeton/v1/queue REST method has been removed

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.14.0
    • Fix Version/s: None
    • Component/s: Documentation, WebHCat
    • Labels:
      None

      Description

      deprecated "queue" REST method was removed from WebHCat in HIVE-6432. "jobs" is the replacement.

      https://cwiki.apache.org/confluence/display/Hive/WebHCat+Reference needs to be updated

        Issue Links

          Activity

          Hide
          Larry McCay added a comment -

          That was the behavior that I expected actually.
          Getting all components to adhere to this would like be difficult but I think that it makes sense for all components that do support the version indicator to take that approach. Some components don't actually even have a version indicator in their APIs.

          Show
          Larry McCay added a comment - That was the behavior that I expected actually. Getting all components to adhere to this would like be difficult but I think that it makes sense for all components that do support the version indicator to take that approach. Some components don't actually even have a version indicator in their APIs.
          Hide
          Eugene Koifman added a comment -

          I think one possibility is that whenever any backward incompatible change is made, to bump the version and make sure all the currently supported endpoints are available there. So that every client either only makes v1 calls, or v2 calls, etc but not some mix across versions. Then when time comes, entire v1 namespace is removed. I'm not sure how much easier this is for clients. If you have suggestions, please let me know.

          Show
          Eugene Koifman added a comment - I think one possibility is that whenever any backward incompatible change is made, to bump the version and make sure all the currently supported endpoints are available there. So that every client either only makes v1 calls, or v2 calls, etc but not some mix across versions. Then when time comes, entire v1 namespace is removed. I'm not sure how much easier this is for clients. If you have suggestions, please let me know.
          Hide
          Larry McCay added a comment -

          Eugene Koifman - thanks for the insight. I am still getting my head around how Knox will handle contract changes across the entire ecosystem. I don't think that asking you to revert it will help that in general but getting some sense of how the APIs evolve will inform how we should track those changes. It seems that that we will need to support component versioning rather than API versioning. If this is how APIs evolve across the other components as well then the version indicator in the URL doesn't seem very meaningful to me.

          Show
          Larry McCay added a comment - Eugene Koifman - thanks for the insight. I am still getting my head around how Knox will handle contract changes across the entire ecosystem. I don't think that asking you to revert it will help that in general but getting some sense of how the APIs evolve will inform how we should track those changes. It seems that that we will need to support component versioning rather than API versioning. If this is how APIs evolve across the other components as well then the version indicator in the URL doesn't seem very meaningful to me.
          Hide
          Eugene Koifman added a comment -

          The general rule in HCat/WebHCat is to keep deprecated API for 2 releases. That is why it has been removed now.
          If we had added templeton/v2/jobs instead of templeton/v1/jobs, this would not help the client once v1 is desupported. So we'd have to support deprecated API for ever...

          I think the fundamental issue is that API evolution is not well defined in WebHCat, as you can see it's still at v1.

          Is this change something that Knox can handle or should we restore the API? (The change was made in trunk, so we can still restore it before 0.14 ships)

          Show
          Eugene Koifman added a comment - The general rule in HCat/WebHCat is to keep deprecated API for 2 releases. That is why it has been removed now. If we had added templeton/v2/jobs instead of templeton/v1/jobs, this would not help the client once v1 is desupported. So we'd have to support deprecated API for ever... I think the fundamental issue is that API evolution is not well defined in WebHCat, as you can see it's still at v1. Is this change something that Knox can handle or should we restore the API? (The change was made in trunk, so we can still restore it before 0.14 ships)
          Hide
          Larry McCay added a comment -

          Hmmmm... so this change is backwards compatible then? What happens when a client calls the removed API?

          Show
          Larry McCay added a comment - Hmmmm... so this change is backwards compatible then? What happens when a client calls the removed API?
          Hide
          Eugene Koifman added a comment -

          I think the general idea for bumping version number is when we introduce some backwards incompatible change to an existing end point. This is arguable not the case here. So, no, we were not planning to introduce v2 at this point.

          Show
          Eugene Koifman added a comment - I think the general idea for bumping version number is when we introduce some backwards incompatible change to an existing end point. This is arguable not the case here. So, no, we were not planning to introduce v2 at this point.
          Hide
          Lefty Leverenz added a comment -

          Eugene Koifman, can you answer Larry McCay's question? Because I don't know.

          Show
          Lefty Leverenz added a comment - Eugene Koifman , can you answer Larry McCay 's question? Because I don't know.
          Hide
          Larry McCay added a comment -

          Hi Lefty Leverenz - I am curious whether the v1 is going to be bumped up to v2 in response to the contract change. I believe that it is easier for consuming projects - such as Apache Knox - to be able to multiplex across expected APIs with specific version indicators.

          Show
          Larry McCay added a comment - Hi Lefty Leverenz - I am curious whether the v1 is going to be bumped up to v2 in response to the contract change. I believe that it is easier for consuming projects - such as Apache Knox - to be able to multiplex across expected APIs with specific version indicators.
          Hide
          Eugene Koifman added a comment -

          +1
          Thanks!

          Show
          Eugene Koifman added a comment - +1 Thanks!
          Show
          Lefty Leverenz added a comment - Done: WebHCat Reference GET queue GET queue/:jobid DELETE queue/:jobid GET jobs GET jobs/:jobid DELETE jobs/:jobid

            People

            • Assignee:
              Lefty Leverenz
              Reporter:
              Eugene Koifman
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:

                Development