[tc][all] Follow up pain point discussion
Dear all
The pain point collection etherpad [1] seems to get good attention from teams. We plan to host a one-hour video meeting to keep the discussion going. Please fill in the doodle to select your preferred time if you can join us: https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link The discussion will be hosted in video format.
Here are some items (but not limited to) I expect we will discuss and hopefully put some actions/efforts on.
- General Pain point: RabbitMQ - General Pain point: OpenStackClient support - General project pain point discussion: How to encourage teams to work/reply on pain points.
Meanwhile, we encourage all to check the etherpad and provide your feedback. Also if teams can help to answer questions/concerns on etherpad (like Nova team does) will be greatly appreciated.
[1] https://etherpad.opendev.org/p/pain-point-elimination
*Rico Lin*
On Fri, 2021-12-03 at 17:37 +0800, Rico Lin wrote:
Dear all
The pain point collection etherpad [1] seems to get good attention from teams. We plan to host a one-hour video meeting to keep the discussion going. Please fill in the doodle to select your preferred time if you can join us: https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link The discussion will be hosted in video format.
Here are some items (but not limited to) I expect we will discuss and hopefully put some actions/efforts on.
- General Pain point: RabbitMQ
- General Pain point: OpenStackClient support
I will try to join for this discussion, but one point on this for anyone else attending: please take the time before this discussion to try out a recent version of OSC. At the moment, our focus is on switching the underlying library used in OSC compute-related commands from novaclient to SDK and we plan to do the same for cinder next. We're doing this because afaict, there aren't any significant CLI gaps left for most of the core services. My understanding of the feature parity situation is as follows:
* neutronclient ✅ full feature parity since...a long time ago - Kudos, neutron team, for your long-term investment here * novaclient ✅ full feature parity since 5.5.0 - We finally introduced a proper '--block-device' option for 'server create' in 5.5.0, which closed our remaining RFE. There have been bugfixes since but it's feature complete, if not bug free. * cinderclient ✅ (effectively) full feature parity - The only remaining gap that I'm aware of is for configurable filters and volume service clusters. There are patches open for these here and here respectively that we simply need to merge to complete this, but it's consider low-ish priority * glanceclient ⍰ not sure, as I've yet to investigate this. I suspect there are a few gaps here. * keystoneclient ⍰ not sure, as I've yet to investigate this. I suspect we're very close if not there already though.
So in summary, I don't think the OSC problem that has existed historically is still a real thing. If there are gaps that I'm not aware of, please be sure to communicate them here or on the Etherpad so we can track them and encourage people (future students, other contributors) to close them.
Stephen
- General project pain point discussion: How to encourage teams to work/reply
on pain points. Meanwhile, we encourage all to check the etherpad and provide your feedback. Also if teams can help to answer questions/concerns on etherpad (like Nova team does) will be greatly appreciated.
[1] https://etherpad.opendev.org/p/pain-point-elimination Rico Lin
On Mon, 6 Dec 2021 at 11:59, Stephen Finucane stephenfin@redhat.com wrote:
novaclient ✅ full feature parity since 5.5.0
We finally introduced a proper '--block-device' option for 'server create' in 5.5.0, which closed our remaining RFE. There have been bugfixes since but it's feature complete, if not bug free.
What about `nova host-evacuate-live` and a few other commands identified in doc/source/cli/data/nova.csv?
aggregate-cache-images,,Request images be cached. (Supported by API versions '2.81' - '2.latest') [hint: use '-- os-compute-api-version' flag to show help message for proper version] host-evacuate,,Evacuate all instances from failed host. host-evacuate-live,,Live migrate all instances off the specified host to other available hosts. host-meta,,Set or Delete metadata on all instances of a host. host-servers-migrate,,Cold migrate all instances off the specified host to other available hosts. hypervisor-servers,,List servers belonging to specific hypervisors. hypervisor-uptime,,Display the uptime of the specified hypervisor. instance-action,,Show an action. instance-action-list,,List actions on a server. instance-usage-audit-log,,List/Get server usage audits. migration-list,,Print a list of migrations. version-list,,List all API versions. volume-update,,Update volume attachment.
On Fri, 2021-12-10 at 22:02 +0100, Pierre Riteau wrote:
On Mon, 6 Dec 2021 at 11:59, Stephen Finucane stephenfin@redhat.com wrote:
novaclient ✅ full feature parity since 5.5.0
We finally introduced a proper '--block-device' option for 'server create' in 5.5.0, which closed our remaining RFE. There have been bugfixes since but it's feature complete, if not bug free.
What about `nova host-evacuate-live` and a few other commands identified in doc/source/cli/data/nova.csv?
this has deliberatlly not being ported to OSC and we never intend to add it.
we advise people to impelemtnt this them selves as it purly a client side impleantion and discurage using the exsiting host-eveacuate-live as its error handeling if some live mirations fail is undefiend.
you can do a better job yourself.
aggregate-cache-images,,Request images be cached. (Supported by API versions '2.81' - '2.latest') [hint: use '-- os-compute-api-version' flag to show help message for proper version] host-evacuate,,Evacuate all instances from failed host. host-evacuate-live,,Live migrate all instances off the specified host to other available hosts.
all the host eveacutate apis were not ported for the same reasons as host-evacuate-live. this is something the nova team nolonger wants to maintain and we deliberatly chose to not port those to osc.
host-meta,,Set or Delete metadata on all instances of a host.
again this is not something we want to maintain. its not part of the nova api and can be implented yourself in a few lines of bash.
host-servers-migrate,,Cold migrate all instances off the specified
as with the other host-evacuate command this is condiers depercated and was intentionally not ported
host to other available hosts. hypervisor-servers,,List servers belonging to specific hypervisors.
openstack server list --all-projects --host <hostname>
by the way all the host-evacuate,host-evacuate-live and host-servers-migrate commands do is call the list endpoint as show aboove to get vms on a give host and loop over them calling evacuate, live migrate or cold migrate there is no error handeling and for hsot-server-migrate i dont think it actully confirms the migration. it may but the dosc dont say one way our another. it certenly wont do the right thing in most caes if there is an error so you should not use it if you really care about the vms.
hypervisor-uptime,,Display the uptime of the specified hypervisor.
the uptime of a hyperivor is part of a deprectated api that was mainly used by xen that is technially avaiable as part of the hyperviors api now but os-host has been deprecated for years and it will eventraully be removed.
instance-action,,Show an action. instance-action-list,,List actions on a server.
the instance action are aviable via openstack server event {list,show}
instance-usage-audit-log,,List/Get server usage audits
usage is aviabel via "openstack usage {list,show}"
. migration-list,,Print a list of migrations.
migration info is aviable at
"openstack server migration {abort,confirm,force complete,list,rever,show}" and you can also confrim or revert a migrate via "openstack server migrate {conrim,revert}"
version-list,,List all API versions. volume-update,,Update volume attachment.
volume updates shoudl be done via cinder all nova proxy apis have been deprecated for 3+ year proably even longer so no clinet shoudl still be using those
the equivalent woudl openstack volume migrate i belvie. the volume-update api is really swap volume i belive
On Sun, 12 Dec 2021 at 22:08, Sean Mooney smooney@redhat.com wrote:
On Fri, 2021-12-10 at 22:02 +0100, Pierre Riteau wrote:
On Mon, 6 Dec 2021 at 11:59, Stephen Finucane stephenfin@redhat.com wrote:
novaclient ✅ full feature parity since 5.5.0
We finally introduced a proper '--block-device' option for 'server create' in 5.5.0, which closed our remaining RFE. There have been bugfixes since but it's feature complete, if not bug free.
What about `nova host-evacuate-live` and a few other commands identified in doc/source/cli/data/nova.csv?
this has deliberatlly not being ported to OSC and we never intend to add it.
we advise people to impelemtnt this them selves as it purly a client side impleantion and discurage using the exsiting host-eveacuate-live as its error handeling if some live mirations fail is undefiend.
you can do a better job yourself.
aggregate-cache-images,,Request images be cached. (Supported by API versions '2.81' - '2.latest') [hint: use '-- os-compute-api-version' flag to show help message for proper version] host-evacuate,,Evacuate all instances from failed host. host-evacuate-live,,Live migrate all instances off the specified host to other available hosts.
all the host eveacutate apis were not ported for the same reasons as host-evacuate-live. this is something the nova team nolonger wants to maintain and we deliberatly chose to not port those to osc.
host-meta,,Set or Delete metadata on all instances of a host.
again this is not something we want to maintain. its not part of the nova api and can be implented yourself in a few lines of bash.
host-servers-migrate,,Cold migrate all instances off the specified
as with the other host-evacuate command this is condiers depercated and was intentionally not ported
host to other available hosts. hypervisor-servers,,List servers belonging to specific hypervisors.
openstack server list --all-projects --host <hostname>
by the way all the host-evacuate,host-evacuate-live and host-servers-migrate commands do is call the list endpoint as show aboove to get vms on a give host and loop over them calling evacuate, live migrate or cold migrate there is no error handeling and for hsot-server-migrate i dont think it actully confirms the migration. it may but the dosc dont say one way our another. it certenly wont do the right thing in most caes if there is an error so you should not use it if you really care about the vms.
hypervisor-uptime,,Display the uptime of the specified hypervisor.
the uptime of a hyperivor is part of a deprectated api that was mainly used by xen that is technially avaiable as part of the hyperviors api now but os-host has been deprecated for years and it will eventraully be removed.
instance-action,,Show an action. instance-action-list,,List actions on a server.
the instance action are aviable via openstack server event {list,show}
instance-usage-audit-log,,List/Get server usage audits
usage is aviabel via "openstack usage {list,show}"
. migration-list,,Print a list of migrations.
migration info is aviable at
"openstack server migration {abort,confirm,force complete,list,rever,show}" and you can also confrim or revert a migrate via "openstack server migrate {conrim,revert}"
version-list,,List all API versions. volume-update,,Update volume attachment.
volume updates shoudl be done via cinder all nova proxy apis have been deprecated for 3+ year proably even longer so no clinet shoudl still be using those
the equivalent woudl openstack volume migrate i belvie. the volume-update api is really swap volume i belive
I didn't realise the host-evacuate-live command was not planned to be reimplemented. Thanks for the details.
Dear all
For pain point discussion, Let's schedule the video meeting for *Dec. 8th, 15:00 UTC time* Location: https://meet.google.com/xsx-inbw-mos
*Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
On Fri, Dec 3, 2021 at 5:37 PM Rico Lin ricolin@ricolky.com wrote:
Dear all
The pain point collection etherpad [1] seems to get good attention from teams. We plan to host a one-hour video meeting to keep the discussion going. Please fill in the doodle to select your preferred time if you can join us: https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link The discussion will be hosted in video format.
Here are some items (but not limited to) I expect we will discuss and hopefully put some actions/efforts on.
- General Pain point: RabbitMQ
- General Pain point: OpenStackClient support
- General project pain point discussion: How to encourage teams to
work/reply on pain points.
Meanwhile, we encourage all to check the etherpad and provide your feedback. Also if teams can help to answer questions/concerns on etherpad (like Nova team does) will be greatly appreciated.
[1] https://etherpad.opendev.org/p/pain-point-elimination
*Rico Lin*
Dear all
First, thank all who join us in the discussion or help on the etherpad [1]
Here are wrap-ups of our first meeting yesterday:
In the meeting, we have quick work through pain points for a couple of projects: Cinder, Ironic, Neutron, QA, Horizon. And put some action or tags(like `FIX NEEDED` or `INFO NEEDED`). As for Nova, there is already have a good quality of replies and actions, gmann will help with discussing tags with rest of Nova team. Horizon team will go through the rest item in team meeting and finish tagging after. Also, TC picks the log level topic (check out log level discussion in [2]) as one of the topics in next TC meeting. So if you're interested, please check out [1] and kindly provide your feedback.
We plan to go through with other projects in our next pain point meeting, which we expect to schedule around mid. of January. Meanwhile, if teams can help with providing replies and tags will be very helpful.
As for possible cross-project pain points: The OSC discussion went very well. The discussion includes OpenStack Client and OpenStackSDK. OSC seems to get more works done than the last time it was proposed as a community goal (back in Train cycle?), so TC has set up a topic in the next TC meeting to discuss the possibility to set this as a community goal (for z or after-z cycles).
RabbitMQ was discussed briefly but didn't have any specific suggestions or actions. So if you have any, please kindly provide your feedback in this ML or [3].
If you would like to suggest other cross-project pain points, kindly suggest in ML or [1] and help TCs to identify them.
Finally, we collect pain points and hope to get things fixed/improved, so if you're interested to help with targeting any of the items in [1], you're most welcome to reach out to project teams or at least provide your feedback in [1].
[1] https://etherpad.opendev.org/p/pain-point-elimination [2] https://etherpad.opendev.org/p/pain-point-elimination#L261 [3] https://etherpad.opendev.org/p/pain-point-elimination#L21
*Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
On Tue, Dec 7, 2021 at 4:39 PM Rico Lin ricolin@ricolky.com wrote:
Dear all
For pain point discussion, Let's schedule the video meeting for *Dec. 8th, 15:00 UTC time* Location: https://meet.google.com/xsx-inbw-mos
*Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
On Fri, Dec 3, 2021 at 5:37 PM Rico Lin ricolin@ricolky.com wrote:
Dear all
The pain point collection etherpad [1] seems to get good attention from teams. We plan to host a one-hour video meeting to keep the discussion going. Please fill in the doodle to select your preferred time if you can join us: https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link The discussion will be hosted in video format.
Here are some items (but not limited to) I expect we will discuss and hopefully put some actions/efforts on.
- General Pain point: RabbitMQ
- General Pain point: OpenStackClient support
- General project pain point discussion: How to encourage teams to
work/reply on pain points.
Meanwhile, we encourage all to check the etherpad and provide your feedback. Also if teams can help to answer questions/concerns on etherpad (like Nova team does) will be greatly appreciated.
[1] https://etherpad.opendev.org/p/pain-point-elimination
*Rico Lin*
Hi,
I missed this thread and the discussion, though I've added to the etherpad:
Glance
FIX NEEDED - Glance doesn't work well over uwsgi, it's the only service with this state (appart from Swfit). We would need Glance to fully gate using uwsgi in the CI.
FIX NEEDED - Glance upload on Ceph is painfully slow. So much that many operators simply don't use the Ceph backend.
Swift
FIX NEEDED - Swift continues to use Eventlet. Switching to uwsgi increases performances dramatically. Switching to uwsgi is possible for swift-proxy, swift-container and swift-account, but it completely fails for swift-object. Swift needs to fully switch to uwsgi in the CI, and repair the swift-proxy to swift-object protocol to follow *real* http specifictions (at some point, swift-object drifted away from respecting http protocol, which makes it impossible to run it under uwsgi).
I hope this helps, Cheers,
Thomas Goirand (zigo)
On 12/9/21 5:42 AM, Rico Lin wrote:
Dear all
First, thank all who join us in the discussion or help on the etherpad [1]
Here are wrap-ups of our first meeting yesterday:
In the meeting, we have quick work through pain points for a couple of projects: Cinder, Ironic, Neutron, QA, Horizon. And put some action or tags(like `FIX NEEDED` or `INFO NEEDED`). As for Nova, there is already have a good quality of replies and actions, gmann will help with discussing tags with rest of Nova team. Horizon team will go through the rest item in team meeting and finish tagging after. Also, TC picks the log level topic (check out log level discussion in [2]) as one of the topics in next TC meeting. So if you're interested, please check out [1] and kindly provide your feedback.
We plan to go through with other projects in our next pain point meeting, which we expect to schedule around mid. of January. Meanwhile, if teams can help with providing replies and tags will be very helpful.
As for possible cross-project pain points: The OSC discussion went very well. The discussion includes OpenStack Client and OpenStackSDK. OSC seems to get more works done than the last time it was proposed as a community goal (back in Train cycle?), so TC has set up a topic in the next TC meeting to discuss the possibility to set this as a community goal (for z or after-z cycles).
RabbitMQ was discussed briefly but didn't have any specific suggestions or actions. So if you have any, please kindly provide your feedback in this ML or [3].
If you would like to suggest other cross-project pain points, kindly suggest in ML or [1] and help TCs to identify them.
Finally, we collect pain points and hope to get things fixed/improved, so if you're interested to help with targeting any of the items in [1], you're most welcome to reach out to project teams or at least provide your feedback in [1].
[1] https://etherpad.opendev.org/p/pain-point-elimination https://etherpad.opendev.org/p/pain-point-elimination [2] https://etherpad.opendev.org/p/pain-point-elimination#L261 https://etherpad.opendev.org/p/pain-point-elimination#L261 [3] https://etherpad.opendev.org/p/pain-point-elimination#L21 https://etherpad.opendev.org/p/pain-point-elimination#L21
*Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
On Tue, Dec 7, 2021 at 4:39 PM Rico Lin <ricolin@ricolky.com mailto:ricolin@ricolky.com> wrote:
Dear all For pain point discussion, Let's schedule the video meeting for *Dec. 8th, 15:00 UTC time* Location: https://meet.google.com/xsx-inbw-mos <https://meet.google.com/xsx-inbw-mos> *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack On Fri, Dec 3, 2021 at 5:37 PM Rico Lin <ricolin@ricolky.com <mailto:ricolin@ricolky.com>> wrote: Dear all The pain point collection etherpad [1] seems to get good attention from teams. We plan to host a one-hour video meeting to keep the discussion going. Please fill in the doodle to select your preferred time if you can join us: https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link <https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link> The discussion will be hosted in video format. Here are some items (but not limited to) I expect we will discuss and hopefully put some actions/efforts on. * General Pain point: RabbitMQ * General Pain point: OpenStackClient support * General project pain point discussion: How to encourage teams to work/reply on pain points. Meanwhile, we encourage all to check the etherpad and provide your feedback. Also if teams can help to answer questions/concerns on etherpad (like Nova team does) will be greatly appreciated. [1] https://etherpad.opendev.org/p/pain-point-elimination <https://etherpad.opendev.org/p/pain-point-elimination> *Rico Lin*
---- On Thu, 09 Dec 2021 04:00:05 -0600 Thomas Goirand zigo@debian.org wrote ----
Hi,
I missed this thread and the discussion, though I've added to the etherpad:
Glance
FIX NEEDED - Glance doesn't work well over uwsgi, it's the onlyservice with this state (appart from Swfit). We would need Glance to fully gate using uwsgi in the CI.
We run glance in uwsgi mode by default since wallaby [1] (GLANCE_STANDALONE=False means uwsgi) and from this patch onwards[2], even import workflow is run in uwsgi by default in CI.
[1] https://github.com/openstack/devstack/blob/6c849e371384e468679d3d030fe494a36... [2] https://review.opendev.org/c/openstack/devstack/+/742332
-gmann
FIX NEEDED - Glance upload on Ceph is painfully slow. So much thatmany operators simply don't use the Ceph backend.
Swift
FIX NEEDED - Swift continues to use Eventlet. Switching to uwsgiincreases performances dramatically. Switching to uwsgi is possible for swift-proxy, swift-container and swift-account, but it completely fails for swift-object. Swift needs to fully switch to uwsgi in the CI, and repair the swift-proxy to swift-object protocol to follow *real* http specifictions (at some point, swift-object drifted away from respecting http protocol, which makes it impossible to run it under uwsgi).
I hope this helps, Cheers,
Thomas Goirand (zigo)
On 12/9/21 5:42 AM, Rico Lin wrote:
Dear all
First, thank all who join us in the discussion or help on the etherpad [1]
Here are wrap-ups of our first meeting yesterday:
In the meeting, we have quick work through pain points for a couple of projects: Cinder, Ironic, Neutron, QA, Horizon. And put some action or tags(like `FIX NEEDED` or `INFO NEEDED`). As for Nova, there is already have a good quality of replies and actions, gmann will help with discussing tags with rest of Nova team. Horizon team will go through the rest item in team meeting and finish tagging after. Also, TC picks the log level topic (check out log level discussion in [2]) as one of the topics in next TC meeting. So if you're interested, please check out [1] and kindly provide your feedback.
We plan to go through with other projects in our next pain point meeting, which we expect to schedule around mid. of January. Meanwhile, if teams can help with providing replies and tags will be very helpful.
As for possible cross-project pain points: The OSC discussion went very well. The discussion includes OpenStack Client and OpenStackSDK. OSC seems to get more works done than the last time it was proposed as a community goal (back in Train cycle?), so TC has set up a topic in the next TC meeting to discuss the possibility to set this as a community goal (for z or after-z cycles).
RabbitMQ was discussed briefly but didn't have any specific suggestions or actions. So if you have any, please kindly provide your feedback in this ML or [3].
If you would like to suggest other cross-project pain points, kindly suggest in ML or [1] and help TCs to identify them.
Finally, we collect pain points and hope to get things fixed/improved, so if you're interested to help with targeting any of the items in [1], you're most welcome to reach out to project teams or at least provide your feedback in [1].
[1] https://etherpad.opendev.org/p/pain-point-elimination https://etherpad.opendev.org/p/pain-point-elimination [2] https://etherpad.opendev.org/p/pain-point-elimination#L261 https://etherpad.opendev.org/p/pain-point-elimination#L261 [3] https://etherpad.opendev.org/p/pain-point-elimination#L21 https://etherpad.opendev.org/p/pain-point-elimination#L21
*Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
On Tue, Dec 7, 2021 at 4:39 PM Rico Lin <ricolin@ricolky.com mailto:ricolin@ricolky.com> wrote:
Dear all For pain point discussion, Let's schedule the video meeting for *Dec. 8th, 15:00 UTC time* Location: https://meet.google.com/xsx-inbw-mos <https://meet.google.com/xsx-inbw-mos> *Rico Lin* OIF Individual Board of directors, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack On Fri, Dec 3, 2021 at 5:37 PM Rico Lin <ricolin@ricolky.com <mailto:ricolin@ricolky.com>> wrote: Dear all The pain point collection etherpad [1] seems to get good attention from teams. We plan to host a one-hour video meeting to keep the discussion going. Please fill in the doodle to select your preferred time if you can join us: https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link <https://doodle.com/poll/kur2mfywceerqcvh?utm_source=poll&utm_medium=link> The discussion will be hosted in video format. Here are some items (but not limited to) I expect we will discuss and hopefully put some actions/efforts on. * General Pain point: RabbitMQ * General Pain point: OpenStackClient support * General project pain point discussion: How to encourage teams to work/reply on pain points. Meanwhile, we encourage all to check the etherpad and provide your feedback. Also if teams can help to answer questions/concerns on etherpad (like Nova team does) will be greatly appreciated. [1] https://etherpad.opendev.org/p/pain-point-elimination <https://etherpad.opendev.org/p/pain-point-elimination> *Rico Lin*
On 12/9/21 6:06 PM, Ghanshyam Mann wrote:
---- On Thu, 09 Dec 2021 04:00:05 -0600 Thomas Goirand zigo@debian.org wrote ----
Hi,
I missed this thread and the discussion, though I've added to the etherpad:
Glance
FIX NEEDED - Glance doesn't work well over uwsgi, it's the onlyservice with this state (appart from Swfit). We would need Glance to fully gate using uwsgi in the CI.
We run glance in uwsgi mode by default since wallaby [1] (GLANCE_STANDALONE=False means uwsgi) and from this patch onwards[2], even import workflow is run in uwsgi by default in CI.
[1] https://github.com/openstack/devstack/blob/6c849e371384e468679d3d030fe494a36... [2] https://review.opendev.org/c/openstack/devstack/+/742332
-gmann
Last time I checked in Victoria, Glance was broken when we had:
Transfer-Encoding: chucked
Has this been fixed? If yes, can someone point at the patches?
Cheers,
Thomas Goirand (zigo)
---- On Thu, 16 Dec 2021 06:56:47 -0600 Thomas Goirand zigo@debian.org wrote ----
On 12/9/21 6:06 PM, Ghanshyam Mann wrote:
---- On Thu, 09 Dec 2021 04:00:05 -0600 Thomas Goirand zigo@debian.org wrote ----
Hi,
I missed this thread and the discussion, though I've added to the etherpad:
Glance
FIX NEEDED - Glance doesn't work well over uwsgi, it's the onlyservice with this state (appart from Swfit). We would need Glance to fully gate using uwsgi in the CI.
We run glance in uwsgi mode by default since wallaby [1] (GLANCE_STANDALONE=False means uwsgi) and from this patch onwards[2], even import workflow is run in uwsgi by default in CI.
[1] https://github.com/openstack/devstack/blob/6c849e371384e468679d3d030fe494a36... [2] https://review.opendev.org/c/openstack/devstack/+/742332
-gmann
Last time I checked in Victoria, Glance was broken when we had:
Transfer-Encoding: chucked
Has this been fixed? If yes, can someone point at the patches?
Import workflow fixes I mentioned above were in wallaby, I am not sure about victoria. Maybe it is better to check on or after wallaby and see if there is still issues or glance team can give more insights (Dan is on PTO until Jan 2nd, he is the one who made it work on uwsgi).
-gmann
Cheers,
Thomas Goirand (zigo)
Last time I checked in Victoria, Glance was broken when we had:
Transfer-Encoding: chucked
Has this been fixed? If yes, can someone point at the patches?
Import workflow fixes I mentioned above were in wallaby, I am not sure about victoria. Maybe it is better to check on or after wallaby and see if there is still issues or glance team can give more insights (Dan is on PTO until Jan 2nd, he is the one who made it work on uwsgi).
Yeah, as gmann noted, we're gating on uwsgi and actively using it during the setup and test phase. I'm not aware of any bugs, so if you have one, point me to it (and/or file it) and I'll take a look.
--Dan
participants (7)
-
Dan Smith
-
Ghanshyam Mann
-
Pierre Riteau
-
Rico Lin
-
Sean Mooney
-
Stephen Finucane
-
Thomas Goirand