Bug 987157
Summary: | [RFE] please add ability to rename systems using csv | ||
---|---|---|---|
Product: | [Retired] Beaker | Reporter: | andrew <alemay> |
Component: | web UI | Assignee: | Amit Saha <asaha> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 0.13 | CC: | aigao, asaha, dcallagh, ebaak, jburke, jingwang, llim, qwan, rmancy |
Target Milestone: | 0.15.3 | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-02-03 04:52:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
andrew
2013-07-22 20:32:58 UTC
Currently there's no way to rename systems because the CSV importer uses the 'fqdn' column to identify the system to update. If we changed it to include the Beaker database id and use that to identify each row instead, we could do it. I guess that could work, since the desired workflow is export -> modify -> import. So if we include the ID column in the export, then this will transparently do the right thing on the import. However, are there other use cases that could break? What if you *want* to add new systems rather than modifying existing ones? I like the idea in principle, I just think we need to be cautious about not breaking existing workflows for people that are used to the current behaviour. A more user friendly approach might be to have *two* FQDN columns in the export. One for "FQDN" and another for "Updated FQDN" (which would obviously be the same on export) I think an id column would work. The import code would need to handle the case where the id column is absent or empty and treat that row the way it does presently (look up by fqdn). Having an "fqdn" and a "new_fqdn" column would work too although I think it makes things more cluttered and more confusing, particularly in the case were you don't actually want to rename anything (the majority of the time, I think). An alternative would be a new bkr command for modifying systems, which also allows renaming: bkr system-modify --fqdn=newfqdn oldfqdn which could be scripted using bash. But for bulk modification of FQDNs that's actually less convenient than just sed'ing a CSV file. OK, I'm persuaded that an optional id column is the way to go. If it's missing entirely or empty for a particular row, then we do the lookup by FQDN (adding systems as needed). If it is present, then we interpret that as referring to a previously exported system, and update the FQDN in the database to match the one in the CSV. We'll also aim to get this into a 0.15 maintenance release, rather than waiting for 0.16. The documentation describing this feature is tracked in a separate patch: http://gerrit.beaker-project.org/#/c/2649/ Suggested verification steps: 1. Export system (for modification) data 2. Modify the FQDN of one or more systems 3. Import the data 4. Check if the FQDNs have been updated. This change is included in the Beaker 0.15.3 maintenance release: http://beaker-project.org/docs/whats-new/release-0.15.html#beaker-0-15-3 |