search

aodn-archive / DELETE_ME_go-go-duck

NetCDF aggregation service
1 stars 0 forks source link

Vm postfix #10

Closed jkburges closed 10 years ago

jkburges commented 10 years ago

https://github.com/aodn/go-go-duck/pull/9 should be merged first.

danfruehauf commented 10 years ago

This is a public repository and you expose the structure of our own private chef repository. Please modify this to not leak such information, by perhaps including the vanilla postfix cookbook for instance. Or any other publicly available postfix cookbook.

jkburges commented 10 years ago

Which is one of the reasons why I think "general" cookbooks (such as postfix) should be in https://github.com/aodn/cookbooks - so that they can be re-used.

aodn/chef should be for truly private and (prod) infrastructure specific things.

I can change it to use public postfix (no idea why we've got our own anyway - I was just trying to use same as we use in production) but what can I do about imos_core?

danfruehauf commented 10 years ago

Change to the public postfix. Now that we have significantly less cookbooks, it'll be much easier to externalize them. Bit by bit...

jkburges commented 10 years ago

Ok - two problems though:

  1. the development environment will now be diverging from production (I've been trying to push us in the opposite direction, and I'm pretty sure you support me on this).
  2. what about the other cookbooks (i.e. chef-solo-encrypted-data-bags and imos_core)?
danfruehauf commented 10 years ago

That's not diverging too much, that's a VM that's pretty far away from production. To test go-go-duck I think it is best to do it from the chef repository, running a VM with go-go-duck. This will provide you everything you need to test go-go-duck.

It's two steps which I believe are unrelated to each other:

jkburges commented 10 years ago

I'm still unsure how to proceed re point 2 above @danfruehauf

danfruehauf commented 10 years ago

Point 2 is something we need to improve. We need to be able to test specific application deployment within chef - rather than nodes. I don't quite have a good idea about it, but my point was that the Vagrantfile in this repository does not reflect what will happen in production - and I think you agree with me about it?

jkburges commented 10 years ago

"that's a VM that's pretty far away from production" - yes, it's a development VM - but, and this is the whole point - it should be like production.

"best to do it from the chef repository" - I whole-heartedly disagree with this. I've said it many times before - aodn/chef should be for our production infrastructure specific stuff.

Things which are common to our production infrastructure, and say dev environments such as this one, should go somewhere "common". Otherwise either people will be discouraged from using chef/vagrant to setup production-like dev envs, and/or we're going to end up with a whole heap of non-production stuff in the chef repo - which will be messy (like the PO pseudo node which we have in there now).

danfruehauf commented 10 years ago

I understand your frustration but this is the situation at the moment. Do I need to remind you who removed 40+ cookbooks out of the chef repository? It was pretty much me and Julian, in case you didn't notice. So the situation is still "dirty" in the chef repository, but we're getting to "clean" at some point. I'd like to see more people except for me and @julian1 cleaning up that stuff. Then, then you can come and rant more about dev/prod boxes.

At the moment, this repository should not rely on a private one. Unless also this repository goes private.

pblain commented 10 years ago

Hey guys, be kind to each other. We're on the same team :-)

danfruehauf commented 10 years ago

@pblain :+1:

jkburges commented 10 years ago

I have no problem helping out with cleaning up chef code, except that I (as a plain-old developer) have to follow what's on the board (and rightly so).

My ranting is in the vain hope of actually lessening the workload on Julian and you, because the idea is that if developers and ops can actually work together from the beginning to deliver production like systems, then the final hurdle of actually installing and maintaining an app into production should be trivial.

Anyway, to proceed with this, I think the following things need to happen:

  1. nco recipe needs to go in a cookbook somewhere other than imos_core, because imos_core has private info in it
  2. cookbook containing nco goes to aodn/cookbooks
  3. cookbook chef-solo-encrypted-data-bags moved to aodn/cookbooks

Then, this project can use these (now public) cookbooks.

2 and 3 not a problem, but where can we put nco? I know you're not keen to add another cookbook, but maybe we need a netcdf cookbook or some such? I experimented with putting the nco recipe in imos-development-environments but on reflection it doesn't really make sense to me to put it there, since it's a recipe which is not just for development envs.