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 >> > > >> > >> > >
