[Tripleo] deploy software on Openstack controller on the Overcloud

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Tripleo] deploy software on Openstack controller on the Overcloud

Dnyaneshwar Pawar
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.


Thanks and Regards,
Dnyaneshwar

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Alex Schultz-2
On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
<[hidden email]> 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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Dnyaneshwar Pawar
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?

Thanks,
Dnyaneshwar

On 5/30/17, 6:52 PM, "Alex Schultz" <[hidden email]> wrote:

On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
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



Thanks and Regards,
Dnyaneshwar

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Emilien Macchi-4
On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
<[hidden email]> 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" <[hidden email]> wrote:
>
> On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
> <[hidden email]> 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: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



--
Emilien Macchi

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Abhishek Kane
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" <[hidden email]> wrote:

    On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
    <[hidden email]> 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" <[hidden email]> wrote:
    >
    > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
    > <[hidden email]> 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: [hidden email]?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: [hidden email]?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: [hidden email]?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
   
   
   
    --
    Emilien Macchi
   
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: [hidden email]?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Emilien Macchi-4
On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane <[hidden email]> wrote:
> Hi Emilien,
>
> The bin does following things on controller:
> 1. Install core HyperScale packages.

Should be done by Puppet, with Package resource.

> 2. Start HyperScale API server

Should be done by Puppet, with Service resource.

> 3. Install UI packages. This will add new files to and modify some existing files of Horison.

Should be done by Puppet, with Package resource and also some changes
in puppet-horizon maybe if you need to change Horizon config.

> 4. Create HyperScale user in mysql db. Create database and dump config. Add permissions of nova and cinder DB to HyperScale user.

We have puppet-openstacklib which already manages DBs, you could
easily re-use it. Please look at puppet-nova for example to see how
things works in nova::db::mysql, etc.

> 5. Add ceilometer pollsters for additional stats and modify ceilometer files.

puppet-ceilometer I guess. What do you mean by "files"? Config files?

> 6. Change OpenStack configuration:
> a. Create rabbitmq exchanges

puppet-* modules already does it.

> b. Create keystone user

puppet-keystone already does it.

> c. Define new flavors

puppet-nova can manage flavors.

> d. Create HyperScale volume type and set default volume type to HyperScale in cinder.conf.

we already support multi backends in tripleo, HyperScale would just be
a new addition. Re-use the bits please: puppet-cinder and
puppet-tripleo will need to be patched.

> e. Restart openstack’s services

Already done by openstack/puppet-* modules.

> 7. Configure HyperScale services

Should be done by your module, (you can either write a _config
provider if it's ini standard otherwise just do a template that you
ship in the module, like puppet-horizon).

> 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.

Should be done by Puppet, with Package resource.

> 2. Change cinder.conf to add backend and change rpc_backend.

puppet-cinder

> 3. Give the raw data disks and meta disks to HyperScale storage layer for usage.

what does it means? Do you run a CLI for that?

> 4. Configure HyperScale services.

Should be done by Puppet, with Service resource.

> 5. Dump config in the HyperScale database.

can be done by a script maybe?

>
> On compute (nova):
> 1. Install HyperScale compute packages.

Should be done by Puppet, with Package resource.

> 2. Configure cgroup.

we don't manage cgroups in TripleO AFIK yet but it's something we
could add, maybe with a puppet module.

> 3. Disable selinux.

Please don't do that. Disabling SElinux is a NOGO when adding new
features (sorry to care about Security).

> 4. Add ceilometer pollsters for additional stats and modify ceilometer files.

puppet-ceilometer

> 5. Modify qemu.conf to relax ACS checks.

puppet-nova maybe, but not sure we really want to do that:
https://vfio.blogspot.fr/2014/08/iommu-groups-inside-and-out.html

Any details on why you're doing it?

> 6. Modify libvirt.conf and libvirtd to allow live migration.

It's already supported by puppet-nova.

> 7. Change network settings.

Should be done by os-net-config in TripleO.

> 8. Configure HyperScale services.

Done by your module (again).

> 9. Dump config in the HyperScale database.

same as before.

>
> 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

Hope it helped.

> On 6/1/17, 4:24 AM, "Emilien Macchi" <[hidden email]> wrote:
>
>     On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
>     <[hidden email]> 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" <[hidden email]> wrote:
>     >
>     > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
>     > <[hidden email]> 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: [hidden email]?subject:unsubscribe
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     > __________________________________________________________________________
>     > OpenStack Development Mailing List (not for usage questions)
>     > Unsubscribe: [hidden email]?subject:unsubscribe
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     > __________________________________________________________________________
>     > OpenStack Development Mailing List (not for usage questions)
>     > Unsubscribe: [hidden email]?subject:unsubscribe
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>
>
>
>     --
>     Emilien Macchi
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: [hidden email]?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Emilien Macchi

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Abhishek Kane
Hi,

On cinder node- we need to modify the cinder.conf. We don’t change any config apart from this. We want to keep the config changes in heat template, package installation in puppet, and trigger rest of the operations via Horizon (as it’s done today). We are also trying to get rid of the nova.conf file changes. Once the approach for cinder is sorted, will get back on this.

If this is correct approach for cinder, I will raise review requests for the following projects:
puppet-tripleo: http://paste.openstack.org/show/611697/
puppet-cinder: http://paste.openstack.org/show/611698/
tripleo-heat-templates: http://paste.openstack.org/show/611700/

Also, I am not sure which TripleO repos need to be patched for the controller components.

We have decomposed the controller bin installer into idempotent modules/scripts. Now, the installer is not a black box operation:
https://github.com/abhishek-kane/puppet-veritas-hyperscale
The inline replies below are w.r.t. this project. The product installer bin currently works in atomic fashion. One issue which we see in puppet is the error handling and rollback operations.

Thanks,
Abhishek

On 6/1/17, 8:41 PM, "Emilien Macchi" <[hidden email]> wrote:

    On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane <[hidden email]> wrote:
    > Hi Emilien,
    >
    > The bin does following things on controller:
    > 1. Install core HyperScale packages.
   
    Should be done by Puppet, with Package resource.
Ak> It’s done.
   
    > 2. Start HyperScale API server
   
    Should be done by Puppet, with Service resource.
AK> It’s done.
   
    > 3. Install UI packages. This will add new files to and modify some existing files of Horison.
   
    Should be done by Puppet, with Package resource and also some changes
    in puppet-horizon maybe if you need to change Horizon config.
Ak> We have got rid of the horizon dependency right now. Our GUI components get installed via separate package.
   
    > 4. Create HyperScale user in mysql db. Create database and dump config. Add permissions of nova and cinder DB to HyperScale user.
   
    We have puppet-openstacklib which already manages DBs, you could
    easily re-use it. Please look at puppet-nova for example to see how
    things works in nova::db::mysql, etc.
AK> TBD

    > 5. Add ceilometer pollsters for additional stats and modify ceilometer files.
   
    puppet-ceilometer I guess. What do you mean by "files"? Config files?
Ak> We are trying to get rid of this dependency as well. TBD.
   
    > 6. Change OpenStack configuration:
    > a. Create rabbitmq exchanges
   
    puppet-* modules already does it.
AK> It’s done via script. Do we need to patch any module?
 
    > b. Create keystone user
   
    puppet-keystone already does it.
AK> It’s done via script. Do we need to patch keystone module?

    > c. Define new flavors
   
    puppet-nova can manage flavors.
AK> It’s done via script. Do we need to patch nova module?
   
    > d. Create HyperScale volume type and set default volume type to HyperScale in cinder.conf.
   
    we already support multi backends in tripleo, HyperScale would just be
    a new addition. Re-use the bits please: puppet-cinder and
    puppet-tripleo will need to be patched.
AK> It’s done via script. Do we need to patch cinder module?
 
    > e. Restart openstack’s services
   
    Already done by openstack/puppet-* modules.
AK> We are trying to get rid of all OpenStack config file changes that we used to do. TBD.

    > 7. Configure HyperScale services
   
    Should be done by your module, (you can either write a _config
    provider if it's ini standard otherwise just do a template that you
    ship in the module, like puppet-horizon).
AK> It’s done.

    > 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.
   
    Should be done by Puppet, with Package resource.
 
    > 2. Change cinder.conf to add backend and change rpc_backend.
   
    puppet-cinder
   
    > 3. Give the raw data disks and meta disks to HyperScale storage layer for usage.
   
    what does it means? Do you run a CLI for that?
   
    > 4. Configure HyperScale services.
   
    Should be done by Puppet, with Service resource.
   
    > 5. Dump config in the HyperScale database.
   
    can be done by a script maybe?

    >
    > On compute (nova):
    > 1. Install HyperScale compute packages.
   
    Should be done by Puppet, with Package resource.
   
    > 2. Configure cgroup.
   
    we don't manage cgroups in TripleO AFIK yet but it's something we
    could add, maybe with a puppet module.
   
    > 3. Disable selinux.
   
    Please don't do that. Disabling SElinux is a NOGO when adding new
    features (sorry to care about Security).

    > 4. Add ceilometer pollsters for additional stats and modify ceilometer files.
   
    puppet-ceilometer

    > 5. Modify qemu.conf to relax ACS checks.
   
    puppet-nova maybe, but not sure we really want to do that:
    https://vfio.blogspot.fr/2014/08/iommu-groups-inside-and-out.html
   
    Any details on why you're doing it?
   
    > 6. Modify libvirt.conf and libvirtd to allow live migration.
   
    It's already supported by puppet-nova.
   
    > 7. Change network settings.
   
    Should be done by os-net-config in TripleO.
   
    > 8. Configure HyperScale services.
   
    Done by your module (again).
   
    > 9. Dump config in the HyperScale database.
   
    same as before.
   
    >
    > 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
   
    Hope it helped.
   
    > On 6/1/17, 4:24 AM, "Emilien Macchi" <[hidden email]> wrote:
    >
    >     On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
    >     <[hidden email]> 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" <[hidden email]> wrote:
    >     >
    >     > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
    >     > <[hidden email]> 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: [hidden email]?subject:unsubscribe
    >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >     >
    >     >
    >     > __________________________________________________________________________
    >     > OpenStack Development Mailing List (not for usage questions)
    >     > Unsubscribe: [hidden email]?subject:unsubscribe
    >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >     >
    >     >
    >     > __________________________________________________________________________
    >     > OpenStack Development Mailing List (not for usage questions)
    >     > Unsubscribe: [hidden email]?subject:unsubscribe
    >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >     >
    >
    >
    >
    >     --
    >     Emilien Macchi
    >
    >     __________________________________________________________________________
    >     OpenStack Development Mailing List (not for usage questions)
    >     Unsubscribe: [hidden email]?subject:unsubscribe
    >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    >
    >
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: [hidden email]?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   
   
   
    --
    Emilien Macchi
   
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: [hidden email]?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Abhishek Kane
Updated https://github.com/abhishek-kane/puppet-veritas-hyperscale with the attempts to reuse puppet modules for keystone, rabbitmq and nova_flavor. Still doing some operation via scripts.

Regards.

On 6/7/17, 8:08 PM, "Abhishek Kane" <[hidden email]> wrote:

    Hi,
   
    On cinder node- we need to modify the cinder.conf. We don’t change any config apart from this. We want to keep the config changes in heat template, package installation in puppet, and trigger rest of the operations via Horizon (as it’s done today). We are also trying to get rid of the nova.conf file changes. Once the approach for cinder is sorted, will get back on this.
   
    If this is correct approach for cinder, I will raise review requests for the following projects:
    puppet-tripleo: http://paste.openstack.org/show/611697/
    puppet-cinder: http://paste.openstack.org/show/611698/
    tripleo-heat-templates: http://paste.openstack.org/show/611700/
   
    Also, I am not sure which TripleO repos need to be patched for the controller components.
   
    We have decomposed the controller bin installer into idempotent modules/scripts. Now, the installer is not a black box operation:
    https://github.com/abhishek-kane/puppet-veritas-hyperscale
    The inline replies below are w.r.t. this project. The product installer bin currently works in atomic fashion. One issue which we see in puppet is the error handling and rollback operations.
   
    Thanks,
    Abhishek
   
    On 6/1/17, 8:41 PM, "Emilien Macchi" <[hidden email]> wrote:
   
        On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane <[hidden email]> wrote:
        > Hi Emilien,
        >
        > The bin does following things on controller:
        > 1. Install core HyperScale packages.
       
        Should be done by Puppet, with Package resource.
    Ak> It’s done.
       
        > 2. Start HyperScale API server
       
        Should be done by Puppet, with Service resource.
    AK> It’s done.
       
        > 3. Install UI packages. This will add new files to and modify some existing files of Horison.
       
        Should be done by Puppet, with Package resource and also some changes
        in puppet-horizon maybe if you need to change Horizon config.
    Ak> We have got rid of the horizon dependency right now. Our GUI components get installed via separate package.
       
        > 4. Create HyperScale user in mysql db. Create database and dump config. Add permissions of nova and cinder DB to HyperScale user.
       
        We have puppet-openstacklib which already manages DBs, you could
        easily re-use it. Please look at puppet-nova for example to see how
        things works in nova::db::mysql, etc.
    AK> TBD
   
        > 5. Add ceilometer pollsters for additional stats and modify ceilometer files.
       
        puppet-ceilometer I guess. What do you mean by "files"? Config files?
    Ak> We are trying to get rid of this dependency as well. TBD.
       
        > 6. Change OpenStack configuration:
        > a. Create rabbitmq exchanges
       
        puppet-* modules already does it.
    AK> It’s done via script. Do we need to patch any module?
     
        > b. Create keystone user
       
        puppet-keystone already does it.
    AK> It’s done via script. Do we need to patch keystone module?
   
        > c. Define new flavors
       
        puppet-nova can manage flavors.
    AK> It’s done via script. Do we need to patch nova module?
       
        > d. Create HyperScale volume type and set default volume type to HyperScale in cinder.conf.
       
        we already support multi backends in tripleo, HyperScale would just be
        a new addition. Re-use the bits please: puppet-cinder and
        puppet-tripleo will need to be patched.
    AK> It’s done via script. Do we need to patch cinder module?
     
        > e. Restart openstack’s services
       
        Already done by openstack/puppet-* modules.
    AK> We are trying to get rid of all OpenStack config file changes that we used to do. TBD.
   
        > 7. Configure HyperScale services
       
        Should be done by your module, (you can either write a _config
        provider if it's ini standard otherwise just do a template that you
        ship in the module, like puppet-horizon).
    AK> It’s done.
   
        > 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.
       
        Should be done by Puppet, with Package resource.
     
        > 2. Change cinder.conf to add backend and change rpc_backend.
       
        puppet-cinder
       
        > 3. Give the raw data disks and meta disks to HyperScale storage layer for usage.
       
        what does it means? Do you run a CLI for that?
       
        > 4. Configure HyperScale services.
       
        Should be done by Puppet, with Service resource.
       
        > 5. Dump config in the HyperScale database.
       
        can be done by a script maybe?
   
        >
        > On compute (nova):
        > 1. Install HyperScale compute packages.
       
        Should be done by Puppet, with Package resource.
       
        > 2. Configure cgroup.
       
        we don't manage cgroups in TripleO AFIK yet but it's something we
        could add, maybe with a puppet module.
       
        > 3. Disable selinux.
       
        Please don't do that. Disabling SElinux is a NOGO when adding new
        features (sorry to care about Security).
   
        > 4. Add ceilometer pollsters for additional stats and modify ceilometer files.
       
        puppet-ceilometer
   
        > 5. Modify qemu.conf to relax ACS checks.
       
        puppet-nova maybe, but not sure we really want to do that:
        https://vfio.blogspot.fr/2014/08/iommu-groups-inside-and-out.html
       
        Any details on why you're doing it?
       
        > 6. Modify libvirt.conf and libvirtd to allow live migration.
       
        It's already supported by puppet-nova.
       
        > 7. Change network settings.
       
        Should be done by os-net-config in TripleO.
       
        > 8. Configure HyperScale services.
       
        Done by your module (again).
       
        > 9. Dump config in the HyperScale database.
       
        same as before.
       
        >
        > 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
       
        Hope it helped.
       
        > On 6/1/17, 4:24 AM, "Emilien Macchi" <[hidden email]> wrote:
        >
        >     On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
        >     <[hidden email]> 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" <[hidden email]> wrote:
        >     >
        >     > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
        >     > <[hidden email]> 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: [hidden email]?subject:unsubscribe
        >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
        >     >
        >     >
        >     > __________________________________________________________________________
        >     > OpenStack Development Mailing List (not for usage questions)
        >     > Unsubscribe: [hidden email]?subject:unsubscribe
        >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
        >     >
        >     >
        >     > __________________________________________________________________________
        >     > OpenStack Development Mailing List (not for usage questions)
        >     > Unsubscribe: [hidden email]?subject:unsubscribe
        >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
        >     >
        >
        >
        >
        >     --
        >     Emilien Macchi
        >
        >     __________________________________________________________________________
        >     OpenStack Development Mailing List (not for usage questions)
        >     Unsubscribe: [hidden email]?subject:unsubscribe
        >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
        >
        >
        >
        >
        > __________________________________________________________________________
        > OpenStack Development Mailing List (not for usage questions)
        > Unsubscribe: [hidden email]?subject:unsubscribe
        > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
       
       
       
        --
        Emilien Macchi
       
        __________________________________________________________________________
        OpenStack Development Mailing List (not for usage questions)
        Unsubscribe: [hidden email]?subject:unsubscribe
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
       
   
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: [hidden email]?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Emilien Macchi-4
In reply to this post by Abhishek Kane
On Wed, Jun 7, 2017 at 10:38 AM, Abhishek Kane
<[hidden email]> wrote:

> Hi,
>
> On cinder node- we need to modify the cinder.conf. We don’t change any config apart from this. We want to keep the config changes in heat template, package installation in puppet, and trigger rest of the operations via Horizon (as it’s done today). We are also trying to get rid of the nova.conf file changes. Once the approach for cinder is sorted, will get back on this.
>
> If this is correct approach for cinder, I will raise review requests for the following projects:
> puppet-tripleo: http://paste.openstack.org/show/611697/
> puppet-cinder: http://paste.openstack.org/show/611698/
> tripleo-heat-templates: http://paste.openstack.org/show/611700/
>
> Also, I am not sure which TripleO repos need to be patched for the controller components.
>
> We have decomposed the controller bin installer into idempotent modules/scripts. Now, the installer is not a black box operation:
> https://github.com/abhishek-kane/puppet-veritas-hyperscale
> The inline replies below are w.r.t. this project. The product installer bin currently works in atomic fashion. One issue which we see in puppet is the error handling and rollback operations.
>
> Thanks,
> Abhishek
>
> On 6/1/17, 8:41 PM, "Emilien Macchi" <[hidden email]> wrote:
>
>     On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane <[hidden email]> wrote:
>     > Hi Emilien,
>     >
>     > The bin does following things on controller:
>     > 1. Install core HyperScale packages.
>
>     Should be done by Puppet, with Package resource.
> Ak> It’s done.
>
>     > 2. Start HyperScale API server
>
>     Should be done by Puppet, with Service resource.
> AK> It’s done.
>
>     > 3. Install UI packages. This will add new files to and modify some existing files of Horison.
>
>     Should be done by Puppet, with Package resource and also some changes
>     in puppet-horizon maybe if you need to change Horizon config.
> Ak> We have got rid of the horizon dependency right now. Our GUI components get installed via separate package.
>
>     > 4. Create HyperScale user in mysql db. Create database and dump config. Add permissions of nova and cinder DB to HyperScale user.
>
>     We have puppet-openstacklib which already manages DBs, you could
>     easily re-use it. Please look at puppet-nova for example to see how
>     things works in nova::db::mysql, etc.
> AK> TBD
>
>     > 5. Add ceilometer pollsters for additional stats and modify ceilometer files.
>
>     puppet-ceilometer I guess. What do you mean by "files"? Config files?
> Ak> We are trying to get rid of this dependency as well. TBD.
>
>     > 6. Change OpenStack configuration:
>     > a. Create rabbitmq exchanges
>
>     puppet-* modules already does it.
> AK> It’s done via script. Do we need to patch any module?

Everything that touch *.conf files of OpenStack services need to be
done by existing openstack/puppet-* modules.

>
>     > b. Create keystone user
>
>     puppet-keystone already does it.
> AK> It’s done via script. Do we need to patch keystone module?

No, you'll need to create the right user/roles/endpoints/... in
puppet-tripleo, in a new profile, most probably.
You'll probably need to read a bit about:
https://github.com/openstack/puppet-keystone#setup
Let me know if you need more help on this thing.

>
>     > c. Define new flavors
>
>     puppet-nova can manage flavors.
> AK> It’s done via script. Do we need to patch nova module?

Same as Keystone.
See: https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/provision.pp#L7-L13
You'll probably need that thing in your module or in puppet-tripleo
(composition layer for tripleo).

>
>     > d. Create HyperScale volume type and set default volume type to HyperScale in cinder.conf.
>
>     we already support multi backends in tripleo, HyperScale would just be
>     a new addition. Re-use the bits please: puppet-cinder and
>     puppet-tripleo will need to be patched.
> AK> It’s done via script. Do we need to patch cinder module?

Same, please look how other backends are done in TripleO, we have a
bunch of examples in puppet-tripleo.

>     > e. Restart openstack’s services
>
>     Already done by openstack/puppet-* modules.
> AK> We are trying to get rid of all OpenStack config file changes that we used to do. TBD.
>
>     > 7. Configure HyperScale services
>
>     Should be done by your module, (you can either write a _config
>     provider if it's ini standard otherwise just do a template that you
>     ship in the module, like puppet-horizon).
> AK> It’s done.
>
>     > 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.
>
>     Should be done by Puppet, with Package resource.
>
>     > 2. Change cinder.conf to add backend and change rpc_backend.
>
>     puppet-cinder
>
>     > 3. Give the raw data disks and meta disks to HyperScale storage layer for usage.
>
>     what does it means? Do you run a CLI for that?

I didn't get reply for that FYI ^

>     > 4. Configure HyperScale services.
>
>     Should be done by Puppet, with Service resource.
>
>     > 5. Dump config in the HyperScale database.
>
>     can be done by a script maybe?

ditto.

>     >
>     > On compute (nova):
>     > 1. Install HyperScale compute packages.
>
>     Should be done by Puppet, with Package resource.
>
>     > 2. Configure cgroup.
>
>     we don't manage cgroups in TripleO AFIK yet but it's something we
>     could add, maybe with a puppet module.
>
>     > 3. Disable selinux.
>
>     Please don't do that. Disabling SElinux is a NOGO when adding new
>     features (sorry to care about Security).
>
>     > 4. Add ceilometer pollsters for additional stats and modify ceilometer files.
>
>     puppet-ceilometer
>
>     > 5. Modify qemu.conf to relax ACS checks.
>
>     puppet-nova maybe, but not sure we really want to do that:
>     https://vfio.blogspot.fr/2014/08/iommu-groups-inside-and-out.html
>
>     Any details on why you're doing it?
>
>     > 6. Modify libvirt.conf and libvirtd to allow live migration.
>
>     It's already supported by puppet-nova.
>
>     > 7. Change network settings.
>
>     Should be done by os-net-config in TripleO.
>
>     > 8. Configure HyperScale services.
>
>     Done by your module (again).
>
>     > 9. Dump config in the HyperScale database.
>
>     same as before.
>
>     >
>     > 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
>
>     Hope it helped.
>
>     > On 6/1/17, 4:24 AM, "Emilien Macchi" <[hidden email]> wrote:
>     >
>     >     On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
>     >     <[hidden email]> 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" <[hidden email]> wrote:
>     >     >
>     >     > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
>     >     > <[hidden email]> 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: [hidden email]?subject:unsubscribe
>     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >     >
>     >     >
>     >     > __________________________________________________________________________
>     >     > OpenStack Development Mailing List (not for usage questions)
>     >     > Unsubscribe: [hidden email]?subject:unsubscribe
>     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >     >
>     >     >
>     >     > __________________________________________________________________________
>     >     > OpenStack Development Mailing List (not for usage questions)
>     >     > Unsubscribe: [hidden email]?subject:unsubscribe
>     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >     >
>     >
>     >
>     >
>     >     --
>     >     Emilien Macchi
>     >
>     >     __________________________________________________________________________
>     >     OpenStack Development Mailing List (not for usage questions)
>     >     Unsubscribe: [hidden email]?subject:unsubscribe
>     >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>     >
>     >
>     >
>     > __________________________________________________________________________
>     > OpenStack Development Mailing List (not for usage questions)
>     > Unsubscribe: [hidden email]?subject:unsubscribe
>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>     --
>     Emilien Macchi
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: [hidden email]?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: [hidden email]?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Emilien Macchi

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Abhishek Kane
Thank you for the comments Emilien!

Updated as per your suggestions:
puppet-veritas-hyperscale: https://github.com/abhishek-kane/puppet-veritas-hyperscale

Also, please find the inline replies to your comments.

We had been able to call the old puppet modules (which had scripts) using the generic puppet way (puppet agent --test). But we are unable to deploy the new puppet modules (which use existing puppet classes) the tripleo way. Following paste shows a sample puppet module which we are trying to deploy on an overcloud which is already deployed. We see that our resources are in “CREATE_COMPLETE” status, but the actual operation hasn’t happened.
http://paste.openstack.org/show/612537/

Regards,
Abhishek

On 6/14/17, 1:18 AM, "Emilien Macchi" <[hidden email]> wrote:

    On Wed, Jun 7, 2017 at 10:38 AM, Abhishek Kane
    <[hidden email]> wrote:
    > Hi,
    >
    > On cinder node- we need to modify the cinder.conf. We don’t change any config apart from this. We want to keep the config changes in heat template, package installation in puppet, and trigger rest of the operations via Horizon (as it’s done today). We are also trying to get rid of the nova.conf file changes. Once the approach for cinder is sorted, will get back on this.
    >
    > If this is correct approach for cinder, I will raise review requests for the following projects:
    > puppet-tripleo: http://paste.openstack.org/show/611697/
    > puppet-cinder: http://paste.openstack.org/show/611698/
    > tripleo-heat-templates: http://paste.openstack.org/show/611700/
    >
    > Also, I am not sure which TripleO repos need to be patched for the controller components.
    >
    > We have decomposed the controller bin installer into idempotent modules/scripts. Now, the installer is not a black box operation:
    > https://github.com/abhishek-kane/puppet-veritas-hyperscale
    > The inline replies below are w.r.t. this project. The product installer bin currently works in atomic fashion. One issue which we see in puppet is the error handling and rollback operations.
    >
    > Thanks,
    > Abhishek
    >
    > On 6/1/17, 8:41 PM, "Emilien Macchi" <[hidden email]> wrote:
    >
    >     On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane <[hidden email]> wrote:
    >     > Hi Emilien,
    >     >
    >     > The bin does following things on controller:
    >     > 1. Install core HyperScale packages.
    >
    >     Should be done by Puppet, with Package resource.
    > Ak> It’s done.
    >
    >     > 2. Start HyperScale API server
    >
    >     Should be done by Puppet, with Service resource.
    > AK> It’s done.
    >
    >     > 3. Install UI packages. This will add new files to and modify some existing files of Horison.
    >
    >     Should be done by Puppet, with Package resource and also some changes
    >     in puppet-horizon maybe if you need to change Horizon config.
    > Ak> We have got rid of the horizon dependency right now. Our GUI components get installed via separate package.
    >
    >     > 4. Create HyperScale user in mysql db. Create database and dump config. Add permissions of nova and cinder DB to HyperScale user.
    >
    >     We have puppet-openstacklib which already manages DBs, you could
    >     easily re-use it. Please look at puppet-nova for example to see how
    >     things works in nova::db::mysql, etc.
    > AK> TBD
    >
    >     > 5. Add ceilometer pollsters for additional stats and modify ceilometer files.
    >
    >     puppet-ceilometer I guess. What do you mean by "files"? Config files?
    > Ak> We are trying to get rid of this dependency as well. TBD.
    >
    >     > 6. Change OpenStack configuration:
    >     > a. Create rabbitmq exchanges
    >
    >     puppet-* modules already does it.
    > AK> It’s done via script. Do we need to patch any module?
   
    Everything that touch *.conf files of OpenStack services need to be
    done by existing openstack/puppet-* modules.

AK> https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_rabbitmq.pp We are still doing some operation via script, but it’s idempotent.

    >
    >     > b. Create keystone user
    >
    >     puppet-keystone already does it.
    > AK> It’s done via script. Do we need to patch keystone module?
   
    No, you'll need to create the right user/roles/endpoints/... in
    puppet-tripleo, in a new profile, most probably.
    You'll probably need to read a bit about:
    https://github.com/openstack/puppet-keystone#setup
    Let me know if you need more help on this thing.
   
AK> I have already. https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_keystone.pp

    >
    >     > c. Define new flavors
    >
    >     puppet-nova can manage flavors.
    > AK> It’s done via script. Do we need to patch nova module?
   
    Same as Keystone.
    See: https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/provision.pp#L7-L13
    You'll probably need that thing in your module or in puppet-tripleo
    (composition layer for tripleo).

AK> Already done that. https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_flavors.pp

    >
    >     > d. Create HyperScale volume type and set default volume type to HyperScale in cinder.conf.
    >
    >     we already support multi backends in tripleo, HyperScale would just be
    >     a new addition. Re-use the bits please: puppet-cinder and
    >     puppet-tripleo will need to be patched.
    > AK> It’s done via script. Do we need to patch cinder module?
   
    Same, please look how other backends are done in TripleO, we have a
    bunch of examples in puppet-tripleo.

Ak> The paste links mentioned in last email. Is it correct approach?
puppet-cinder: http://paste.openstack.org/show/612493/
puppet-tripleo: http://paste.openstack.org/show/611697/
tripleo-heat-templates: http://paste.openstack.org/show/611700/

    >     > e. Restart openstack’s services
    >
    >     Already done by openstack/puppet-* modules.
    > AK> We are trying to get rid of all OpenStack config file changes that we used to do. TBD.
    >
    >     > 7. Configure HyperScale services
    >
    >     Should be done by your module, (you can either write a _config
    >     provider if it's ini standard otherwise just do a template that you
    >     ship in the module, like puppet-horizon).
    > AK> It’s done.
    >
    >     > 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.
    >
    >     Should be done by Puppet, with Package resource.
    >

Ak> We have written a puppet module.
https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/datanode_pkg_inst.pp

    >     > 2. Change cinder.conf to add backend and change rpc_backend.
    >
    >     puppet-cinder
Ak > Paste links mentioned above.

    >
    >     > 3. Give the raw data disks and meta disks to HyperScale storage layer for usage.
    >
    >     what does it means? Do you run a CLI for that?
   
    I didn't get reply for that FYI ^

Ak> We need disk names as user input. We show the filtered (exclude mounted, partitioned, etc disks) disks on the GUI and let user choose disks. We create LVM volumes and create XFS mount points which we use later as backend for instance volumes. Since this operation is not done at the time of deployment, we don’t have any puppet module for this.

    >     > 4. Configure HyperScale services.
    >
    >     Should be done by Puppet, with Service resource.
    >
AK> We have added a puppet module for this.
https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/datanode_service_start.pp

    >     > 5. Dump config in the HyperScale database.
    >
    >     can be done by a script maybe?
   
    ditto.

Ak> Work in progress to use the openstacklib mysql component. Currently we are running .sql files. Once we finalize it I will upload it on the github and update.
   
    >     >
    >     > On compute (nova):
    >     > 1. Install HyperScale compute packages.
    >
    >     Should be done by Puppet, with Package resource.
    >
Ak> https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/compute_pkg_inst.pp

    >     > 2. Configure cgroup.
    >
    >     we don't manage cgroups in TripleO AFIK yet but it's something we
    >     could add, maybe with a puppet module.
    >
AK> TODO

    >     > 3. Disable selinux.
    >
    >     Please don't do that. Disabling SElinux is a NOGO when adding new
    >     features (sorry to care about Security).
    >
Ak> We have now removed this change. We don’t change any selinux setting now.

    >     > 4. Add ceilometer pollsters for additional stats and modify ceilometer files.
    >
    >     puppet-ceilometer
    >
Ak> We are trying to get rid of the ceilometer changes. Will update on this later.

    >     > 5. Modify qemu.conf to relax ACS checks.
    >
    >     puppet-nova maybe, but not sure we really want to do that:
    >     https://vfio.blogspot.fr/2014/08/iommu-groups-inside-and-out.html
    >
    >     Any details on why you're doing it?
    >
AK> TODO

    >     > 6. Modify libvirt.conf and libvirtd to allow live migration.
    >
Ak> TODO

    >     It's already supported by puppet-nova.
    >
    >     > 7. Change network settings.
    >
    >     Should be done by os-net-config in TripleO.
    >
Ak> TODO

    >     > 8. Configure HyperScale services.
    >
    >     Done by your module (again).
    >
Ak> https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/compute_service_start.pp

    >     > 9. Dump config in the HyperScale database.
    >
    >     same as before.
    >
Ak> Work in progress to use the openstacklib mysql component. Currently we are running .sql files. Once we finalize it I will upload it on the github and update.

    >     >
    >     > 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
    >
    >     Hope it helped.
    >
    >     > On 6/1/17, 4:24 AM, "Emilien Macchi" <[hidden email]> wrote:
    >     >
    >     >     On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
    >     >     <[hidden email]> 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" <[hidden email]> wrote:
    >     >     >
    >     >     > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
    >     >     > <[hidden email]> 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: [hidden email]?subject:unsubscribe
    >     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >     >     >
    >     >     >
    >     >     > __________________________________________________________________________
    >     >     > OpenStack Development Mailing List (not for usage questions)
    >     >     > Unsubscribe: [hidden email]?subject:unsubscribe
    >     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >     >     >
    >     >     >
    >     >     > __________________________________________________________________________
    >     >     > OpenStack Development Mailing List (not for usage questions)
    >     >     > Unsubscribe: [hidden email]?subject:unsubscribe
    >     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >     >     >
    >     >
    >     >
    >     >
    >     >     --
    >     >     Emilien Macchi
    >     >
    >     >     __________________________________________________________________________
    >     >     OpenStack Development Mailing List (not for usage questions)
    >     >     Unsubscribe: [hidden email]?subject:unsubscribe
    >     >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >     >
    >     >
    >     >
    >     >
    >     > __________________________________________________________________________
    >     > OpenStack Development Mailing List (not for usage questions)
    >     > Unsubscribe: [hidden email]?subject:unsubscribe
    >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    >
    >
    >     --
    >     Emilien Macchi
    >
    >     __________________________________________________________________________
    >     OpenStack Development Mailing List (not for usage questions)
    >     Unsubscribe: [hidden email]?subject:unsubscribe
    >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
    >
    >
    > __________________________________________________________________________
    > OpenStack Development Mailing List (not for usage questions)
    > Unsubscribe: [hidden email]?subject:unsubscribe
    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   
   
   
    --
    Emilien Macchi
   
    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe: [hidden email]?subject:unsubscribe
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
   

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [EXTERNAL] Re: [Tripleo] deploy software on Openstack controller on the Overcloud

Dnyaneshwar Pawar

On 6/14/17, 6:00 PM, "Abhishek Kane" <[hidden email]> wrote:

>Thank you for the comments Emilien!
>
>Updated as per your suggestions:
>puppet-veritas-hyperscale: https://github.com/abhishek-kane/puppet-veritas-hyperscale
>
>Also, please find the inline replies to your comments.
>
>We had been able to call the old puppet modules (which had scripts) using the generic puppet way (puppet agent --test). But we are unable to deploy the new puppet modules (which use existing puppet classes) the tripleo way. Following paste shows a sample puppet module which we are trying to deploy on an overcloud which is already deployed. We see that our resources are in “CREATE_COMPLETE” status, but the actual operation hasn’t happened.
>http://paste.openstack.org/show/612537/

Thanks to Steven Hardy, We are now able to apply (puppet apply) our individual puppet modules inside overcloud controller.
We are working on creating compossible services.



>
>Regards,
>Abhishek
>
>On 6/14/17, 1:18 AM, "Emilien Macchi" <[hidden email]> wrote:
>
>    On Wed, Jun 7, 2017 at 10:38 AM, Abhishek Kane
>    <[hidden email]> wrote:
>    > Hi,
>    >
>    > On cinder node- we need to modify the cinder.conf. We don’t change any config apart from this. We want to keep the config changes in heat template, package installation in puppet, and trigger rest of the operations via Horizon (as it’s done today). We are also trying to get rid of the nova.conf file changes. Once the approach for cinder is sorted, will get back on this.
>    >
>    > If this is correct approach for cinder, I will raise review requests for the following projects:
>    > puppet-tripleo: http://paste.openstack.org/show/611697/
>    > puppet-cinder: http://paste.openstack.org/show/611698/
>    > tripleo-heat-templates: http://paste.openstack.org/show/611700/
>    >
>    > Also, I am not sure which TripleO repos need to be patched for the controller components.
>    >
>    > We have decomposed the controller bin installer into idempotent modules/scripts. Now, the installer is not a black box operation:
>    > https://github.com/abhishek-kane/puppet-veritas-hyperscale
>    > The inline replies below are w.r.t. this project. The product installer bin currently works in atomic fashion. One issue which we see in puppet is the error handling and rollback operations.
>    >
>    > Thanks,
>    > Abhishek
>    >
>    > On 6/1/17, 8:41 PM, "Emilien Macchi" <[hidden email]> wrote:
>    >
>    >     On Thu, Jun 1, 2017 at 3:47 PM, Abhishek Kane <[hidden email]> wrote:
>    >     > Hi Emilien,
>    >     >
>    >     > The bin does following things on controller:
>    >     > 1. Install core HyperScale packages.
>    >
>    >     Should be done by Puppet, with Package resource.
>    > Ak> It’s done.
>    >
>    >     > 2. Start HyperScale API server
>    >
>    >     Should be done by Puppet, with Service resource.
>    > AK> It’s done.
>    >
>    >     > 3. Install UI packages. This will add new files to and modify some existing files of Horison.
>    >
>    >     Should be done by Puppet, with Package resource and also some changes
>    >     in puppet-horizon maybe if you need to change Horizon config.
>    > Ak> We have got rid of the horizon dependency right now. Our GUI components get installed via separate package.
>    >
>    >     > 4. Create HyperScale user in mysql db. Create database and dump config. Add permissions of nova and cinder DB to HyperScale user.
>    >
>    >     We have puppet-openstacklib which already manages DBs, you could
>    >     easily re-use it. Please look at puppet-nova for example to see how
>    >     things works in nova::db::mysql, etc.
>    > AK> TBD
>    >
>    >     > 5. Add ceilometer pollsters for additional stats and modify ceilometer files.
>    >
>    >     puppet-ceilometer I guess. What do you mean by "files"? Config files?
>    > Ak> We are trying to get rid of this dependency as well. TBD.
>    >
>    >     > 6. Change OpenStack configuration:
>    >     > a. Create rabbitmq exchanges
>    >
>    >     puppet-* modules already does it.
>    > AK> It’s done via script. Do we need to patch any module?
>    
>    Everything that touch *.conf files of OpenStack services need to be
>    done by existing openstack/puppet-* modules.
>
>AK> https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_rabbitmq.pp We are still doing some operation via script, but it’s idempotent.
>
>    >
>    >     > b. Create keystone user
>    >
>    >     puppet-keystone already does it.
>    > AK> It’s done via script. Do we need to patch keystone module?
>    
>    No, you'll need to create the right user/roles/endpoints/... in
>    puppet-tripleo, in a new profile, most probably.
>    You'll probably need to read a bit about:
>    https://github.com/openstack/puppet-keystone#setup
>    Let me know if you need more help on this thing.
>    
>AK> I have already. https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_keystone.pp
>
>    >
>    >     > c. Define new flavors
>    >
>    >     puppet-nova can manage flavors.
>    > AK> It’s done via script. Do we need to patch nova module?
>    
>    Same as Keystone.
>    See: https://github.com/openstack/puppet-openstack-integration/blob/master/manifests/provision.pp#L7-L13
>    You'll probably need that thing in your module or in puppet-tripleo
>    (composition layer for tripleo).
>
>AK> Already done that. https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/hs_flavors.pp
>
>    >
>    >     > d. Create HyperScale volume type and set default volume type to HyperScale in cinder.conf.
>    >
>    >     we already support multi backends in tripleo, HyperScale would just be
>    >     a new addition. Re-use the bits please: puppet-cinder and
>    >     puppet-tripleo will need to be patched.
>    > AK> It’s done via script. Do we need to patch cinder module?
>    
>    Same, please look how other backends are done in TripleO, we have a
>    bunch of examples in puppet-tripleo.
>
>Ak> The paste links mentioned in last email. Is it correct approach?
>puppet-cinder: http://paste.openstack.org/show/612493/
>puppet-tripleo: http://paste.openstack.org/show/611697/
>tripleo-heat-templates: http://paste.openstack.org/show/611700/
>
>    >     > e. Restart openstack’s services
>    >
>    >     Already done by openstack/puppet-* modules.
>    > AK> We are trying to get rid of all OpenStack config file changes that we used to do. TBD.
>    >
>    >     > 7. Configure HyperScale services
>    >
>    >     Should be done by your module, (you can either write a _config
>    >     provider if it's ini standard otherwise just do a template that you
>    >     ship in the module, like puppet-horizon).
>    > AK> It’s done.
>    >
>    >     > 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.
>    >
>    >     Should be done by Puppet, with Package resource.
>    >
>
>Ak> We have written a puppet module.
>https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/datanode_pkg_inst.pp
>
>    >     > 2. Change cinder.conf to add backend and change rpc_backend.
>    >
>    >     puppet-cinder
>Ak > Paste links mentioned above.
>
>    >
>    >     > 3. Give the raw data disks and meta disks to HyperScale storage layer for usage.
>    >
>    >     what does it means? Do you run a CLI for that?
>    
>    I didn't get reply for that FYI ^
>
>Ak> We need disk names as user input. We show the filtered (exclude mounted, partitioned, etc disks) disks on the GUI and let user choose disks. We create LVM volumes and create XFS mount points which we use later as backend for instance volumes. Since this operation is not done at the time of deployment, we don’t have any puppet module for this.
>
>    >     > 4. Configure HyperScale services.
>    >
>    >     Should be done by Puppet, with Service resource.
>    >
>AK> We have added a puppet module for this.
>https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/datanode_service_start.pp
>
>    >     > 5. Dump config in the HyperScale database.
>    >
>    >     can be done by a script maybe?
>    
>    ditto.
>
>Ak> Work in progress to use the openstacklib mysql component. Currently we are running .sql files. Once we finalize it I will upload it on the github and update.
>    
>    >     >
>    >     > On compute (nova):
>    >     > 1. Install HyperScale compute packages.
>    >
>    >     Should be done by Puppet, with Package resource.
>    >
>Ak> https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/compute_pkg_inst.pp
>
>    >     > 2. Configure cgroup.
>    >
>    >     we don't manage cgroups in TripleO AFIK yet but it's something we
>    >     could add, maybe with a puppet module.
>    >
>AK> TODO
>
>    >     > 3. Disable selinux.
>    >
>    >     Please don't do that. Disabling SElinux is a NOGO when adding new
>    >     features (sorry to care about Security).
>    >
>Ak> We have now removed this change. We don’t change any selinux setting now.
>
>    >     > 4. Add ceilometer pollsters for additional stats and modify ceilometer files.
>    >
>    >     puppet-ceilometer
>    >
>Ak> We are trying to get rid of the ceilometer changes. Will update on this later.
>
>    >     > 5. Modify qemu.conf to relax ACS checks.
>    >
>    >     puppet-nova maybe, but not sure we really want to do that:
>    >     https://vfio.blogspot.fr/2014/08/iommu-groups-inside-and-out.html
>    >
>    >     Any details on why you're doing it?
>    >
>AK> TODO
>
>    >     > 6. Modify libvirt.conf and libvirtd to allow live migration.
>    >
>Ak> TODO
>
>    >     It's already supported by puppet-nova.
>    >
>    >     > 7. Change network settings.
>    >
>    >     Should be done by os-net-config in TripleO.
>    >
>Ak> TODO
>
>    >     > 8. Configure HyperScale services.
>    >
>    >     Done by your module (again).
>    >
>Ak> https://github.com/abhishek-kane/puppet-veritas-hyperscale/blob/master/manifests/compute_service_start.pp
>
>    >     > 9. Dump config in the HyperScale database.
>    >
>    >     same as before.
>    >
>Ak> Work in progress to use the openstacklib mysql component. Currently we are running .sql files. Once we finalize it I will upload it on the github and update.
>
>    >     >
>    >     > 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
>    >
>    >     Hope it helped.
>    >
>    >     > On 6/1/17, 4:24 AM, "Emilien Macchi" <[hidden email]> wrote:
>    >     >
>    >     >     On Wed, May 31, 2017 at 6:29 PM, Dnyaneshwar Pawar
>    >     >     <[hidden email]> 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" <[hidden email]> wrote:
>    >     >     >
>    >     >     > On Mon, May 29, 2017 at 5:05 AM, Dnyaneshwar Pawar
>    >     >     > <[hidden email]> 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: [hidden email]?subject:unsubscribe
>    >     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    >     >     >
>    >     >     >
>    >     >     > __________________________________________________________________________
>    >     >     > OpenStack Development Mailing List (not for usage questions)
>    >     >     > Unsubscribe: [hidden email]?subject:unsubscribe
>    >     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    >     >     >
>    >     >     >
>    >     >     > __________________________________________________________________________
>    >     >     > OpenStack Development Mailing List (not for usage questions)
>    >     >     > Unsubscribe: [hidden email]?subject:unsubscribe
>    >     >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    >     >     >
>    >     >
>    >     >
>    >     >
>    >     >     --
>    >     >     Emilien Macchi
>    >     >
>    >     >     __________________________________________________________________________
>    >     >     OpenStack Development Mailing List (not for usage questions)
>    >     >     Unsubscribe: [hidden email]?subject:unsubscribe
>    >     >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    >     >
>    >     >
>    >     >
>    >     >
>    >     > __________________________________________________________________________
>    >     > OpenStack Development Mailing List (not for usage questions)
>    >     > Unsubscribe: [hidden email]?subject:unsubscribe
>    >     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    >
>    >
>    >
>    >     --
>    >     Emilien Macchi
>    >
>    >     __________________________________________________________________________
>    >     OpenStack Development Mailing List (not for usage questions)
>    >     Unsubscribe: [hidden email]?subject:unsubscribe
>    >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    >
>    >
>    > __________________________________________________________________________
>    > OpenStack Development Mailing List (not for usage questions)
>    > Unsubscribe: [hidden email]?subject:unsubscribe
>    > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    
>    
>    
>    --
>    Emilien Macchi
>    
>    __________________________________________________________________________
>    OpenStack Development Mailing List (not for usage questions)
>    Unsubscribe: [hidden email]?subject:unsubscribe
>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>    
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: [hidden email]?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [hidden email]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Loading...