Bug 453532
| Summary: | Change the name of the pre-created 'default' machine group | ||
|---|---|---|---|
| Product: | [Community] Virtualization Tools | Reporter: | Daniel Berrangé <berrange> |
| Component: | ovirt-server-suite | Assignee: | Scott Seago <sseago> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | hbrock, jguiditt, ovirt-maint, sseago |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-06-21 17:14:29 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Daniel Berrangé
2008-07-01 08:38:09 UTC
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. How about having an explicit boolean flag against the pool table, to designate the default one. 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. 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. 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. Can we not derive the DefaultPool from the nested-set information? Or is that too fragile? 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. Anything that relies on names is going to break when we inevitably have to translate this stuff in the future. |