Larry, excellent! Thank you for taking the time to clarify. I think that answers all of my questions.
i'll try to provide a docs patch soonish. Cheers, Lars On Wed, Dec 5, 2018 at 9:37 PM larry mccay <[email protected]> wrote: > Hi Lars - > > It is indeed true that shared provider configs are only consumed by simple > descriptors. > They do so by having them pulled into the compiled topologies as you > suspect. > It would be good to make that clear. > > The answer to whether you should use one or the other is - it depends... > > 1. Do you have a source for discovery like Ambari - which is the only one > we currently have support for? This would be a No for you apparently. > 2. Do you hate XML with the fury of a thousand suns? Some folks do and > would much rather click and edit text boxes. I am not one of them. > > Either of the above answers being 'yes' then I would suggest that you > switch. > > Discovery is really nice - if you haven't read much about that and only > the provider configs and descriptors without that context then you should > dig in there a bit more. > Move a NN to another host with Ambari and we find out without having to > restart Knox at all. > A port number changes through Ambari and we find out and regenerate the > topology with the new port number - no changes needed in topologies or > restarts of Knox. > If you include a service in a descriptor that hasn't been installed yet > and it subsequently gets installed by Ambari, we find it and regenerate the > topology and expose the previously unavailable service automatically. > > The other thing that is related and is also only supported for provider > configs and descriptors, is remote configuration monitoring. > Instead of having to keep all of your Knox instances in sync with the same > topologies, pushing the configs and descriptors to Zookeeper means that all > the instances will be in sync via monitoring of the remote configuration in > ZK. This makes Knox HA deployments much easier. Again, straight topologies > do not work here. So a possible #3 to the above list is would you like > centralized management of topologies that are not limited to the three > known by Ambari. > > Anyway, yeah, its good stuff but we will continue to support straight > topologies as the least common denominator but do not intend to have the > above types of improvements available for them. > > Look forward to your docs patch. > > thanks, > > --larry > > > On Wed, Dec 5, 2018 at 1:51 PM Lars Francke <[email protected]> > wrote: > >> Hi, >> >> I read the docs about shared providers and simplified descriptors today. >> The documentation hints at it but doesn't actually describe or mention it: >> >> Shared providers can only be used with simplified descriptors because >> they are actually compiled into XML topology files? >> >> If that understanding is correct I'll add something to the docs. >> >> And if it is correct I have two follow-up questions: >> Should we still be writing XML topology files or is the recommendation to >> switch to the simplified ones? >> >> I think I saw in the code that the discovery type defaults to Ambari if I >> don't provide one. Is there any problem if I don't use Ambari? >> >> Cheers, >> Lars >> >
