Perfect! On Thu, Aug 17, 2017 at 3:44 PM, Sandeep More <[email protected]> wrote:
> Ok, so I created a JIRA for renaming of Knox class packages task - KNOX-998 > <https://issues.apache.org/jira/browse/KNOX-998> and a new branch for the > refactoring work (KNOX-998-Package_Restructuring) > > Best, > Sandeep > > > > On Thu, Aug 17, 2017 at 3:23 PM, Sandeep More <[email protected]> > wrote: > > > Great, thanks for the pointers Larry. > > > > I'll start off with the groundwork for KIP-5 by filing a JIRA and > creating > > a branch. > > > > Best, > > Sandeep > > > > On Wed, Aug 16, 2017 at 10:14 PM, larry mccay <[email protected]> wrote: > > > >> Yes, I think the 1.0.0 release is still something that we should > consider > >> for 0.14.0. > >> I meant to bring that up. > >> > >> I think we actually have an existing KIP for that for trying to capture > >> the > >> impact. > >> > >> More than likely there will be a good bit of work for the topology > >> simplification that we can collaborate on. > >> > >> We should also try and target a release date - how does a Halloween > >> release > >> sound? (0.13.0 would have been a better number) > >> Perhaps front loading the 1.0.0 refactoring would be a good idea - > rather > >> than waiting until it is too large and too late and we push it out > again. > >> > >> Let's create a feature branch for KIP-5 [1] and file a JIRA and maybe > >> child > >> tasks for it. > >> We'll need to have it track master and merge in once it is complete. > >> Maybe some jenkins jobs to make sure it is building and passing tests? > >> > >> 1. > >> https://cwiki.apache.org/confluence/display/KNOX/KIP-5+Renam > >> ing+of+Knox+Class+Packages > >> > >> On Wed, Aug 16, 2017 at 9:46 PM, Sandeep More <[email protected]> > >> wrote: > >> > >> > Hello Larry, > >> > > >> > Thanks a lot for starting the DISCUSS thread on these improvements, I > >> > really liked the ideas you are proposing so I am +1 for all of them. > >> > > >> > Before digging into them, I would like to digress a bit on the 1.0.0 > >> topic. > >> > I remember we talked a bit about it the last time especially about the > >> > packaging (basically changing the package names so as to take out > hadoop > >> > from the package names) and the complications it presents. Do you see > >> this > >> > task happening in 0.14.0 given that it will have some significant and > >> > undesirable impact ? > >> > > >> > I would love to take a shot at the service registry and discovery > part. > >> I > >> > have had some experience in the area of service discovery and registry > >> > (mainly with Eureka, Zookeeper, Consul) but not with Ambari APIs, so a > >> bit > >> > of a learning curve there. If anyone want to to jump in, I would love > >> it or > >> > if anyone wants to work on it solo I wouldn't mind that as well. It's > a > >> > good idea and I think it will be a good feature and ease a lot of > >> > configuration burden and take out some redundancy. > >> > > >> > +1 with making the topologies simpler, I am not a big fan of the way > >> Knox > >> > topologies are included in Ambari, they are error prone and kind of > look > >> > ugly (XML formatted and all) so this will be a big step forward in > user > >> > experience. > >> > > >> > Again, thanks for bringing this up and it's better to start early with > >> > 0.14.0 / 1.0.0 Planning. > >> > > >> > Best, > >> > Sandeep > >> > > >> > > >> > > >> > > >> > On Wed, Aug 16, 2017 at 9:19 PM, larry mccay <[email protected]> > wrote: > >> > > >> > > All - > >> > > > >> > > As we are in the final hours of the 0.13.0 VOTE on RC-2, I thought > we > >> > might > >> > > start a thread for planning on 0.14.0 (1.0.0). > >> > > > >> > > We have made a good deal of progress on our existing KIP's over the > >> last > >> > > couple of releases. > >> > > > >> > > There may be a couple stray tasks from a few of them and I will go > >> > through > >> > > and try to identify them and pull them in 0.14.0 or revisit whether > >> they > >> > > are actually needed. > >> > > > >> > > There is already a set of 0.14.0 issues that were pushed out of > 0.13.0 > >> > > which we can start with as well. > >> > > > >> > > I'd like to put up for consideration a feature that abstracts a > >> service > >> > > registry or discovery service that we could plug in various > >> > implementations > >> > > to. We could potentially start with an implementation that leverages > >> the > >> > > Ambari API to determine the endpoints of services described in a > >> > topology. > >> > > > >> > > I'd also like to simplify the creation of topologies so that they > can > >> be > >> > > much more easily authored in UIs like Ambari or our admin UI without > >> it > >> > > being a big blob of XML. > >> > > > >> > > Thinking about a simple, flat file with service names and the name > of > >> a > >> > > separately configured set of providers. Then deployment machinery > can > >> > > discover changes to these files and generate topologies by > leveraging > >> the > >> > > discovery service to find the service details such as: URL/s, HA or > >> not, > >> > > etc. > >> > > > >> > > I am also going to spend some time thinking about how to simplify > the > >> > > rewrite rules for UI proxying. I will start a separate DISCUSS on > this > >> > if I > >> > > come up with anything. > >> > > > >> > > If anyone would like to take a crack at writing up one or more of > the > >> > above > >> > > as a KIP, please feel free. > >> > > > >> > > Thanks! > >> > > > >> > > --larry > >> > > > >> > > >> > > > > >
