Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Fabien Boucher]

> 1 and 2 -> Create an httpd::mod defined type that is a wrapper of the 
> original httpd_mod, as done on https://review.openstack.org/#/c/216835/. This 
> wrapper should add the before (and notify?) calls ,
> as well as skipping the call to httpd_mod in centos case 
> (https://review.openstack.org/#/c/216318/) 
> . This is a good solution, but 
> will involve a rewrite on all our manifests, to replace httpd_mod
> calls by httpd::mod as done on https://review.openstack.org/#/c/217334/.

I think that is a good solution as it will remove a lot of duplicate code in 
others manifests. Also modifying the others manifests can be done smoothly
as http_mod and the new resource http::mod will coexist together. Furthermore 
as well as handling there the race and the centos support I'm wondering if
we can introduce into http::mod this kind of check: "if ! 
defined(Httpd::Mod['themod']) {httpd::mod { 'themod': ensure => present}}" ?

Thanks for raising this discussion on the ml.

Fabien

On 28/08/2015 07:45, Yolanda Robla Mota wrote:
> So ... to summarize, we found 3 different issues:
> 
> 1. Races on httpd_mod -> httpd_mod is a custom type, relying on ruby code. It 
> has a clear race, that is shown on all of our manifests using that. If you 
> use httpd_mod to install
> new apache modules, they won't be applied until apache is restarted manually. 
> Reason is that the manifest installs the apache package, and just after that 
> does a start of the apache service,
> without considering other extra configurations needed (httpd_mod in that 
> case).
> 
> 2. httpd_mod is not valid for Centos/RHEL systems. There is a change proposed 
> to fix this behaviour in internal types: 
> https://review.openstack.org/#/c/216318/
> But really all our manifests using httpd_mod should be applying this patch as 
> well. Also, manual workarounds are needed to install mods on CentOS:
> https://review.openstack.org/#/c/199798/8/manifests/init.pp
> 
> puppetlabs-apache does the job internally, allowing to pass related packages 
> to the apache::mod
> construction: 
> https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/mod.pp
> 
> 3. Module does not offer possibilities for adding extra configuration files, 
> need to be done manually such as on: 
> https://review.openstack.org/#/c/215169/2/manifests/apache.pp
> puppetlabs-apache module is offering that: 
> https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/custom_config.pp
> 
> And the short term solution for each problem will be:
> 
> 1 and 2 -> Create an httpd::mod defined type that is a wrapper of the 
> original httpd_mod, as done on https://review.openstack.org/#/c/216835/. This 
> wrapper should add the before (and notify?) calls ,
> as well as skipping the call to httpd_mod in centos case 
> (https://review.openstack.org/#/c/216318/) 
> . This is a good solution, but 
> will involve a rewrite on all our manifests, to replace httpd_mod
> calls by httpd::mod as done on https://review.openstack.org/#/c/217334/.
> 
> 3 -> we should take a look at 
> https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/custom_config.pp
>  , get inspired by that, and add this bits to our httpd module.
> 
> In the long term i'm in favour for puppetlabs-apache migration, but that can 
> be an independent discussion.
> 
> Do we agree on this plan?
> 
> Best
> Yolanda
> 
> 
> El 28/08/15 a las 03:08, Jeremy Stanley escribió:
>> On Thu, Aug 27, 2015 at 5:38 PM, Spencer Krum  wrote:
>> [...]
>>> In that case I would recommend either before => Package['httpd'] or before
>>> => Class['httpd::install']. (The second one requires us to create that
>>> class, but this is a pattern used by many modules to expose exactly this
>>> kind of hooks into the dependency graph).
>> Do you maybe mean "after => Package['httpd']" there? The directories
>> we want to put these files in won't exist until the package
>> installation completes. We just want to make sure we notify the
>> service after the files get installed.
>>
>> Anyway, I'm willing to give this another shot. I will admit I took
>> the easy way out in my patch and just puppeted the needed
>> directories after I ran up against Puppet complaining about a
>> circular dep tree calculation.
> 
> -- 
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer
> +34 605641639
> yolanda.robla-m...@hp.com
> 
> 
> 
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
> 

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[James E. Blair]

Spencer Krum  writes:

> Hello All,
>
> At the meeting on August 25th, we discussed an issue with the puppet-httpd
> module and a few solutions. The issue is that the httpd_mod type does not
> have a baked-in ordering relationship with the Service['httpd'] resource.
> This means that sometimes httpd_mod resources are instantiated after the
> service attempts to come up, meaning the service cannot start.
>
> A few solutions have been proposed:
>
> 1) Modify our use of the httpd_mod resource to use 'before' everywhere.
> This patch [1] is an example of doing that for puppet-gerrit, we'd have to
> perform similar modifications elsewhere in our code.
>
> 2) Modify the httpd module to do this automatically. This patch [2] changes
> the type at the ruby layer using puppet internal apis to add an
> 'autobefore' on the Service['httpd'] resource.
>
> 3) Create an httpd::mod defined type that can do this automatically. We'd
> have to then change every invocation of httpd_mod to be httpd::mod. This
> patch [3] is the patch to create httpd::mod and this patch [4] shows what
> using it would be like. We'd have to apply changes like [4] everywhere in
> our infrastructure.
>
> 4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving
> patching that module to support our usecase and the other(4b) where we use
> the existing api.

Here are the principals I'm working from:

* Puppet should be used to describe the end state of a system and should
be used to ensure that reality matches the described state.

* Puppet has multiple levels of abstraction and implementation.

* The mechanics of how something is done in puppet should be hidden from
the next level of abstraction out.  This facilitates the outermost use
of puppet being as close to mere state description as possible while the
inner layers are concerned with the mechanics of achieving that state.

When we invoke the gerrit module, we might pass some parameters
indicating how it should be used which have implications for the
contents of a configuration file.  In that case, the module user should
not be concerned with what is needed to put that file in place, they may
not even know about the file at all.  The gerrit module itself should
describe how to write that file and what needs to be in place before it
is written.  Because puppet itself has know way of knowing that before
writing a gerrit config file, a java program needs to be run to prepare
the filesystem, we must tell puppet about that ordering.  So the gerrit
module where this happens is the inner-most layer of abstraction that
can define that ordering relationship, and so that's where we should do
it.

Compare that to the simple act of writing a file in a directory.  In
that case, puppet can (now) auto-require the parent directory.  There is
no conceivable need to write a file before creating its containing
directory, in fact, that makes no sense, and puppet itself can detect
that condition and establish the correct ordering.

In our case, we know that in order to start the apache service, the
complete configuration must be written to disk first.  There is no
reason to write part of the configuration, start the service, and then
write more.  Therefore, the innermost layer of abstraction that can
encapsulate the logic is the apache module.  It should take, as input,
the final configuration state of apache.  Within, it should describe the
order of operations needed to achieve that state.  We know that is:

1) install the package
2) configure modules, write vhost and main configuration files
3) start the service

There is never a reason for a user to do those in any other order, so
the apache module should do that for them.

(However, there is a reason for the user to want to avoid starting the
service, so we should expose that as an option.)

Following this logic, I believe that means we should do options 2 or 3
above.  I note that we have an httpd::vhost class already, which
suggests that option 3, create httpd::mod, might be the most internally
consistent.

Yolanda also suggests that this seems to be the way to proceed in her
summary reply to this thread.

-Jim

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Yolanda Robla Mota]

So ... to summarize, we found 3 different issues:

1. Races on httpd_mod -> httpd_mod is a custom type, relying on ruby 
code. It has a clear race, that is shown on all of our manifests using 
that. If you use httpd_mod to install
new apache modules, they won't be applied until apache is restarted 
manually. Reason is that the manifest installs the apache package, and 
just after that does a start of the apache service,
without considering other extra configurations needed (httpd_mod in that 
case).


2. httpd_mod is not valid for Centos/RHEL systems. There is a change 
proposed to fix this behaviour in internal types: 
https://review.openstack.org/#/c/216318/
But really all our manifests using httpd_mod should be applying this 
patch as well. Also, manual workarounds are needed to install mods on 
CentOS:

https://review.openstack.org/#/c/199798/8/manifests/init.pp
puppetlabs-apache does the job internally, allowing to pass related 
packages to the apache::mod
construction: 
https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/mod.pp


3. Module does not offer possibilities for adding extra configuration 
files, need to be done manually such as on: 
https://review.openstack.org/#/c/215169/2/manifests/apache.pp
puppetlabs-apache module is offering that: 
https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/custom_config.pp


And the short term solution for each problem will be:

1 and 2 -> Create an httpd::mod defined type that is a wrapper of the 
original httpd_mod, as done on https://review.openstack.org/#/c/216835/. 
This wrapper should add the before (and notify?) calls ,
as well as skipping the call to httpd_mod in centos case 
(https://review.openstack.org/#/c/216318/) 
. This is a good solution, 
but will involve a rewrite on all our manifests, to replace httpd_mod

calls by httpd::mod as done on https://review.openstack.org/#/c/217334/.

3 -> we should take a look at 
https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/custom_config.pp 
, get inspired by that, and add this bits to our httpd module.


In the long term i'm in favour for puppetlabs-apache migration, but that 
can be an independent discussion.


Do we agree on this plan?

Best
Yolanda


El 28/08/15 a las 03:08, Jeremy Stanley escribió:

On Thu, Aug 27, 2015 at 5:38 PM, Spencer Krum  wrote:
[...]

In that case I would recommend either before => Package['httpd'] or before
=> Class['httpd::install']. (The second one requires us to create that
class, but this is a pattern used by many modules to expose exactly this
kind of hooks into the dependency graph).

Do you maybe mean "after => Package['httpd']" there? The directories
we want to put these files in won't exist until the package
installation completes. We just want to make sure we notify the
service after the files get installed.

Anyway, I'm willing to give this another shot. I will admit I took
the easy way out in my patch and just puppeted the needed
directories after I ran up against Puppet complaining about a
circular dep tree calculation.


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hp.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Spencer Krum]

> Do you maybe mean "after => Package['httpd']" there?
Yes. I mean 'require.'

On Thu, Aug 27, 2015 at 6:08 PM, Jeremy Stanley  wrote:

> On Thu, Aug 27, 2015 at 5:38 PM, Spencer Krum 
> wrote:
> [...]
> > In that case I would recommend either before => Package['httpd'] or
> before
> > => Class['httpd::install']. (The second one requires us to create that
> > class, but this is a pattern used by many modules to expose exactly this
> > kind of hooks into the dependency graph).
>
> Do you maybe mean "after => Package['httpd']" there? The directories
> we want to put these files in won't exist until the package
> installation completes. We just want to make sure we notify the
> service after the files get installed.
>
> Anyway, I'm willing to give this another shot. I will admit I took
> the easy way out in my patch and just puppeted the needed
> directories after I ran up against Puppet complaining about a
> circular dep tree calculation.
> --
> Jeremy Stanley
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>



-- 
Spencer Krum
(619)-980-7820
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Jeremy Stanley]

On Thu, Aug 27, 2015 at 5:38 PM, Spencer Krum  wrote:
[...]
> In that case I would recommend either before => Package['httpd'] or before
> => Class['httpd::install']. (The second one requires us to create that
> class, but this is a pattern used by many modules to expose exactly this
> kind of hooks into the dependency graph).

Do you maybe mean "after => Package['httpd']" there? The directories
we want to put these files in won't exist until the package
installation completes. We just want to make sure we notify the
service after the files get installed.

Anyway, I'm willing to give this another shot. I will admit I took
the easy way out in my patch and just puppeted the needed
directories after I ran up against Puppet complaining about a
circular dep tree calculation.
-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Spencer Krum]

I went off list accidentally here. Copying in for the benefit of others.

On Thu, Aug 27, 2015 at 5:38 PM, Spencer Krum 
wrote:

> In that case I would recommend either before => Package['httpd'] or before
> => Class['httpd::install']. (The second one requires us to create that
> class, but this is a pattern used by many modules to expose exactly this
> kind of hooks into the dependency graph).
>
> On Thu, Aug 27, 2015 at 5:18 PM, Jeremy Stanley  wrote:
>
>> On 2015-08-27 14:11:05 -0700 (-0700), Spencer Krum wrote:
>> > That should be easy to solve by having these files require =>
>> > Class['httpd'], or maybe Package['httpd']. Can you describe this
>> > issue in greater detail?
>>
>> When I tried to require=>Class['httpd'] for some of these files in
>> puppet-etherpad_lite I ended up with a circular dependency, which
>> looked like it had to do with the fact that at least one of the
>> files also had a notify on the service. Unfortunately I neglected to
>> save a copy of the output, so will need to try to recreate this
>> scenario if you need additional details.
>> --
>> Jeremy Stanley
>>
>
>
>
> --
> Spencer Krum
> (619)-980-7820
>



-- 
Spencer Krum
(619)-980-7820
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Paul Belanger]

On Wed, Aug 26, 2015 at 11:31:35AM -0700, Spencer Krum wrote:
> Hello All,
> 
> At the meeting on August 25th, we discussed an issue with the puppet-httpd
> module and a few solutions. The issue is that the httpd_mod type does not
> have a baked-in ordering relationship with the Service['httpd'] resource.
> This means that sometimes httpd_mod resources are instantiated after the
> service attempts to come up, meaning the service cannot start.
> 
> A few solutions have been proposed:
> 
> 1) Modify our use of the httpd_mod resource to use 'before' everywhere.
> This patch [1] is an example of doing that for puppet-gerrit, we'd have to
> perform similar modifications elsewhere in our code.
> 
> 2) Modify the httpd module to do this automatically. This patch [2] changes
> the type at the ruby layer using puppet internal apis to add an
> 'autobefore' on the Service['httpd'] resource.
> 
> 3) Create an httpd::mod defined type that can do this automatically. We'd
> have to then change every invocation of httpd_mod to be httpd::mod. This
> patch [3] is the patch to create httpd::mod and this patch [4] shows what
> using it would be like. We'd have to apply changes like [4] everywhere in
> our infrastructure.
> 
> 4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving
> patching that module to support our usecase and the other(4b) where we use
> the existing api.
> 
For me, migrating to puppet-apache is a long term goal. I personally would like
to see us do it but know it will take us work to get there.  So, to fix the
ordering issue, which ever way falls inline more with upstream puppet-apache
gets my vote.  I would be reluctant to have us implement our own solution,
where (correct me if I am wrong) this works properly under puppet-apache.

So, I would like to see option 3, since upstream does this.

> I have my own opinions about what we should be doing, but this message is
> meant to explain the problem and roads available to us, not to editorialize.
> 
> [1] https://review.openstack.org/#/c/216708/
> [2] https://review.openstack.org/#/c/216436/
> [3] https://review.openstack.org/#/c/216835/
> [4] https://review.openstack.org/#/c/217334/
> 
> -- 
> Spencer Krum
> (619)-980-7820

> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Jeremy Stanley]

On 2015-08-26 11:31:35 -0700 (-0700), Spencer Krum wrote:
[...]
> The issue is that the httpd_mod type does not have a baked-in
> ordering relationship with the Service['httpd'] resource.
[...]

This is not the only issue. We also discovered there are places
we're installing files into /etc/apache2 subdirectories, expecting
installation of the apache2 package to create them. We need to
decide whether:

1. we have each consuming module create the directories it needs,
even if the package installation will later recreate these

2. find some way to define a (non-circular) dependency on the
package installation so that we only install configuration files
after it's completed and then reload or restart the service
-- 
Jeremy Stanley

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Yolanda Robla Mota]

So... we are already consuming several modules from other providers, 
relying on it. Is there some problem of trust in the puppetlabs-apache 
community?
Which are the main reasons (apart from the vhost generation) that are 
preventing us to rely on it, while we rely on others?


El 27/08/15 a las 20:22, Spencer Krum escribió:
I don't think we should plan to use puppet-apache. I think we should 
commit to our fork and fix the issues we have. We can build a simple, 
flexible apache module and stop. Committing to puppetlabs-apache puts 
us on the roller coaster of updates and bugfixes.


The issues we are having are not hard to fix, imho. As with any 
software we build, we need to classify the problems, identify the 
fixes, do the work, etc.


On Thu, Aug 27, 2015 at 11:09 AM, Yolanda Robla Mota 
mailto:yolanda.robla-m...@hp.com>> wrote:


I agree with that approach. We are hitting several issues with
httpd_mod that should be fixed using a defined type.
But I do believe that the way is to consume modules that are
trusted by the community, and don't put efforts on maintaining and
evolving our own modules if there are good alternatives. This will
need a patch to puppetlabs-apache or a wrapper, and a proper
migration plan, so it needs an spec.

Best
Yolanda

El 27/08/15 a las 11:23, Ricardo Carrillo Cruz escribió:

I lean towards fixing now by using the new defined type and we
write a spec
for migrating to puppetlabs-apache (once we merge in upstream
infra needs).

Regards

2015-08-27 11:07 GMT+02:00 Yolanda Robla Mota
mailto:yolanda.robla-m...@hp.com>>:

Hi
Thanks for the explanation. As this is a topic that needs
more background, and a deeper discussion, I created an
etherpad to work on it.
You can access on:
https://etherpad.openstack.org/p/puppet-httpd_vs_puppetlabs-apache

Best
Yolanda

El 26/08/15 a las 20:31, Spencer Krum escribió:

Hello All,

At the meeting on August 25th, we discussed an issue with
the puppet-httpd module and a few solutions. The issue is
that the httpd_mod type does not have a baked-in ordering
relationship with the Service['httpd'] resource. This means
that sometimes httpd_mod resources are instantiated after
the service attempts to come up, meaning the service cannot
start.

A few solutions have been proposed:

1) Modify our use of the httpd_mod resource to use 'before'
everywhere. This patch [1] is an example of doing that for
puppet-gerrit, we'd have to perform similar modifications
elsewhere in our code.

2) Modify the httpd module to do this automatically. This
patch [2] changes the type at the ruby layer using puppet
internal apis to add an 'autobefore' on the Service['httpd']
resource.

3) Create an httpd::mod defined type that can do this
automatically. We'd have to then change every invocation of
httpd_mod to be httpd::mod. This patch [3] is the patch to
create httpd::mod and this patch [4] shows what using it
would be like. We'd have to apply changes like [4]
everywhere in our infrastructure.

4) Migrate to puppetlabs-apache. This has two forms, one(4a)
involving patching that module to support our usecase and
the other(4b) where we use the existing api.

I have my own opinions about what we should be doing, but
this message is meant to explain the problem and roads
available to us, not to editorialize.

[1] https://review.openstack.org/#/c/216708/
[2] https://review.openstack.org/#/c/216436/
[3] https://review.openstack.org/#/c/216835/
[4] https://review.openstack.org/#/c/217334/

-- 
Spencer Krum

(619)-980-7820 


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org  

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


-- 
Yolanda Robla Mota

Cloud Automation and Distribution Engineer
+34 605641639  
yolanda.robla-m...@hp.com  


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra




-- 
Yolanda Robla Mota

Cloud Automation and Distribution Engineer
+34 605641639  
yolanda.robla-m...@hp.com  


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Spencer Krum]

I don't think we should plan to use puppet-apache. I think we should commit
to our fork and fix the issues we have. We can build a simple, flexible
apache module and stop. Committing to puppetlabs-apache puts us on the
roller coaster of updates and bugfixes.

The issues we are having are not hard to fix, imho. As with any software we
build, we need to classify the problems, identify the fixes, do the work,
etc.

On Thu, Aug 27, 2015 at 11:09 AM, Yolanda Robla Mota <
yolanda.robla-m...@hp.com> wrote:

> I agree with that approach. We are hitting several issues with httpd_mod
> that should be fixed using a defined type.
> But I do believe that the way is to consume modules that are trusted by
> the community, and don't put efforts on maintaining and evolving our own
> modules if there are good alternatives. This will need a patch to
> puppetlabs-apache or a wrapper, and a proper migration plan, so it needs an
> spec.
>
> Best
> Yolanda
>
> El 27/08/15 a las 11:23, Ricardo Carrillo Cruz escribió:
>
> I lean towards fixing now by using the new defined type and we write a
> spec
> for migrating to puppetlabs-apache (once we merge in upstream infra needs).
>
> Regards
>
> 2015-08-27 11:07 GMT+02:00 Yolanda Robla Mota :
>
>> Hi
>> Thanks for the explanation. As this is a topic that needs more
>> background, and a deeper discussion, I created an etherpad to work on it.
>> You can access on:
>> https://etherpad.openstack.org/p/puppet-httpd_vs_puppetlabs-apache
>>
>> Best
>> Yolanda
>>
>> El 26/08/15 a las 20:31, Spencer Krum escribió:
>>
>> Hello All,
>>
>> At the meeting on August 25th, we discussed an issue with the
>> puppet-httpd module and a few solutions. The issue is that the httpd_mod
>> type does not have a baked-in ordering relationship with the
>> Service['httpd'] resource. This means that sometimes httpd_mod resources
>> are instantiated after the service attempts to come up, meaning the service
>> cannot start.
>>
>> A few solutions have been proposed:
>>
>> 1) Modify our use of the httpd_mod resource to use 'before' everywhere.
>> This patch [1] is an example of doing that for puppet-gerrit, we'd have to
>> perform similar modifications elsewhere in our code.
>>
>> 2) Modify the httpd module to do this automatically. This patch [2]
>> changes the type at the ruby layer using puppet internal apis to add an
>> 'autobefore' on the Service['httpd'] resource.
>>
>> 3) Create an httpd::mod defined type that can do this automatically. We'd
>> have to then change every invocation of httpd_mod to be httpd::mod. This
>> patch [3] is the patch to create httpd::mod and this patch [4] shows what
>> using it would be like. We'd have to apply changes like [4] everywhere in
>> our infrastructure.
>>
>> 4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving
>> patching that module to support our usecase and the other(4b) where we use
>> the existing api.
>>
>> I have my own opinions about what we should be doing, but this message is
>> meant to explain the problem and roads available to us, not to editorialize.
>>
>> [1] https://review.openstack.org/#/c/216708/
>> [2] https://review.openstack.org/#/c/216436/
>> [3] https://review.openstack.org/#/c/216835/
>> [4] https://review.openstack.org/#/c/217334/
>>
>> --
>> Spencer Krum
>> (619)-980-7820
>>
>>
>> ___
>> OpenStack-Infra mailing 
>> listOpenStack-Infra@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>> --
>> Yolanda Robla Mota
>> Cloud Automation and Distribution Engineer+34 
>> 605641639yolanda.robla-m...@hp.com
>>
>>
>> ___
>> OpenStack-Infra mailing list
>> OpenStack-Infra@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
> --
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer+34 
> 605641639yolanda.robla-m...@hp.com
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>


-- 
Spencer Krum
(619)-980-7820
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Yolanda Robla Mota]

I agree with that approach. We are hitting several issues with httpd_mod 
that should be fixed using a defined type.
But I do believe that the way is to consume modules that are trusted by 
the community, and don't put efforts on maintaining and evolving our own 
modules if there are good alternatives. This will need a patch to 
puppetlabs-apache or a wrapper, and a proper migration plan, so it needs 
an spec.


Best
Yolanda

El 27/08/15 a las 11:23, Ricardo Carrillo Cruz escribió:
I lean towards fixing now by using the new defined type and we write a 
spec
for migrating to puppetlabs-apache (once we merge in upstream infra 
needs).


Regards

2015-08-27 11:07 GMT+02:00 Yolanda Robla Mota 
mailto:yolanda.robla-m...@hp.com>>:


Hi
Thanks for the explanation. As this is a topic that needs more
background, and a deeper discussion, I created an etherpad to work
on it.
You can access on:
https://etherpad.openstack.org/p/puppet-httpd_vs_puppetlabs-apache

Best
Yolanda

El 26/08/15 a las 20:31, Spencer Krum escribió:

Hello All,

At the meeting on August 25th, we discussed an issue with the
puppet-httpd module and a few solutions. The issue is that the
httpd_mod type does not have a baked-in ordering relationship
with the Service['httpd'] resource. This means that sometimes
httpd_mod resources are instantiated after the service attempts
to come up, meaning the service cannot start.

A few solutions have been proposed:

1) Modify our use of the httpd_mod resource to use 'before'
everywhere. This patch [1] is an example of doing that for
puppet-gerrit, we'd have to perform similar modifications
elsewhere in our code.

2) Modify the httpd module to do this automatically. This patch
[2] changes the type at the ruby layer using puppet internal apis
to add an 'autobefore' on the Service['httpd'] resource.

3) Create an httpd::mod defined type that can do this
automatically. We'd have to then change every invocation of
httpd_mod to be httpd::mod. This patch [3] is the patch to create
httpd::mod and this patch [4] shows what using it would be like.
We'd have to apply changes like [4] everywhere in our infrastructure.

4) Migrate to puppetlabs-apache. This has two forms, one(4a)
involving patching that module to support our usecase and the
other(4b) where we use the existing api.

I have my own opinions about what we should be doing, but this
message is meant to explain the problem and roads available to
us, not to editorialize.

[1] https://review.openstack.org/#/c/216708/
[2] https://review.openstack.org/#/c/216436/
[3] https://review.openstack.org/#/c/216835/
[4] https://review.openstack.org/#/c/217334/

-- 
Spencer Krum

(619)-980-7820 


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org  

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


-- 
Yolanda Robla Mota

Cloud Automation and Distribution Engineer
+34 605641639  
yolanda.robla-m...@hp.com  


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra




--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hp.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Ricardo Carrillo Cruz]

I lean towards fixing now by using the new defined type and we write a spec
for migrating to puppetlabs-apache (once we merge in upstream infra needs).

Regards

2015-08-27 11:07 GMT+02:00 Yolanda Robla Mota :

> Hi
> Thanks for the explanation. As this is a topic that needs more background,
> and a deeper discussion, I created an etherpad to work on it.
> You can access on:
> https://etherpad.openstack.org/p/puppet-httpd_vs_puppetlabs-apache
>
> Best
> Yolanda
>
> El 26/08/15 a las 20:31, Spencer Krum escribió:
>
> Hello All,
>
> At the meeting on August 25th, we discussed an issue with the puppet-httpd
> module and a few solutions. The issue is that the httpd_mod type does not
> have a baked-in ordering relationship with the Service['httpd'] resource.
> This means that sometimes httpd_mod resources are instantiated after the
> service attempts to come up, meaning the service cannot start.
>
> A few solutions have been proposed:
>
> 1) Modify our use of the httpd_mod resource to use 'before' everywhere.
> This patch [1] is an example of doing that for puppet-gerrit, we'd have to
> perform similar modifications elsewhere in our code.
>
> 2) Modify the httpd module to do this automatically. This patch [2]
> changes the type at the ruby layer using puppet internal apis to add an
> 'autobefore' on the Service['httpd'] resource.
>
> 3) Create an httpd::mod defined type that can do this automatically. We'd
> have to then change every invocation of httpd_mod to be httpd::mod. This
> patch [3] is the patch to create httpd::mod and this patch [4] shows what
> using it would be like. We'd have to apply changes like [4] everywhere in
> our infrastructure.
>
> 4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving
> patching that module to support our usecase and the other(4b) where we use
> the existing api.
>
> I have my own opinions about what we should be doing, but this message is
> meant to explain the problem and roads available to us, not to editorialize.
>
> [1] https://review.openstack.org/#/c/216708/
> [2] https://review.openstack.org/#/c/216436/
> [3] https://review.openstack.org/#/c/216835/
> [4] https://review.openstack.org/#/c/217334/
>
> --
> Spencer Krum
> (619)-980-7820
>
>
> ___
> OpenStack-Infra mailing 
> listOpenStack-Infra@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
> --
> Yolanda Robla Mota
> Cloud Automation and Distribution Engineer+34 
> 605641639yolanda.robla-m...@hp.com
>
>
> ___
> OpenStack-Infra mailing list
> OpenStack-Infra@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>
>
___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

Re: [OpenStack-Infra] Puppet Apache Dependency Issues

[Yolanda Robla Mota]

Hi
Thanks for the explanation. As this is a topic that needs more 
background, and a deeper discussion, I created an etherpad to work on it.

You can access on:
https://etherpad.openstack.org/p/puppet-httpd_vs_puppetlabs-apache

Best
Yolanda

El 26/08/15 a las 20:31, Spencer Krum escribió:

Hello All,

At the meeting on August 25th, we discussed an issue with the 
puppet-httpd module and a few solutions. The issue is that the 
httpd_mod type does not have a baked-in ordering relationship with the 
Service['httpd'] resource. This means that sometimes httpd_mod 
resources are instantiated after the service attempts to come up, 
meaning the service cannot start.


A few solutions have been proposed:

1) Modify our use of the httpd_mod resource to use 'before' 
everywhere. This patch [1] is an example of doing that for 
puppet-gerrit, we'd have to perform similar modifications elsewhere in 
our code.


2) Modify the httpd module to do this automatically. This patch [2] 
changes the type at the ruby layer using puppet internal apis to add 
an 'autobefore' on the Service['httpd'] resource.


3) Create an httpd::mod defined type that can do this automatically. 
We'd have to then change every invocation of httpd_mod to be 
httpd::mod. This patch [3] is the patch to create httpd::mod and this 
patch [4] shows what using it would be like. We'd have to apply 
changes like [4] everywhere in our infrastructure.


4) Migrate to puppetlabs-apache. This has two forms, one(4a) involving 
patching that module to support our usecase and the other(4b) where we 
use the existing api.


I have my own opinions about what we should be doing, but this message 
is meant to explain the problem and roads available to us, not to 
editorialize.


[1] https://review.openstack.org/#/c/216708/
[2] https://review.openstack.org/#/c/216436/
[3] https://review.openstack.org/#/c/216835/
[4] https://review.openstack.org/#/c/217334/

--
Spencer Krum
(619)-980-7820


___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra


--
Yolanda Robla Mota
Cloud Automation and Distribution Engineer
+34 605641639
yolanda.robla-m...@hp.com

___
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra