User Details
- User Since
- Oct 7 2020, 6:01 PM (181 w, 1 d)
- Availability
- Available
- IRC Nick
- blancadesal
- LDAP User
- Slavina Stefanova
- MediaWiki User
- SStefanova (WMF) [ Global Accounts ]
Wed, Mar 20
Tue, Mar 19
Mon, Mar 18
Using the new Build Service is now the recommended method for deploying Django applications on Toolforge. I think a better idea would be to:
Fri, Mar 15
The current error message probably comes from the envvars API that envvars-cli talks to. The repo is here: https://gitlab.wikimedia.org/repos/cloud/toolforge/envvars-api
Thu, Mar 14
Do we want to expose the /healthz and /metrics endpoints in the unified spec?
Wed, Mar 13
Hmm, we do want to generate the client libraries that we will use in the consolidated CLI, though. Also, I think tools that generate documentation rely on the uniqueness of operationId to correctly link operations to descriptions, parameters, and responses.
operationIds need to be unique. At what level do we want to deal with this? Enforce a naming convention across the individual APis such as {serviceName}_{resourceName}_{operation}? Prefixing when merging the specs?
@dcaro How should we deal with the security top-level element. We are currently ignoring it. Maybe add it to the base.yaml?
Tue, Mar 12
@dcaro thanks! Another question: each openapi spec has it's own /openapi.json endpoint. We will want the gateway to expose the unified spec created by merging the files. Should we remove the individual /openapi.json endpoints from the merged spec?
@dcaro what is the base.yaml in your script?
Mon, Mar 11
@dcaro What is our plan for creating the Toolforge CLI from the autogenerated SDK? Manually? Automatically with a post-generation script?
Fri, Mar 8
OpenAPI Ggenerator and Swagger Codegen look very similar on the surface. A little digging reveals that OpenAPI Generator was forked from Swagger Codegen in 2018 by a group of the Swagger Codegen community and contributors who wanted to proceed in a slightly different direction. Their stated goals were to speed up development and acceptance of new features, improve the quality and maintainability of the code base, and make it easier for new contributors to get involved.
Thu, Mar 7
Feb 23 2024
Do reach out if you need help with anything Toolforge or Cloud VPS related. Especially the build service is still somewhat new, so we are eager to hear what worked/didn't work for you.
Feb 22 2024
Feb 21 2024
The ability to configure it using json is nice though
Nice! I was just experimenting with https://www.npmjs.com/package/openapi-merge-cli, merging just envvars and build to begin with. It generates a valid spec out-of-the-box but I'm also visually checking it.
Doing it "on the fly", so we don't have to generate a new definition any of the sub-apis changes
- Apimatic is a proprietary service so we can't use it, but they have this article about microservices API integration which I found interesting: https://www.apimatic.io/blog/2022/09/auto-merging-apis-and-microservices-specifications-to-ease-api-integration.
- https://github.com/robertmassaioli/openapi-merge is a tool for merging multiple OpenAPI 3.0 files together. The last commit was from 2 years ago though
- https://github.com/iouring-engineering/openapi-merge is a fork of the above with some added functionality
Feb 19 2024
@Albertoleoncio Your tool has been granted write access to Elasticsearch now. The credentials are available to your tool as envvars. When logged into Toolforge as your tool, you can see them by running toolforge envvars list:
Feb 16 2024
sstefanova@cloudcontrol1005:~$ sudo wmcs-openstack quota show iiab | grep ram | ram | 32768 | sstefanova@cloudcontrol1005:~$ sudo wmcs-openstack quota show iiab | grep cores | cores | 16 |
Feb 12 2024
Feb 6 2024
Feb 1 2024
would a pool of warm VMs instantiated outside the user critical path lessen this issue? Or only move it around?
We now have support for unmanaged (unpuppetized) instances, so this should no longer be necessary.
Jan 31 2024
Jan 30 2024
Jan 29 2024
Done – Both projects now have 2Gi harbor storage quota each.
@Raymond_Ndibe do you still plan to work on this during this iteration? If not, I wouldn't mind doing it.
It’s perhaps worth noting that for some reason, 317.19Mi or 317.20Mi of storage are still reported by toolforge build quota even after a successful toolforge build clean (twice now, with almost the same number). I don’t know where that’s coming from.
Jan 25 2024
Jan 24 2024
With there being support for lima in addition to vagrant now (T354406: [dev] Investigate lima-vm as an alternative to Vagrant for lima-kilo) I think this task can be closed. If anyone feels like exploring other alternatives, feel free to open it again.
As there is no clear consensus, a decision meeting will be scheduled as described here: https://www.mediawiki.org/wiki/Wikimedia_Cloud_Services_team/Decision_Making
There is now support for lima in addition to vagrant. Some things may still need improvement, e.g. for me builds run considerably slower on lima vs. vagrant, but I think this task can be closed as the basic support is there.
Jan 22 2024
Thank you @taavi
Jan 12 2024
I think we're increasingly using lima-kilo, where kind has been working fine. If I'm wrong or you feel a strong preference for minikube, please chime in. Otherwise I will close this task as resolved a week from now.
Jan 10 2024
I ran into the same error yesterday with builds-cli when trying to start a build. Upon retry a few moments later, it worked fine.