| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-cyborg - 2026-09-01 | |||
| 14:31:13 | sean-k-mooney | as a general topic im debating which fo spec, bluepirnt and rfe bug we want to use for cybrog in general | |
| 14:31:39 | sean-k-mooney | i think for small things like this i woudl prefer to have wishlist rfe bugs if its small rahter then specless bluerpints | |
| 14:31:57 | sean-k-mooney | but we can dicuss that later unless folks haven an imideate reaction/prefence | |
| 14:32:34 | melwitt | I like specless blueprints personally but am not vehement about it | |
| 14:32:57 | sean-k-mooney | neutron starts alls feature enhacment as an RFE bug and graduates to bluepritn or specs if it need more trackign or discussion | |
| 14:33:36 | gamio_ | as a newer contributor, the rfe bug flow worked well for 2161354. no spec needed and low friction | |
| 14:34:00 | sean-k-mooney | i guess for nwo we can triage things in the meeting as they come up | |
| 14:34:10 | sean-k-mooney | adn we can write down our perfered flow next cycle | |
| 14:36:04 | sean-k-mooney | ok for now i have updated https://bugs.launchpad.net/openstack-cyborg/+bug/2165432 | |
| 14:36:11 | sean-k-mooney | anythin esle we want ot discuss on that | |
| 14:36:22 | rlandy | all set on this topic, melwitt? | |
| 14:36:51 | sean-k-mooney | melwitt: is this somethign you want to adress for rc1 or 2027.1 | |
| 14:37:05 | melwitt | yes all good. I was thinking 2027.1 | |
| 14:37:13 | sean-k-mooney | i assumed the latter ya | |
| 14:37:28 | rlandy | k ... moving on ... | |
| 14:37:33 | opendevreview | Merged openstack/cyborg master: Improve installation guide index https://review.opendev.org/c/openstack/cyborg/+/1001774 | |
| 14:37:44 | sean-k-mooney | i want to add nic emualtion to the pci-sim next cycel adn we can discuss testing this with that later | |
| 14:38:02 | rlandy | #link https://bugs.launchpad.net/python-cyborgclient | |
| 14:38:07 | rlandy | looks all triaged here | |
| 14:38:28 | rlandy | so let's move on to the open discussion | |
| 14:38:37 | rlandy | #topic open discussion | |
| 14:38:48 | rlandy | anything else to bring up today? | |
| 14:39:25 | melwitt | just wanted to share that I proposed a spec for 2027.1 for adding a services table and versioning and heartbeats etc if anyone might be interested https://review.opendev.org/c/openstack/cyborg-specs/+/1001999 | |
| 14:39:25 | sean-k-mooney | i guess a minor admin thing | |
| 14:39:45 | sean-k-mooney | ah let start with your topic | |
| 14:40:00 | sean-k-mooney | ya i will hopfely look at that next week | |
| 14:40:30 | sean-k-mooney | i think my main feedback before was | |
| 14:40:49 | sean-k-mooney | if we supprot healtchecsk at all i woudl prefer to supprot the per binday helathchecks | |
| 14:41:02 | sean-k-mooney | like was propsoed for nova/manilla | |
| 14:41:45 | melwitt | not a ton to say about it but that I'm thinking of it as a first step toward being able to support rolling upgrades which I think we need for production readiness | |
| 14:41:53 | sean-k-mooney | the services api i thnk makes sesne but not sure about forced down | |
| 14:42:34 | melwitt | yes i remember :) per process healthchecks. I was thinking that would not be part of this particular spec work but would be a thing to add separately | |
| 14:42:35 | sean-k-mooney | ya so i think that is what we shoudl use it for | |
| 14:42:49 | sean-k-mooney | i dont think the service api shoudl really be a monitoring api | |
| 14:42:58 | sean-k-mooney | it can report state | |
| 14:43:07 | sean-k-mooney | but i think its value is for rolling upgrdes | |
| 14:43:07 | melwitt | same, I am personally thinking we will not have forced down but wanted to put it out there for discussion in case others have thoughts | |
| 14:43:29 | sean-k-mooney | im not actully sure we even need state/staus | |
| 14:43:36 | sean-k-mooney | i.e. if its up | |
| 14:43:53 | sean-k-mooney | we may but if we had per service healthcheck endpoint its not stricly needed | |
| 14:44:11 | melwitt | really? I was thinking it would be nice to know when/if each agent reported in | |
| 14:44:28 | sean-k-mooney | yes it can be but if you can monitor that externally | |
| 14:44:34 | sean-k-mooney | its not strictly required | |
| 14:44:45 | sean-k-mooney | so its nice to have rahter then requried | |
| 14:44:53 | melwitt | ah. yeah, I see what you mean | |
| 14:44:57 | gamio | interested, I'll take a look at 1001999 this week | |
| 14:45:15 | sean-k-mooney | im not nessialy saying we remove it | |
| 14:45:29 | sean-k-mooney | jsut not prostion it as the primary way for operator to detech that | |
| 14:45:58 | sean-k-mooney | prostion -> propose/postion | |
| 14:46:19 | melwitt | gotcha. if I had to guess I would expect cloud operators would prefer to have it available as a CLI command for example to see "up/unknown" sort of status. even if there is also healthcheck data available externally | |
| 14:46:43 | sean-k-mooney | yep so i think they are complementary | |
| 14:46:59 | sean-k-mooney | but if the service info was a bit stale or delayed that woudl not be a bug | |
| 14:47:38 | sean-k-mooney | if you need lifeness checking with low latency then the main rest api is not the scaleable solution | |
| 14:48:07 | sean-k-mooney | but if it answering has this agent checked in in the last 60s its fine | |
| 14:48:24 | melwitt | yeah | |
| 14:48:32 | sean-k-mooney | anything else on this you want to highlight? | |
| 14:48:41 | melwitt | no that was it | |
| 14:49:01 | sean-k-mooney | cool then the admin itime i had is https://blueprints.launchpad.net/openstack-cyborg | |
| 14:49:15 | sean-k-mooney | ill go thru and update the serise adn status on those on monday | |
| 14:49:36 | sean-k-mooney | we will need to reappvoe/retarget any that are not merged by firday to next cycle | |
| 14:50:17 | sean-k-mooney | that was all i had just noting we need to create the 2027.1 serise on all launchpads and update them as needed | |
| 14:50:43 | rlandy | thank you sean-k-mooney | |
| 14:50:47 | rlandy | anything else? | |
| 14:51:44 | rlandy | moving on ... | |
| 14:51:52 | rlandy | #topic: Volunteers to chair next meeting | |
| 14:52:07 | rlandy | anyone available to run the meeting next week? | |
| 14:52:52 | sean-k-mooney | unles someone else wants to i can i guess | |
| 14:53:11 | rlandy | ok - let's put you in as a place holder name | |
| 14:53:14 | rlandy | thank you | |
| 14:53:22 | rlandy | thank you folks for joining | |
| 14:53:29 | rlandy | #endmeeting | |
| 14:53:29 | opendevmeet | Meeting ended Tue Sep 1 14:53:29 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 14:53:29 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/cyborg_irc_meeting_september_1__2026/2026/cyborg_irc_meeting_september_1__2026.2026-09-01-14.03.html | |
| 14:53:29 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/cyborg_irc_meeting_september_1__2026/2026/cyborg_irc_meeting_september_1__2026.2026-09-01-14.03.txt | |
| 14:53:29 | opendevmeet | Log: https://meetings.opendev.org/meetings/cyborg_irc_meeting_september_1__2026/2026/cyborg_irc_meeting_september_1__2026.2026-09-01-14.03.log.html | |
| 19:16:59 | opendevreview | Merged openstack/cyborg master: Add agentic scaffolding and contributor docs https://review.opendev.org/c/openstack/cyborg/+/1001767 | |
| 19:17:00 | opendevreview | Merged openstack/cyborg master: Reorganize documentation landing page https://review.opendev.org/c/openstack/cyborg/+/1001779 | |
| #openstack-cyborg - 2026-09-02 | |||
| 10:43:12 | opendevreview | OpenStack Release Bot proposed openstack/python-cyborgclient master: Update master for stable/2026.2 https://review.opendev.org/c/openstack/python-cyborgclient/+/1003451 | |
| 12:07:43 | chandankumar | sean-k-mooney: Hello, Here is the nvme cleanup strategy test result: https://gist.github.com/raukadah/fdccdecb7c92fc932ac49d2fb7ccad9f | |
| 12:08:01 | chandankumar | Do let me know is there anything else I need to include in this. | |
| 12:11:38 | sean-k-mooney | so i hav enot looked at that specificly in tempet but this is actully wrtign data to the device and verifying that that data is not present as part of the test? or is it just booting the vm with the device and makign sure the cleian up didnt fail | |
| 12:12:04 | sean-k-mooney | and did you capture service log fo the calls | |
| 12:12:21 | sean-k-mooney | ah you do have the agent output | |
| 12:12:25 | chandankumar | I have captured cyborg-agent logs | |
| 12:12:41 | chandankumar | The current test is done with cirros image where we donot write data to the device | |
| 12:13:05 | chandankumar | so it is a plain vm boot with the device | |
| 12:13:16 | chandankumar | and making sure cleanup works fine | |
| 12:13:47 | sean-k-mooney | ack can you do a one of test where you echo a fixed byte strign tot he /dev/nvme... device | |
| 12:14:04 | sean-k-mooney | stop the vm an check its there on the host | |
| 12:14:11 | sean-k-mooney | and hten delete it and check it after | |
| 12:14:16 | sean-k-mooney | just to confirm it worked onces | |
| 12:14:32 | sean-k-mooney | ill review your logs later but if we can do that i think we are good | |
| 12:14:52 | sean-k-mooney | the current testign show the nvme cli arges are valid | |
| 12:15:01 | sean-k-mooney | we dont really need to test nvme cli itself | |
| 12:15:11 | sean-k-mooney | i just want to see it work once | |
| 12:15:25 | sean-k-mooney | to make sure its not siglently failing adn we are not seeign it in the logs | |
| 12:15:35 | chandankumar | sure | |
| 12:15:37 | chandankumar | Let me do that | |
| 14:05:45 | chandankumar | sean-k-mooney: I think it is working with data write https://gist.github.com/raukadah/fdccdecb7c92fc932ac49d2fb7ccad9f#6-manual-data-verification-test | |
| 14:05:57 | chandankumar | Feel free to comment to add more verification | |