Naming convention for packer address

[youzi]

Instead of naming the url, something like: mtv-develop.vigour.io, which follows this convention: <short-project-name>-<branch-name>.vigour.io, I propose we follow a more strict convention, like:<exact-repo-name>-<branch-name>.vigour.io

Although this will result in slightly longer url's, you will never have to worry about a namespace being taken, plus the url will be a 100% predictable.

I want to verify this with @jimdebeer and @marcusbesjes, before executing

[youzi]

for mtv-play, this means you would get:

mtv-play-develop.vigour.io and mtv-play-master.vigour.io for instance

say we would get another project for mtv, we would have no issues inventing a name, or renaming existing stuff, etc.

[youzi]

obviously you would still be able to create shorter url's for convenience

[jimdebeer]

i would like this

[branch].[repo].vigour.io

with one exeption and that is the master branch

[repo].vigour.io (also avaible as master.[repo].vigour.io, but this is for conveinience)

then you get stuff as

demo.mtv-play.vigour.io
mtv-play.vigour.io
ramon.directv-fl.vigour.io
staging.mtv-play.vigour.io

this also requires us to make nicer names *

[shawninder]

@jimdebeer For now, we can't do this because the SSL certificate we have only supports one subdomain level. In other words, we can do demo.mtv-play.vigour.io, but it won't work with https (until we get a better, more expensive certificate).

[jimdebeer]

ok then we buy a certificate that supports multiple levels

[youzi]

+1

[jimdebeer]

defualt for deployment will have regions as an extra subdomain so we have to check that -- basicly idea is this kind of stuff is all configurable in the package so native has a packer address (in the settings) and you setup a url in super system that fixes the dns records etc

[jimdebeer]

super system is now called dowhap

[jimdebeer]

urls are configurable always -- its only convention then no internal workings

[shawninder]

@aphorise Want to find us such a multi-level certificate?

[marcusbesjes]

I don't think its possible to have an SSL certificate for dynamic / changing levels of subdomains, so you can only have *.vigour.io or *.X.vigour.io, where X is static and * can be anything. I don't think *.*.vigour.io is possible. @aphorise Can you confirm this? (so we can have *.vigour.io, but that won't cover demo.mtv-play.vigour.io)

I'm ok with - as the seperation character: "full repo name" + - + "branch name" + .vigour.io eg mtv-play-demo.vigour.io

I do really think it should be the full repo + branch name because then you always know where to find things, and you don't have to ask / check "hmm where can I find the packer for this branch?"

[shawninder]

Ah yes, that rings a bell. What about mtv-play_demo, just so you know at a glance where the repo name stops and where the branch name begins?

[marcusbesjes]

I don't think it's really important to be able to deduct repo + branch name from the domain name, only the other way around (repo + branch to domain name) because I think it will be obvious in most cases, and I think http://mtv-play_demo.vigour.io looks really ugly :)

[youzi]

@marcusbesjes +1

[shawninder]

@marcusbesjes I don't understand what you mean with your "other way around" thing

[youzi]

@shawninder I think, @marcusbesjes means that are not really any use cases, where someone would have the url, and would then have to find the repo (based on the url).

[aphorise]

Indeed these are multi-level sub-domains and with the introduction of each . the levelling is increased. Eg in the following each of these differ: foo.sublevel1.tld.org bar.sublevel2.tld.org As such they'd each need a septate SSL certificates which come in of the following types:

• Single / Static Scoped (+ $15/year cheapest). -- foo.sublevel1.tld.org only.
• WildCard (+ $80/year - only 1 of:) -- *.sublevel1.tld.org -- *.sublevel2.tld.org
• SAN / Multiple-scope Alternative Naming (cheap but annoying). -- *.sublevel1.tld.org & *.sublevel1.tld.org in single certificate - but these would need regeneration with each addition to the certificate chain.

IMPORTANT Considerations:

1. Although _ is a valid part of DNS RFC & specifications they can cause problems as per in Chrome where for example prefixing _ at the start of a FQDN use to cause it to ignore & do a google search of things - @marcusbesjes may recall me showing him this at the start of the year when I joined.
2. SSL to IP's are 1:1 - this is very important to consider if forexample you're wanting to have foo.sublevel1.tld.org & bar.sublevel2.tld.org on the same machine / environment then we'd need multiple IP's for that host

IMO mtv-play is just mtv - how many MTV branded projects do we have other than play ATM? I also think its all rather subject to whichever gets discovered the first... as long as there is a convention thats explicitly articulated in repo - then whatever the manifestation of projects-branches are in the FQDN then its something we'd all be able to read & understand.

[youzi]

@aphorise Actually we also did a mtv prototype, before doing mtv-play, but this was not hosted on github. Same reasoning applies to directv, for whom we have just finished a prototype, and we will hopefully do more projects for them.

So it's pretty common to have multiple projects for a single client. I still think repo names are the best identifier for a project. (Plus it gives you an incentive to come up with good repo-names ;))

[aphorise]

I'm guessing mtv-prototype would've been the prototype for the eventual mtv-play product? - I like whats been currently proposed and think it may also be worthwhile as a long term approach to consider several different Top-Level-Domains as the main reference of repository/project to: DNS / URL.

So this way for the main and ongoing projects we'de have for example: *.mtv-play.tld All components or subversions of a long term project would then be the final deliver with all parts: pl-hubs.mtvplay.tld, prototype.mtvplay.tld, dev.mtvplay.tld youri.mtvplay.tld, staging.mtvplay.tld etc. etc.

This would need an extra DNS registration & 1x Wild-card SSL certificate if in our convention we keep all sub-repo's of project & master #branch's of the final product delivery on the same level as or @ *.mtv-play.tld with 1x DNS A-Record & 1-CName record and all going to 1x Server environment (imagine 32-Threads / 24Gb Ram) we'd be well set-up for further elasticated or replication as required. This is also good way of seeing how much resources a project collectively consume and where all related assets collectively reside. The only additional work with later load-balancing is that DNS records would need further A-Records with new IP's or DNS (in SSL context).

I do like this approach of different DNS more - as it also doesn't mix / compromise the same SSL's across different projects and spaces nor - and further more they have their own lifespan & timelines (with certificates, names, etc).

[marcusbesjes]

So we are still on repo + - + branch + .vigour.io as the pattern right?

@aphorise we'll need to have some services available through their own dedicated loadbalancers but this is not the default. As we don't want to buy an SSL certificate every time someone decides to deploy something new :)

So the standard flow would be to deploy your project / service as a sub-domain of vigour.io, then in an advanced stage (where you want a dedicated loadbalancer for a service), we would host that on a separate domain, but keep the standard stuff available. e.g. http://mtvplay.tv serves the #production branch through loadbalancer(s), while at the same time http://mtv-play-demo.vigour.io serves the #demo branch, and http://mtv-play-production.vigour.io also serves production, but through the default "shared" load balancer.

(We should be able to monitor recourse consumption per project regardless of domain pattern.)

[aphorise]

@marcusbesjes - hooking everything onto vigour.io is fine for the time being - however with the intended growth it is not advised as it increases dependencies in terms of both human factors, services & providers - thus my recommendations for proper & new scoped DNS naming by project into the future.

Simply put - having all DNS records in one place - and those all managed by 1x provider - with all records accessible by all in one place - is a recipe for disaster. Thats overlooking the fact that we are all using the same access credentials ATM as well which means that our strength is as strong as the 1st compromise in security that anyone one of 5 people could encouter?

Also added to this if there are any unforeseen issues or violations (affecting others, abuse, etc) - then it has automatic association and falls under the umbrella of vigour activity directly - whether directly or indirectly that of vigour and perhaps other 3rd parties we may be working with in collaboration.

If a project - gets a signing within which a single Service-Orientated-Architecture (front & back-end) is expected as part of that deliverable - then its time that this should be self scoped and have a domain of its own.

This can also work well into the future as well when wanting to archive things for example - or having others make any alteration / changes that are: 1.) in DNS scope of project itself only - their own 2.) initially / first prototyped @vigour.io - 3.) Going from point 2 to 1 is similar to delivery to client on different DNS / record - and can be reused to rehearse delivery - 4.) If no client DNS or other issues with that - already a well named & scoped DNS which can be used and ownership transferred onto them

For example I see ATM that mtv-play.com is actually available which is well suited IMO. This is the scope of the project and could house all related branches of different component / modules (hubs, scrapers, etc).

We are talking about a max €90 per project / DNS per right year right?

[shawninder]

This is not the packer's responsibility, it's up to whoever (or rather whatever) is launching the packer