Open Stack

Hi Emilien,

The bin does following things on controller:
1. Install core HyperScale packages.
2. Start HyperScale API server
3. Install UI packages. This will add new files to and modify some existing files of Horison.
4. Create HyperScale user in mysql db. Create database and dump config. Add permissions of nova and cinder DB to HyperScale user.
5. Add ceilometer pollsters for additional stats and modify ceilometer files.
6. Change OpenStack configuration:
a. Create rabbitmq exchanges
b. Create keystone user
c. Define new flavors
d. Create HyperScale volume type and set default volume type to HyperScale in cinder.conf.
e. Restart openstack’s services
7. Configure HyperScale services

Once the controller is configured, we use HyperScale’s CLI to configure data and compute nodes-

On data node (cinder):
1. Install HyperScale data node packages.
2. Change cinder.conf to add backend and change rpc_backend.
3. Give the raw data disks and meta disks to HyperScale storage layer for usage.
4. Configure HyperScale services.
5. Dump config in the HyperScale database.

On compute (nova):
1. Install HyperScale compute packages.
2. Configure cgroup.
3. Disable selinux.
4. Add ceilometer pollsters for additional stats and modify ceilometer files.
5. Modify qemu.conf to relax ACS checks.
6. Modify libvirt.conf and libvirtd to allow live migration.
7. Change network settings.
8. Configure HyperScale services.
9. Dump config in the HyperScale database.

We assume that we will not require steps to install packages if we put packages in the overcloud image. We have started to convert the bin and the CLI into puppet modules.


Regards,
Abhishek

On 6/1/17, 4:24 AM, "Emilien Macchi" <emilien at redhat.com> wrote:

    On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
    <Dnyaneshwar.Pawar at veritas.com> wrote:
    > Hi Alex,
    >
    > Currently we have puppet modules[0] to configure our software which has
    > components on Openstack Controller, Cinder node and Nova node.
    > As per document[1] we successfully tried out role specific configuration[2].
    >
    > So, does it mean that if we have an overcloud image with our packages
    > inbuilt and we call our configuration scripts using role specific
    > configuration, we may not need puppet modules[0] ? Is it acceptable
    > deployment method?
    
    So running a binary from Puppet, to make configuration management is
    not something we recommend.
    Puppet has been good at managing configuration files and services for
    example. In your module, you just manage a file and execute it. The
    problem with that workflow is we have no idea what happens in backend.
    Also we have no way to make Puppet run idempotent, which is one
    important aspect in TripleO.
    
    Please tell us what does the binary, and maybe we can convert the
    tasks into Puppet resources that could be managed by your module. Also
    make the resources by class (service), so we can plug it into the
    composable services in TripleO.
    
    Thanks,
    
    > [0] https://github.com/abhishek-kane/puppet-veritas-hyperscale
    > [1]
    > https://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_config.html
    > [2] http://paste.openstack.org/show/611116/
    >
    > Thanks,
    > Dnyaneshwar
    >
    > On 5/30/17, 6:52 PM, "Alex Schultz" <aschultz at redhat.com> wrote:
    >
    > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
    > <Dnyaneshwar.Pawar at veritas.com> wrote:
    >
    > Hi,
    >
    > I am tying to deploy a software on openstack controller on the overcloud.
    > One way to do this is by modifying ‘overcloud image’ so that all packages of
    > our software are added to image and then run overcloud deploy.
    > Other way is to write heat template and puppet module which will deploy the
    > required packages.
    >
    > Question: Which of above two approaches is better?
    >
    > Note: Configuration part of the software will be done via separate heat
    > template and puppet module.
    >
    >
    > Usually you do both.  Depending on how the end user is expected to
    > deploy, if they are using the TripleoPackages service[0] in their
    > role, the puppet installation of the package won't actually work (we
    > override the package provider to noop) so it needs to be in the
    > images.  That being said, usually there is also a bit of puppet that
    > needs to be written to configure the end service and as a best
    > practice (and for development purposes), it's a good idea to also
    > capture the package in the manifest.
    >
    > Thanks,
    > -Alex
    >
    > [0]
    > https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/tripleo-packages.yaml
    >
    >
    > Thanks and Regards,
    > Dnyaneshwar
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    
    
    
    -- 
    Emilien Macchi
    
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev