| opendevreview | Raghavendra Tilay proposed openstack/cinder master: HPE 3par: Fix issue seen during retype/migrate https://review.opendev.org/c/openstack/cinder/+/887559 | 07:48 |
|---|---|---|
| *** geguileo is now known as Guest10299 | 08:36 | |
| *** chuanm6 is now known as chuanm | 10:26 | |
| *** chuanm0 is now known as chuanm | 11:18 | |
| *** chuanm9 is now known as chuanm | 11:36 | |
| opendevreview | Walt proposed openstack/cinder master: Add action_track facility https://review.opendev.org/c/openstack/cinder/+/879895 | 14:05 |
| hemna- | not that I'm aware of. I created it for my fork of cinder in our deployment in SAP's cloud. | 14:11 |
| hemna- | It's really nice to have in a running deployment to be able to search the logs by action_track and volume id | 14:11 |
| hemna- | makes it easy to see what actions are being taken on a volume | 14:12 |
| hemna- | at least at a somewhat high level | 14:12 |
| hemna- | someone could write a different 'backend' for the facility as well and shove entries in a db table, or put it in a rabbitmq queue if they wanted. | 14:21 |
| simondodsley | hemna-: this action track looks pretty useful. Is it something that should be adopted by vendor drivers after your patch merges, or will your patch be enough? | 14:24 |
| jbernard | hemna-: also, can you describe your workflow for using this? very curious | 15:14 |
| tkajinam | May ask someone from the core to review https://review.opendev.org/c/openstack/cinder/+/894237 and https://review.opendev.org/c/openstack/os-brick/+/900913 . these are needed so that we can get rid of os-win right after 2024.1 and I want to make sure these are not abandoned | 15:34 |
| hemna- | well, I didn't think putting those action_track entries in drivers is a good thing. The purpose of it is to track/log at a high level actions being take on resources (volumes/snaps/backups) to see the lifecycle of the resources | 15:40 |
| hemna- | if drivers start using it, then it's just another flood of logs. dunno | 15:41 |
| hemna- | so my workflow with it is this | 15:41 |
| hemna- | some volume ends up having a problem of some sort, like being stuck in attaching/deleting, etc. | 15:41 |
| hemna- | I get the volume uuid, then go to our opensearch where all of our logs go, then search for "cinder.action_track" and "<volume uuid>" | 15:42 |
| hemna- | that lets me easily find the actions being taken on that volume in the time period I am looking for | 15:43 |
| hemna- | to understand what was happening to that volume at that time. It also tends to lead me to the failure to leave that volume stuck in the state | 15:43 |
| hemna- | it just provides the context of what was happening to that volume during that time, when it got stuck | 15:44 |
| hemna- | and theoretically you can track actions and collect stats about what actions are happening on resources | 15:45 |
| hemna- | I think it would be too much to add the action track decorators to the drivers. | 15:46 |
| hemna- | need a balance of just enough action track entries | 15:46 |
| hemna- | or you might as well just be looking at debug logging. | 15:46 |
| hemna- | the entries look like '2023-12-14 15:47:56,026 10 INFO cinder.action_track [req-8c864d4d-3193-46f1-b2a2-8882b3b988fe greq-d1bdcaa6-68c5-02aa-b069-7ad1a8d000f4 600d96a94437dab2f002e6504c2bd7c5452e9d23caf89d0b6c1aecf9fb9b1d39 d940aae3f8084f15a9b67de5b3b39720 - - -] [a0fd566d-a91b-4422-9ddb-3eb69992eddd] ACTION:'volume_attach' MSG:'attachment_update | 15:49 |
| hemna- | completed_successfully' FILE:/var/lib/openstack/lib/python3.8/site-packages/cinder/volume/manager.py:5177:attachment_update RSC:Volume(_name_id=None.......' | 15:49 |
| hemna- | tells you exactly the 'action' being taken on a volume, where in the cinder code that's happening and the resource (volume object and it's details) | 15:50 |
| hemna- | it's really handy when you tail the logs with lnav and can do a filter on 'cinder.action_track'. All you then see is the actions on the volumes and filter out all the debug log noise | 15:52 |
| opendevreview | Merged openstack/cinder master: RBD: Flattening of child volumes during deletion https://review.opendev.org/c/openstack/cinder/+/835384 | 16:16 |
| opendevreview | Eric Harney proposed openstack/cinder master: mypy: Cleanup "noqa: H301" comments https://review.opendev.org/c/openstack/cinder/+/901053 | 16:29 |
| opendevreview | Walt proposed openstack/cinder master: Add action_track facility https://review.opendev.org/c/openstack/cinder/+/879895 | 16:43 |
| drencrom | Hi, I got some errors regarding missing/wrong ssh keys on the openstack-tox-py311 tests here: https://review.opendev.org/c/openstack/cinder/+/868485 | 19:01 |
| drencrom | Has there been any changes with the CI infra? | 19:01 |
| rosmaita | drencrom: i think you just got unlucky: https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-py311&project=openstack%2Fcinder&skip=0 | 19:54 |
| drencrom | Thanks rosmaita, this cursed patch refuses to merge :) | 19:57 |
| rosmaita | :D | 19:58 |
| happystacker | Hell team, There is also an ask by one of our partner to include Unisphere v10 (feature) support to their PowerVC orchestration engine which is based on Yoga. If backport isn't possible, what can we do to proceed? | 20:12 |
| rosmaita | happystacker: there are no more releases from yoga, but the branch is in Unmaintained status, so patches can be merged into it once it's been tagged and moved to unmaintained/yoga (the openstack-unmaintained-core team has +2W powers) | 20:25 |
| happystacker | But it seams that backporting a feature is not acceptable. | 20:26 |
| happystacker | so what's the process I need to put in place to have this patch merged into yoga? | 20:26 |
| rosmaita | sorry, i missed the "feature" part | 20:27 |
| rosmaita | i think you may be out of luck, then, as far as upstream goes ... is Unisphere support currently in any upstream branches? | 20:29 |
| happystacker | it's supported starting from 2023.1 antelope | 20:30 |
| rosmaita | i guess it depends on the downstream rules for whatever openstack distro your customer is using, then | 20:33 |
| happystacker | IBM told me PowerVC 2.1 uses yoga | 20:33 |
| happystacker | and they have some asks from customer who wants to use Unisphere 10 which is not currently supported with their release | 20:34 |
| happystacker | PowerVC is based on the community edition | 20:35 |
| rosmaita | right, but yoga is no longer a Maintained branch, so I guess PowerVC must maintain its own? | 20:36 |
| happystacker | Let me ask them. | 20:37 |
| rosmaita | yeah, find out what they expect and what their plans to maintain yoga are | 20:37 |
| happystacker | So no patches nor features allowed to backport to yoga because it's unmaintained ? | 20:40 |
| happystacker | because we have some requests to backport patches (fixes) to Wallaby for OSP 17 onwards integration | 20:42 |
| happystacker | It says on https://releases.openstack.org/ that Yoga is still Maintained, is it outdated? | 20:45 |
| rosmaita | happystacker: yes, yoga is transitioning to Unmaintained: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/ZYAZG43BLJJVXCYZVPYQX5733BYDVVNL/ | 20:52 |
| rosmaita | i think this was the final yoga cinder release: https://review.opendev.org/c/openstack/releases/+/901813 | 20:53 |
| happystacker | ok so backporting anything earlier than Zed is therefore impossible? | 20:54 |
| rosmaita | to be in a release, yes | 20:54 |
| rosmaita | but there will be "unmaintained" branches for collaboration | 20:55 |
| happystacker | but Wallaby is also in unmaitained | 20:55 |
| rosmaita | https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branches.html | 20:55 |
| happystacker | so backporting to it is also not possible | 20:55 |
| happystacker | I'm still learning this release lifecycle | 20:56 |
| rosmaita | i understand | 20:56 |
| rosmaita | basically, downstream distributors will support versions of openstack that we no longer support upstream | 20:57 |
| happystacker | wow, such a headache | 20:57 |
| rosmaita | right, so whether/how to get a fix into a downstream distro will depend on that distro's rules | 20:58 |
| happystacker | RH for example which have OSP 17 based on wallaby | 20:58 |
| happystacker | which is unmaintained | 20:58 |
| rosmaita | for example, Red Hat requires that the fix/backport must be available upstream | 20:58 |
| happystacker | if it's unmaintained, we can't backport | 20:59 |
| rosmaita | well, RH just says it must be upstream, not necessarily in an unreleaseable branch | 20:59 |
| happystacker | ok so it means that just needs to be upsteam? if it's present in antelope, can it be included into OSP 17 still? | 21:00 |
| happystacker | I'm confused, might be in relation with the time in my TZ, getting late here | 21:01 |
| rosmaita | yes, the RH policy is that it should be backported as far as is allowed upstream. So a feature into antelope won't be backportable upstream (because it's a feature). But if you want to get the feature into OSP 17, you need to file a ticket with RH to work out the details | 21:02 |
| rosmaita | same thing would apply to other openstack distros, you have to work with the distributor to get the code into their distribution | 21:03 |
| rosmaita | happystacker: get some sleep and we can talk more tomorrow | 21:04 |
| happystacker | rosmalta: Ok it'll help me to understand all of that. Thank you Brian | 21:13 |
| *** geguileo is now known as Guest10368 | 21:16 | |
| opendevreview | Ghanshyam proposed openstack/cinder-tempest-plugin master: Update stable jobs on master gate https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/885669 | 23:33 |
| opendevreview | Ghanshyam proposed openstack/cinder-tempest-plugin master: Moving API microversion fixture in resource_setup https://review.opendev.org/c/openstack/cinder-tempest-plugin/+/895972 | 23:33 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!