Bug 1274128 - RFE: provide "unlike" operator
RFE: provide "unlike" operator
Product: Beaker
Classification: Community
Component: scheduler (Show other bugs)
All Linux
low Severity high (vote)
: ---
: ---
Assigned To: beaker-dev-list
Depends On: 610745 741496
  Show dependency treegraph
Reported: 2015-10-21 23:20 EDT by Wayne Sun
Modified: 2015-10-27 18:15 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 610745
Last Closed: 2015-10-27 18:15:00 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)
Comment 1 Dan Callaghan 2015-10-23 01:26:48 EDT
We already have <not> which negates anything inside of it, so you can write:

<not><system><model op="like" value="%x3250%"/></system></not>

Can you use that?
Comment 2 Wayne Sun 2015-10-23 02:57:21 EDT
Don't know that, and as I tested, it works:
# bkr list-systems --xml-filter='<not><system><model op="like" value="%x3250%"/></system></not>' |grep x3250

So is it supported in bkr.client yet? As 'like' only got in recently in bug 1010355.
Comment 3 Dan Callaghan 2015-10-25 20:35:38 EDT
bkr client has allowed you to pass any XML to --hostrequire for a long time, so you can use it already:

    --hostrequire '<not><system><model op="like" value="%x3250%"/></system></not>'

What you are talking about for bug 1010355 is the shortcut syntax which translates

    --hostrequire 'a like b'

into <a op="like" value="b"/>.

I'm not sure what shortcut syntax we could invent for <not/>, maybe a ! prefix or something, but I don't see much point in continuing to invent more and more extra bits of syntax for the --hostrequire option when we already have an entire filtering language in XML already.
Comment 4 Dan Callaghan 2015-10-25 20:37:02 EDT
BTW the <model/> filter is already inaccessible from the --hostrequire shortcut syntax since it needs to be wrapped in <system/>. I think at this level of complexity you're better off just passing the XML as is rather than having an extra layer of translation.
Comment 5 Wayne Sun 2015-10-27 02:18:38 EDT
I originally thought the translation is the only way to get the 'like' or syntax <not/> into the job xml in our CI, turns out we could passing XML directly like you said. I put the xml with <and/>, <not/> into hostrequire list in the JSON file for CI and it also works.

 "hostrequire": [
                        "<and><system><name op='like' value='%ibm%'/></system></and>",
                        "<not><system><model op='like' value='%x3250%'/></system></not>",
                        "<not><system><model op='like' value='%x3850%'/></system></not>"

So I think this bug is resolved and could be closed now, thx.
Comment 6 Dan Callaghan 2015-10-27 18:15:00 EDT
Yes if you have a complicated <hostRequires/> filter the best option is to build it as XML and pass that straight through, then you can make use of the full filtering language.

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