search

CCI-MOC / hil-vpn

vpn microservice for use with HIL
Apache License 2.0
0 stars 1 forks source link

Decide how configuration should work #4

Open zenhack opened 6 years ago

zenhack commented 6 years ago

In particular, we probably need to be able to specify at least:

  1. The ports that may be allocated for openvpn.
  2. The VLANs that may be used.

Since this will only be used the HIL api server, maybe it makes sense not to make 2 configurable, and just allow anything that's a valid VLAN id. I've left this check out in #3, since this is TBD.

There's also some stuff that's redundant with how OBMd works (TLS certs, etc). There's probably a library somewhere that does a lot of that bit for us; we should look around. I'd prefer not to write that stuff twice; if for some reason we can't find anything we should factor that stuff out into a common library or something.

naved001 commented 6 years ago

maybe it makes sense not to make 2 configurable, and just allow anything that's a valid VLAN id.

Yeah, otherwise the admins will have to ensure that HIL config and VPN config allow the same range of VLANs.

zenhack commented 6 years ago

I'm tempted to suggest merging the two repositories so we can more easily share helper packages in a common internal/ directory; I don't want to maintain the config stuff in parallel. Opinions?

naved001 commented 6 years ago

Sorry it's not clear, but what 2 repositories should we merge?

zenhack commented 6 years ago

obmd & hil-vpn

zenhack commented 5 years ago

I've been thinking about the config thing lately, and it might be nice to standardize on using environment variables for config; there are a lot of nice benefits to this, it provides a lot of flexibility as to where to store the data, and it cuts down on the logic we have to write to read in the config. hil-vpnd could just recognize two environment variables MIN_VPN_PORT and MAX_VPN_PORT to tell it what range to allocate in.

With systemd we can just put an EnvironmentFIle=/etc/conf.d/hil-vpnd directive or something and then we can put the variables in that file. But various cloud environments, Travis, etc. all provide nice ways of setting environment variables. Some folks from Heroku wrote up a somewhat popular manifesto on how to design services like this, and config in the environment is one of the things they recommend:

https://12factor.net/config

I think I'll go ahead and do the MIN/MAX environment variable thing for now, just so I'm not blocked on this decision, but thoughts?

naved001 commented 5 years ago

Sorry it's taking me a while to get to this (and the other PRs that are lined up)

obmd & hil-vpn

If we merge the two repositories together, it might be a bit confusing to manage the releases, CI will always run for both, issues will have to be tagged. Though, these aren't such big issues.

Is there a way we could put the common/helper packages in one of the repositories (let's say obmd) and then import it in the other?

And about the configuration stuff, I think it's fine to read from the environment. I'll spend some time reading all the twelve-factors, seems like an interesting read!

zenhack commented 5 years ago

As long as we don't put stuff under an internal/ directory, one of them could import the other. I don't love the asymmetry; with one repo they could just share a single internal/. But other than the aesthetic thing I don't know that there's a huge problem here. It seems a bit clumsy to have to have possibly-related changes spread across several repos though. I am ambivalent.

The env stuff is part of one of the outstanding prs now.

zenhack commented 5 years ago

I think I'll start off by factoring out some of the logic we want from obmd into a package that can be imported from this repo. We can shuffle around where these things live as we go.

ianballou commented 5 years ago

I do think it's a little strange to have hil-vpn rely on obmd, would it be too much of a headache to have a separate repo for the shared code? I agree with @naved001 against merging hil-vpn and obmd, I feel like they should be separate as separate services.

zenhack commented 5 years ago

The thinking was not so much merging the services as just managing our go code in a single repo. But I'm also fine with adding a third repo for shared utilities. The token and http setup stuff both make sense as stand-alone packages.

zenhack commented 5 years ago

It seems like we've come to agreement on what config should look like; are we ready to close this? we may want to open a separate issue (maybe on the obmd tracker) re: factoring stuff out into a common lib.