| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-11-27 | |||
| 13:48:07 | sean-k-mooney | the etherpad is purly to help publisise and priories reviews | |
| 13:48:17 | sean-k-mooney | it is not require at all for our process | |
| 13:48:58 | ildikov | I interpreted the etherpad process as a lightweight project management tool that helps the core team to keep track of things that are ongoing | |
| 13:49:11 | sean-k-mooney | yep | |
| 13:49:54 | sean-k-mooney | somethime things can get "lost" in gerrit or lanchpad | |
| 13:50:02 | s3rj1k | imo, I see this as not so optimal, but ok, if that works | |
| 13:50:36 | sean-k-mooney | its manily working aroudn some limistaion in launchpads and gerrit ui | |
| 13:50:50 | sean-k-mooney | to be clear i almost exclisilvy ignor the etherpad | |
| 13:51:11 | sean-k-mooney | i do look at it form time to time but i look at gerrit much more frequently directly | |
| 13:51:34 | sean-k-mooney | i try to take a look at the ether pad once a week however but dont always fidn time too | |
| 13:52:03 | s3rj1k | could been just automated away based on data from gerrit and launchpad) | |
| 13:52:26 | sean-k-mooney | no the peopel that whated it wanted it to be human qurated | |
| 13:52:37 | sean-k-mooney | *curated | |
| 13:52:58 | sean-k-mooney | if we did an automated sync we woudl be back to the noise problem | |
| 13:55:52 | sean-k-mooney | s3rj1k: i get that process can be furstrating, especially if its not clear why or how it works | |
| 13:56:57 | s3rj1k | it just adds extra layer of bureaucracy and this will impact adoption for new community members | |
| 13:57:15 | sean-k-mooney | s3rj1k: how so. currently its not required at all | |
| 13:58:12 | s3rj1k | I have a gut feeling about this, I guess in time we will see | |
| 13:58:38 | sean-k-mooney | its actully there to allow people to engages async and to ask for reviews | |
| 13:58:45 | sean-k-mooney | so its intended to help continutors | |
| 13:59:06 | sean-k-mooney | i.e. so that they dont have to be on irc to ask for reviews | |
| 13:59:17 | sean-k-mooney | when they are not gettign feedback in gerrit | |
| 13:59:54 | sean-k-mooney | gerrit, irc and the mailing list are the 3 primary engagment points for contibutors with launch pad (bugs) for users | |
| 14:00:47 | s3rj1k | there is still RFE step that is semi-supported | |
| 14:00:50 | sean-k-mooney | s3rj1k: im not discounting your feedback im wonderign howe to improvie it (beyond updating the docs) | |
| 14:01:06 | sean-k-mooney | so nova does not use RFE bugs | |
| 14:01:11 | sean-k-mooney | that a neutron specific thing | |
| 14:01:20 | sean-k-mooney | we have experiemtned with adding it but its not part of our process | |
| 14:01:44 | s3rj1k | yea, but how to propose a draft for a feature to talk about? rfe seems perfect for this | |
| 14:01:46 | sean-k-mooney | most openstack teams dont sue RFE bugs, neutron use it because you cant realy have discussion in bluepirnts due to the ui | |
| 14:02:34 | s3rj1k | it's not like rfe is a call to action for core devs) just a place to put text and talk in comments | |
| 14:02:55 | sean-k-mooney | right but lanuchpad is not where we have those dicussions in general | |
| 14:03:13 | s3rj1k | mailing lists? | |
| 14:03:14 | sean-k-mooney | gerrit, irc or the mailing list is outside fo the ptg | |
| 14:03:41 | sean-k-mooney | so normally unless its a triival feature we would expect to have design discussion in a spec review | |
| 14:04:14 | sean-k-mooney | the actul workflow is ment to be, if you have a feature request bring it up on the mailing list or in the irc meeting | |
| 14:04:34 | sean-k-mooney | then based on the inital feedback file a spec or blueprint for it | |
| 14:05:04 | sean-k-mooney | specless blueprings are used for very small features that done require an actual spec but most feature will need a spec | |
| 15:46:16 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Simplify parameter types https://review.opendev.org/c/openstack/nova/+/936369 | |
| 15:46:17 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Ensure all APIs have a response body schema https://review.opendev.org/c/openstack/nova/+/924598 | |
| 16:30:29 | opendevreview | Serhii Ivanov proposed openstack/nova-specs master: [SPEC] `Add Distributed Locking for Host Discovery`. https://review.opendev.org/c/openstack/nova-specs/+/936389 | |
| 16:37:33 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix missing oslo.policy options https://review.opendev.org/c/openstack/nova/+/936392 | |
| 16:48:15 | opendevreview | Takashi Kajinami proposed openstack/nova master: Fix missing oslo.policy options https://review.opendev.org/c/openstack/nova/+/936392 | |
| 16:53:14 | opendevreview | Serhii Ivanov proposed openstack/nova-specs master: [SPEC] `Add Distributed Locking for Host Discovery`. https://review.opendev.org/c/openstack/nova-specs/+/936389 | |
| 17:01:19 | yosef | Hi, in case of complete data loss of openstack database for example in 1 day, is there any way to restore to db, VMs created in this one day? | |
| 17:37:34 | sean-k-mooney | yosef: not really. you could try and manually creat the records but there is no tooling to enable that | |
| 18:15:40 | opendevreview | Merged openstack/nova master: [codespell] Fixes for latest version https://review.opendev.org/c/openstack/nova/+/923738 | |
| 18:15:56 | opendevreview | Merged openstack/nova master: pre-commit: Bump versions https://review.opendev.org/c/openstack/nova/+/923739 | |
| 19:00:01 | s3rj1k | sean-k-mooney: Can you take a quick look on that Spec CR? https://review.opendev.org/c/openstack/nova-specs/+/936389 | |
| 19:00:44 | s3rj1k | I've put also some of the alternatives that you've mentioned in there | |
| 19:01:10 | sean-k-mooney | sure | |
| 19:01:17 | s3rj1k | thanks | |
| 19:01:22 | sean-k-mooney | im not convicd you primay propsol is what we shoudl do | |
| 19:01:27 | sean-k-mooney | btu we can discuss it on the spec | |
| 19:02:13 | s3rj1k | at least I hope to have this finalized in any way) best to have this solved rather than ignoring the issue | |
| 19:02:36 | s3rj1k | so any way works as long as we go forward :) | |
| 19:02:39 | sean-k-mooney | well right now you want to add a distribute lock manager and annoter usage of tooz | |
| 19:02:52 | sean-k-mooney | where as we ahve dicussed how to remove tooz form teh code base | |
| 19:03:03 | sean-k-mooney | at least twice in the last year or two | |
| 19:03:21 | s3rj1k | just like in original rfe, tooz was there yes | |
| 19:03:25 | sean-k-mooney | so we may be able to proced with this but your askign for use to reverse cources on that | |
| 19:03:58 | s3rj1k | we can replace tooz I guess | |
| 19:04:02 | sean-k-mooney | ok jsut so your aware that thsi is a pretty contiversiol approch | |
| 19:04:17 | sean-k-mooney | we generally did not want to ahve a distribute lock manager in nova at all | |
| 19:04:39 | s3rj1k | that's why I invested time in alternatives) | |
| 19:05:04 | sean-k-mooney | the main concern with tooz by the way is its overall mantance | |
| 19:05:37 | sean-k-mooney | what migh be simpler to do is some form of leader elelction | |
| 19:05:44 | sean-k-mooney | rather then a distributed lock | |
| 19:06:14 | s3rj1k | that won't cover CLI | |
| 19:06:29 | sean-k-mooney | well to be clear it does not have too | |
| 19:06:40 | sean-k-mooney | currently the sideefect does nto break anything | |
| 19:07:08 | sean-k-mooney | the db enforces consitenty so the worst case side effecti is the command exits with an error but it does not break anything | |
| 19:07:17 | s3rj1k | yea, I guess so, if periodics can be safely fixed for concurrency | |
| 19:07:18 | sean-k-mooney | so that ok on the cli | |
| 19:07:36 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Allow min/max_version arguments to response https://review.opendev.org/c/openstack/nova/+/936364 | |
| 19:07:36 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Allow min/max_version arguments to expected_errors https://review.opendev.org/c/openstack/nova/+/936363 | |
| 19:07:37 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Stop using wsgi.Controller.api_version to switch between API versions https://review.opendev.org/c/openstack/nova/+/936366 | |
| 19:07:37 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Adjust validation helpers for a single-method future https://review.opendev.org/c/openstack/nova/+/936365 | |
| 19:07:38 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Only run format checks on strings https://review.opendev.org/c/openstack/nova/+/936368 | |
| 19:07:38 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Add new, simpler api_version decorator https://review.opendev.org/c/openstack/nova/+/936367 | |
| 19:07:39 | opendevreview | Stephen Finucane proposed openstack/nova master: api: Simplify parameter types https://review.opendev.org/c/openstack/nova/+/936369 | |
| 19:07:40 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Ensure all APIs have a response body schema https://review.opendev.org/c/openstack/nova/+/924598 | |
| 19:07:43 | s3rj1k | no reason to force CLI with cronjobs | |
| 19:08:46 | sean-k-mooney | what i was orginally thinking was to use a Rendezvous hash to select the leader form the active schduler and only run the perodic form that one | |
| 19:09:31 | sean-k-mooney | that way we dont actully need an external depency (distibuted lock manager) or any addtional rpcs ectra | |
| 19:09:40 | sean-k-mooney | im just not sure if that will work with our current system | |
| 19:10:25 | sean-k-mooney | a concern with a dlm is makeing sure the lock is released if any of the pods get restarted for example | |
| 19:10:42 | s3rj1k | btw, is there a formal doc on tooz deprecation? | |
| 19:10:53 | sean-k-mooney | its not deprecated as a lib | |
| 19:11:08 | sean-k-mooney | so the only usage of it in nova is the ironic driver and we deprecated the fature that uses it in that | |
| 19:11:25 | s3rj1k | so for nova removal in this case | |
| 19:11:33 | sean-k-mooney | currently the ironic drivcer can use manual sharding or a dynmic hashring(provided by tooz) | |
| 19:12:08 | sean-k-mooney | the dynmaic hash ring is deprecated for removal which would have removed tooz as a side effect | |
| 19:15:12 | sean-k-mooney | s3rj1k: each schduler is a memebr of a service group | |
| 19:15:14 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/scheduler/manager.py#L69 | |
| 19:15:57 | sean-k-mooney | there are 2 service group drivers, the db and memcache | |
| 19:17:18 | sean-k-mooney | im wondering if we can reuse that to do leader elelction and then have only one of the member run the perodic if its currently the leader | |
| 19:19:31 | sean-k-mooney | the problem is the curernt service group api does nto really ahve a way to do that | |
| 19:20:04 | sean-k-mooney | it has a way to test if a member of a service group is up | |
| 19:20:16 | sean-k-mooney | but not a way to list the memebr and or select a leader | |