Earlier  
Posted Nick Remark
#openstack-cyborg - 2026-09-01
14:30:52 jgilaber +1
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 sean-k-mooney i guess a minor admin thing
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: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 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:07 sean-k-mooney but i think its value is for rolling upgrdes
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 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
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 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 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 rlandy #endmeeting
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

Earlier   Later