Closed patcon closed 8 years ago
Maybe we could consider leaving this cookbook with the default HSQL and creating separate confluence-mysql
, confluence-postgresql
, etc?
Those cookbooks could override the main cookbook resources and provide database specific attributes and upstream module support
Actually, that's pretty enticing. I particularly find it difficult that the dependencies for both mysql and postgresql are required and pinned for each of the atlassian cookbooks... Having said that, I would find it equally helpful to just remove the "depends" in favour of "recommends" in the metadata, if ppl don't like the idea of database-specific wrapper cookbooks
On second thought, that's a larger question and rethink of the cookbook that I'd love to pick up in another issue. For now, it would be great to see this small change considered and hopefully merged :)
I have push access, but I'd want to get a +1 before doing so!
Hi @patcon, Thanks for the contribution! It looks good to me except some notes:
"none"
database type seems to be not really meaningful. May be, it makes sence to keep just "hsqldb"
as no-op value?CHANGELOG.md
here, but usually it is not recommened to do so in the scope of Pull-Request. It's specified in contribution guidelenes (link). So, adding .gitattributes
could be skipped, IMO.About the dependencies and database management in particular:
I agree with you guys. All the situation around postgresql
, mysql
cookbook (as well as nginx
, apache
, java
) and other 3rd-party stuff makes us to understend that we should to make our cookbook as lightweight as possible, with minimal set of dependencies.
In my opinion, this cookbook should be truely "application" cookbook with the main goal - to set up and configure Conflience application. So, it seems reasonable to move 3rd-party customizations, such as database, reverse-proxy and JRE setup, outside of the cookbook. We can provide wrapper examples and other best practices, but it should be done outside.
I think about working on it soon by adding custom resources like confluence_install
and confluence_standalone
for both of installation ways we curenly support. That will be done in the separate branch yet and we will discuss it together before releasing under the new major version.
Keep in touch! :)
The path needs a bit more checking: e.g. libraries/helpers.rb will barf at 74.
68 case settings['database']['type']
69 when 'mysql'
70 settings['database']['port'] ||= 3306
71 when 'postgresql'
72 settings['database']['port'] ||= 5432
73 else
74 raise "Unsupported database type: #{settings['database']['type']}"
75 end
Done and done!
@patcon Just not to bother you, I've squashed & rebased your PR with saved authorship: GH-119. Don't you mind it to be merged?
Thanks! Looks great!
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
We were looking to test some new platforms with just the bundled HSQLDB. There is currently no intuitive way to do this. The closest thing is but setting the
node['confluence']['database']['host']
to a non-127.0.0.1
value, which skips the database recipe, but this is a little indirect for someone else reading.I'd like to add a no-op condition in the database recipe for
hsqldb
:)