Vhosts?

[renich]

Please, NginX doesn't use this term. It does not provide "VirtualHosts"; it provides server blocks: https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/

[nicksloan]

@renich I'm not a contributor to this formula, but I'm not sure what my opinion is on this.

I think calling it vhost makes it easier for those that are coming from an Apache configuration, but I don't think it is as safe to assume that that is the case as it once was.

For someone building a formula for nginx without that background, I can definitely agree that calling these things vhosts would likely make things more confusing.

It is also important to note that these are not, strictly speaking, server blocks either. They are bit of configuration that can (and often do) contain one or more server blocks, as well as a host of other directives.

Debian-likes represents these as "sites", but I don't know if that terminology translates to Red Hat or other distributions well.

[renich]

Well, curiously enough, we had a discussion on this here as well: voxpupuli/puppet-nginx#348 (comment)

I think sticking to NginX's terminology is the way to go. NginX is not a small subset of the web servers out there anymore. It is a pretty big player and we should hold up the terminology they use.

sites, IMHO, is not a good term for that. Besides, check this out: https://www.nginx.com/resources/wiki/start/topics/examples/server_blocks/

Actually, it would be good if you could read up the issue I posted up there.

Let me know what you think

[nicksloan]

@renich I think I'm with you that using Nginx terminology would be an improvement, but then again, referring to the both the config file, AND the directive as a "server" or "server block" can also lead to confusion. I have many such config files with multiple server blocks in them, not to mention upstreams, maps, and other helpful goodies.

It doesn't appear that Nginx itself takes any stance on the naming or organization of its config files… at least not that I've seen so far.

[renich]

Well, IMHO, you have conf.d/; which serves as the right place to store those many of those things. Mainly, global server configuration.

Then, you have server.d; which holds the server blocks. Those blocks might include maps. I use maps myself (for some wordpress installations, which suck) and I put those guess where? You guessed it! map.d!

[nicksloan]

Speaking of conf.d, I just created an issue the other day for allowing you to define additional config files in the pillar. See #133.

In some cases the maps.d approach would be handy, but my current use of maps are all pretty tightly coupled to a particular site, so I keep them in the site config file. Anyway, I think I still prefer "site" personally, but either option would be an improvement over vhost, and I'd be glad to see either one merged.

[renich]

Well, on the "sites" preference, you're the maintainer and it's up to you. That said, NginX can serve as a proxy and balancer for, pretty much, anything.

Their website defines it not only as a web server, but a proxy:

"NGINX is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server"

https://www.nginx.com/resources/wiki/

NginX Plus goes even further, stating that it is:

"A complete set of web serving, proxying, acceleration, and load-balancing capabilities for HTTP-based, TCP-based, and UDP-based services."

https://www.nginx.com/products/technical-specs/

So, again, this is why I don't think "sites" will do. They are using the "server block" terminology in their websites, though.

[nicksloan]

@renich I'm not the maintainer! Haha. Just someone who was looking at the issues and wanted to contribute, and hopefully bring the maintainers interest back around this way.

[gravyboat]

@renich Feel free to make a PR if you would like.

[renich]

@nicksloan well, good discussion.

@gravyboat sure thing. Will look into it.

[EvaSDK]

The formula was converted to use "servers" in place of "vhosts" a couple of weeks ago. I think this issue can be closed now.

[alfiepates]

It's worth noting that in general, if you're building a thing (Thing 1) that wraps the configuration of another thing (Thing 2), Thing 1 should use the terminology Thing 2 establishes.

Otherwise, you end up with ambiguity which might make sense in the context of Thing 2 and Thing 3, but if you're just working with Thing 2 the documentation might mention "Widgets" when you're working with "Whirligigs".

[EvaSDK]

CC @aboe76, this can probably be closed now.

[aboe76]

@EvaSDK I think you are right.