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