Bug 1112131
Summary: | [RFE] accept and preserve arbitrary XML elements in job XML | ||
---|---|---|---|
Product: | [Retired] Beaker | Reporter: | David Kutálek <dkutalek> |
Component: | general | Assignee: | Roman Joost <rjoost> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
Severity: | unspecified | Docs Contact: | |
Priority: | medium | ||
Version: | 0.16 | CC: | aigao, beaker-dev-list, dcallagh, dowang, ebaak, emrakova, rjoost |
Target Milestone: | 22.0 | Keywords: | FutureFeature, Patch |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-01-14 05:34:14 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: | |||
Bug Depends On: | |||
Bug Blocks: | 1193570 |
Description
David Kutálek
2014-06-23 08:14:54 UTC
The general concept gets a +1 from me - similar to the recent addition of the "remote_post" metavar, I think some kind of arbitrary "job annotations" capability (whether using XML namespaces or as a dedicated element) would allow Beaker to become a more powerful and flexible platform without significantly increasing the complexity of the core Beaker application. Independently this need popped up once more in bug 1269105, so it seems there is a real demand for this feature. Please can you take a look once more and raise prio? I would be more happy with more general solution (like namespaces?) so that that users can easily store a little bit more data in their other use cases, if necessary, without having to add yet another tags via another bugs here. *** Bug 1269105 has been marked as a duplicate of this bug. *** Dear David, my apology for the late reply. We're considering expanding the whiteboard field to accept multiple lines (as proposed by https://beaker-project.org/dev/proposals/job-page-improvements.html see Whiteboards). Would that go in the direction you were proposing with this bug? (In reply to Roman Joost from comment #5) > Dear David, > > my apology for the late reply. We're considering expanding the whiteboard > field to accept multiple lines (as proposed by > https://beaker-project.org/dev/proposals/job-page-improvements.html see > Whiteboards). Would that go in the direction you were proposing with this > bug? Hi Roman, basic direction yes. Not sure this is the best specific route to go. As noted in linked document, whiteboard is now used more or less as title in gui and that fits me very well. Info we would like to store is IMHO not to be consumed by user always, or regularly. I would like to get to it via GUI, but not be visible by default, as it is not needed in all times and could be quite big text. So what about having new 'title' element together with existing 'whiteboard' element? I think the whiteboard should remain as the human-friendly description. In the new job page we will accept Markdown and show multiple lines, which will be useful I think. But for this RFE, which is really about embedding machine-readable metadata in the job, I think the original idea of having Beaker preserve arbitrary elements in other XML namespaces is the nicest one. For context, here was the original thread where we discussed it: http://post-office.corp.redhat.com/archives/beaker-dev-list/2014-June/msg00051.html To keep the implementation simple, I would start out by only allowing the arbitrary elements at the top level inside <job/>, like this: <job> <options xmlns="http://example.com/mytool">--distro RHEL6</options> <whiteboard>Running tests on RHEL6</whiteboard> ... where the <options/> could be any arbitrary XML element including any other arbitrary XML content, which Beaker will store as is. So it would be possible to store actual structured data in there too if desired. Then when viewing job results XML the same elements will be included. It wouldn't preserve the *order* or *position* of the elements within <job/> because Beaker doesn't store things that way. They would always be dumped out at the top in arbitrary order. Should Beaker also preserve the extra XML elements when cloning a job? (In reply to Dan Callaghan from comment #8) > To keep the implementation simple, I would start out by only allowing the > arbitrary elements at the top level inside <job/>, like this: > > <job> > <options xmlns="http://example.com/mytool">--distro RHEL6</options> > <whiteboard>Running tests on RHEL6</whiteboard> > ... > > where the <options/> could be any arbitrary XML element including any other > arbitrary XML content, which Beaker will store as is. So it would be > possible to store actual structured data in there too if desired. > > Then when viewing job results XML the same elements will be included. It > wouldn't preserve the *order* or *position* of the elements within <job/> > because Beaker doesn't store things that way. They would always be dumped > out at the top in arbitrary order. > > Should Beaker also preserve the extra XML elements when cloning a job? I would be very happy with this proposed solution. We should definitely preserve these extra XML elements when cloning a job. It is kind of a property of the job and it should be user's responsibility to clean/modify these elements when needed. Do you have some ETA when we can expect implementation? Dear David, I'm picking this one up and work on it. A conservative ETA is early next year. I'll keep you posted on the progress on this bug. Thank you Roman, I am happy you will be working on that. First patch set is up: https://gerrit.beaker-project.org/#/c/4478/1 This bug fix is included in beaker-server-22.0-0.git.110.c41cd4c which is currently available for testing here: https://beaker-devel.app.eng.bos.redhat.com/ Beaker 22.0 has been released. |