trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amanda Moran <amanda.mo...@esgyn.com>
Subject Re: Automatic restart of Cloudera/Hortonworks in Installer
Date Tue, 20 Oct 2015 19:00:32 GMT
Hi there Dennis-

Yes, Cloudera/Hortonworks MUST be restarted for Trafodion to start.
Cloudera/HDP has no way of knowing the hbase-trx*.jar file has been added
without a restart... without that no connection between
Cloudera/Hortonworks and Trafodion can be established.

I like Steve's idea of making the restart automatic but allowing for a
by-pass option of some sort, if you really don't want a restart of
Cloudera/Hortonworks and will start everything including Trafodion at
another time. (Does seem like a pretty special case.. if you ask me :)) I
will need to think on how the best way to do that is, but I like that idea.

Upgrade question: User does not need to worry about an upgrade. The
installer determines that and proceeds down the correct path.

Thanks all!

On Tue, Oct 20, 2015 at 11:43 AM, D. Markt <dmarkt7370@gmail.com> wrote:

> Hi Amanda,
>
>   I think we've all been annoyed when installing Windows updates and we're
> ask to restart the system when we don't really understand why a restart is
> required given what was updated.  Conversely, if an installer is installing
> a package that will not work without a reboot or an application restart,
> not doing the restart will just waste more time when the application fails
> to run successfully.  Are there times when Trafodion can be installed and
> run successfully without restarting Cloudera/Hortonworks?  If not, then we
> should do the restart.
>
>   That said, my recollection is it does seem a (very little) bit
> inconsistent that we prompt the user if we want Trafodion to be started but
> don't prompt if the user wants us to restart Cloudera/Hortonworks.  Given
> the installer does need sudo access one could envision one person doing the
> installation for another person that then would restart
> Cloudera/Hortonworks before trying to start Trafodion at a later time.
> Likewise, I recall one time realizing that I would prefer not to restart
> Cloudera/Hortonworks at the time because I was going to need to restart it
> shortly anyway but given the current prompts all I could do was exit the
> installer or allow the install to continue and have to restart the cluster
> twice.
>
>   So I would probably vote for prompting if Cloudera/Hortonworks should be
> restarted.  Then if not doing the restart is very likely to cause Trafodion
> to not start up, then I would make the start Trafodion prompt default be
> "No" and if "Yes" is entered warn that without the Cloudera/Hortonworks
> restart the Trafodion start is likely to fail.  If the Cloudera/Hortonworks
> restart isn't required or it was done then keep the start Trafodion prompt
> default as "Yes".
>
>   Now a question for you, when should a user indicate the Trafodion
> installation is an "upgrade"?  Is that only appropriate for a new release
> of Trafodion that requires the metadata to be upgraded?  Or can "upgrade"
> be used to update the software in its current location?
>
> Thanks,
> Dennis
>
> -----Original Message-----
> From: Amanda Moran [mailto:amanda.moran@esgyn.com]
> Sent: Tuesday, October 20, 2015 12:57 PM
> To: dev <dev@trafodion.incubator.apache.org>
> Subject: Automatic restart of Cloudera/Hortonworks in Installer
>
> Hi there All-
>
> Currently, in the installer we automatically restart Cloudera or
> Hortonworks after new HBase/HDFS/Zookeeper configs are added and our
> hbase-trx*.jar file is copied into the HBase directory.
>
> Should this still be done automatically? In the past, the installer asked
> the user to go restart by hand... and received a lot of negative feedback
> on that.
>
> Should the installer prompt the user if they would like to restart, stay
> as is, or not even attempt to restart and wait for the user to do by hand?
>
> Thank you!
>
> --
> Thanks,
>
> Amanda Moran
>
>


-- 
Thanks,

Amanda Moran

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message