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 2017/06/08 13:12:37 UTC
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
All -
Just an FYI - I am currently trying to resolve a number of url encoding
related issues that were introduced by a change to get proxying of Ambari
UI working properly.
Personally, I feel this is a blocker and would like to get a fix in for
0.13.0.
At the same time, we may determine that most of the issues are edge cases
or at least not very common.
I am aware of WebHDFS issues with spaces in the filename or path and HBase
related issues where reserved characters such as '/' are being used.
It appears that this has been introduced by trying to accommodate Ambari's
use of an unwise character '|' in its URLs.
A general approach of encoding and decoding the URL has led to a number of
inconsistencies with what the backend services expect.
I will attempt to find the most surgical and least invasive fix for this
issue as to reduce risk for 0.13.0 closedown.
thanks,
--larry
On Wed, May 24, 2017 at 9:49 AM, Sandeep More <mo...@gmail.com> wrote:
> Ah ! got it.
>
>
> On Wed, May 24, 2017 at 9:46 AM, larry mccay <lm...@apache.org> wrote:
>
>> Actually, what I am proposing is that we *branch* on Monday and double
>> commit as necessary in order to close down before the rc and through the
>> release process. I'd like to get to a rc by the end of next week - 6/2 - if
>> not sooner.
>>
>> We will also likely need to double commit bug fixes to master and 0.13.0
>> branch for some time in case we need a new 0.13.x release to avoid the
>> 1.0.0 refactoring for existing deployments.
>>
>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More <mo...@gmail.com>
>> wrote:
>>
>>> Hello Larry,
>>>
>>> Thanks for starting the discussion, given that we are away from the
>>> target date just by a week I too think that releasing 0.13.0 on Monday and
>>> then working towards 1.0.0 (package refactoring) would be a good idea. One
>>> upshot of this is that we don't have to double commit as we had initially
>>> thought :)
>>>
>>> Best,
>>> Sandeep
>>>
>>> On Tue, May 23, 2017 at 4:44 PM, larry mccay <lm...@apache.org> wrote:
>>>
>>>> All -
>>>>
>>>> As we targeted a 5/31 date for the release of 0.13.0, I think we need
>>>> to look at managing the current scope for 0.13.0 as well as the plan for a
>>>> 1.0.0 again.
>>>> Since we are just a week away from the target date, I think that
>>>> refactoring the package names for the 1.0.0 release at the same time is a
>>>> stretch.
>>>>
>>>> We currently have 22 or so JIRAs and will not be able to get them all
>>>> into 0.13.0.
>>>> What do you think about the following:
>>>>
>>>> * We manage the existing scope over the rest of this week.
>>>> * I will post comments on some JIRAs about potentially moving them out
>>>> and without any movement will move them out by Friday 26th.
>>>> * JIRAs that I think are outside the KIPs that are driving the release
>>>> or that may destabilize the release I will just move.
>>>>
>>>> If I move something that is something wanted by you, please feel free
>>>> to add it back, comment or raise discussion on this thread.
>>>>
>>>> I also propose that we branch for 0.13.0 on Monday 5/29th and work
>>>> toward getting the rest of the required issues in and an RC by the 31st or
>>>> by end of the week. Once we release 0.13.0, we should refactor master for
>>>> the 1.0.0 release - concentrate on closing down any fallout from package
>>>> name changes and do an immediate 1.0.0 release.
>>>>
>>>> Thoughts?
>>>>
>>>> thanks,
>>>>
>>>> --larry
>>>>
>>>>
>>>> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More <mo...@gmail.com>
>>>> wrote:
>>>>
>>>>> Sounds great !
>>>>>
>>>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <lm...@apache.org>
>>>>> wrote:
>>>>>
>>>>> > That sounds reasonable to me.
>>>>> > I was hoping to get as many of the patches available and important
>>>>> bugs
>>>>> > fixed before the split as well.
>>>>> > Minimizing the double commits/patches is definitely in our interest.
>>>>> >
>>>>> > At the same time, we need to have enough time to spend on
>>>>> refactoring as
>>>>> > well.
>>>>> > I'm thinking that May 15th may be a good branch point - giving us 2
>>>>> weeks
>>>>> > to concentrate on repackaging and adapter classes.
>>>>> >
>>>>> >
>>>>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <
>>>>> moresandeep@gmail.com>
>>>>> > wrote:
>>>>> >
>>>>> > > Oh, I guess it depends on when we split, I was planning on taking
>>>>> up the
>>>>> > > new feature (mentioned in earlier email).
>>>>> > > If we decide to go for the feature I was hoping to get it in sooner
>>>>> > (before
>>>>> > > the split) if possible.
>>>>> > >
>>>>> > >
>>>>> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay <lm...@apache.org>
>>>>> wrote:
>>>>> > >
>>>>> > > > Actually, I meant 5/31 for a release date.
>>>>> > > > You think that is too early for a repackaged and narrowly scoped
>>>>> 1.0.0?
>>>>> > > >
>>>>> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
>>>>> moresandeep@gmail.com>
>>>>> > > > wrote:
>>>>> > > >
>>>>> > > > > Great, thanks Larry for starting the discussion and the KIP !
>>>>> > > > >
>>>>> > > > > May 31st target date sounds good, just to be sure, this date
>>>>> is when
>>>>> > we
>>>>> > > > > split 0.13 right ?
>>>>> > > > >
>>>>> > > > > KIP-5 looks good, I will try to see whether I can find any
>>>>> extended
>>>>> > > > classes
>>>>> > > > > that might need adapter classes.
>>>>> > > > >
>>>>> > > > > Best,
>>>>> > > > > Sandeep
>>>>> > > > >
>>>>> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay <
>>>>> lmccay@apache.org>
>>>>> > > wrote:
>>>>> > > > >
>>>>> > > > > > Forgot to add the [1] to the initial mail.
>>>>> > > > > >
>>>>> > > > > > Enjoy...
>>>>> > > > > >
>>>>> > > > > > 1.
>>>>> > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
>>>>> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
>>>>> > > > > rFEHJG6G5sB4Q%40mail.gmail.
>>>>> > > > > > com%3E
>>>>> > > > > >
>>>>> > > > > >
>>>>> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay <
>>>>> lmccay@apache.org>
>>>>> > > > wrote:
>>>>> > > > > >
>>>>> > > > > > > All -
>>>>> > > > > > >
>>>>> > > > > > > After many recent distractions, I would like to start the
>>>>> scoping
>>>>> > > and
>>>>> > > > > > > planning for what will likely be our 1.0.0 release.
>>>>> > > > > > >
>>>>> > > > > > > As discussed in [1], we will begin to repackaging/refactor
>>>>> master
>>>>> > > > after
>>>>> > > > > > > branching for an 0.13.0 release and only release 0.13.0 if
>>>>> the
>>>>> > work
>>>>> > > > on
>>>>> > > > > > > repackaging master doesn't seem like it will make whatever
>>>>> date
>>>>> > we
>>>>> > > > > chose
>>>>> > > > > > > for the release.
>>>>> > > > > > >
>>>>> > > > > > > That said, I would like to limit scope to only those new
>>>>> features
>>>>> > > and
>>>>> > > > > bug
>>>>> > > > > > > fixes that are absolutely necessary or low risk for
>>>>> breaking
>>>>> > > backward
>>>>> > > > > > > compatibility.
>>>>> > > > > > >
>>>>> > > > > > > I propose that the following is needed:
>>>>> > > > > > >
>>>>> > > > > > > * A KIP (KIP-5) be created for the repackaging/refactoring
>>>>> work
>>>>> > > > > required
>>>>> > > > > > > for the 1.0.0 release
>>>>> > > > > > > * Determine the existing JIRAs and patches that must/can
>>>>> be in
>>>>> > the
>>>>> > > > > > release
>>>>> > > > > > > but try and defer as many as possible
>>>>> > > > > > > * Determine required improvements - I have a few security
>>>>> related
>>>>> > > > > > > improvements in mind
>>>>> > > > > > > * Write up KIPs for features that involve architectural
>>>>> and/or
>>>>> > > > > strategic
>>>>> > > > > > > feature details
>>>>> > > > > > > * Determine when to branch for 0.13.0 and take on double
>>>>> commits
>>>>> > > for
>>>>> > > > > > 1.0.0
>>>>> > > > > > > parity
>>>>> > > > > > > * Agree on a target release date
>>>>> > > > > > >
>>>>> > > > > > > My initial thought is to target May 31st as the release
>>>>> date.
>>>>> > > > > > >
>>>>> > > > > > > Thoughts?
>>>>> > > > > > >
>>>>> > > > > > > --larry
>>>>> > > > > > >
>>>>> > > > > >
>>>>> > > > >
>>>>> > > >
>>>>> > >
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Posted by larry mccay <lm...@apache.org>.
Okay, All -
I am serious this time.
Planning to branch for 0.13.0 this weekend or early next week.
I will be reviewing and committing outstanding patches that are ready to go
and looking to get an RC next week.
The following are the current outstanding JIRAs for 0.13.0.
If anyone has any additional issues that should be considered critical for
0.13.0 please file a JIRA or set the Fix Version to 0.13.0 for
consideration.
TPatch InfoKeySummaryAssigneeReporterPStatusResolutionCreatedUpdatedDue
<https://issues.apache.org/jira/browse/KNOX-979>[image: Bug]
<https://issues.apache.org/jira/browse/KNOX-979> KNOX-979
<https://issues.apache.org/jira/browse/KNOX-979>
Documentation for Atlas UI & Atlas Rest Api via Knox Proxy
<https://issues.apache.org/jira/browse/KNOX-979>
Nixon Rodrigues
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=nixonrodrigues>
Nixon
Rodrigues
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=nixonrodrigues>
[image:
Major] PATCH AVAILABLE *Unresolved* 06/Jul/17 02/Aug/17
<https://issues.apache.org/jira/rest/api/1.0/issues/13085193/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin>
<https://issues.apache.org/jira/browse/KNOX-976>[image: Task]
<https://issues.apache.org/jira/browse/KNOX-976> KNOX-976
<https://issues.apache.org/jira/browse/KNOX-976>
Add Jupyter Kernel Gateway Service Definitions
<https://issues.apache.org/jira/browse/KNOX-976>
Jesus Alvarez
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jesus.alv> Jesus
Alvarez
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jesus.alv> [image:
Major] PATCH AVAILABLE *Unresolved* 22/Jun/17 19/Jul/17
<https://issues.apache.org/jira/rest/api/1.0/issues/13081856/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin>
<https://issues.apache.org/jira/browse/KNOX-972>[image: Bug]
<https://issues.apache.org/jira/browse/KNOX-972> KNOX-972
<https://issues.apache.org/jira/browse/KNOX-972>
Update Hbase UI service <https://issues.apache.org/jira/browse/KNOX-972>
Jeffrey E Rodriguez
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeffreyr97>
Jeffrey
E Rodriguez
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeffreyr97>
[image:
Major] PATCH AVAILABLE *Unresolved* 22/Jun/17 03/Aug/17 23/Jun/17
<https://issues.apache.org/jira/rest/api/1.0/issues/13081847/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin>
<https://issues.apache.org/jira/browse/KNOX-789>[image: New Feature]
<https://issues.apache.org/jira/browse/KNOX-789> KNOX-789
<https://issues.apache.org/jira/browse/KNOX-789>
Apache Atlas REST API support
<https://issues.apache.org/jira/browse/KNOX-789>
Nixon Rodrigues
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=nixonrodrigues>
Jeffrey
E Rodriguez
<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=jeffreyr97>
[image:
Major] REOPENED *Unresolved* 15/Nov/16 03/Aug/17 Actions
<https://issues.apache.org/jira/rest/api/1.0/issues/13020977/ActionsAndOperations?atl_token=A5KQ-2QAV-T4JA-FDED|8625c7065e7e8cc0a730553e2a34cb6e913d7cde|lin>
Thanks,
--larry
On Mon, Jun 26, 2017 at 12:35 PM, Jeffrey Rodriguez <je...@gmail.com>
wrote:
> Thanks for you efforts to resolve the encoding issues.
>
> Being that most of this changes were introduce to help with Ambari URL
> mapping.
>
> These changes cause some grief to us (my team) when moving to Knox 0.11.0
> and some of the UIs we supported would break.
>
> Instead of making such a general changes and being that UIs don't follow a
> spec. thus we may run into special cases. It would have been nice to make
> the encoding an "optional" attribute thus the changes could have been made
> just for Ambari UI URL or any other UI that require these changes for
> encoding.
>
> On a related topic, it is very hard to support different versions of the UI
> even with versioning. The issue is that most of the times we don't know
> what has changed and rules that used to work may not work. Here is the need
> to have a tool to test the UI in a systematic way. We thought of a crawling
> tool but that presented other challenges. I bring this up so we may discuss
> UI rewrites which different of REST which are APIs change from version to
> version, also UI page are more complex in style and way to manipulate
> requests/responses.
>
> Regards,
> Jeff Rodriguez
>
>
>
>
> On Mon, Jun 26, 2017 at 8:47 AM, larry mccay <lm...@apache.org> wrote:
>
> > While working on the encoding issues, we have had a number of JIRAs filed
> > for updated UI service definitions.
> > I know this happens to be a sore spot for many deployments since many
> have
> > become obsolete.
> > UIs are such a moving target.
> >
> > I would like to try and wait to get these patches in for the 0.13.0
> > release.
> >
> > We also have some additional verification of the encoding fix outstanding
> > and we are waiting treating this as a blocker for the release.
> >
> > I will be making another pass through the open JIRAs shortly in order to
> > push things out to the next release for managing scope of 0.13.0.
> >
> > Thank you for your patience!
> >
> > On Thu, Jun 8, 2017 at 9:12 AM, larry mccay <lm...@apache.org> wrote:
> >
> > > All -
> > >
> > > Just an FYI - I am currently trying to resolve a number of url encoding
> > > related issues that were introduced by a change to get proxying of
> Ambari
> > > UI working properly.
> > >
> > > Personally, I feel this is a blocker and would like to get a fix in for
> > > 0.13.0.
> > > At the same time, we may determine that most of the issues are edge
> cases
> > > or at least not very common.
> > > I am aware of WebHDFS issues with spaces in the filename or path and
> > HBase
> > > related issues where reserved characters such as '/' are being used.
> > >
> > > It appears that this has been introduced by trying to accommodate
> > Ambari's
> > > use of an unwise character '|' in its URLs.
> > > A general approach of encoding and decoding the URL has led to a number
> > of
> > > inconsistencies with what the backend services expect.
> > >
> > > I will attempt to find the most surgical and least invasive fix for
> this
> > > issue as to reduce risk for 0.13.0 closedown.
> > >
> > > thanks,
> > >
> > > --larry
> > >
> > > On Wed, May 24, 2017 at 9:49 AM, Sandeep More <mo...@gmail.com>
> > > wrote:
> > >
> > >> Ah ! got it.
> > >>
> > >>
> > >> On Wed, May 24, 2017 at 9:46 AM, larry mccay <lm...@apache.org>
> wrote:
> > >>
> > >>> Actually, what I am proposing is that we *branch* on Monday and
> double
> > >>> commit as necessary in order to close down before the rc and through
> > the
> > >>> release process. I'd like to get to a rc by the end of next week -
> 6/2
> > - if
> > >>> not sooner.
> > >>>
> > >>> We will also likely need to double commit bug fixes to master and
> > 0.13.0
> > >>> branch for some time in case we need a new 0.13.x release to avoid
> the
> > >>> 1.0.0 refactoring for existing deployments.
> > >>>
> > >>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More <moresandeep@gmail.com
> >
> > >>> wrote:
> > >>>
> > >>>> Hello Larry,
> > >>>>
> > >>>> Thanks for starting the discussion, given that we are away from the
> > >>>> target date just by a week I too think that releasing 0.13.0 on
> > Monday and
> > >>>> then working towards 1.0.0 (package refactoring) would be a good
> > idea. One
> > >>>> upshot of this is that we don't have to double commit as we had
> > initially
> > >>>> thought :)
> > >>>>
> > >>>> Best,
> > >>>> Sandeep
> > >>>>
> > >>>> On Tue, May 23, 2017 at 4:44 PM, larry mccay <lm...@apache.org>
> > wrote:
> > >>>>
> > >>>>> All -
> > >>>>>
> > >>>>> As we targeted a 5/31 date for the release of 0.13.0, I think we
> need
> > >>>>> to look at managing the current scope for 0.13.0 as well as the
> plan
> > for a
> > >>>>> 1.0.0 again.
> > >>>>> Since we are just a week away from the target date, I think that
> > >>>>> refactoring the package names for the 1.0.0 release at the same
> time
> > is a
> > >>>>> stretch.
> > >>>>>
> > >>>>> We currently have 22 or so JIRAs and will not be able to get them
> all
> > >>>>> into 0.13.0.
> > >>>>> What do you think about the following:
> > >>>>>
> > >>>>> * We manage the existing scope over the rest of this week.
> > >>>>> * I will post comments on some JIRAs about potentially moving them
> > out
> > >>>>> and without any movement will move them out by Friday 26th.
> > >>>>> * JIRAs that I think are outside the KIPs that are driving the
> > release
> > >>>>> or that may destabilize the release I will just move.
> > >>>>>
> > >>>>> If I move something that is something wanted by you, please feel
> free
> > >>>>> to add it back, comment or raise discussion on this thread.
> > >>>>>
> > >>>>> I also propose that we branch for 0.13.0 on Monday 5/29th and work
> > >>>>> toward getting the rest of the required issues in and an RC by the
> > 31st or
> > >>>>> by end of the week. Once we release 0.13.0, we should refactor
> > master for
> > >>>>> the 1.0.0 release - concentrate on closing down any fallout from
> > package
> > >>>>> name changes and do an immediate 1.0.0 release.
> > >>>>>
> > >>>>> Thoughts?
> > >>>>>
> > >>>>> thanks,
> > >>>>>
> > >>>>> --larry
> > >>>>>
> > >>>>>
> > >>>>> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More <
> moresandeep@gmail.com
> > >
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Sounds great !
> > >>>>>>
> > >>>>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <lm...@apache.org>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>> > That sounds reasonable to me.
> > >>>>>> > I was hoping to get as many of the patches available and
> important
> > >>>>>> bugs
> > >>>>>> > fixed before the split as well.
> > >>>>>> > Minimizing the double commits/patches is definitely in our
> > interest.
> > >>>>>> >
> > >>>>>> > At the same time, we need to have enough time to spend on
> > >>>>>> refactoring as
> > >>>>>> > well.
> > >>>>>> > I'm thinking that May 15th may be a good branch point - giving
> us
> > 2
> > >>>>>> weeks
> > >>>>>> > to concentrate on repackaging and adapter classes.
> > >>>>>> >
> > >>>>>> >
> > >>>>>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <
> > >>>>>> moresandeep@gmail.com>
> > >>>>>> > wrote:
> > >>>>>> >
> > >>>>>> > > Oh, I guess it depends on when we split, I was planning on
> > taking
> > >>>>>> up the
> > >>>>>> > > new feature (mentioned in earlier email).
> > >>>>>> > > If we decide to go for the feature I was hoping to get it in
> > >>>>>> sooner
> > >>>>>> > (before
> > >>>>>> > > the split) if possible.
> > >>>>>> > >
> > >>>>>> > >
> > >>>>>> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay <
> > lmccay@apache.org>
> > >>>>>> wrote:
> > >>>>>> > >
> > >>>>>> > > > Actually, I meant 5/31 for a release date.
> > >>>>>> > > > You think that is too early for a repackaged and narrowly
> > >>>>>> scoped 1.0.0?
> > >>>>>> > > >
> > >>>>>> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
> > >>>>>> moresandeep@gmail.com>
> > >>>>>> > > > wrote:
> > >>>>>> > > >
> > >>>>>> > > > > Great, thanks Larry for starting the discussion and the
> KIP
> > !
> > >>>>>> > > > >
> > >>>>>> > > > > May 31st target date sounds good, just to be sure, this
> date
> > >>>>>> is when
> > >>>>>> > we
> > >>>>>> > > > > split 0.13 right ?
> > >>>>>> > > > >
> > >>>>>> > > > > KIP-5 looks good, I will try to see whether I can find any
> > >>>>>> extended
> > >>>>>> > > > classes
> > >>>>>> > > > > that might need adapter classes.
> > >>>>>> > > > >
> > >>>>>> > > > > Best,
> > >>>>>> > > > > Sandeep
> > >>>>>> > > > >
> > >>>>>> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay <
> > >>>>>> lmccay@apache.org>
> > >>>>>> > > wrote:
> > >>>>>> > > > >
> > >>>>>> > > > > > Forgot to add the [1] to the initial mail.
> > >>>>>> > > > > >
> > >>>>>> > > > > > Enjoy...
> > >>>>>> > > > > >
> > >>>>>> > > > > > 1.
> > >>>>>> > > > > > http://mail-archives.apache.
> org/mod_mbox/knox-dev/201704.
> > >>>>>> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
> > >>>>>> > > > > rFEHJG6G5sB4Q%40mail.gmail.
> > >>>>>> > > > > > com%3E
> > >>>>>> > > > > >
> > >>>>>> > > > > >
> > >>>>>> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay <
> > >>>>>> lmccay@apache.org>
> > >>>>>> > > > wrote:
> > >>>>>> > > > > >
> > >>>>>> > > > > > > All -
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > After many recent distractions, I would like to start
> > the
> > >>>>>> scoping
> > >>>>>> > > and
> > >>>>>> > > > > > > planning for what will likely be our 1.0.0 release.
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > As discussed in [1], we will begin to
> > >>>>>> repackaging/refactor master
> > >>>>>> > > > after
> > >>>>>> > > > > > > branching for an 0.13.0 release and only release
> 0.13.0
> > >>>>>> if the
> > >>>>>> > work
> > >>>>>> > > > on
> > >>>>>> > > > > > > repackaging master doesn't seem like it will make
> > >>>>>> whatever date
> > >>>>>> > we
> > >>>>>> > > > > chose
> > >>>>>> > > > > > > for the release.
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > That said, I would like to limit scope to only those
> new
> > >>>>>> features
> > >>>>>> > > and
> > >>>>>> > > > > bug
> > >>>>>> > > > > > > fixes that are absolutely necessary or low risk for
> > >>>>>> breaking
> > >>>>>> > > backward
> > >>>>>> > > > > > > compatibility.
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > I propose that the following is needed:
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > * A KIP (KIP-5) be created for the
> > >>>>>> repackaging/refactoring work
> > >>>>>> > > > > required
> > >>>>>> > > > > > > for the 1.0.0 release
> > >>>>>> > > > > > > * Determine the existing JIRAs and patches that
> must/can
> > >>>>>> be in
> > >>>>>> > the
> > >>>>>> > > > > > release
> > >>>>>> > > > > > > but try and defer as many as possible
> > >>>>>> > > > > > > * Determine required improvements - I have a few
> > security
> > >>>>>> related
> > >>>>>> > > > > > > improvements in mind
> > >>>>>> > > > > > > * Write up KIPs for features that involve
> architectural
> > >>>>>> and/or
> > >>>>>> > > > > strategic
> > >>>>>> > > > > > > feature details
> > >>>>>> > > > > > > * Determine when to branch for 0.13.0 and take on
> double
> > >>>>>> commits
> > >>>>>> > > for
> > >>>>>> > > > > > 1.0.0
> > >>>>>> > > > > > > parity
> > >>>>>> > > > > > > * Agree on a target release date
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > My initial thought is to target May 31st as the
> release
> > >>>>>> date.
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > Thoughts?
> > >>>>>> > > > > > >
> > >>>>>> > > > > > > --larry
> > >>>>>> > > > > > >
> > >>>>>> > > > > >
> > >>>>>> > > > >
> > >>>>>> > > >
> > >>>>>> > >
> > >>>>>> >
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> > >
> >
>
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Posted by Jeffrey Rodriguez <je...@gmail.com>.
Thanks for you efforts to resolve the encoding issues.
Being that most of this changes were introduce to help with Ambari URL
mapping.
These changes cause some grief to us (my team) when moving to Knox 0.11.0
and some of the UIs we supported would break.
Instead of making such a general changes and being that UIs don't follow a
spec. thus we may run into special cases. It would have been nice to make
the encoding an "optional" attribute thus the changes could have been made
just for Ambari UI URL or any other UI that require these changes for
encoding.
On a related topic, it is very hard to support different versions of the UI
even with versioning. The issue is that most of the times we don't know
what has changed and rules that used to work may not work. Here is the need
to have a tool to test the UI in a systematic way. We thought of a crawling
tool but that presented other challenges. I bring this up so we may discuss
UI rewrites which different of REST which are APIs change from version to
version, also UI page are more complex in style and way to manipulate
requests/responses.
Regards,
Jeff Rodriguez
On Mon, Jun 26, 2017 at 8:47 AM, larry mccay <lm...@apache.org> wrote:
> While working on the encoding issues, we have had a number of JIRAs filed
> for updated UI service definitions.
> I know this happens to be a sore spot for many deployments since many have
> become obsolete.
> UIs are such a moving target.
>
> I would like to try and wait to get these patches in for the 0.13.0
> release.
>
> We also have some additional verification of the encoding fix outstanding
> and we are waiting treating this as a blocker for the release.
>
> I will be making another pass through the open JIRAs shortly in order to
> push things out to the next release for managing scope of 0.13.0.
>
> Thank you for your patience!
>
> On Thu, Jun 8, 2017 at 9:12 AM, larry mccay <lm...@apache.org> wrote:
>
> > All -
> >
> > Just an FYI - I am currently trying to resolve a number of url encoding
> > related issues that were introduced by a change to get proxying of Ambari
> > UI working properly.
> >
> > Personally, I feel this is a blocker and would like to get a fix in for
> > 0.13.0.
> > At the same time, we may determine that most of the issues are edge cases
> > or at least not very common.
> > I am aware of WebHDFS issues with spaces in the filename or path and
> HBase
> > related issues where reserved characters such as '/' are being used.
> >
> > It appears that this has been introduced by trying to accommodate
> Ambari's
> > use of an unwise character '|' in its URLs.
> > A general approach of encoding and decoding the URL has led to a number
> of
> > inconsistencies with what the backend services expect.
> >
> > I will attempt to find the most surgical and least invasive fix for this
> > issue as to reduce risk for 0.13.0 closedown.
> >
> > thanks,
> >
> > --larry
> >
> > On Wed, May 24, 2017 at 9:49 AM, Sandeep More <mo...@gmail.com>
> > wrote:
> >
> >> Ah ! got it.
> >>
> >>
> >> On Wed, May 24, 2017 at 9:46 AM, larry mccay <lm...@apache.org> wrote:
> >>
> >>> Actually, what I am proposing is that we *branch* on Monday and double
> >>> commit as necessary in order to close down before the rc and through
> the
> >>> release process. I'd like to get to a rc by the end of next week - 6/2
> - if
> >>> not sooner.
> >>>
> >>> We will also likely need to double commit bug fixes to master and
> 0.13.0
> >>> branch for some time in case we need a new 0.13.x release to avoid the
> >>> 1.0.0 refactoring for existing deployments.
> >>>
> >>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More <mo...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hello Larry,
> >>>>
> >>>> Thanks for starting the discussion, given that we are away from the
> >>>> target date just by a week I too think that releasing 0.13.0 on
> Monday and
> >>>> then working towards 1.0.0 (package refactoring) would be a good
> idea. One
> >>>> upshot of this is that we don't have to double commit as we had
> initially
> >>>> thought :)
> >>>>
> >>>> Best,
> >>>> Sandeep
> >>>>
> >>>> On Tue, May 23, 2017 at 4:44 PM, larry mccay <lm...@apache.org>
> wrote:
> >>>>
> >>>>> All -
> >>>>>
> >>>>> As we targeted a 5/31 date for the release of 0.13.0, I think we need
> >>>>> to look at managing the current scope for 0.13.0 as well as the plan
> for a
> >>>>> 1.0.0 again.
> >>>>> Since we are just a week away from the target date, I think that
> >>>>> refactoring the package names for the 1.0.0 release at the same time
> is a
> >>>>> stretch.
> >>>>>
> >>>>> We currently have 22 or so JIRAs and will not be able to get them all
> >>>>> into 0.13.0.
> >>>>> What do you think about the following:
> >>>>>
> >>>>> * We manage the existing scope over the rest of this week.
> >>>>> * I will post comments on some JIRAs about potentially moving them
> out
> >>>>> and without any movement will move them out by Friday 26th.
> >>>>> * JIRAs that I think are outside the KIPs that are driving the
> release
> >>>>> or that may destabilize the release I will just move.
> >>>>>
> >>>>> If I move something that is something wanted by you, please feel free
> >>>>> to add it back, comment or raise discussion on this thread.
> >>>>>
> >>>>> I also propose that we branch for 0.13.0 on Monday 5/29th and work
> >>>>> toward getting the rest of the required issues in and an RC by the
> 31st or
> >>>>> by end of the week. Once we release 0.13.0, we should refactor
> master for
> >>>>> the 1.0.0 release - concentrate on closing down any fallout from
> package
> >>>>> name changes and do an immediate 1.0.0 release.
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> thanks,
> >>>>>
> >>>>> --larry
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More <moresandeep@gmail.com
> >
> >>>>> wrote:
> >>>>>
> >>>>>> Sounds great !
> >>>>>>
> >>>>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <lm...@apache.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>> > That sounds reasonable to me.
> >>>>>> > I was hoping to get as many of the patches available and important
> >>>>>> bugs
> >>>>>> > fixed before the split as well.
> >>>>>> > Minimizing the double commits/patches is definitely in our
> interest.
> >>>>>> >
> >>>>>> > At the same time, we need to have enough time to spend on
> >>>>>> refactoring as
> >>>>>> > well.
> >>>>>> > I'm thinking that May 15th may be a good branch point - giving us
> 2
> >>>>>> weeks
> >>>>>> > to concentrate on repackaging and adapter classes.
> >>>>>> >
> >>>>>> >
> >>>>>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <
> >>>>>> moresandeep@gmail.com>
> >>>>>> > wrote:
> >>>>>> >
> >>>>>> > > Oh, I guess it depends on when we split, I was planning on
> taking
> >>>>>> up the
> >>>>>> > > new feature (mentioned in earlier email).
> >>>>>> > > If we decide to go for the feature I was hoping to get it in
> >>>>>> sooner
> >>>>>> > (before
> >>>>>> > > the split) if possible.
> >>>>>> > >
> >>>>>> > >
> >>>>>> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay <
> lmccay@apache.org>
> >>>>>> wrote:
> >>>>>> > >
> >>>>>> > > > Actually, I meant 5/31 for a release date.
> >>>>>> > > > You think that is too early for a repackaged and narrowly
> >>>>>> scoped 1.0.0?
> >>>>>> > > >
> >>>>>> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
> >>>>>> moresandeep@gmail.com>
> >>>>>> > > > wrote:
> >>>>>> > > >
> >>>>>> > > > > Great, thanks Larry for starting the discussion and the KIP
> !
> >>>>>> > > > >
> >>>>>> > > > > May 31st target date sounds good, just to be sure, this date
> >>>>>> is when
> >>>>>> > we
> >>>>>> > > > > split 0.13 right ?
> >>>>>> > > > >
> >>>>>> > > > > KIP-5 looks good, I will try to see whether I can find any
> >>>>>> extended
> >>>>>> > > > classes
> >>>>>> > > > > that might need adapter classes.
> >>>>>> > > > >
> >>>>>> > > > > Best,
> >>>>>> > > > > Sandeep
> >>>>>> > > > >
> >>>>>> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay <
> >>>>>> lmccay@apache.org>
> >>>>>> > > wrote:
> >>>>>> > > > >
> >>>>>> > > > > > Forgot to add the [1] to the initial mail.
> >>>>>> > > > > >
> >>>>>> > > > > > Enjoy...
> >>>>>> > > > > >
> >>>>>> > > > > > 1.
> >>>>>> > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
> >>>>>> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
> >>>>>> > > > > rFEHJG6G5sB4Q%40mail.gmail.
> >>>>>> > > > > > com%3E
> >>>>>> > > > > >
> >>>>>> > > > > >
> >>>>>> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay <
> >>>>>> lmccay@apache.org>
> >>>>>> > > > wrote:
> >>>>>> > > > > >
> >>>>>> > > > > > > All -
> >>>>>> > > > > > >
> >>>>>> > > > > > > After many recent distractions, I would like to start
> the
> >>>>>> scoping
> >>>>>> > > and
> >>>>>> > > > > > > planning for what will likely be our 1.0.0 release.
> >>>>>> > > > > > >
> >>>>>> > > > > > > As discussed in [1], we will begin to
> >>>>>> repackaging/refactor master
> >>>>>> > > > after
> >>>>>> > > > > > > branching for an 0.13.0 release and only release 0.13.0
> >>>>>> if the
> >>>>>> > work
> >>>>>> > > > on
> >>>>>> > > > > > > repackaging master doesn't seem like it will make
> >>>>>> whatever date
> >>>>>> > we
> >>>>>> > > > > chose
> >>>>>> > > > > > > for the release.
> >>>>>> > > > > > >
> >>>>>> > > > > > > That said, I would like to limit scope to only those new
> >>>>>> features
> >>>>>> > > and
> >>>>>> > > > > bug
> >>>>>> > > > > > > fixes that are absolutely necessary or low risk for
> >>>>>> breaking
> >>>>>> > > backward
> >>>>>> > > > > > > compatibility.
> >>>>>> > > > > > >
> >>>>>> > > > > > > I propose that the following is needed:
> >>>>>> > > > > > >
> >>>>>> > > > > > > * A KIP (KIP-5) be created for the
> >>>>>> repackaging/refactoring work
> >>>>>> > > > > required
> >>>>>> > > > > > > for the 1.0.0 release
> >>>>>> > > > > > > * Determine the existing JIRAs and patches that must/can
> >>>>>> be in
> >>>>>> > the
> >>>>>> > > > > > release
> >>>>>> > > > > > > but try and defer as many as possible
> >>>>>> > > > > > > * Determine required improvements - I have a few
> security
> >>>>>> related
> >>>>>> > > > > > > improvements in mind
> >>>>>> > > > > > > * Write up KIPs for features that involve architectural
> >>>>>> and/or
> >>>>>> > > > > strategic
> >>>>>> > > > > > > feature details
> >>>>>> > > > > > > * Determine when to branch for 0.13.0 and take on double
> >>>>>> commits
> >>>>>> > > for
> >>>>>> > > > > > 1.0.0
> >>>>>> > > > > > > parity
> >>>>>> > > > > > > * Agree on a target release date
> >>>>>> > > > > > >
> >>>>>> > > > > > > My initial thought is to target May 31st as the release
> >>>>>> date.
> >>>>>> > > > > > >
> >>>>>> > > > > > > Thoughts?
> >>>>>> > > > > > >
> >>>>>> > > > > > > --larry
> >>>>>> > > > > > >
> >>>>>> > > > > >
> >>>>>> > > > >
> >>>>>> > > >
> >>>>>> > >
> >>>>>> >
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Posted by larry mccay <lm...@apache.org>.
While working on the encoding issues, we have had a number of JIRAs filed
for updated UI service definitions.
I know this happens to be a sore spot for many deployments since many have
become obsolete.
UIs are such a moving target.
I would like to try and wait to get these patches in for the 0.13.0 release.
We also have some additional verification of the encoding fix outstanding
and we are waiting treating this as a blocker for the release.
I will be making another pass through the open JIRAs shortly in order to
push things out to the next release for managing scope of 0.13.0.
Thank you for your patience!
On Thu, Jun 8, 2017 at 9:12 AM, larry mccay <lm...@apache.org> wrote:
> All -
>
> Just an FYI - I am currently trying to resolve a number of url encoding
> related issues that were introduced by a change to get proxying of Ambari
> UI working properly.
>
> Personally, I feel this is a blocker and would like to get a fix in for
> 0.13.0.
> At the same time, we may determine that most of the issues are edge cases
> or at least not very common.
> I am aware of WebHDFS issues with spaces in the filename or path and HBase
> related issues where reserved characters such as '/' are being used.
>
> It appears that this has been introduced by trying to accommodate Ambari's
> use of an unwise character '|' in its URLs.
> A general approach of encoding and decoding the URL has led to a number of
> inconsistencies with what the backend services expect.
>
> I will attempt to find the most surgical and least invasive fix for this
> issue as to reduce risk for 0.13.0 closedown.
>
> thanks,
>
> --larry
>
> On Wed, May 24, 2017 at 9:49 AM, Sandeep More <mo...@gmail.com>
> wrote:
>
>> Ah ! got it.
>>
>>
>> On Wed, May 24, 2017 at 9:46 AM, larry mccay <lm...@apache.org> wrote:
>>
>>> Actually, what I am proposing is that we *branch* on Monday and double
>>> commit as necessary in order to close down before the rc and through the
>>> release process. I'd like to get to a rc by the end of next week - 6/2 - if
>>> not sooner.
>>>
>>> We will also likely need to double commit bug fixes to master and 0.13.0
>>> branch for some time in case we need a new 0.13.x release to avoid the
>>> 1.0.0 refactoring for existing deployments.
>>>
>>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More <mo...@gmail.com>
>>> wrote:
>>>
>>>> Hello Larry,
>>>>
>>>> Thanks for starting the discussion, given that we are away from the
>>>> target date just by a week I too think that releasing 0.13.0 on Monday and
>>>> then working towards 1.0.0 (package refactoring) would be a good idea. One
>>>> upshot of this is that we don't have to double commit as we had initially
>>>> thought :)
>>>>
>>>> Best,
>>>> Sandeep
>>>>
>>>> On Tue, May 23, 2017 at 4:44 PM, larry mccay <lm...@apache.org> wrote:
>>>>
>>>>> All -
>>>>>
>>>>> As we targeted a 5/31 date for the release of 0.13.0, I think we need
>>>>> to look at managing the current scope for 0.13.0 as well as the plan for a
>>>>> 1.0.0 again.
>>>>> Since we are just a week away from the target date, I think that
>>>>> refactoring the package names for the 1.0.0 release at the same time is a
>>>>> stretch.
>>>>>
>>>>> We currently have 22 or so JIRAs and will not be able to get them all
>>>>> into 0.13.0.
>>>>> What do you think about the following:
>>>>>
>>>>> * We manage the existing scope over the rest of this week.
>>>>> * I will post comments on some JIRAs about potentially moving them out
>>>>> and without any movement will move them out by Friday 26th.
>>>>> * JIRAs that I think are outside the KIPs that are driving the release
>>>>> or that may destabilize the release I will just move.
>>>>>
>>>>> If I move something that is something wanted by you, please feel free
>>>>> to add it back, comment or raise discussion on this thread.
>>>>>
>>>>> I also propose that we branch for 0.13.0 on Monday 5/29th and work
>>>>> toward getting the rest of the required issues in and an RC by the 31st or
>>>>> by end of the week. Once we release 0.13.0, we should refactor master for
>>>>> the 1.0.0 release - concentrate on closing down any fallout from package
>>>>> name changes and do an immediate 1.0.0 release.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> thanks,
>>>>>
>>>>> --larry
>>>>>
>>>>>
>>>>> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More <mo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sounds great !
>>>>>>
>>>>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <lm...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> > That sounds reasonable to me.
>>>>>> > I was hoping to get as many of the patches available and important
>>>>>> bugs
>>>>>> > fixed before the split as well.
>>>>>> > Minimizing the double commits/patches is definitely in our interest.
>>>>>> >
>>>>>> > At the same time, we need to have enough time to spend on
>>>>>> refactoring as
>>>>>> > well.
>>>>>> > I'm thinking that May 15th may be a good branch point - giving us 2
>>>>>> weeks
>>>>>> > to concentrate on repackaging and adapter classes.
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <
>>>>>> moresandeep@gmail.com>
>>>>>> > wrote:
>>>>>> >
>>>>>> > > Oh, I guess it depends on when we split, I was planning on taking
>>>>>> up the
>>>>>> > > new feature (mentioned in earlier email).
>>>>>> > > If we decide to go for the feature I was hoping to get it in
>>>>>> sooner
>>>>>> > (before
>>>>>> > > the split) if possible.
>>>>>> > >
>>>>>> > >
>>>>>> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay <lm...@apache.org>
>>>>>> wrote:
>>>>>> > >
>>>>>> > > > Actually, I meant 5/31 for a release date.
>>>>>> > > > You think that is too early for a repackaged and narrowly
>>>>>> scoped 1.0.0?
>>>>>> > > >
>>>>>> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
>>>>>> moresandeep@gmail.com>
>>>>>> > > > wrote:
>>>>>> > > >
>>>>>> > > > > Great, thanks Larry for starting the discussion and the KIP !
>>>>>> > > > >
>>>>>> > > > > May 31st target date sounds good, just to be sure, this date
>>>>>> is when
>>>>>> > we
>>>>>> > > > > split 0.13 right ?
>>>>>> > > > >
>>>>>> > > > > KIP-5 looks good, I will try to see whether I can find any
>>>>>> extended
>>>>>> > > > classes
>>>>>> > > > > that might need adapter classes.
>>>>>> > > > >
>>>>>> > > > > Best,
>>>>>> > > > > Sandeep
>>>>>> > > > >
>>>>>> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay <
>>>>>> lmccay@apache.org>
>>>>>> > > wrote:
>>>>>> > > > >
>>>>>> > > > > > Forgot to add the [1] to the initial mail.
>>>>>> > > > > >
>>>>>> > > > > > Enjoy...
>>>>>> > > > > >
>>>>>> > > > > > 1.
>>>>>> > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
>>>>>> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
>>>>>> > > > > rFEHJG6G5sB4Q%40mail.gmail.
>>>>>> > > > > > com%3E
>>>>>> > > > > >
>>>>>> > > > > >
>>>>>> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay <
>>>>>> lmccay@apache.org>
>>>>>> > > > wrote:
>>>>>> > > > > >
>>>>>> > > > > > > All -
>>>>>> > > > > > >
>>>>>> > > > > > > After many recent distractions, I would like to start the
>>>>>> scoping
>>>>>> > > and
>>>>>> > > > > > > planning for what will likely be our 1.0.0 release.
>>>>>> > > > > > >
>>>>>> > > > > > > As discussed in [1], we will begin to
>>>>>> repackaging/refactor master
>>>>>> > > > after
>>>>>> > > > > > > branching for an 0.13.0 release and only release 0.13.0
>>>>>> if the
>>>>>> > work
>>>>>> > > > on
>>>>>> > > > > > > repackaging master doesn't seem like it will make
>>>>>> whatever date
>>>>>> > we
>>>>>> > > > > chose
>>>>>> > > > > > > for the release.
>>>>>> > > > > > >
>>>>>> > > > > > > That said, I would like to limit scope to only those new
>>>>>> features
>>>>>> > > and
>>>>>> > > > > bug
>>>>>> > > > > > > fixes that are absolutely necessary or low risk for
>>>>>> breaking
>>>>>> > > backward
>>>>>> > > > > > > compatibility.
>>>>>> > > > > > >
>>>>>> > > > > > > I propose that the following is needed:
>>>>>> > > > > > >
>>>>>> > > > > > > * A KIP (KIP-5) be created for the
>>>>>> repackaging/refactoring work
>>>>>> > > > > required
>>>>>> > > > > > > for the 1.0.0 release
>>>>>> > > > > > > * Determine the existing JIRAs and patches that must/can
>>>>>> be in
>>>>>> > the
>>>>>> > > > > > release
>>>>>> > > > > > > but try and defer as many as possible
>>>>>> > > > > > > * Determine required improvements - I have a few security
>>>>>> related
>>>>>> > > > > > > improvements in mind
>>>>>> > > > > > > * Write up KIPs for features that involve architectural
>>>>>> and/or
>>>>>> > > > > strategic
>>>>>> > > > > > > feature details
>>>>>> > > > > > > * Determine when to branch for 0.13.0 and take on double
>>>>>> commits
>>>>>> > > for
>>>>>> > > > > > 1.0.0
>>>>>> > > > > > > parity
>>>>>> > > > > > > * Agree on a target release date
>>>>>> > > > > > >
>>>>>> > > > > > > My initial thought is to target May 31st as the release
>>>>>> date.
>>>>>> > > > > > >
>>>>>> > > > > > > Thoughts?
>>>>>> > > > > > >
>>>>>> > > > > > > --larry
>>>>>> > > > > > >
>>>>>> > > > > >
>>>>>> > > > >
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Planning for Apache Knox 0.13.0 (1.0.0) Release
Posted by larry mccay <lm...@apache.org>.
While working on the encoding issues, we have had a number of JIRAs filed
for updated UI service definitions.
I know this happens to be a sore spot for many deployments since many have
become obsolete.
UIs are such a moving target.
I would like to try and wait to get these patches in for the 0.13.0 release.
We also have some additional verification of the encoding fix outstanding
and we are waiting treating this as a blocker for the release.
I will be making another pass through the open JIRAs shortly in order to
push things out to the next release for managing scope of 0.13.0.
Thank you for your patience!
On Thu, Jun 8, 2017 at 9:12 AM, larry mccay <lm...@apache.org> wrote:
> All -
>
> Just an FYI - I am currently trying to resolve a number of url encoding
> related issues that were introduced by a change to get proxying of Ambari
> UI working properly.
>
> Personally, I feel this is a blocker and would like to get a fix in for
> 0.13.0.
> At the same time, we may determine that most of the issues are edge cases
> or at least not very common.
> I am aware of WebHDFS issues with spaces in the filename or path and HBase
> related issues where reserved characters such as '/' are being used.
>
> It appears that this has been introduced by trying to accommodate Ambari's
> use of an unwise character '|' in its URLs.
> A general approach of encoding and decoding the URL has led to a number of
> inconsistencies with what the backend services expect.
>
> I will attempt to find the most surgical and least invasive fix for this
> issue as to reduce risk for 0.13.0 closedown.
>
> thanks,
>
> --larry
>
> On Wed, May 24, 2017 at 9:49 AM, Sandeep More <mo...@gmail.com>
> wrote:
>
>> Ah ! got it.
>>
>>
>> On Wed, May 24, 2017 at 9:46 AM, larry mccay <lm...@apache.org> wrote:
>>
>>> Actually, what I am proposing is that we *branch* on Monday and double
>>> commit as necessary in order to close down before the rc and through the
>>> release process. I'd like to get to a rc by the end of next week - 6/2 - if
>>> not sooner.
>>>
>>> We will also likely need to double commit bug fixes to master and 0.13.0
>>> branch for some time in case we need a new 0.13.x release to avoid the
>>> 1.0.0 refactoring for existing deployments.
>>>
>>> On Wed, May 24, 2017 at 9:29 AM, Sandeep More <mo...@gmail.com>
>>> wrote:
>>>
>>>> Hello Larry,
>>>>
>>>> Thanks for starting the discussion, given that we are away from the
>>>> target date just by a week I too think that releasing 0.13.0 on Monday and
>>>> then working towards 1.0.0 (package refactoring) would be a good idea. One
>>>> upshot of this is that we don't have to double commit as we had initially
>>>> thought :)
>>>>
>>>> Best,
>>>> Sandeep
>>>>
>>>> On Tue, May 23, 2017 at 4:44 PM, larry mccay <lm...@apache.org> wrote:
>>>>
>>>>> All -
>>>>>
>>>>> As we targeted a 5/31 date for the release of 0.13.0, I think we need
>>>>> to look at managing the current scope for 0.13.0 as well as the plan for a
>>>>> 1.0.0 again.
>>>>> Since we are just a week away from the target date, I think that
>>>>> refactoring the package names for the 1.0.0 release at the same time is a
>>>>> stretch.
>>>>>
>>>>> We currently have 22 or so JIRAs and will not be able to get them all
>>>>> into 0.13.0.
>>>>> What do you think about the following:
>>>>>
>>>>> * We manage the existing scope over the rest of this week.
>>>>> * I will post comments on some JIRAs about potentially moving them out
>>>>> and without any movement will move them out by Friday 26th.
>>>>> * JIRAs that I think are outside the KIPs that are driving the release
>>>>> or that may destabilize the release I will just move.
>>>>>
>>>>> If I move something that is something wanted by you, please feel free
>>>>> to add it back, comment or raise discussion on this thread.
>>>>>
>>>>> I also propose that we branch for 0.13.0 on Monday 5/29th and work
>>>>> toward getting the rest of the required issues in and an RC by the 31st or
>>>>> by end of the week. Once we release 0.13.0, we should refactor master for
>>>>> the 1.0.0 release - concentrate on closing down any fallout from package
>>>>> name changes and do an immediate 1.0.0 release.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> thanks,
>>>>>
>>>>> --larry
>>>>>
>>>>>
>>>>> On Thu, Apr 27, 2017 at 1:32 PM, Sandeep More <mo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Sounds great !
>>>>>>
>>>>>> On Thu, Apr 27, 2017 at 12:32 PM, larry mccay <lm...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>> > That sounds reasonable to me.
>>>>>> > I was hoping to get as many of the patches available and important
>>>>>> bugs
>>>>>> > fixed before the split as well.
>>>>>> > Minimizing the double commits/patches is definitely in our interest.
>>>>>> >
>>>>>> > At the same time, we need to have enough time to spend on
>>>>>> refactoring as
>>>>>> > well.
>>>>>> > I'm thinking that May 15th may be a good branch point - giving us 2
>>>>>> weeks
>>>>>> > to concentrate on repackaging and adapter classes.
>>>>>> >
>>>>>> >
>>>>>> > On Thu, Apr 27, 2017 at 12:16 PM, Sandeep More <
>>>>>> moresandeep@gmail.com>
>>>>>> > wrote:
>>>>>> >
>>>>>> > > Oh, I guess it depends on when we split, I was planning on taking
>>>>>> up the
>>>>>> > > new feature (mentioned in earlier email).
>>>>>> > > If we decide to go for the feature I was hoping to get it in
>>>>>> sooner
>>>>>> > (before
>>>>>> > > the split) if possible.
>>>>>> > >
>>>>>> > >
>>>>>> > > On Thu, Apr 27, 2017 at 11:53 AM, larry mccay <lm...@apache.org>
>>>>>> wrote:
>>>>>> > >
>>>>>> > > > Actually, I meant 5/31 for a release date.
>>>>>> > > > You think that is too early for a repackaged and narrowly
>>>>>> scoped 1.0.0?
>>>>>> > > >
>>>>>> > > > On Thu, Apr 27, 2017 at 11:46 AM, Sandeep More <
>>>>>> moresandeep@gmail.com>
>>>>>> > > > wrote:
>>>>>> > > >
>>>>>> > > > > Great, thanks Larry for starting the discussion and the KIP !
>>>>>> > > > >
>>>>>> > > > > May 31st target date sounds good, just to be sure, this date
>>>>>> is when
>>>>>> > we
>>>>>> > > > > split 0.13 right ?
>>>>>> > > > >
>>>>>> > > > > KIP-5 looks good, I will try to see whether I can find any
>>>>>> extended
>>>>>> > > > classes
>>>>>> > > > > that might need adapter classes.
>>>>>> > > > >
>>>>>> > > > > Best,
>>>>>> > > > > Sandeep
>>>>>> > > > >
>>>>>> > > > > On Thu, Apr 27, 2017 at 11:35 AM, larry mccay <
>>>>>> lmccay@apache.org>
>>>>>> > > wrote:
>>>>>> > > > >
>>>>>> > > > > > Forgot to add the [1] to the initial mail.
>>>>>> > > > > >
>>>>>> > > > > > Enjoy...
>>>>>> > > > > >
>>>>>> > > > > > 1.
>>>>>> > > > > > http://mail-archives.apache.org/mod_mbox/knox-dev/201704.
>>>>>> > > > > > mbox/%3CCACRbFygW6y7adt_PNJrQ8n3fCswi6F_kDO5T-
>>>>>> > > > > rFEHJG6G5sB4Q%40mail.gmail.
>>>>>> > > > > > com%3E
>>>>>> > > > > >
>>>>>> > > > > >
>>>>>> > > > > > On Wed, Apr 26, 2017 at 12:45 PM, larry mccay <
>>>>>> lmccay@apache.org>
>>>>>> > > > wrote:
>>>>>> > > > > >
>>>>>> > > > > > > All -
>>>>>> > > > > > >
>>>>>> > > > > > > After many recent distractions, I would like to start the
>>>>>> scoping
>>>>>> > > and
>>>>>> > > > > > > planning for what will likely be our 1.0.0 release.
>>>>>> > > > > > >
>>>>>> > > > > > > As discussed in [1], we will begin to
>>>>>> repackaging/refactor master
>>>>>> > > > after
>>>>>> > > > > > > branching for an 0.13.0 release and only release 0.13.0
>>>>>> if the
>>>>>> > work
>>>>>> > > > on
>>>>>> > > > > > > repackaging master doesn't seem like it will make
>>>>>> whatever date
>>>>>> > we
>>>>>> > > > > chose
>>>>>> > > > > > > for the release.
>>>>>> > > > > > >
>>>>>> > > > > > > That said, I would like to limit scope to only those new
>>>>>> features
>>>>>> > > and
>>>>>> > > > > bug
>>>>>> > > > > > > fixes that are absolutely necessary or low risk for
>>>>>> breaking
>>>>>> > > backward
>>>>>> > > > > > > compatibility.
>>>>>> > > > > > >
>>>>>> > > > > > > I propose that the following is needed:
>>>>>> > > > > > >
>>>>>> > > > > > > * A KIP (KIP-5) be created for the
>>>>>> repackaging/refactoring work
>>>>>> > > > > required
>>>>>> > > > > > > for the 1.0.0 release
>>>>>> > > > > > > * Determine the existing JIRAs and patches that must/can
>>>>>> be in
>>>>>> > the
>>>>>> > > > > > release
>>>>>> > > > > > > but try and defer as many as possible
>>>>>> > > > > > > * Determine required improvements - I have a few security
>>>>>> related
>>>>>> > > > > > > improvements in mind
>>>>>> > > > > > > * Write up KIPs for features that involve architectural
>>>>>> and/or
>>>>>> > > > > strategic
>>>>>> > > > > > > feature details
>>>>>> > > > > > > * Determine when to branch for 0.13.0 and take on double
>>>>>> commits
>>>>>> > > for
>>>>>> > > > > > 1.0.0
>>>>>> > > > > > > parity
>>>>>> > > > > > > * Agree on a target release date
>>>>>> > > > > > >
>>>>>> > > > > > > My initial thought is to target May 31st as the release
>>>>>> date.
>>>>>> > > > > > >
>>>>>> > > > > > > Thoughts?
>>>>>> > > > > > >
>>>>>> > > > > > > --larry
>>>>>> > > > > > >
>>>>>> > > > > >
>>>>>> > > > >
>>>>>> > > >
>>>>>> > >
>>>>>> >
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>