- openstack-discuss - lists.openstack.org

[ptl][election][horizon] PTL candidacy for 2024.2
by Tatiana Ovchinnikova 26 Feb '24

26 Feb '24

Hi all, I would like to announce my candidacy for PTL of the Horizon project for the 2024.2 (Dalmatian) cycle. During the Caracal cycle we did a great job on integration tests improvement, feature implementation, bug fixing, and have completed migration from Django 3.2 to Django 4.2. For the Dalmatian cycle, I would like to focus on the following: * Continue working with feature gap, * Switch from current integration tests to new pytest-based selenium tests, * Switch to OpenSDK * Triage more bugs * Involve more contributors into the community. Thank you for your consideration. Tatiana Ovchinnikova (tmazur)

1 0

[ptl][election][neutron] PTL candidacy for 2024.2
by Brian Haley 26 Feb '24

26 Feb '24

Hello Openstack Community, I am writing to submit my candidacy for the Neutron PTL position during the 2024.2 cycle, continuing in my role from the 2024.1 cycle. A lot of my priorities as PTL are the same as the 2024.1 cycle: * Always make sure the stable branches are consumable downstream. With the introduction of unmaintained branches, the community has extended the lifecycle in a new direction. As a member of the downstream community that relies on these branches, I will continue to dedicate part of my time to reviewing backports and keeping them maintained. * Continue pursuing CI stability. * Keep working on ongoing specs. We did a good job of getting some of the larger specs done this cycle, but there are still a few in our review pipeline. I would set a goal to get these completed next cycle if they fail to make 2024.1: ** Active-active L3 Gateway with Multihoming (LP #2002687) ** Multiple back-end support for L3 routers in ML2/OVN (LP #2020823) * Reduce the bug backlog. Over the past cycle we were able to keep our bug backlog constant through the continued great work of a lot of contributors. Having a reduction, either through verification or bug fixes, would be one of my goals. * Making sure we are good stewards of gate resources. * Always welcome new contributors. Thanks for your support. -Brian Haley (haleyb, haleyb.dev(a)gmail.com)

1 0

[tc] Next Technical Committee meeting Feb 27
by Jay Faulkner 26 Feb '24

26 Feb '24

Hi all, The next TC meeting will be February 27 at 1800 UTC in #openstack-tc on OFTC. The proposed agenda is below. Agenda - Roll call - Follow up on tracked action items - Gate health check - Implementation of Unmaintained branch statuses - Testing runtime for 2024.2 release (gmann) - https://review.opendev.org/c/openstack/governance/+/908862 - Murano inactivity and Caracal release - Should https://review.opendev.org/c/openstack/governance/+/908859/ be landed with/without the release removal change? - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

[kolla][octavia][ovs] networking issue with dhcp-agent namespace
by Satish Patel 26 Feb '24

26 Feb '24

Folks, All my deployment is running on OVN and things are working great with octavia and its special lb-mgmt-net working. Recently I am deploying a new cloud using the OVS network plugin and found dhcp-agent namespace not pinging because I have a similar IP address configured on the host interface. My LBaaS nic /etc/netplan/00-network.yml ... ... # OS1_LBAAS bond0.15: id: 15 link: bond0 dhcp4: false dhcp6: false mtu: 1500 addresses: [ 192.168.32.201/24 ] Controller node interface # ifconfig bond0.15 bond0.15: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.32.201 netmask 255.255.255.0 broadcast 192.168.32.255 inet6 fe80::b489:8ff:fe61:2298 prefixlen 64 scopeid 0x20<link> ether b6:89:08:61:22:98 txqueuelen 1000 (Ethernet) RX packets 1074073 bytes 54067608 (54.0 MB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1594 bytes 78172 (78.1 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 octavia DHCP agent namespace (lb-mgmt-net) # ip netns exec qdhcp-1008bdd3-372a-44af-8fd3-00fb99b8e489 ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 13: tape6186f5a-40: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:c7:bf:2d brd ff:ff:ff:ff:ff:ff inet 192.168.32.10/24 brd 192.168.32.255 scope global tape6186f5a-40 valid_lft forever preferred_lft forever inet 169.254.169.254/32 brd 169.254.169.254 scope global tape6186f5a-40 valid_lft forever preferred_lft forever My global.yml ################### # Octavia options ################### enable_octavia: "yes" octavia_network_interface: "bond0.15" octavia_amp_flavor: name: "amphora" is_public: no vcpus: 2 ram: 2048 disk: 5 octavia_amp_network: name: lb-mgmt-net provider_network_type: vlan provider_segmentation_id: 15 provider_physical_network: physnet1 external: false shared: false subnet: name: lb-mgmt-subnet cidr: "192.168.32.0/24" allocation_pool_start: "192.168.32.10" allocation_pool_end: "192.168.32.100" no_gateway_ip: yes enable_dhcp: yes When I ping from namespace to controller machine LBaaS interface I am not able to ping # ip netns exec qdhcp-1008bdd3-372a-44af-8fd3-00fb99b8e489 ping 192.168.32.201 PING 192.168.32.201 (192.168.32.201) 56(84) bytes of data. ^C --- 192.168.32.201 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2039ms Seems like standard linux arp/kernel issue. How does it work? In OVN there is no namespace so everything works fine but in OVS because of namespace it doesn't work.

1 0

[ptl][election][manila] PTL candidacy for 2024.2
by Carlos Silva 26 Feb '24

26 Feb '24

Hello, I would like to announce my candidacy for the role of Manila PTL during the 2024.2 cycle. I have been serving as PTL to this amazing community for 4 cycles, and I would like to continue serving as PTL. With the brilliant work of the Zorillas, we managed to make great progress on several community wide efforts, and deliver good quality features and fixes that will for sure enhance the usability and stability of the features. For the next cycle, I would like to focus on: * Working with the contributors to harden the security of our code base by ensuring we have proper testing on CI, and working on security related tech debt such as the rootwrap migration to privsep. * Engaging contributors to assist in the completion of the integration of Manila with OpenStack SDK and Barbican. * Working on the stability of our CI jobs and getting more test scenarios implemented in all Manila repositories. * Continue increasing the number of active reviewers through mentoring and creating more community engagement opportunities, such as: promoting hackatons, bug squashes and collaborative review sessions. Thank you for your consideration! Carlos da Silva IRC: carloss

1 0

[ptl][election][tacker] Yasufumi Ogawa candidancy for Tacker PTL
by Yasufumi Ogawa 26 Feb '24

26 Feb '24

Hi, I'd like to nominate myself for Tacker PTL for 2024.2 cycle. I've contributed to Tacker as a PTL since victoria release. In caracal cycle, we've improved Tacker for the 5G usecases including radio-access network and core network. We also contributed to O-RAN SC to provide Tacker as Service Management and Orchestration (SMO) which is a key feature of resource management in O-RAN architecture as a collaboration activity of OpenStack and O-RAN SC. In the next cycle, we'll continue to improve Tacker for container management required for vRAN usecases in addition to the features developed in caracal, such as advanced monitoring for large amount of vRAN apps, the latest container networking for performance or descriptor for container. Regards, Yasufumi (yasufum)

1 0

Re: [TC][openapi] Request for new projects under the OpenStack hat
by gtema 26 Feb '24

26 Feb '24

Reposting Sean's response with my answers > > > > > what i really dont wnat to see is going forward an api change to nova > > > woudl > > > also requrie the oepnapi schema be updated by submiting a patch to a > > > speratre repo. > > > so im fine with haveing schemas in the nova repo but im not ok with > > > having a https://opendev.org/openstack/openstack-openapi/ repo > > > > Please do not mix jsonschemas in services and the resulting OpenAPI spec > > file. > if we crate an openapi spec file i woudl like to use that for api validation > in the serveircies and i would like to ensure that the two never get out of > sync which is why i want to have the OpenAPI spec file be part of the > project. From your comments further down in the message I see where you are heading. From all the tooling and docs around OpenAPI you can see there are 2 different use cases of OpenAPI spec: 1. generation of the spec from current sources giving you freedom to use whichever underlying technology you want (Stephen's nova-spec change is also explicitly going this way) 2. using spec in the sources in the runtime a) query parameters + body validation b) request routing Those are actually very contradicting with each other. We need to align what exactly we are talking about and what is the scope of the change Your direction feels like (2.) about having devs to write a standalone spec and letting service consume it to implement the API in runtime (2b). This requires that either all services switch to single framework or we implement OpenStack-flavoured OpenAPI support into all of the currently used frameworks (or of course we again stuck with services doing absolutely different things) My proposal (1.) is to have spec generated supporting current zoo of frameworks used by services for request routing without devs needing to deal with OpenAPI directly. That requires us to ensure current jsonschemas and docstrings in the code are complete. Currently I see a tendency in other opensource projects that the bigger projects tend to go for 1. (with Kubernetes and GitHub being examples here) while smaller ones tend to choose 2. This can be explained by the additional complexity you get with maintaining manually the spec for huge services (my current compute OpenAPI spec is 46511 lines of code). Last, but not least, is the evolution of the OpenAPI standard itself forcing you to rewrite the spec time to time. This approach does not let you to consume openapi to route requests while it still allows you to have a test suite that would validate your service behaves like the spec describes. If we are on that level of discussion I really would like to see TC to get more actively into the discussion and we all agree and commit on a single way. > > > Anyway, I was thinking about such approach also. Issue, but not really > > critical for me, is that having schemas in various repos will make it > > harder for the user to actually grep them, unless we build a single page > > with links to all specs. > > > > In addition to that with the spec generated by a different tool we are > > going to have some workflow issue: schema is an artifact of a build and > > need to be hosted somewhere permanently. > > yep we can host it in the project docs sight. > besided the rendered api_ref. > we can also commit it to the git repo is if we want to. > i feel like not maing it the output of a build process also has advantages. > > > You would be having problem in having an API > > > > affecting change which during merge generates spec and this spec being > > submitted into the repo as well. > > i was not proposing having any generations of the schema and instead > modfiying them by hand when we are modifying the api to ensure the two > correalate and capture the intent of the api change. Ok, but this is exactly what I am proposing - generate spec from source code of services My analysis of the source code of services showed that there are much more things and bugs exposed then devs know/expect/want. Maintaining OpenAPI per hand is something people have problem with and is very error-prone with respect to OpenStack API nuances. > > Forcing devs to manually invoke the generator and include the spec into > > the > > change is definitely a very strong no-go for me, this will be a disaster. > > Pushing rendered specs to some artifacts server is necessary. > > well having external schema files is also a stong no-go form me but im > trying not to draw red lines and find a way forward. > > there are three thing i want to prevent. > i never want to have an external schema definition result in a client > rejecting a api call that should have been valid for a given cloud. > i don't want to maintain two diffent vallidation schmea for the apis (one in > the proeject and a second external) finally i dont want to have to do a > seperate release of a lib just to udpate the schema to be able to merge a > new api microversion or the reverses to require an update an external repo > after every api microversion. > > if we have the openapi sechma defs in nova we should not need to update the > openstack sdk when we have an api uidate and woudl only need to update > openstack client to use that new api. Agreed, as said - I am ok with not keeping the rendered spec part of different repository and wasn't under any means proposing to have a "lib" like repo with releases and so on. 3rd party "doc" repo can be used to link specs of different services together. One more time clarifying since I still feel we are not in sync about one technical aspect: jsonschemas of request bodies are and must be in the service repository, service router is exposing list of supported routes/methods with corresponding body jsonschemas. OpenAPI spec combines information about those exposed routes with their corresponding bodies and descriptions and applies standard on how to document microversions and actions (your router just shows that there is /"servers/{server_id}/action" url while you need to further define all the different actions and microversions). > > > In any case what is required is to have a sphinx-extension that allows us > > to generate docs for the schema and this repo is primarily is exactly > > about that (I have no issue renaming it to better indicate that fact). > > Just as a matter of temporary demonstration it also hosts the rendered > > specs. > > > > > > # My "ideal" workflow would look like that: > > > > - service developer creates change like above that changes the API > > so in my expected workflow the openapi spec file would be a file in the repo > that is updated and review as part of the normal review process > > > - Zuul job generates OpenAPI spec for the service respecting the change > > and > > publishes it together with job artifacts (just like docs right now) > > > > - Once a change is merged the OpenAPI spec artifact is published as a > > deliverable (just like doc job publishes built docs). Maybe the api-ref > > job > > can be modified to publish openapi spec and rendered HTML together > > i also think we should have a job to publish the spec file too but im not > sure we need to have any generation step outside of what we already do for > the api ref. > > - [from here absolutely speculatively] > > > > - another job kicks in and automatically proposes changes to projects that > > consume this OpenAPI spec (like a change toward the SDK is automatically > > opened that applies corresponding change) > > this gets a little dicey in terms of licensing as we currently have a policy > in openstack that all patches must be authored by a human who has signed > the icla with the exception of the depency bump patches so we would have to > make sure that any such patches dont fall foul of the guidance that > maintainer should not merge patches form AI bots > > in general any generated code not submitted by a human is problematic form a > copyright point of view and icla point of veiw which is partly why i woudl > prefer the spec update to be in the orginal patch to the project not > autogenerated via a job. This is not AI generated code. It is similar to a tooling that RM is using to open bunch changes to the projects (only difference is who triggers it: a human or Zuul as a result of another job). Here it is about rendering pre-defined templates with new values and automatically proposing that as a change. We control both the templates and the values. I really do not understand a point of discussion like in example when a job completely under your control is doing periodic check of new available dependencies versions following your update strategy and proposing an update once all tests are green. But I definitely do not want to move the discussion into the different aspect. It is not about that. Anyway, I hope we can address this aspect by adapting our policies where required or stop being productive in a fear of laws. > > > - dependent project developers review this automatic change and > > merge/modify it as necessary > > > > > > === openstack-rs > > > > https://gtema.github.io/openstack/ > > > > > > > > This is a Rust monorepo project with few items: > > > > - SDK for OpenStack out of the rendered OpenAPI specs > > > > - experimental CLI following very different approach compared to the > > > > python- openstackclient. It is compiled into single binary (what helps > > > > those not willing to pull whole python with all deps and the insanity > > > > we > > > > experience lately or those who build docker containers with only OSC > > > > inside to bypass the mentioned hell) and purely auto-generated from > > > > the > > > > specs > > > > - [future] openstack-tui (similar to k9s for Kubernetes) > > > > > > i was actully playing with rust and pyo3 to try and generate rust data > > > types form the jsonscheam defintion of novas oslo versioend objects > > > https://github.com/SeanMooney/nova-oxide thats mainly to paly with rust > > > and > > > rust<>python interaction in partarlary. > > > > > > i was toying with the idea of writing a deamon that coudl comuncitate > > > with > > > nova comonets over the rpc bus effectivly a rust implemetiaon of a > > > nova-comptue agent as way to learn rust. basically nova-comput ewould > > > need > > > effectivly a rewrite to remove our use of eventlet anyway so i was > > > toying > > > with the idea of if we are rewriting should we rewtien in something > > > other > > > then python. > > > > > > have you considerd using something like pyo3 to provide python binding > > > around a rust inmpelmation of the sdk to support both lanageues form a > > > singel codeabse. https://pyo3.rs/v0.20.3/ > > > > Yes, it is clearly possible and I am poking with idea of integrating > > generated code into the openstacksdk (at least in some parts like auth > > caching). > > > > I really think of having a new openstacksdk2 that is either also generated > > from specs or is under the hood uses the rust sdk. > > Changing the current OpenStackSDK would require huge breaking changes, so > > this is not in the scope right now. > > i think if we were to add rust to the supproted langugaes for openstack > projects then creating an openstack-sdk-rs project would make sense however > rust is not an appvoed lanague for use in offial project go, javascript adn > python are so for this to proceed in the openstack namespace you would need > to formally request rust be added via > https://github.com/openstack/governance/blob/master/reference/new-language-r > equirements.rst > > and we woudl have to defien a new rust pti likely targeting the rust stable > release. https://github.com/openstack/governance/tree/master/reference/pti Ouch, I completely missed when "Go" was added into that list. Right, and thus mentioning it here. At least now I see you are also thinking about usage of Rust so at least there are now 2 person and this can be triggered. If Rust is not accepted then my project will not be official OpenStack delivery. The real question is who wins in that case. > > > > > Here it is all really oriented only on the user facing tooling. I am > > > > very > > > > convinced in this project and will continue working on it independent > > > > on > > > > the outcome. > > > > > > > > Any objections/ideas/comments? > > > > > > yep see above. > > > mainly just decopleing the schmas form the implemation. > > > if we keep the schemas with the python code in the same repo or in a lib > > > repo provded by each service project > > > > I do not get the point here really. > > > > - Ideally every service is extending schemas already present in the code > > and adds descriptions directly into the code. > > - from schemas in the service code we are able to generate OpenAPI > > - the OpenAPI spec can be used to render API docs of the service > > - OpenAPI specs can be used to generate client facing (and possibly also > > server bindings) tooling (sdk, cli, etc) > > ideally from my point of view we would remove our custom jsonschma > validation and replace it with an openapi spec file then use something like > https://github.com/python-openapi/openapi-core?utm_source=openapi-tools&utm_ > medium=website&utm_campaign=data-validators to load the spec file form disk > and use it ot add server side request validation. i would really like the > nova api to be able to do somethign like > ``` > from openapi_core import OpenAPI > openapi = OpenAPI.from_file_path('openapi.json') > try: > result = openapi.unmarshal_request(request) > handel_request(request) > excpet ValidationError: > ... > ``` > > the current json schema validation we have is a custom intergartion and im > inclidned to consider it techdebt and look to replace it with a better > supported, purpose built project that we dont have to maintain long term... This is an absolutely valid approach (as also pointed above), but in my eyes would require much more work and will not work for all OpenStack services together without enforcement of OpenStack flavor of OpenAPI (same as you can't enforce all services to use same wsgi framework as of now or to follow the accepted API guidelines). As described my proposal is about going a less offensive way and allows us have "auto-documented" code what could be standardized across services while keeping the service's freedom to use whichever technology it prefers. That does not block any service from implementing service relying on the spec, but puts certain requirements on the form of the spec. N.B: what really surprises and disappoints me is general lack of any reaction in this thread as well as all previous attempts. Is it so unimportant ? Is it a fear of debate or just understanding that this is going to be another heated discussion without consensus? Is it something too big to do and thus let us not even start doing that? Is the community "died out" short in front of elections? Is it just waiting for somebody to break the "governance/policies/rules" wall we built between each other? Or am I the only one who thinks to see this issue? But that would not match to what others tell me directly. P.S. I re-read my message and assume some may feel offended by the tone. It is not really intended, so sorry in advance. Regards, Artem

1 0

[ptl][election] Sylvain Bauza candidacy for Nova 2024.1 PTL
by Sylvain Bauza 26 Feb '24

26 Feb '24

Hey Nova and Placement folks, Yet again, I'm asking you to put myself on the Nova and Placement PTL seat. I was awaiting to see whether new candidates were wanting to nominate themselves for that seat but now I am convinced to run again for this position. Challenges are still upfront. Our gate is still coughing every single day and despite the excellent work that a very few awesome people did on stabilizing and which helped improving the situation (kudos to those who will recognize themselves), we are still urging to fix the most common patterns. As a PTL, I'll ensure to keep the energy to chase those issues and identify them so as a team we can fight them. Another concern to me is the reviewing pace. While we're continuing to deliver solid reviews on feature proposals and patches, our team isn't much evolving and we need fresh blood. In order to be able to deliver things, we need to ensure that we properly recognize those who dedicate a portion of their daytime to help others by providing valuable feedback (and I stress on the fact that this feedback *has to* be valuable in order to by worthy). As a PTL, I'll continue to encourage people to express their thoughts and concerns into Gerrit comments so that we are able to count on. The last challenge I have to mention here is the release cadence. Now that we are about to deliver 2023.1 (Caracal), it will be time to remember ourselves that 2023.2 (Dalmatian) will be a skippable release for operators and we need to carefully think about the implications of such things. I'll just finish on a last word. While I really appreciated acting as a PTL for the last 5 cycles, I'd be more than happy if someone would like to step up next cycle (E) so I could offer some mentoring for a smooth transition. Thanks, -Sylvain

1 0

[all][elections][ptl][tc] Combined PTL/TC 2024.2 cycle Election Nominations Kickoff
by Ian Y. Choi 26 Feb '24

26 Feb '24

Nominations for OpenStack PTLs (Project Team Leads) and TC (Technical Committee) positions (5 positions) are now open and will remain open until Feb 28, 2024 23:45 UTC. All nominations must be submitted as a text file to the openstack/election repository as explained at https://governance.openstack.org/election/#how-to-submit-a-candidacy Please make sure to follow the candidacy file naming convention: candidates/2024.2/<Project_Name or "TC">/<email_address> (for example, "candidates/2024.2/TC/stacker(a)example.org"). The name of the file should match an email address for your current OpenStack Foundation Individual Membership. Take this opportunity to ensure that your OSF member profile contains current information: https://www.openstack.org/profile/ Any OpenStack Foundation Individual Member can propose their candidacy for an available, directly-elected seat on the Technical Committee. In order to be an eligible candidate for PTL you must be an OpenStack Foundation Individual Member. PTL candidates must also have contributed to the corresponding team during the 2023.2 to 2024.1 timeframe, Mar 03, 2023 00:00 UTC - Feb 28, 2024 00:00 UTC. Your Gerrit account must also have a verified email address matching the one used in your candidacy filename. Both PTL and TC elections will be held from Mar 06, 2024 23:45 UTC through to Mar 20, 2024 23:45 UTC. The electorate for the TC election are the OpenStack Foundation Individual Members who have a code contribution to one of the official teams over the 2023.2 to 2024.1 timeframe, Mar 03, 2023 00:00 UTC - Feb 28, 2024 00:00 UTC, as well as any Extra ACs who are acknowledged by the TC. The electorate for a PTL election are the OpenStack Foundation Individual Members who have a code contribution over the 2023.2 to 2024.1 timeframe, Mar 03, 2023 00:00 UTC - Feb 28, 2024 00:00 UTC, in a deliverable repository maintained by the team which the PTL would lead, as well as the Extra ACs who are acknowledged by the TC for that specific team. The list of project teams can be found at https://governance.openstack.org/tc/reference/projects/ and their individual team pages include lists of corresponding Extra ACs. Please find below the timeline: PTL + TC nomination starts @ Feb 14, 2024 23:45 UTC PTL + TC nomination ends @ Feb 28, 2024 23:45 UTC TC campaigning starts @ Feb 28, 2024 23:45 UTC TC campaigning ends @ Mar 06, 2024 23:45 UTC PTL + TC elections start @ Mar 06, 2024 23:45 UTC PTL + TC elections end @ Mar 20, 2024 23:45 UTC Shortly after election officials approve candidates, they will be listed on the https://governance.openstack.org/election/ page. The electorate is requested to confirm their email addresses in Gerrit prior to 2024-02-28 00:00:00+00:00, so that the emailed ballots are sent to the correct email address. This email address should match one which was provided in your foundation member profile as well. Gerrit account information and OSF member profiles can be updated at https://review.openstack.org/#/settings/contact and https://www.openstack.org/profile/ accordingly. If you have any questions please be sure to either ask them on the mailing list or to the elections officials: https://governance.openstack.org/election/#election-officials

1 1

Re: [TC][openapi] Request for new projects under the OpenStack hat
by gtema 26 Feb '24

26 Feb '24

Ups, used wrong button and replied to Sean only, reposting my replies here directly > Hey, > > thanks for feedback > > see comments inline > > > > === openstack-openapi > > > https://gtema.github.io/openstack-openapi/ > > > > > > This repo hosts rendered specs and provides analogue to the os-api-ref > > > Sphinx extension that renders them into the html (what you see under the > > > link is a mix of Swagger and os-api-ref style). I was not really > > > effectively working on that rendering lately, the repo right now is more > > > or less a storage for the specs themselves with a first sketch of sphinx > > > extension of rendering and basic OpenAPI flavoring doc. > > > > i personally object to haveing a offical repo to define the open api > > scemas > > for offial projcet that scope of the relevent repo. > > > > i.e. i do not agree that we shoudl have openapi defintion for the nova api > > ourside of the nova repo or a repo that is not a deliverable of the > > comptue > > project. > > > > stephen has proposed a spec to add openapi support to nova directly > > https://review.opendev.org/c/openstack/nova-specs/+/909448 > > I was referring to that spec in the header of my email > > > what i really dont wnat to see is going forward an api change to nova > > woudl > > also requrie the oepnapi schema be updated by submiting a patch to a > > speratre repo. > > so im fine with haveing schemas in the nova repo but im not ok with having > > a https://opendev.org/openstack/openstack-openapi/ repo > > Please do not mix jsonschemas in services and the resulting OpenAPI spec > file. > > Anyway, I was thinking about such approach also. Issue, but not really > critical for me, is that having schemas in various repos will make it harder > for the user to actually grep them, unless we build a single page with > links to all specs. > > In addition to that with the spec generated by a different tool we are going > to have some workflow issue: schema is an artifact of a build and need to > be hosted somewhere permanently. You would be having problem in having an > API affecting change which during merge generates spec and this spec being > submitted into the repo as well. > Forcing devs to manually invoke the generator and include the spec into the > change is definitely a very strong no-go for me, this will be a disaster. > Pushing rendered specs to some artifacts server is necessary. > > In any case what is required is to have a sphinx-extension that allows us to > generate docs for the schema and this repo is primarily is exactly about > that (I have no issue renaming it to better indicate that fact). Just as a > matter of temporary demonstration it also hosts the rendered specs. > > > # My "ideal" workflow would look like that: > > - service developer creates change like above that changes the API > > - Zuul job generates OpenAPI spec for the service respecting the change and > publishes it together with job artifacts (just like docs right now) > > - Once a change is merged the OpenAPI spec artifact is published as a > deliverable (just like doc job publishes built docs). Maybe the api-ref job > can be modified to publish openapi spec and rendered HTML together > > - [from here absolutely speculatively] > > - another job kicks in and automatically proposes changes to projects that > consume this OpenAPI spec (like a change toward the SDK is automatically > opened that applies corresponding change) > > - dependent project developers review this automatic change and merge/modify > it as necessary > > > > === openstack-rs > > > https://gtema.github.io/openstack/ > > > > > > This is a Rust monorepo project with few items: > > > - SDK for OpenStack out of the rendered OpenAPI specs > > > - experimental CLI following very different approach compared to the > > > > > > python- openstackclient. It is compiled into single binary (what helps > > > those not willing to pull whole python with all deps and the insanity we > > > experience lately or those who build docker containers with only OSC > > > inside to bypass the mentioned hell) and purely auto-generated from the > > > specs > > > > > > - [future] openstack-tui (similar to k9s for Kubernetes) > > > > i was actully playing with rust and pyo3 to try and generate rust data > > types form the jsonscheam defintion of novas oslo versioend objects > > https://github.com/SeanMooney/nova-oxide thats mainly to paly with rust > > and > > rust<>python interaction in partarlary. > > > > i was toying with the idea of writing a deamon that coudl comuncitate with > > nova comonets over the rpc bus effectivly a rust implemetiaon of a > > nova-comptue agent as way to learn rust. basically nova-comput ewould need > > effectivly a rewrite to remove our use of eventlet anyway so i was toying > > with the idea of if we are rewriting should we rewtien in something other > > then python. > > > > have you considerd using something like pyo3 to provide python binding > > around a rust inmpelmation of the sdk to support both lanageues form a > > singel codeabse. https://pyo3.rs/v0.20.3/ > > Yes, it is clearly possible and I am poking with idea of integrating > generated code into the openstacksdk (at least in some parts like auth > caching). > > I really think of having a new openstacksdk2 that is either also generated > from specs or is under the hood uses the rust sdk. > Changing the current OpenStackSDK would require huge breaking changes, so > this is not in the scope right now. > > > > Here it is all really oriented only on the user facing tooling. I am > > > very > > > convinced in this project and will continue working on it independent on > > > the outcome. > > > > > > Any objections/ideas/comments? > > > > yep see above. > > mainly just decopleing the schmas form the implemation. > > if we keep the schemas with the python code in the same repo or in a lib > > repo provded by each service project > > I do not get the point here really. > > - Ideally every service is extending schemas already present in the code and > adds descriptions directly into the code. > - from schemas in the service code we are able to generate OpenAPI > - the OpenAPI spec can be used to render API docs of the service > - OpenAPI specs can be used to generate client facing (and possibly also > server bindings) tooling (sdk, cli, etc)

1 0