You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by larry mccay <lm...@apache.org> on 2014/05/05 21:14:08 UTC
Service and API Versioning
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
Re: Service and API Versioning
Posted by larry mccay <la...@gmail.com>.
This is true - I think that we would need to have a bit more sophisticated
and easily authored rewrite mechanism for creating adapters for each
service. If we were gating access to a single API rather than numerous it
would be easier.
I cringe at the thought of testing backward compatibility of APIs across
versions and across multiple services.
This type of feature is probably best exposed as an version adapter
authoring kit that leaves us out of the business directly but enables the
ability for client apps to continue to use their APIs with the use of
various rewrite rules. Leaving behavior incompatibility as an exercise for
the consumer.
On Tue, May 6, 2014 at 9:32 AM, Dilli Arumugam <da...@hortonworks.com>wrote:
> Larry, Kevin,
>
> Agree with your perspectives.
>
> It would be theoretical at this point.
>
> In future, there is a potential that Knox could extend REST backward
> compatibility by at least one more version than provided by service. Knox
> is a proxy and it has the knowledge to deal with different versions. With
> such knowledge, it could also serve as an adapter proxy to certain degree.
>
> Thanks
> Dilli
>
>
>
> On Tue, May 6, 2014 at 5:47 AM, Kevin Minder
> <ke...@hortonworks.com>wrote:
>
> > I also do not think Knox should attempt to mediate between service API
> > versions. There are a few key points here.
> >
> > 1) When services rev their API version they _should_ continue to accept
> > the old version with the old behavior. This is in fact the primary
> reason
> > that the REST community has more or less settled on putting the API
> version
> > in the path of the URL.
> >
> > 2) With the API version in place client can be sure about which API
> > contract they are using. If Knox made that decision for them they would
> > have no way to tell. Granted you can make the argument that it should
> > always be backwards compatible. However if this were the case there
> > wouldn't really have been a need to rev the API version.
> >
> >
> > On 5/6/14 7:30 AM, larry mccay wrote:
> >
> >> 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 <
> darumugam@hortonworks.com
> >> >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 <la...@gmail.com>
> >>> 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
> >>>> <ke...@hortonworks.com>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.
> >>>
> >>>
> >
> > --
> > 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.
>
Re: Service and API Versioning
Posted by Dilli Arumugam <da...@hortonworks.com>.
Larry, Kevin,
Agree with your perspectives.
It would be theoretical at this point.
In future, there is a potential that Knox could extend REST backward
compatibility by at least one more version than provided by service. Knox
is a proxy and it has the knowledge to deal with different versions. With
such knowledge, it could also serve as an adapter proxy to certain degree.
Thanks
Dilli
On Tue, May 6, 2014 at 5:47 AM, Kevin Minder
<ke...@hortonworks.com>wrote:
> I also do not think Knox should attempt to mediate between service API
> versions. There are a few key points here.
>
> 1) When services rev their API version they _should_ continue to accept
> the old version with the old behavior. This is in fact the primary reason
> that the REST community has more or less settled on putting the API version
> in the path of the URL.
>
> 2) With the API version in place client can be sure about which API
> contract they are using. If Knox made that decision for them they would
> have no way to tell. Granted you can make the argument that it should
> always be backwards compatible. However if this were the case there
> wouldn't really have been a need to rev the API version.
>
>
> On 5/6/14 7:30 AM, larry mccay wrote:
>
>> 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 <darumugam@hortonworks.com
>> >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 <la...@gmail.com>
>>> 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
>>>> <ke...@hortonworks.com>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.
>>>
>>>
>
> --
> 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.
Re: Service and API Versioning
Posted by Kevin Minder <ke...@hortonworks.com>.
I also do not think Knox should attempt to mediate between service API
versions. There are a few key points here.
1) When services rev their API version they _should_ continue to accept
the old version with the old behavior. This is in fact the primary
reason that the REST community has more or less settled on putting the
API version in the path of the URL.
2) With the API version in place client can be sure about which API
contract they are using. If Knox made that decision for them they would
have no way to tell. Granted you can make the argument that it should
always be backwards compatible. However if this were the case there
wouldn't really have been a need to rev the API version.
On 5/6/14 7:30 AM, larry mccay wrote:
> 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 <da...@hortonworks.com>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 <la...@gmail.com> 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
>>> <ke...@hortonworks.com>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.
>>
--
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.
Re: Service and API Versioning
Posted by larry mccay <la...@gmail.com>.
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 <da...@hortonworks.com>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 <la...@gmail.com> 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
> > <ke...@hortonworks.com>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.
>
Re: Service and API Versioning
Posted by Dilli Arumugam <da...@hortonworks.com>.
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 <la...@gmail.com> 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
> <ke...@hortonworks.com>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.
Re: Service and API Versioning
Posted by larry mccay <la...@gmail.com>.
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
<ke...@hortonworks.com>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.
>
Re: Service and API Versioning
Posted by Kevin Minder <ke...@hortonworks.com>.
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.