Bug 453532 - Change the name of the pre-created 'default' machine group
Change the name of the pre-created 'default' machine group
Product: Virtualization Tools
Classification: Community
Component: ovirt-server-suite (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Scott Seago
Depends On:
  Show dependency treegraph
Reported: 2008-07-01 04:38 EDT by Daniel Berrange
Modified: 2016-04-26 13:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-06-21 13:14:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Daniel Berrange 2008-07-01 04:38:09 EDT
Description of problem:
On a fresh install there is a top level machine group created called 'default'.
As someone who'd never used oVirt before it wasn't immediately obvious just what
this was.

I think it'd be more informative to name it  'My Data Center' or 'The Data
Center' to make it clear that it is the primary top level grouping of machines.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Scott Seago 2008-10-02 11:30:17 EDT
We can certainly change the name of this. One limitation of the current "find default pool" API is that the default pool cannot be renamed -- we currently find the default pool by finding the child of the HW pool DirectoryPool with a name of HardwarePool::DEFAULT_POOL_NAME.

So picking a new name for the top level HW pool is easy. Making it arbitrarily updatable would be a more involved task.
Comment 2 Daniel Berrange 2008-10-02 11:35:29 EDT
How about having an explicit boolean flag against the pool table, to designate the default one.
Comment 3 Hugh Brock 2008-10-17 16:18:31 EDT
Yeah, users are absolutely going to want to be able to change the name of this pool, I'm confident. Let's come up with a better solution for designating the top-level node and make the pool name editable.
Comment 4 Jason Guiditta 2008-10-17 17:44:20 EDT
How about an actual Pool type of DefaultPool, since we are using STI anyway?  Then it could treated like any other, but still give us differentiation should we need to do something specific.
Comment 5 Scott Seago 2008-10-17 21:47:50 EDT
Both the boolean flag and the DefaultPool type would work, but neither makes it clear in the model that only one pool may be default. Using DefaultPool would add additional complexity in that there are definitely places in the code that make use of pool[:type] -- which would now  return DefaultPool instead of HardwarePool (even if DefaultPool extends HardwarePool). I think the is_default attribute is marginally better in that respect, but we'll need to verify in the save method that at most one pool has this flag set.
Comment 6 Hugh Brock 2008-10-20 08:45:02 EDT
Can we not derive the DefaultPool from the nested-set information? Or is that too fragile?
Comment 7 Scott Seago 2008-10-20 11:42:21 EDT
Well that's sort of what we're doing now, but we needed the name to guarantee uniqueness. Currently the default pool is the immediate child of the 'hardware' directory pool named 'default'. But the model allows multiple children (although there's not currently any way in the UI to create other children here, a ruby script could do it). We also hard-code the 'hardware' directory pool name as well, but again that doesn't show in the UI right now.

So this approach would also require some model validation changes -- i.e. we'd have to prevent more than one pool from being a child of 'hardware' -- which means we'd have to customize the move_to_child_of method to fail if the new parent is 'hardware' and there's already a child pool there.
Comment 8 Daniel Berrange 2008-10-20 12:03:14 EDT
Anything that relies on names is going to break when we inevitably have to translate this stuff in the future.

Note You need to log in before you can comment on or make changes to this bug.