Yeah, Dilli - I don't think there is anything we can do about that. *When* the URL is different than it will be up to the client to have to know that. We certainly don't want to be in the business of trying to normalize contracts across versions.
I'm not sure that it will be confusing but it will limit the use of clients across service versions - with or without Knox in the picture unless it is built into the client code somehow. Nature of the beast. --larry On Tue, May 6, 2014 at 1:37 AM, Dilli Arumugam <[email protected]>wrote: > Does client of Knox has the responsibility of constructing the right Knox > URL based on the version of service running in the cluster? > > If Knox is fronting multiple clusters with each cluster having different > version of service, the client would construct different URL patterns based > on the version of the service? > > This could be confusing to the end client. > > Thanks > Dilli > > > > On Mon, May 5, 2014 at 1:46 PM, larry mccay <[email protected]> wrote: > > > They are willing to revert and he followed up with an approach that > matches > > what my expectations would have been. Which would be a given client only > > using one version at a time. Then eventually they would deprecate and > > retire entire versions. > > > > As I said in the jira - that would be what I would expect and would > > probably be great for components to do but we will need to likely use the > > component versioning anyway because not all components will do it that > way > > and some don't even have a version indicator. > > > > > > On Mon, May 5, 2014 at 4:34 PM, Kevin Minder > > <[email protected]>wrote: > > > > > Seems to me they should still be reving their version number. For > > example > > > .../v1/queue > > > .../v2/job > > > Not that we have any say in the matter. > > > > > > > > > On 5/5/14 3:14 PM, larry mccay wrote: > > > > > >> All - > > >> > > >> The discussion on jira: > > >> https://issues.apache.org/jira/browse/HIVE-7010leads me to believe > > >> > > >> that we will need to deal with multiple API versions > > >> via component release versions - as Kevin has spoken of as well. > > >> > > >> Templeton is removing the .../v1/queue APIs and adding a .../v1/job > > APIs. > > >> > > >> The way that they seem to evolve APIs is to deprecate something for 2 > > >> releases and then remove them. Presumably the notice to prepare to > > migrate > > >> is used as "backward compatibility" - which may make sense. > > >> > > >> With the addition of service params in 0.4.0, we may be able to > indicate > > >> the version as a param and have the contributors load the appropriate > > >> rewrite rules. Otherwise, we could also add an explicit version > element > > to > > >> the service definitions. > > >> > > >> Either way, we will need to default the versions to the supported > > >> component > > >> versions in 0.4.0 - since we don't have any explicit version mechanism > > >> yet. > > >> > > >> Thoughts? > > >> > > >> --larry > > >> > > >> > > > > > > -- > > > CONFIDENTIALITY NOTICE > > > NOTICE: This message is intended for the use of the individual or > entity > > > to which it is addressed and may contain information that is > > confidential, > > > privileged and exempt from disclosure under applicable law. If the > reader > > > of this message is not the intended recipient, you are hereby notified > > that > > > any printing, copying, dissemination, distribution, disclosure or > > > forwarding of this communication is strictly prohibited. If you have > > > received this communication in error, please contact the sender > > immediately > > > and delete it from your system. Thank You. > > > > > > > -- > CONFIDENTIALITY NOTICE > NOTICE: This message is intended for the use of the individual or entity to > which it is addressed and may contain information that is confidential, > privileged and exempt from disclosure under applicable law. If the reader > of this message is not the intended recipient, you are hereby notified that > any printing, copying, dissemination, distribution, disclosure or > forwarding of this communication is strictly prohibited. If you have > received this communication in error, please contact the sender immediately > and delete it from your system. Thank You. >
