Thanks for the questions.
Yes, that is exactly what I was proposing - I want to make it extremely
easy to copy without much chance for messing up:
cp -r demo/conf conf
is all that we would have to do.
We could move it under templates (samples aren't the same thing) and it
would look like:
cp -r templates/demo/conf conf
or
cp -r templates/demo/sandbox/conf conf
There is a risk that they start the copy from the wrong directory and copy
a bunch of junk into the actual conf but we could also provide a demo
install script to help mitigate that.
The reason that I wasn't thinking to put it under templates earlier is that
they are really templates for production deployments but I can imagine
extending that scope to include demos as well.
FYI - I will also be adding a new template called topology.xml for use as
the production template rather than sample.xml.
It is a bit unruly in that directory now and I think that we probably
should provide some tooling to help with the more complicated
configurations at some point. I would love to have a shell where you add
providers and services interactively and end it with a save as template or
deploy command. I also think that actual templating with files in that
directory would be great. IMHO, all of that needs some more thought and
attention before a 1.0 release.
Would you rather we put the demo into the templates directory?
On Tue, Sep 2, 2014 at 11:30 AM, Kevin Minder <kevin.min...@hortonworks.com>
wrote:
> Can you be a bit more specific about what you are considering doing in the
> source tree? Are you saying that you will be adding these directories:
>
> gateway-release/home/demo
> gateway-release/home/demo/conf
>
> My only concern is that we already have these:
>
> gateway-release/home/templates
> gateway-release/home/samples
>
> and they are already a little poorly defined and out of control. I'm sure
> this is why you are going with a new directory but isn't that really making
> the problem worse? Also doesn't this end up being a very specific type of
> demo (i.e. HDP Sandbox demo)? Ideally there could be others right?
>
>
> On 9/2/14 11:11 AM, larry mccay wrote:
>
>> All -
>>
>> In order to describe the installation of a production deployment vs a demo
>> deployment, I would like to separate the out-of-the-box install from demo
>> setup.
>>
>> Currently, when you unpack the knox archive, the conf directory includes a
>> couple artifacts that are demo specific and are not likely required for a
>> production install.
>>
>> What I have in mind is to move those artifacts into a demo/conf directory
>> and describe the recursive copy of that directory into the actual conf
>> directory in order to deploy the demo.
>>
>> Alternatively, when creating a production deployment, you would copy a
>> templates/topology.xml to the conf/topologies/{clustername}.xml file and
>> edit it to reflect the production environment details.
>>
>> The templates/admin.xml would then be optionally copied to conf/topologies
>> as well.
>>
>> Then for both types of deployments the creation of the master secret would
>> be done through the 'knoxcli.sh create-master' command.
>>
>> Following that, the deployment is ready for start.
>>
>> Unless someone has an objection to this approach, I will make the required
>> changes to the gateway-release module today.
>>
>> Please let me know if this makes sense to you.
>>
>> thanks,
>>
>> --larry
>>
>>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity
> to which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
