I think there are some use cases we need What Jon proposed. For example, users installed hawq via Ambari, but they want to automate the configuration changes, it would be convenient to have hawq CLI change the configurations.
Cheers Lei On Fri, Mar 3, 2017 at 8:36 AM, Alex (Oleksandr) Diachenko < odiache...@pivotal.io> wrote: > I see, that makes sense. > But is there any action users cannot do via Ambari? > > Ranger is also a good example, there we are making assumption, > users either use Ranger or HAWQ's authorization engine. > > The same logic might be extrapolated to HAWQ/Ambari - users might use > either Ambari or HAWQ CLI, but not both at the same time. > In that way, we can keep things simple. > > Regards, Alex. > > > > On Thu, Mar 2, 2017 at 4:28 PM, Jon Roberts <jrobe...@pivotal.io> wrote: > > > Right. Just like HAWQ will be operational without Ranger. > > > > We have the hawq CLI and will obviously continue to have it. Some people > > use Ambari while others don't. So just like with Ranger support, > integrate > > when possible but don't require it. > > > > > > Jon > > > > On Thu, Mar 2, 2017 at 6:26 PM, Alex (Oleksandr) Diachenko < > > odiache...@pivotal.io> wrote: > > > > > Not really, because HAWQ should be operational even without Ambari(if > > > that's the case). > > > > > > On Thu, Mar 2, 2017 at 4:21 PM, Jon Roberts <jrobe...@pivotal.io> > wrote: > > > > > > > If that is the case, should we remove the "hawq" CLI? > > > > > > > > Jon > > > > > > > > On Thu, Mar 2, 2017 at 6:12 PM, Alex (Oleksandr) Diachenko < > > > > odiache...@pivotal.io> wrote: > > > > > > > > > Hi Jon, > > > > > > > > > > I think it was designed that Ambari is supposed to be only one > source > > > of > > > > > true. > > > > > The whole purpose of integration id to provide a user-friendly > > > interface > > > > > and avoid manually editing/distributing config files > > > > > or running CLI commands. > > > > > The idea of coupling HAWQ master with Ambari doesn't seem to be > > clean. > > > > > > > > > > Regards, Alex. > > > > > > > > > > On Thu, Mar 2, 2017 at 4:05 PM, Jon Roberts <jrobe...@pivotal.io> > > > wrote: > > > > > > > > > > > It would be handy if the "hawq config" also updated Ambari's > > database > > > > so > > > > > > that changes could be made in either place are retained when > > changes > > > > are > > > > > > made in either place. > > > > > > > > > > > > Register Ambari: > > > > > > hawq ambari -u admin -w admin -h myhost -p 8080 > > > > > > > > > > > > "hawq config" could then raise INFO/WARN messages about updating > > > > Ambari. > > > > > > > > > > > > Example: > > > > > > hawq config -c hawq_rm_stmt_vseg_memory -v 16gb > > > > > > INFO: Updated Ambari with hawq_rm_stmt_vseg_memory=16gb > > > > > > or > > > > > > hawq config -c hawq_rm_stmt_vseg_memory -v 16gb > > > > > > WARN: Failed to update Ambari with hawq_rm_stmt_vseg_memory=16gb. > > > > Please > > > > > > update Ambari credentials manually to retain this configuration > > > change > > > > > > after a restart. > > > > > > > > > > > > The implementation would require interacting with the Ambari APIs > > and > > > > > also > > > > > > storing the credentials in an encrypted file on the HAWQ Master. > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > Jon Roberts > > > > > > Principal Engineer | jrobe...@pivotal.io | 615-426-8661 > > > > > > > > > > > > > > > > > > > > >
