From 6073238e3a39282ebac81959764a1142f31ce32e Mon Sep 17 00:00:00 2001 From: Gerrit User 15334 <15334@4a232e18-c5a9-48ee-94c0-e04e7cca6543> Date: Wed, 27 Mar 2024 17:13:52 +0000 Subject: [PATCH] Update patch set 2 Patch Set 2: (6 comments) Patch-set: 2 Attention: {"person_ident":"Gerrit User 11604 \u003c11604@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_15334\u003e replied on the change"} Attention: {"person_ident":"Gerrit User 15334 \u003c15334@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"REMOVE","reason":"\u003cGERRIT_ACCOUNT_15334\u003e replied on the change"} --- 506e904394ef20ad7729a38c9366aa5406d68568 | 120 +++++++++++++++++++++++ 1 file changed, 120 insertions(+) diff --git a/506e904394ef20ad7729a38c9366aa5406d68568 b/506e904394ef20ad7729a38c9366aa5406d68568 index 411d42d67..cb9cf7800 100644 --- a/506e904394ef20ad7729a38c9366aa5406d68568 +++ b/506e904394ef20ad7729a38c9366aa5406d68568 @@ -75,6 +75,30 @@ "revId": "506e904394ef20ad7729a38c9366aa5406d68568", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": false, + "key": { + "uuid": "4da5e131_7f9b8b81", + "filename": "specs/2024.2/approved/openapi.rst", + "patchSetId": 2 + }, + "lineNbr": 38, + "author": { + "id": 15334 + }, + "writtenOn": "2024-03-27T17:13:52Z", + "side": 1, + "message": "I make sure to always place them at the bottom of the section they are used in, so this is rarely if ever an issue for me.", + "parentUuid": "9cb87aa8_9a137937", + "range": { + "startLine": 38, + "startChar": 19, + "endLine": 38, + "endChar": 49 + }, + "revId": "506e904394ef20ad7729a38c9366aa5406d68568", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": { @@ -92,6 +116,24 @@ "revId": "506e904394ef20ad7729a38c9366aa5406d68568", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": false, + "key": { + "uuid": "5bd1d0e0_b13f2477", + "filename": "specs/2024.2/approved/openapi.rst", + "patchSetId": 2 + }, + "lineNbr": 62, + "author": { + "id": 15334 + }, + "writtenOn": "2024-03-27T17:13:52Z", + "side": 1, + "message": "I didn\u0027t mean replacing jsonschema. I meant replacing webob or routes (the latter of which is no longer actively maintained, and the former of which is barely maintained from the looks of things)", + "parentUuid": "f5006b74_e1d0bc78", + "revId": "506e904394ef20ad7729a38c9366aa5406d68568", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": { @@ -145,6 +187,24 @@ "revId": "506e904394ef20ad7729a38c9366aa5406d68568", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": false, + "key": { + "uuid": "4ed2b6d8_35edf5b6", + "filename": "specs/2024.2/approved/openapi.rst", + "patchSetId": 2 + }, + "lineNbr": 79, + "author": { + "id": 15334 + }, + "writtenOn": "2024-03-27T17:13:52Z", + "side": 1, + "message": "\u003e starting with those is fine but we will need to review them again when adding them to the nova repo for correctness.\n\nFYI API sample tests do this for us. At least for APIs that have not been removed.\n\n\u003e i agree that doing this for remvoed api like nova network is not somethign we should do. deprecated apis woudl be a low priority but dependign on the continued usage there may be some value so as long a we have not moved the api but just deprecated some usage of the api i.e. the force parmaters for live migration we still proably would want validatidtion for the deprecated microverions.\n\nWe\u0027ll actually need to do this if we want to use the schema for our api-ref docs.\n\n\u003e that would be a lower priorty for me then covering the actully supproted parts.\n\u003e so i would conder validateion fo deprectated functionality in older microversion to be a strech goal.\n\nAgreed.", + "parentUuid": "b7f7acf1_c21a6237", + "revId": "506e904394ef20ad7729a38c9366aa5406d68568", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": { @@ -162,6 +222,24 @@ "revId": "506e904394ef20ad7729a38c9366aa5406d68568", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": false, + "key": { + "uuid": "7aca9bbd_6983dd7a", + "filename": "specs/2024.2/approved/openapi.rst", + "patchSetId": 2 + }, + "lineNbr": 112, + "author": { + "id": 15334 + }, + "writtenOn": "2024-03-27T17:13:52Z", + "side": 1, + "message": "\u003e right but unless we make this an entirly optional feature we muct make nova not have a hard dep on those tools\n\u003e \n\u003e while i am warming to rust its not an approved langruge for use in openstack.\n\u003e so the tools artem ahs created cannot be a hard depency of nova.\n\u003e https://github.com/openstack/governance/blob/master/resolutions/20150901-programming-languages.rst\n\u003e \n\u003e we are allowed to use other languages for experiment but we cant create new openstack porjects in rust today.\n\u003e\n\u003e from my perspective there is a gray line around using somethign like py03\n\u003e pyoxide will allow rust tool to be exposed via python bindings so the usage of the libs would still be via python and there is no diffent to having a c module or rust module in my view.\n\u003e \n\u003e when talking about clis there may be addtional leyway there that would not be affored if its driectly called by nova runtime code.\n\u003e the main implication for that is we will need to keep the api ref/schema generation\n\u003e opetional like the pdf generations.\n\u003e \n\u003e i.e. if you have the tool installsed then a given tox target can be used to generate the openapi schemea docs \n\u003e \n\u003e if you dont then the normal docs target shoudl be able to generate the api ref as normal.\n\u003e \n\u003e if we want to change that we need to add rust just like go was added \n\u003e \n\u003e https://github.com/openstack/governance/blob/master/resolutions/20170329-golang-use-case.rst\n\u003e \n\u003e i think we should do that for what its worth.\n\ngtema\u0027s tools are all Python based. It has to be, since we\u0027re introspecting stuff. The Rust code he has is to generate a CLI which is not directly related to this effort.", + "parentUuid": "871724db_705d5722", + "revId": "506e904394ef20ad7729a38c9366aa5406d68568", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": { @@ -196,6 +274,24 @@ "revId": "506e904394ef20ad7729a38c9366aa5406d68568", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": false, + "key": { + "uuid": "161c9bc3_3e88d07e", + "filename": "specs/2024.2/approved/openapi.rst", + "patchSetId": 2 + }, + "lineNbr": 139, + "author": { + "id": 15334 + }, + "writtenOn": "2024-03-27T17:13:52Z", + "side": 1, + "message": "While I don\u0027t think it should be used in production, I *do* think DevStack should allow setting it and it should be set in integration jobs (or set by default in DevStack) once things are stabilised. Our schemas are our docs so failures should be be somewhat painful IMO.", + "parentUuid": "0e57b3aa_aa76b158", + "revId": "506e904394ef20ad7729a38c9366aa5406d68568", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": { @@ -242,6 +338,30 @@ }, "revId": "506e904394ef20ad7729a38c9366aa5406d68568", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, + { + "unresolved": false, + "key": { + "uuid": "c11bf33f_ab80a0d9", + "filename": "specs/2024.2/approved/openapi.rst", + "patchSetId": 2 + }, + "lineNbr": 181, + "author": { + "id": 15334 + }, + "writtenOn": "2024-03-27T17:13:52Z", + "side": 1, + "message": "Acknowledged", + "parentUuid": "11e2a5da_7e5deae4", + "range": { + "startLine": 181, + "startChar": 56, + "endLine": 181, + "endChar": 66 + }, + "revId": "506e904394ef20ad7729a38c9366aa5406d68568", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" } ] } \ No newline at end of file