jsonschema 3 incompatibility with OpenStack #604
Comments
jayvdb
changed the title
|
Hi. I'm not sure what there is to do here really in this library -- especially if as you say, you tried it on some OpenStack thing and the tests all pass. Sounds like OpenStack just needs some PRs bumping the dep in all the repos. The only real breaking change that tends to cause a major version bump and not the normal deprecation cycle is changing what draft is used by default -- as new drafts are released, there's a new Specifically, 3.x uses draft 7, the latest draft released at the time (and at the minute, until draft 8 is released, at which point So as long as schemas are specified properly (i.e. they contain |
|
Would it be possible to have an envvar to override which draft is used by default? |
|
What problem would we be trying to solve, is it something related to this? It's trivial to specify either what draft you want to run, either in the schema, which everyone should be doing anyhow, or in any of the places you do validation, so yeah, what would be the goal of an envvar? |
|
While it might be easy to update the code, or the data, OpenStack has lots of separate sub-projects using jsonschema, with different development teams, different roadmaps, etc. One project has done the changes needed, but most have not. It likely is not a high priority for them. If it involves altering the data interchange between their services, I can see why they would be reluctant to tackle the change - it is easier to pin If there is an envvar which can be set by the top level apps in OpenStack, even if they have no direct dependency on jsonschema, they might be able to get QA passing with jsonschema v3 sooner. |
|
So, I should have asked this to start but are you part of OpenStack and this is a reason why it hasn't moved over to 3 (the lack of a way to change the default externally) or are you speculating about reasons there on their behalf? (And in case I didn't say it initially, thanks certainly for flagging this, but yeah I want to understand what issues they're running into) |
|
I am not part of OpenStack. I have a few very minor contribs to their devops repos from years ago. However OpenStack is used by several orgs I've been involved with, so I have a bit of familiarity as a user. I am only guessing about future work they might do, or ways to help them, but their support of already released versions, which have a I am also not part of openSUSE; again just a user, and I am trying to get poetry into their core package collection, but that breaks because the openSUSE maintainers have so far chosen to keep jsonschema pinned to I have most of the OpenStack jsonschema related projects in a build project at https://build.opensuse.org/project/show/home:jayvdb:jsonschema , and a bunch of other 'prominent' packages using jsonschema , so I could play around with those builds in order to try to get them all green. Let me know if there are any other important packages which I should add to that build project to test compatibility with jsonschema v3. I could patch the jsonschema in that build project to change the defaults, or add an envvar, to see if that is enough to get them green. |
|
Will respond in more detail (apologies, I've been at a conference), but thanks that's helpful -- I'm not keen to add an envvar (the short version being simply that it's global mutable state that things can fight over), but I do respect thinking about the problem so not saying there's nothing to do. Thanks a ton for filing the OpenSUSE issue at very least, will track that -- and if you do see anything fail a build definitely keen to see why, like I said, very little's changed. Will keep this open and yeah probably come back to add a bit more detail after I review the two links you posted, so thanks again! |
|
@handrews @Relequestual I still haven't even done so myself but might be interesting to you to flip through the failing builds too, since like I mentioned, they likely represent the fraction of downstream schema users that do not declare $schema in their usages. |
|
@jayvdb I haven't gotten a ton more time to flip through these, but it seems likely we need a baseline run that uses 2.6.0 to compare to, because out of the first 5 project failures, most of them look pretty suspicious (unlikely to be jsonschema related)... Not sure if that's something you've looked at already. |
|
Ya, good idea. I'll set it up |
|
Hi -- not sure if there is any movement here -- going to close this since I still don't know that there's anything to do here within |
|
No worries. Sorry I havent had time to get back to this. |
78c888273 Merge pull request #618 from json-schema-org/gregsdennis/contentschema-should-fail-content 5cbc53bc0 Merge pull request #613 from santhosh-tekuri/rjp-multidigit bb000ce98 Merge pull request #620 from json-schema-org/ether/remove-unused-remotes c4c490f1d Merge pull request #617 from json-schema-org/gregsdennis/dynamicAnchor-inside-propertyDependencies 0189831a9 remove schemas that are never referenced cf1b94249 Merge pull request #610 from handrews/rm-remotes d6490e817 move anchors into defs 2f9d117c0 Merge pull request #616 from json-schema-org/gregsdennis/propertyDependencies-and-unevaluated 4e5649cd0 move tests to draft-next a41f2f6c4 added type:object to contentSchema schemas 2f50e7864 add tests for $dynamicAnchor in multiple branches of propertyDependencies 4794a1991 add tests for unevaluatedProperties seeing inside propertyDependencies 27cc299f3 Add RJP test 'multi-digit integer prefix' 716b95d94 Merge pull request #612 from santhosh-tekuri/rjp-positive 320c804d1 Add RJP test 'explicit positive prefix' c8f210c39 Merge pull request #611 from santhosh-tekuri/time-alpha 3faeb222d add time test 'contains letters' 642441f2d Merge pull request #603 from santhosh-tekuri/uuid-nonstr 94d5043c7 add non-string uri tests 0c81374a2 Remove unneeded remotes 97a3e2156 Merge pull request #608 from json-schema-org/json-everything-uses-the-test-suite bdaf7e8be added json-everything to 'who uses' section of readme; removed manatee.json (deprecated) f00ec1008 Merge pull request #606 from santhosh-tekuri/duration-nounit 134480721 Merge pull request #607 from santhosh-tekuri/time-offsetprefix dd4538eee Test time format 'offset not starting with plus or minus' 80fe2db15 test duration format 'element without unit' 38ea15116 Merge pull request #604 from santhosh-tekuri/time-offset 613ec170e second fraction, not offset ee4bd4eb6 Add time format test with second fraction, no offset 86c2517cd Merge pull request #605 from santhosh-tekuri/rjp-empty cfe80006a Add relative-json-pointer test with empty string 31796b3b8 add non-string uuid tests git-subtree-dir: json git-subtree-split: 78c8882732bcdc2dad81cd7ce1e3f9bca6fb7a9d
I am surprised there isnt an issue about this.
A lot of the openstack projects have had pins like
jsonschema<3.0.0,>=2.6.0for quite a long time.This is blocking some distros (at least openSUSE) from moving to jsonschema 3.x , as they dont want to break openstack. Which means they can also have all the new software which is now using features only in jsonschema 3.x .
I see there is movement on this front on the openstack side, e.g.
e.g. https://opendev.org/openstack/zaqar/commit/1af2c91e41b147f95082b68e3ec9df95ab458fb2
I have also run the
glance_storeunit tests with jsonschema 3.latest and those tests pass.But the supported version of openstack (codenamed Stein) still has the pin, and will likely continue to be supported for a while.
Is there anything that can be done on the jsonschema side to reduce the incompatibilities with jsonschema 2.6. Perhaps a shim can be created, or an upgrading guide (if one doesnt exist).
The text was updated successfully, but these errors were encountered: