Scoping unique host names to organizations rather than globally

Is anyone against relaxing the restriction against duplicate host names? What if the unique restriction was enforced at the organization level?

In addition to multi-tenant needs, there is also a case where customers need to have hosts be represented from a subscription point of view differently depending on the organization. Specifically, a hypervisor is often "duplicated" in multiple organizations so that different product subscriptions may be assigned for the groups.

··· -- @thomasmckay


“The leader must aim high, see big, judge widely, thus setting himself apart form the ordinary people who debate in narrow confines.” ~ Charles De Gaulle

“Leadership is about making others better as a result of your presence and making sure that impact lasts in your absence.” ~ Harvard Business School

Given the fluid nature of our hosts being passed from org to org, I would
not want to deal with the conflicts that may arise.

··· On Monday, October 12, 2015 at 7:45:49 AM UTC-5, Tom McKay wrote: > > > Is anyone against relaxing the restriction against duplicate host names? > What if the unique restriction was enforced at the organization level? > > In addition to multi-tenant needs, there is also a case where customers > need to have hosts be represented from a subscription point of view > differently depending on the organization. Specifically, a hypervisor is > often "duplicated" in multiple organizations so that different product > subscriptions may be assigned for the groups. > > > -- > @thomasmckay > > -- > "The leader must aim high, see big, judge widely, thus setting himself > apart form the ordinary people who debate in narrow confines." ~ Charles De > Gaulle > > "Leadership is about making others better as a result of your presence and > making sure that impact lasts in your absence." ~ Harvard Business School >

I don't think this is possible with puppet - perhaps hypervisor should be
an aspect?

··· On Oct 12, 2015 2:45 PM, "Tom McKay" wrote:

Is anyone against relaxing the restriction against duplicate host names?
What if the unique restriction was enforced at the organization level?

In addition to multi-tenant needs, there is also a case where customers
need to have hosts be represented from a subscription point of view
differently depending on the organization. Specifically, a hypervisor is
often “duplicated” in multiple organizations so that different product
subscriptions may be assigned for the groups.


@thomasmckay


“The leader must aim high, see big, judge widely, thus setting himself
apart form the ordinary people who debate in narrow confines.” ~ Charles De
Gaulle

“Leadership is about making others better as a result of your presence and
making sure that impact lasts in your absence.” ~ Harvard Business School


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Moved to foreman-dev from foreman-users.

> I don't think this is possible with puppet - perhaps hypervisor should be
> an aspect?

DNS would cause an issue, too, if you somehow ended up with the same
hosts using the same DNS proxy to manage their records.

Is there a reason a hypervisor can't be an object in more than one
org/location in Foreman?

Is the main problem with that Candlepin?

··· On Mon, Oct 12, 2015 at 05:45:56PM +0200, Eric D Helms wrote:

On Oct 12, 2015 2:45 PM, “Tom McKay” thomasmckay@redhat.com wrote:

Is anyone against relaxing the restriction against duplicate host names?
What if the unique restriction was enforced at the organization level?

In addition to multi-tenant needs, there is also a case where customers
need to have hosts be represented from a subscription point of view
differently depending on the organization. Specifically, a hypervisor is
often “duplicated” in multiple organizations so that different product
subscriptions may be assigned for the groups.


@thomasmckay


“The leader must aim high, see big, judge widely, thus setting himself
apart form the ordinary people who debate in narrow confines.” ~ Charles De
Gaulle

“Leadership is about making others better as a result of your presence and
making sure that impact lasts in your absence.” ~ Harvard Business School


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


Best Regards,

Stephen Benjamin
Red Hat Engineering

> I don't think this is possible with puppet - perhaps hypervisor should be
> an aspect?

Puppet uses the fqdn as the "ID" of the host? Is the organization not known on the host by puppet?

··· ----- Original Message -----

On Oct 12, 2015 2:45 PM, “Tom McKay” thomasmckay@redhat.com wrote:

Is anyone against relaxing the restriction against duplicate host names?
What if the unique restriction was enforced at the organization level?

In addition to multi-tenant needs, there is also a case where customers
need to have hosts be represented from a subscription point of view
differently depending on the organization. Specifically, a hypervisor is
often “duplicated” in multiple organizations so that different product
subscriptions may be assigned for the groups.


@thomasmckay


“The leader must aim high, see big, judge widely, thus setting himself
apart form the ordinary people who debate in narrow confines.” ~ Charles De
Gaulle

“Leadership is about making others better as a result of your presence and
making sure that impact lasts in your absence.” ~ Harvard Business School


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

> Given the fluid nature of our hosts being passed from org to org, I would
> not want to deal with the conflicts that may arise.

Would there be conflicts if your usage never created same-named hosts? What conflicts do you envision for your usage? Are there times when the duplicate name validation has prevented error scenarios?

Lots of questions, I know. :slight_smile:

··· ----- Original Message -----

On Monday, October 12, 2015 at 7:45:49 AM UTC-5, Tom McKay wrote:

Is anyone against relaxing the restriction against duplicate host names?
What if the unique restriction was enforced at the organization level?

In addition to multi-tenant needs, there is also a case where customers
need to have hosts be represented from a subscription point of view
differently depending on the organization. Specifically, a hypervisor is
often “duplicated” in multiple organizations so that different product
subscriptions may be assigned for the groups.


@thomasmckay


“The leader must aim high, see big, judge widely, thus setting himself
apart form the ordinary people who debate in narrow confines.” ~ Charles De
Gaulle

“Leadership is about making others better as a result of your presence and
making sure that impact lasts in your absence.” ~ Harvard Business School


You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Some conflicts off the top of my head:

  • We are on track to bring on 20+ orgs by years end and I already see
    'jenkins', 'www', 'test', 'foo' hostname variations.
  • Multiple orgs working on a similar project will pass a host to another
    org rather than add users into their org.
··· On Tuesday, October 13, 2015 at 5:12:48 PM UTC-5, Tom McKay wrote: > > > > ----- Original Message ----- > > Given the fluid nature of our hosts being passed from org to org, I > would > > not want to deal with the conflicts that may arise. > > Would there be conflicts if your usage never created same-named hosts? > What conflicts do you envision for your usage? Are there times when the > duplicate name validation has prevented error scenarios? > > Lots of questions, I know. :) > > >