+1 I feel the same, also, it will be easier to put features after refactoring. Halloween release sounds good to me !
Best, Sandeep On Thu, Aug 17, 2017 at 9:24 AM, Philip Zampino <[email protected]> wrote: > IMO, front-loading the refactoring (renaming) work would be ideal. > > > 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+ > > Renaming+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 > > > > > > > > > >
