On 29 May 2014, at 18:43, Matthew Farrellee wrote:
> i do not think we should release any images that have a root password set
> (essentially a backdoor).
>
> for K we should deprecate the hadoop1 versions and thus significantly cut the
> size of the new image artifact.
>
Agree don’t publis
On 05/29/2014 10:22 AM, Sergey Lukjanov wrote:
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size of
So, it looks like we have an agreement on all question.
There is only one technical question - keeping release images means
that we need to keep the whole matrix of images: plugin X version X
OSy [X root-passwdord]. I'll take a look on total size of them and
ability to publish them on OS infra.
O
Bunch of responses/thoughts:
> API
I'm ok that semantics additions could be done in one API version w/o
increasing minor version. I like the idea to keep only major API
versions starting from the next API version.
RE backward compat period, for now 1-2 cycles is ok.
> Images
Agreed that we shou
Catching up...
On Thu, 2014-05-29 at 15:59 +0400, Alexander Ignatov wrote:
> On 28 May 2014, at 17:14, Sergey Lukjanov wrote:
> > 1. How should we handle addition of new functionality to the API,
> > should we bump minor version and just add new endpoints?
>
> Agree with most of folks. No new ve
On 28 May 2014, at 17:14, Sergey Lukjanov wrote:
> 1. How should we handle addition of new functionality to the API,
> should we bump minor version and just add new endpoints?
Agree with most of folks. No new versions on adding new endpoints.
Semantic changes require new major version of rest a
On 05/28/2014 03:50 PM, Andrew Lazarev wrote:
for juno we should just have a v1 api (there can still be a v1.1
endpoint, but it should be deprecated), and maybe a v2 api
+1 any semantic changes require new major version number
+1 api should only have a major number (no 1.1 or 2
> for juno we should just have a v1 api (there can still be a v1.1 endpoint,
> but it should be deprecated), and maybe a v2 api
>
> +1 any semantic changes require new major version number
>
> +1 api should only have a major number (no 1.1 or 2.1)
>
In this case we will end up with new major numbe
On 05/28/2014 01:59 PM, Michael McCune wrote:
- Original Message -
Open questions
1. How should we handle addition of new functionality to the API,
should we bump minor version and just add new endpoints?
I think we should not include the minor revision number in the url.
Looking a
On 05/28/2014 09:14 AM, Sergey Lukjanov wrote:
Hey folks,
it's a small wrap-up for the two topics "Sahara backward compat" and "
"Hadoop cluster backward compatibility", both were discussed on design
summit, etherpad [0] contains info about them. There are some open
questions listed in the end o
- Original Message -
> > Open questions
>
> 1. How should we handle addition of new functionality to the API,
> should we bump minor version and just add new endpoints?
I think we should not include the minor revision number in the url. Looking at
some of the other projects (nova, keys
Hey folks,
it's a small wrap-up for the two topics "Sahara backward compat" and "
"Hadoop cluster backward compatibility", both were discussed on design
summit, etherpad [0] contains info about them. There are some open
questions listed in the end of email, please, don't skip them :)
> Sahara bac
12 matches
Mail list logo
