install.sh needs an overhaul

Some things I'd like if you're rewriting it:

The puppet master is current run outside of apache for some reason. I dont' think this is actually needed.

All in one shouldn't just run apply and be treated differently to everything else

1) How about you just rename it install_simple_aio_on_one_node_with_eth0_as_your_management_and_eth1_as_your_public_network.sh

2) Write another script that by default drops into q&a mode, asks the questions to the user (perhaps with sensible defaults defined), and then can do whatever configuration is necessary for the more complex cases. That script could even do some validity checking, and with Pradeeps previous work in this area, could even present itself as as web-ui.

But let's not try to turn something simple into something complex.

If it's easier to consume as user stories:

As a first time OpenStack operator/user, I'd like to have a simple script to turn that on, so that I can get a better understanding for how OpenStack works and wether it's fit for my purposes.

and

As an OpenStack operator, I'd like to have a script to help me deal with the myriad configuration options based on my targeted deployment type, so that I don't miss configuring any required or non-trivial configuration parameters

Those are two different things. If the latter can cover the former easily, more power to it.

R

On Dec 18, 2013, at 7:50 PM, Michael Chapman <email address hidden>
 wrote:

> Some things I'd like if you're rewriting it:
>
> The puppet master is current run outside of apache for some reason. I
> dont' think this is actually needed.
>
> All in one shouldn't just run apply and be treated differently to
> everything else
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1262281
>
> Title:
> install.sh needs an overhaul
>
> Status in Openstack @ Cisco:
> New
>
> Bug description:
> install.sh in it's current incarnation is problematic. We're expecting
> the user to set a few envs and then curl the script from a remote
> repo. This is probably not a sustainable model. I think we need a
> discussion on how to rewrite it. I've heard that this current form is
> needed for upstream test setup, so I propose that we move this script
> to a test status and create a new one for actual installation.
>
> Some ideas that have come up so far are:
> 1. parameterize the script and have the user pass their requirements as args
> 2. have a list of envs at the top of the script that the user will be instructed to edit
>
> There are two other blocks in the script which are problematic: the
> domain setting if block and the hosts file modification block. There
> are people who are already ripping out the hosts block. I always have.
> I also always remove the domain block and set it statically. It should
> be done this way, not leaving the gathering of the fqdn to hostname
> -f. Facter could be a viable solution.
>
> Please include your thoughts on how we may make this more user
> friendly and I will gladly write a new script on our conclusions.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openstack-cisco/+bug/1262281/+subscriptions

Don,

The install script has evolved in a strange way. Dan and I were using env vars to pull in data from Jenkins when we did builds because parsing yaml was difficult in bash. This then turned into the user facing script because Robert wanted something he could use to get going quickly with AIO.

I want to say now that env vars is definitely the wrong way to do things and it's mostly my fault it's like this.

If you're going to rewrite the install script it should be entirely yaml driven, which probably means using a language that isn't bash. All the lines that say things like "export external_interface="${external_interface:-eth1}" should be replaced with code that does a hiera lookup. Most of them shouldn't even be needed because they can just be in the user.%{scenario}.yaml or user.common. This then means that all parameters that are set in that script should be checked to make sure they are actually in our default set of yaml for each scenario.

IMO the install experience should be
1 Run a script that prepares the environment for use, which would mean installing git and puppet, cloning builder, and applying setup.pp. This is not parameterized at all.
2 User customizes by editing yaml OR via a Q&A script
3 Run a script that will apply config and download plugins

With the current installer script what i can see is

1. if we need to add a node we have to rebuild the whole cloud which is pretty hectic if some one have more nodes
2. if some one have to add multiple nodes then he need to add 100 entries to role_mappings.yaml which is again hectic job

what we can have is by adding nodes we need not to rebuild the whole cloud
and for adding multiple nodes we should not need to add all the entries

for example:
if someone wants to add 100 compute nodes then we can have a class which will look for hostname "compute" if the hostname of the server is computeXXXXXX where XXXXXX are numbers then it should automatically added to compute servers list and same for swift and cinder

by that way it wont be required to rebuild the whole cloud system.

any thoughts on it?

Chatted with Michael, he has some good ideas he will add to the blueprint.

https://blueprints.launchpad.net/openstack-cisco/+spec/new-install-scripts

Satya,

For 1) That's isn't or shouldn't be the case, but I can imagine it being complex if you're doing something like adding a second or third controller. To be clear, once the choice of HA/not-HA has been made and the set of control nodes has been deployed, adding compute nodes at any time should be a matter of adding role mappings. If that's not the case then I/we messed up somewhere.

For 2), I need to double check this, but you should be able to use puppet's regex-matching stuff for defining multiple nodes. Off the top of my head that's /compute/ or similar

If that doesn't work then it's probably an issue in the node terminus.