<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 10, 2015 at 7:42 AM, Lennart Regebro <span dir="ltr"><<a href="mailto:lregebro@redhat.com" target="_blank">lregebro@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not so sure about the idea that we can't "hijack" other projects<br>
namespaces. If only ironic is allowed to use the prefix "baremetal",<br>
then the prefix should not have been "baremetal" in the first place,<br>
it should have been "ironic". Which of course means it would just be a<br>
replacement for the ironic client, making these whole namespaces<br>
pointless.<br></blockquote><div><br></div><div>I would like to paraphrase this a bit and say that the point of namespacing prefixes is for disambiguation, not to identify which API or project 'owns' a resource.  Users should not need to know or care about that.  Thus far, most plugins have simply used their project name (BAD) or SC endpoint type (still not great) for this.</div><div><br></div><div>I would also say that the whole exercise is not pointless even if there winds up being 'overcloud' and 'undercloud'  top-level commands as the rest of the exercise in consistency is well worth the effort for our users.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I do agree that many of these should not be in baremetal at all as<br>
they are not baremetal specific, but tripleo-things, and hence is a<br>
part of the overcloud/undercloud namespace, and that in the minimum<br>
teaches us to be more careful with the namespaces. We should probably<br>
double-check with others first.<br>
<br>
Oh, sorry, I mean "We should probably increase cross-team<br>
communication visibility to synchronize the integrational aspects of<br>
the openstack client project, going forward."<br></blockquote><div><br></div><div>We do keep track of the resources being used by plugins in the OSC docs as a best-effort central coordination.  This is strictly opt-in as OSC has no way (yet?) to enforce who 'owns' which resource name.</div><div> </div><div>dt</div><div><br></div></div>-- <br><div class="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>