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 2018/04/27 23:36:53 UTC
Re: [DISCUSS] Planning for Apache Knox 1.1.0 Release
All -
I'd like to point out that we need to start pulling in the 1.1.0 release.
I see lots of progress and collaboration on some important ecosystem UIs
which is great.
As well as a couple really good features have made it in - like the remote
alias service support!
I would like to try and reset expectations for the 1.1.0 release to mid May
but we need to take some time and work through the open issues.
We currently have :
* ~35 with fixVersion = 1.1.0 of which 8 are Patch Available
* ~54 with fixVersion 0.15.0 of which 9 are Patch Available
I dropped the ball in migrating all of the 0.15.0 issues to either 1.1.0 or
1.2.0 as I intended when this thread began.
I will spend time over this weekend to try and make sense of all that and
really try to get the ones with Patch Available into 1.1.0 where possible.
If anyone feels strongly that particular issues from 0.15.0 be in 1.1.0
please comment on them to that end to help guide this migration.
Once we have cleared out 0.1.5.0, we will then need to have another pass
through what is slated for 1.1.0 and likely defer some work that are not
blockers.
thoughts?
--larry
On Sun, Feb 25, 2018 at 8:44 PM, Phil Zampino <pz...@apache.org> wrote:
> I'm not sure if it merits an entire KIP, but I think it would be worthwhile
> to provide a distributed/remote alias service (ala KNOX-1187
> <https://issues.apache.org/jira/browse/KNOX-1187>) in the 1.1.0 release.
> This would make the management of Knox topologies via ZooKeeper more
> complete, allowing admins to define gateway aliases once for all monitoring
> Knox instances instead of having to define them for each and every
> instance.
> This impacts service discovery in particular.
>
>
> On Sat, Feb 24, 2018 at 12:57 PM, larry mccay <lm...@apache.org> wrote:
>
> > All -
> >
> > Sorry for the delay on this topic.
> >
> > We are going to start of this planning thread with ~85 Unresolved JIRAs
> in
> > either 1.1.0 or 0.15.0 fixVersion.
> >
> > project = KNOX AND resolution = Unresolved AND fixVersion in (1.1.0,
> > 0.15.0) ORDER BY priority DESC, updated DESC
> >
> > I will spend some time migrating all 0.15.0 to 1.1.0 to begin with and
> then
> > we will need to go through and see what is already taken care of or can
> > wait for a 1.2.0 or later.
> >
> > I also have a couple KIPs in mind to target larger features/themes for
> this
> > release.
> >
> > Off the top of my head:
> >
> > * I think we need to address some cloud specific usecases and plan to
> > provide a KIP for that. Hybrid cloud/federated knox instances, Azure AD
> > integration, ID mapping from Hadoop user to IAM users/roles, etc. Perhaps
> > some CASB-like features if they make sense.
> >
> > * I also think we need one for articulating a reasonable flow for Logout
> in
> > KnoxSSO. There are a lot of little nuances to logout across multiple apps
> > and between different IDPs. This will require some discussion.
> >
> > * Another thing that has been tugging at my interest has been the fact
> that
> > we may be able provide some common libraries to help ecosystem
> applications
> > uptake the trusted proxy pattern and KnoxSSO.
> >
> > Anyway, these are my initial thoughts, please feel free to raise
> additional
> > ideas/themes for KIPs, etc.
> >
> > I was thinking that we could try and target an end of March or Mid April
> > 1.1.0 release.
> >
> > Thoughts?
> >
> > --larry
> >
>
Re: [DISCUSS] Planning for Apache Knox 1.1.0 Release
Posted by Phil Zampino <pz...@apache.org>.
+1, I think the tightly-scoped 1.2.0 release is a great approach for
knocking out some of the cloud-related tasks.
On Wed, Jul 4, 2018 at 1:18 PM larry mccay <lm...@apache.org> wrote:
> All -
>
> We are done to around 4 JIRAs marked as 1.1.0 issues.
>
> I am thinking about branching for the release where we can continue the
> work on the final changes but also start the planning of 1.2.0.
> The 1.1.0 release has been largely taken up with improvements in
> disovery/topology generation, HA provisioning improvements and UI proxying
> contributions which have all taken considerable time to get right.
>
> Some ground work for the KIP-11 Cloud usecases has been done but not really
> completed as full features yet.
> I think that a quick follow up 1.2.0 release to tackle a few of those
> features and other cloud related contributions would be a good thing to get
> done.
> So, I think we should target a tightly scoped 1.2.0 and defer most other
> JIRAs until the next one.
>
> In the meantime, this note is really meant to provide notice that we will
> be branching for 1.1.0 release in the next day or so.
> That is, unless someone has an objection to doing so.
>
> thanks,
>
> --larry
>
> On Fri, Apr 27, 2018 at 7:36 PM, larry mccay <lm...@apache.org> wrote:
>
> > All -
> >
> > I'd like to point out that we need to start pulling in the 1.1.0 release.
> > I see lots of progress and collaboration on some important ecosystem UIs
> > which is great.
> > As well as a couple really good features have made it in - like the
> remote
> > alias service support!
> >
> > I would like to try and reset expectations for the 1.1.0 release to mid
> > May but we need to take some time and work through the open issues.
> >
> > We currently have :
> >
> > * ~35 with fixVersion = 1.1.0 of which 8 are Patch Available
> > * ~54 with fixVersion 0.15.0 of which 9 are Patch Available
> >
> > I dropped the ball in migrating all of the 0.15.0 issues to either 1.1.0
> > or 1.2.0 as I intended when this thread began.
> > I will spend time over this weekend to try and make sense of all that and
> > really try to get the ones with Patch Available into 1.1.0 where
> possible.
> >
> > If anyone feels strongly that particular issues from 0.15.0 be in 1.1.0
> > please comment on them to that end to help guide this migration.
> > Once we have cleared out 0.1.5.0, we will then need to have another pass
> > through what is slated for 1.1.0 and likely defer some work that are not
> > blockers.
> >
> > thoughts?
> >
> > --larry
> >
> >
> > On Sun, Feb 25, 2018 at 8:44 PM, Phil Zampino <pz...@apache.org>
> wrote:
> >
> >> I'm not sure if it merits an entire KIP, but I think it would be
> >> worthwhile
> >> to provide a distributed/remote alias service (ala KNOX-1187
> >> <https://issues.apache.org/jira/browse/KNOX-1187>) in the 1.1.0
> release.
> >> This would make the management of Knox topologies via ZooKeeper more
> >> complete, allowing admins to define gateway aliases once for all
> >> monitoring
> >> Knox instances instead of having to define them for each and every
> >> instance.
> >> This impacts service discovery in particular.
> >>
> >>
> >> On Sat, Feb 24, 2018 at 12:57 PM, larry mccay <lm...@apache.org>
> wrote:
> >>
> >> > All -
> >> >
> >> > Sorry for the delay on this topic.
> >> >
> >> > We are going to start of this planning thread with ~85 Unresolved
> JIRAs
> >> in
> >> > either 1.1.0 or 0.15.0 fixVersion.
> >> >
> >> > project = KNOX AND resolution = Unresolved AND fixVersion in (1.1.0,
> >> > 0.15.0) ORDER BY priority DESC, updated DESC
> >> >
> >> > I will spend some time migrating all 0.15.0 to 1.1.0 to begin with and
> >> then
> >> > we will need to go through and see what is already taken care of or
> can
> >> > wait for a 1.2.0 or later.
> >> >
> >> > I also have a couple KIPs in mind to target larger features/themes for
> >> this
> >> > release.
> >> >
> >> > Off the top of my head:
> >> >
> >> > * I think we need to address some cloud specific usecases and plan to
> >> > provide a KIP for that. Hybrid cloud/federated knox instances, Azure
> AD
> >> > integration, ID mapping from Hadoop user to IAM users/roles, etc.
> >> Perhaps
> >> > some CASB-like features if they make sense.
> >> >
> >> > * I also think we need one for articulating a reasonable flow for
> >> Logout in
> >> > KnoxSSO. There are a lot of little nuances to logout across multiple
> >> apps
> >> > and between different IDPs. This will require some discussion.
> >> >
> >> > * Another thing that has been tugging at my interest has been the fact
> >> that
> >> > we may be able provide some common libraries to help ecosystem
> >> applications
> >> > uptake the trusted proxy pattern and KnoxSSO.
> >> >
> >> > Anyway, these are my initial thoughts, please feel free to raise
> >> additional
> >> > ideas/themes for KIPs, etc.
> >> >
> >> > I was thinking that we could try and target an end of March or Mid
> April
> >> > 1.1.0 release.
> >> >
> >> > Thoughts?
> >> >
> >> > --larry
> >> >
> >>
> >
> >
>
Re: [DISCUSS] Planning for Apache Knox 1.1.0 Release
Posted by Sandeep Moré <mo...@gmail.com>.
+1
Thanks Larry, sounds good.
Best,
Sandeep
On Wed, Jul 4, 2018 at 1:18 PM larry mccay <lm...@apache.org> wrote:
> All -
>
> We are done to around 4 JIRAs marked as 1.1.0 issues.
>
> I am thinking about branching for the release where we can continue the
> work on the final changes but also start the planning of 1.2.0.
> The 1.1.0 release has been largely taken up with improvements in
> disovery/topology generation, HA provisioning improvements and UI proxying
> contributions which have all taken considerable time to get right.
>
> Some ground work for the KIP-11 Cloud usecases has been done but not really
> completed as full features yet.
> I think that a quick follow up 1.2.0 release to tackle a few of those
> features and other cloud related contributions would be a good thing to get
> done.
> So, I think we should target a tightly scoped 1.2.0 and defer most other
> JIRAs until the next one.
>
> In the meantime, this note is really meant to provide notice that we will
> be branching for 1.1.0 release in the next day or so.
> That is, unless someone has an objection to doing so.
>
> thanks,
>
> --larry
>
> On Fri, Apr 27, 2018 at 7:36 PM, larry mccay <lm...@apache.org> wrote:
>
> > All -
> >
> > I'd like to point out that we need to start pulling in the 1.1.0 release.
> > I see lots of progress and collaboration on some important ecosystem UIs
> > which is great.
> > As well as a couple really good features have made it in - like the
> remote
> > alias service support!
> >
> > I would like to try and reset expectations for the 1.1.0 release to mid
> > May but we need to take some time and work through the open issues.
> >
> > We currently have :
> >
> > * ~35 with fixVersion = 1.1.0 of which 8 are Patch Available
> > * ~54 with fixVersion 0.15.0 of which 9 are Patch Available
> >
> > I dropped the ball in migrating all of the 0.15.0 issues to either 1.1.0
> > or 1.2.0 as I intended when this thread began.
> > I will spend time over this weekend to try and make sense of all that and
> > really try to get the ones with Patch Available into 1.1.0 where
> possible.
> >
> > If anyone feels strongly that particular issues from 0.15.0 be in 1.1.0
> > please comment on them to that end to help guide this migration.
> > Once we have cleared out 0.1.5.0, we will then need to have another pass
> > through what is slated for 1.1.0 and likely defer some work that are not
> > blockers.
> >
> > thoughts?
> >
> > --larry
> >
> >
> > On Sun, Feb 25, 2018 at 8:44 PM, Phil Zampino <pz...@apache.org>
> wrote:
> >
> >> I'm not sure if it merits an entire KIP, but I think it would be
> >> worthwhile
> >> to provide a distributed/remote alias service (ala KNOX-1187
> >> <https://issues.apache.org/jira/browse/KNOX-1187>) in the 1.1.0
> release.
> >> This would make the management of Knox topologies via ZooKeeper more
> >> complete, allowing admins to define gateway aliases once for all
> >> monitoring
> >> Knox instances instead of having to define them for each and every
> >> instance.
> >> This impacts service discovery in particular.
> >>
> >>
> >> On Sat, Feb 24, 2018 at 12:57 PM, larry mccay <lm...@apache.org>
> wrote:
> >>
> >> > All -
> >> >
> >> > Sorry for the delay on this topic.
> >> >
> >> > We are going to start of this planning thread with ~85 Unresolved
> JIRAs
> >> in
> >> > either 1.1.0 or 0.15.0 fixVersion.
> >> >
> >> > project = KNOX AND resolution = Unresolved AND fixVersion in (1.1.0,
> >> > 0.15.0) ORDER BY priority DESC, updated DESC
> >> >
> >> > I will spend some time migrating all 0.15.0 to 1.1.0 to begin with and
> >> then
> >> > we will need to go through and see what is already taken care of or
> can
> >> > wait for a 1.2.0 or later.
> >> >
> >> > I also have a couple KIPs in mind to target larger features/themes for
> >> this
> >> > release.
> >> >
> >> > Off the top of my head:
> >> >
> >> > * I think we need to address some cloud specific usecases and plan to
> >> > provide a KIP for that. Hybrid cloud/federated knox instances, Azure
> AD
> >> > integration, ID mapping from Hadoop user to IAM users/roles, etc.
> >> Perhaps
> >> > some CASB-like features if they make sense.
> >> >
> >> > * I also think we need one for articulating a reasonable flow for
> >> Logout in
> >> > KnoxSSO. There are a lot of little nuances to logout across multiple
> >> apps
> >> > and between different IDPs. This will require some discussion.
> >> >
> >> > * Another thing that has been tugging at my interest has been the fact
> >> that
> >> > we may be able provide some common libraries to help ecosystem
> >> applications
> >> > uptake the trusted proxy pattern and KnoxSSO.
> >> >
> >> > Anyway, these are my initial thoughts, please feel free to raise
> >> additional
> >> > ideas/themes for KIPs, etc.
> >> >
> >> > I was thinking that we could try and target an end of March or Mid
> April
> >> > 1.1.0 release.
> >> >
> >> > Thoughts?
> >> >
> >> > --larry
> >> >
> >>
> >
> >
>
Re: [DISCUSS] Planning for Apache Knox 1.1.0 Release
Posted by larry mccay <lm...@apache.org>.
All -
We are done to around 4 JIRAs marked as 1.1.0 issues.
I am thinking about branching for the release where we can continue the
work on the final changes but also start the planning of 1.2.0.
The 1.1.0 release has been largely taken up with improvements in
disovery/topology generation, HA provisioning improvements and UI proxying
contributions which have all taken considerable time to get right.
Some ground work for the KIP-11 Cloud usecases has been done but not really
completed as full features yet.
I think that a quick follow up 1.2.0 release to tackle a few of those
features and other cloud related contributions would be a good thing to get
done.
So, I think we should target a tightly scoped 1.2.0 and defer most other
JIRAs until the next one.
In the meantime, this note is really meant to provide notice that we will
be branching for 1.1.0 release in the next day or so.
That is, unless someone has an objection to doing so.
thanks,
--larry
On Fri, Apr 27, 2018 at 7:36 PM, larry mccay <lm...@apache.org> wrote:
> All -
>
> I'd like to point out that we need to start pulling in the 1.1.0 release.
> I see lots of progress and collaboration on some important ecosystem UIs
> which is great.
> As well as a couple really good features have made it in - like the remote
> alias service support!
>
> I would like to try and reset expectations for the 1.1.0 release to mid
> May but we need to take some time and work through the open issues.
>
> We currently have :
>
> * ~35 with fixVersion = 1.1.0 of which 8 are Patch Available
> * ~54 with fixVersion 0.15.0 of which 9 are Patch Available
>
> I dropped the ball in migrating all of the 0.15.0 issues to either 1.1.0
> or 1.2.0 as I intended when this thread began.
> I will spend time over this weekend to try and make sense of all that and
> really try to get the ones with Patch Available into 1.1.0 where possible.
>
> If anyone feels strongly that particular issues from 0.15.0 be in 1.1.0
> please comment on them to that end to help guide this migration.
> Once we have cleared out 0.1.5.0, we will then need to have another pass
> through what is slated for 1.1.0 and likely defer some work that are not
> blockers.
>
> thoughts?
>
> --larry
>
>
> On Sun, Feb 25, 2018 at 8:44 PM, Phil Zampino <pz...@apache.org> wrote:
>
>> I'm not sure if it merits an entire KIP, but I think it would be
>> worthwhile
>> to provide a distributed/remote alias service (ala KNOX-1187
>> <https://issues.apache.org/jira/browse/KNOX-1187>) in the 1.1.0 release.
>> This would make the management of Knox topologies via ZooKeeper more
>> complete, allowing admins to define gateway aliases once for all
>> monitoring
>> Knox instances instead of having to define them for each and every
>> instance.
>> This impacts service discovery in particular.
>>
>>
>> On Sat, Feb 24, 2018 at 12:57 PM, larry mccay <lm...@apache.org> wrote:
>>
>> > All -
>> >
>> > Sorry for the delay on this topic.
>> >
>> > We are going to start of this planning thread with ~85 Unresolved JIRAs
>> in
>> > either 1.1.0 or 0.15.0 fixVersion.
>> >
>> > project = KNOX AND resolution = Unresolved AND fixVersion in (1.1.0,
>> > 0.15.0) ORDER BY priority DESC, updated DESC
>> >
>> > I will spend some time migrating all 0.15.0 to 1.1.0 to begin with and
>> then
>> > we will need to go through and see what is already taken care of or can
>> > wait for a 1.2.0 or later.
>> >
>> > I also have a couple KIPs in mind to target larger features/themes for
>> this
>> > release.
>> >
>> > Off the top of my head:
>> >
>> > * I think we need to address some cloud specific usecases and plan to
>> > provide a KIP for that. Hybrid cloud/federated knox instances, Azure AD
>> > integration, ID mapping from Hadoop user to IAM users/roles, etc.
>> Perhaps
>> > some CASB-like features if they make sense.
>> >
>> > * I also think we need one for articulating a reasonable flow for
>> Logout in
>> > KnoxSSO. There are a lot of little nuances to logout across multiple
>> apps
>> > and between different IDPs. This will require some discussion.
>> >
>> > * Another thing that has been tugging at my interest has been the fact
>> that
>> > we may be able provide some common libraries to help ecosystem
>> applications
>> > uptake the trusted proxy pattern and KnoxSSO.
>> >
>> > Anyway, these are my initial thoughts, please feel free to raise
>> additional
>> > ideas/themes for KIPs, etc.
>> >
>> > I was thinking that we could try and target an end of March or Mid April
>> > 1.1.0 release.
>> >
>> > Thoughts?
>> >
>> > --larry
>> >
>>
>
>