| Summary: | Removing a lab controller results in an ISE | ||
|---|---|---|---|
| Product: | [Retired] Beaker | Reporter: | Matt Brodeur <mbrodeur> |
| Component: | web UI | Assignee: | Raymond Mancy <rmancy> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 0.6 | CC: | bpeck, dcallagh, ebaak, mcsontos, rmancy, rousseau, stl |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-19 05:16:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Matt Brodeur
2011-04-01 18:19:51 UTC
Ray, We probably have some outstanding jobs still running on that lab. We should show the user a list of active recipes off that lab controller, and confirm that removing the lab will cancel these. It seems to be a problem with constraints and tables that have lab_controller_id FKs. I'm not sure if it's even a good idea to remove lab controllers. Job history will be incorrect, and it may break various parts of the code. I'd suggest that we just disable it. I'll close this as WONTFIX, unless someone comes up with a compelling reason for making this work. (In reply to comment #2) > > I'm not sure if it's even a good idea to remove lab controllers. Job history > will be incorrect, and it may break various parts of the code. I'd suggest that > we just disable it. > > I'll close this as WONTFIX, unless someone comes up with a compelling reason > for making this work. First, you just closed/wontfix-ed a bug about a server error generated when clicking an existing UI feature. I would expect *AT LEAST* that the Remove link would be taken out of the UI if it wasn't being fixed. Second, how long do you expect Beaker to be around? If we assume we'll be rewriting or replacing this thing again in a year then I'm fine with this course. Otherwise stop and think about what the lab controller list might look like in five years after labs have opened, closed, moved, merged, split, etc. Right now the BNE lab controller still shows up in the selector list for all systems. Anyone can assign their systems to this "disabled" controller. What will the scheduler do if it finds a suitable candidate system on a disabled controller? Does the scheduler reject distro updates from disabled controllers? Agree 100% with Matt here. I looked for all the places we reference LabController: GuestRecipe - location points to lab controller, but its done via a query and has logic for zero results System - Can be assigned to a lab controller but can also be Null Distro - Already handles distros going away from lab controllers. - Removing a lab controller will require us to remove all distro mappings for that distro RecipeSet - Has lab controller reference so that multi-host recipes will be scheduled against same lab. - Again, can be Null. Those are all the places where I see we reference lab controller. (In reply to comment #3) > (In reply to comment #2) > > > > I'm not sure if it's even a good idea to remove lab controllers. Job history > > will be incorrect, and it may break various parts of the code. I'd suggest that > > we just disable it. > > > > I'll close this as WONTFIX, unless someone comes up with a compelling reason > > for making this work. > > First, you just closed/wontfix-ed a bug about a server error generated when > clicking an existing UI feature. I would expect *AT LEAST* that the Remove > link would be taken out of the UI if it wasn't being fixed. Why would I create a bug for a removal of a feature that we haven't yet confirmed that there is no compelling reason to remove? > > Second, how long do you expect Beaker to be around? If we assume we'll be > rewriting or replacing this thing again in a year then I'm fine with this > course. Otherwise stop and think about what the lab controller list might look > like in five years after labs have opened, closed, moved, merged, split, etc. > Right now the BNE lab controller still shows up in the selector list for all > systems. You incorrectly assume those systems will be going away once their lab controller goes away. We have a policy of not deleting those that have job histories. So if we had a million systems (of which had at least one job run on them) on the BNE lab controller, not a single one would disappear once we remove the LC regardless of how the removal of LCs are handled. > Anyone can assign their systems to this "disabled" controller. Anyone can assign their system to a functioning lab on the other side of the world anyway and equally stop their system from working. Either way, you'd have to have rocks in your head. > What > will the scheduler do if it finds a suitable candidate system on a disabled > controller? It doesn't find suitable candidate systems on a disabled controller. > Does the scheduler reject distro updates from disabled > controllers? Not sure. (In reply to comment #4) > Agree 100% with Matt here. > > I looked for all the places we reference LabController: > > GuestRecipe > - location points to lab controller, but its done via a query and has logic > for zero results > > System > - Can be assigned to a lab controller but can also be Null > > Distro > - Already handles distros going away from lab controllers. > - Removing a lab controller will require us to remove all distro mappings for > that distro > > RecipeSet > - Has lab controller reference so that multi-host recipes will be scheduled > against same lab. > - Again, can be Null. > > > Those are all the places where I see we reference lab controller. Right, it's not that hard to implement. I was just thinking about the fact that we will never be able to include historical job data (of those jobs that ran against a deleted LC) in reports where we are doing a cross reference against an LC. I'm sure in the scheme of things this would be inconsequential anyway with the BNE LC (I don't think it had all that many jobs run against it's systems, but as mbrodeur said what happens in 5 years time with other lab controllers).In fact I'm not sure if management care about this kind of data or not. They probably don't, I don't know. Though if they even think that they perhaps might at one point in the future, then we can't guarantee that they will have this information. (In reply to comment #6) > > Right, it's not that hard to implement. > > I was just thinking about the fact that we will never be able to include > historical job data (of those jobs that ran against a deleted LC) in reports > where we are doing a cross reference against an LC. I'm sure in the scheme of > things this would be inconsequential anyway with the BNE LC (I don't think it > had all that many jobs run against it's systems, but as mbrodeur said what > happens in 5 years time with other lab controllers).In fact I'm not sure if > management care about this kind of data or not. They probably don't, I don't > know. You have a point about reporting against lab controllers. rousseau, Would we ever need to run reports against a lab controller which has been removed. > > Though if they even think that they perhaps might at one point in the future, > then we can't guarantee that they will have this information. It depends if we have any historical data live somewhere else or if it needs to be available on the LC for requery. Ideally we would have the data up until the time of the LC removal so the actual removal would not affect reporting. We need a longer term solution to the historical data problem ... As we don't yet have any resolution to this issue at large it seems. For the time being I'll remove the 'Remove' button so no one is tempted to hit it and give an ISE. Ed, Unfortunately it doesn't work like that at the moment. Our database is quite normalised and we only store lab controller names in one place. So once it's gone, it's like it never existed. Perhaps one option is to introduce some redundancy in tables where we store historical data (i.e storing actual names instead of ids). Of course this approach is littered with a few obvious problems. Perhaps we could just have a 'deleted' field, like we do for jobs. Where they disappear, but are still in the DB. Still show the lab controllers on the admin menu. If systems still attached, warn, and then remove their lab controllers. |