[openstack-announce] [OSSA-2024-001] OpenStack Cinder, Glance, Nova: Arbitrary file access through custom QCOW2 external data (CVE-2024-32498)
=== OSSA-2024-001: Arbitrary file access through custom QCOW2 external data === :Date: July 02, 2024 :CVE: CVE-2024-32498 Affects ~~~ - Cinder: <22.1.3, >=23.0.0 <23.1.1, ==24.0.0 - Glance: <26.0.1, ==27.0.0, >=28.0.0 <28.0.2 - Nova: <27.3.1, >=28.0.0 <28.1.1, >=29.0.0 <29.0.3 Description ~~~ Martin Kaesberger reported a vulnerability in QCOW2 image processing for Cinder, Glance and Nova. By supplying a specially created QCOW2 image which references a specific data file path, an authenticated user may convince systems to return a copy of that file's contents from the server resulting in unauthorized access to potentially sensitive data. All Cinder deployments are affected; only Glance deployments with image conversion enabled are affected; all Nova deployments are affected. Patches ~~~ - https://review.opendev.org/923247 (2023.1/antelope(cinder)) - https://review.opendev.org/923277 (2023.1/antelope(glance)) - https://review.opendev.org/923278 (2023.1/antelope(glance)) - https://review.opendev.org/923279 (2023.1/antelope(glance)) - https://review.opendev.org/923280 (2023.1/antelope(glance)) - https://review.opendev.org/923281 (2023.1/antelope(glance)) - https://review.opendev.org/923282 (2023.1/antelope(glance)) - https://review.opendev.org/923283 (2023.1/antelope(glance)) - https://review.opendev.org/923288 (2023.1/antelope(nova)) - https://review.opendev.org/923289 (2023.1/antelope(nova)) - https://review.opendev.org/923290 (2023.1/antelope(nova)) - https://review.opendev.org/923281 (2023.1/antelope(nova)) - https://review.opendev.org/923246 (2023.2/bobcat(cinder)) - https://review.opendev.org/923266 (2023.2/bobcat(glance)) - https://review.opendev.org/923267 (2023.2/bobcat(glance)) - https://review.opendev.org/923268 (2023.2/bobcat(glance)) - https://review.opendev.org/923269 (2023.2/bobcat(glance)) - https://review.opendev.org/923270 (2023.2/bobcat(glance)) - https://review.opendev.org/923271 (2023.2/bobcat(glance)) - https://review.opendev.org/923272 (2023.2/bobcat(glance)) - https://review.opendev.org/923284 (2023.2/bobcat(nova)) - https://review.opendev.org/923285 (2023.2/bobcat(nova)) - https://review.opendev.org/923286 (2023.2/bobcat(nova)) - https://review.opendev.org/923287 (2023.2/bobcat(nova)) - https://review.opendev.org/923245 (2024.1/caracal(cinder)) - https://review.opendev.org/923259 (2024.1/caracal(glance)) - https://review.opendev.org/923260 (2024.1/caracal(glance)) - https://review.opendev.org/923261 (2024.1/caracal(glance)) - https://review.opendev.org/923262 (2024.1/caracal(glance)) - https://review.opendev.org/923263 (2024.1/caracal(glance)) - https://review.opendev.org/923264 (2024.1/caracal(glance)) - https://review.opendev.org/923265 (2024.1/caracal(glance)) - https://review.opendev.org/923273 (2024.1/caracal(nova)) - https://review.opendev.org/923274 (2024.1/caracal(nova)) - https://review.opendev.org/923275 (2024.1/caracal(nova)) - https://review.opendev.org/923276 (2024.1/caracal(nova)) - https://review.opendev.org/923244 (2024.2/dalmatian(cinder)) - https://review.opendev.org/923248 (2024.2/dalmatian(glance)) - https://review.opendev.org/923249 (2024.2/dalmatian(glance)) - https://review.opendev.org/923250 (2024.2/dalmatian(glance)) - https://review.opendev.org/923251 (2024.2/dalmatian(glance)) - https://review.opendev.org/923252 (2024.2/dalmatian(glance)) - https://review.opendev.org/923253 (2024.2/dalmatian(glance)) - https://review.opendev.org/923254 (2024.2/dalmatian(glance)) - https://review.opendev.org/923255 (2024.2/dalmatian(nova)) - https://review.opendev.org/923256 (2024.2/dalmatian(nova)) - https://review.opendev.org/923257 (2024.2/dalmatian(nova)) - https://review.opendev.org/923258 (2024.2/dalmatian(nova)) Credits ~~~ - Martin Kaesberger (CVE-2024-32498) References ~~ - https://launchpad.net/bugs/2059809 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-32498 Notes ~ - Due to the scope of the problem and complexity of the resulting fixes, regressions and additional bypasses were reported in the original bug by downstream stakeholders during the coordinated disclosure period. As a result, our initially chosen publication date was rescheduled, which put the advisory four days past our promised ninety day maximum embargo length. Additional revised patches and regression fixes were supplied to stakeholders as soon as possible, but we understand the unfortunate timing of these last-minute changes resulted in a lot of additional work for everyone involved. -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: PGP signature ___ OpenStack-announce mailing list -- openstack-announce@lists.openstack.org To unsubscribe send an email to openstack-announce-le...@lists.openstack.org
[openstack-announce] OSSN-0093: [Murano] Unsafe Environment Handling in MuranoPL
OSSN-0093 Unsafe Environment Handling in MuranoPL ### Summary ### The Murano service's MuranoPL extension to the YAQL language fails to sanitize the supplied environment, leading to potential leakage of sensitive service account information. Murano is an inactive project[*], so no fix is currently under development for this vulnerability. It is strongly recommended that any OpenStack deployments disable or fully remove Murano, if installed, at the earliest opportunity. [*] https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects ### Affected Services / Software ### - murano: all versions ### Discussion ### The YAQL interpreter project has released a new major version (3.0.0) which removes support for format strings, a feature necessary to exploit this condition in MuranoPL. Because Murano is not considered under active maintenance in OpenStack, its complete removal from all deployments is still strongly advised. Note that this behavior change in YAQL means configurations relying on string formatting will no longer be interpreted the same after upgrading, which could cause them to not work as intended by their users in services which accept YAQL (including Heat and Mistral). Reliance on that feature is considered to be unusual, but users should be made aware in case it negatively impacts their configuration. ### Recommended Actions ### Disable the Murano service in, or fully remove it from, all OpenStack deployments at the earliest opportunity. ### Credits ### kirualawliet and edwardpeng from Sangfor Security Research Team ### Contacts / References ### Authors: - Jeremy Stanley, OpenStack Vulnerability Coordinator This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0093 Original bug: https://launchpad.net/bugs/2048114 Mailing List : [security-sig] openstack-disc...@lists.openstack.org -- Jeremy Stanley, OpenStack Vulnerability Coordinator signature.asc Description: PGP signature ___ OpenStack-announce mailing list -- openstack-announce@lists.openstack.org To unsubscribe send an email to openstack-announce-le...@lists.openstack.org
[openstack-announce] OSSN-0093: Unresolved Vulnerability in OpenStack Murano
OSSN-0093 Unresolved Vulnerability in OpenStack Murano ### Summary ### A severe security vulnerability in all versions of the Murano service will be disclosed at a later date. Murano is an inactive project[*], so no fix is currently under development for this vulnerability. It is strongly recommended that any OpenStack deployments disable or fully remove Murano, if installed, at the earliest opportunity. This security note will be amended at the time of public disclosure to include further details and context, but action should be taken as soon as possible in order to minimize the risk it poses. [*] https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#current-inactive-projects ### Affected Services / Software ### - murano: all versions ### Discussion ### This security note is a redacted placeholder, and will be amended with complete details once the associated bug report becomes public. ### Recommended Actions ### Disable the Murano service in, or fully remove it from, all OpenStack deployments at the earliest opportunity. ### Credits ### Not yet disclosed. ### Contacts / References ### Authors: - Jeremy Stanley, OpenStack Vulnerability Coordinator This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0093 Original bug: https://launchpad.net/bugs/2048114 (not yet public) Mailing List : [security-sig] openstack-disc...@lists.openstack.org -- Jeremy Stanley, OpenStack Vulnerability Coordinator signature.asc Description: PGP signature ___ OpenStack-announce mailing list -- openstack-announce@lists.openstack.org To unsubscribe send an email to openstack-announce-le...@lists.openstack.org
[openstack-announce] [OSSA-2023-003] cinder, glance_store, nova, os-brick: Unauthorized volume access through deleted volume attachments (CVE-2023-2088)
ent more focused on Nova: doc/source/admin/configuration/service-user-token.rst 5. The cinder glance_store driver does not attach volumes to instances; instead, it attaches volumes directly to the Glance node. Thus, the Cinder change in step 4 will recognize an attachment-delete request coming from Glance as safe and allow it. (Of course, we expect that you will have applied the patches in steps 1 and 3 to your Glance nodes.) Errata ~~ An additional nova patch is required to fix a minor regression in periodic tasks and some nova-manage actions (errata 1). Also a patch to tempest is needed to account for behavior changes with fixes in place (errata 2). Patches ~~~ - https://review.opendev.org/882836 (2023.1/antelope cinder) - https://review.opendev.org/882851 (2023.1/antelope glance_store) - https://review.opendev.org/882858 (2023.1/antelope nova) - https://review.opendev.org/882859 (2023.1/antelope nova errata 1) - https://review.opendev.org/882843 (2023.1/antelope os-brick) - https://review.opendev.org/882835 (2023.2/bobcat cinder) - https://review.opendev.org/882834 (2023.2/bobcat glance_store) - https://review.opendev.org/882847 (2023.2/bobcat nova) - https://review.opendev.org/882852 (2023.2/bobcat nova errata 1) - https://review.opendev.org/882840 (2023.2/bobcat os-brick) - https://review.opendev.org/882876 (2023.2/bobcat tempest errata 2) - https://review.opendev.org/882869 (Wallaby nova) - https://review.opendev.org/882870 (Wallaby nova errata 1) - https://review.opendev.org/882839 (Xena cinder) - https://review.opendev.org/882855 (Xena glance_store) - https://review.opendev.org/882867 (Xena nova) - https://review.opendev.org/882868 (Xena nova errata 1) - https://review.opendev.org/882848 (Xena os-brick) - https://review.opendev.org/882838 (Yoga cinder) - https://review.opendev.org/882854 (Yoga glance_store) - https://review.opendev.org/882863 (Yoga nova) - https://review.opendev.org/882864 (Yoga nova errata 1) - https://review.opendev.org/882846 (Yoga os-brick) - https://review.opendev.org/882837 (Zed cinder) - https://review.opendev.org/882853 (Zed glance_store) - https://review.opendev.org/882860 (Zed nova) - https://review.opendev.org/882861 (Zed nova errata 1) - https://review.opendev.org/882844 (Zed os-brick) Credits ~~~ - Jan Wasilewski from Atman (CVE-2023-2088) - Gorka Eguileor from Red Hat (CVE-2023-2088) References ~~ - https://launchpad.net/bugs/2004555 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2088 Notes ~ - Limited Protection Against Accidents... If you are only concerned with protecting against the accidental case described earlier in this document, steps 1-3 above should be sufficient. Note, however, that only applying steps 1-3 leaves your cloud wide open to the intentional exploitation of this vulnerability. Therefore, we recommend that the full fix be applied to all deployments. - Using Configuration as a Short-Term Mitigation... An alternative approach to mitigation can be found in OSSN-0092 https://wiki.openstack.org/wiki/OSSN/OSSN-0092 - The stable/xena and stable/wallaby branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy where available. OSSA History - 2023-05-10 - Errata 2 - 2023-05-10 - Errata 1 - 2023-05-10 - Original Version -- Jeremy Stanley OpenStack Vulnerability Management Team Using Configuration as a Short-Term Mitigation for OSSA-2023-003 --- ### Summary ### An unauthorized access to a volume could occur when an iSCSI or FC connection from a host is severed due to a volume being unmapped on the storage system and the device is later reused for another volume on the same host. ### Affected Services / Software ### - cinder: <20.2.1, >=21.0.0 <21.2.1, ==22.0.0 - glance_store: <3.0.1, >=4.0.0 <4.1.1, >=4.2.0 <4.3.1 - nova: <25.1.2, >=26.0.0 <26.1.2, ==27.0.0 - os-brick: <5.2.3, >=6.0.0 <6.1.1, >=6.2.0 <6.2.2 ### Discussion ### It is recommended to apply the fixes provided in OSSA-2023-003 https://security.openstack.org/ossa/OSSA-2023-003.html but updating an OpenStack deployment may take a long time requiring a proper maintenance window and may even require a validation process of the release prior to the deployment, so operators may prefer applying tactical configuration changes to their cloud to prevent harmful actions while they go through their standarized process. In this case the fastest way to prevent an unsafe attach deletion is twofold: 1. ensuring that Nova uses a user with a service role to send its token on all the requests made to Cinder on behalf of users, and 2. Cinder protects the vulnerable APIs via policy. ### Recommended Actions ### If the deployment has Glance using Cinder as a backend, in order to use this alternative short-term mitigation, Glance must be configured to use a single user having
[openstack-announce] [OSSA-2023-002] Cinder, Glance, Nova: Arbitrary file access through custom VMDK flat descriptor (CVE-2022-47951)
OSSA-2023-002: Arbitrary file access through custom VMDK flat descriptor :Date: January 24, 2023 :CVE: CVE-2022-47951 Affects ~~~ - Cinder, glance, nova: Cinder <19.1.2, >=20.0.0 <20.0.2, ==21.0.0; Glance <23.0.1, >=24.0.0 <24.1.1, ==25.0.0; Nova <24.1.2, >=25.0.0 <25.0.2, ==26.0.0 Description ~~~ Guillaume Espanel, Pierre Libeau, Arnaud Morin and Damien Rannou (OVH) reported a vulnerability in VMDK image processing for Cinder, Glance and Nova. By supplying a specially created VMDK flat image which references a specific backing file path, an authenticated user may convince systems to return a copy of that file's contents from the server resulting in unauthorized access to potentially sensitive data. All Cinder deployments are affected; only Glance deployments with image conversion enabled are affected; all Nova deployments are affected. Patches ~~~ - https://review.opendev.org/871631 (Train(cinder)) - https://review.opendev.org/871630 (Train(glance)) - https://review.opendev.org/871629 (Ussuri(cinder)) - https://review.opendev.org/871626 (Ussuri(glance)) - https://review.opendev.org/871628 (Victoria(cinder)) - https://review.opendev.org/871623 (Victoria(glance)) - https://review.opendev.org/871627 (Wallaby(cinder)) - https://review.opendev.org/871621 (Wallaby(glance)) - https://review.opendev.org/871625 (Xena(cinder)) - https://review.opendev.org/871619 (Xena(glance)) - https://review.opendev.org/871622 (Xena(nova)) - https://review.opendev.org/871620 (Yoga(cinder)) - https://review.opendev.org/871617 (Yoga(glance)) - https://review.opendev.org/871624 (Yoga(nova)) - https://review.opendev.org/871618 (Zed(cinder)) - https://review.opendev.org/871614 (Zed(glance)) - https://review.opendev.org/871616 (Zed(nova)) - https://review.opendev.org/871615 (2023.1/antelope(cinder)) - https://review.opendev.org/871613 (2023.1/antelope(glance)) - https://review.opendev.org/871612 (2023.1/antelope(nova)) Credits ~~~ - Guillaume Espanel from OVH (CVE-2022-47951) - Pierre Libeau from OVH (CVE-2022-47951) - Arnaud Morin from OVH (CVE-2022-47951) - Damien Rannou from OVH (CVE-2022-47951) References ~~ - https://launchpad.net/bugs/1996188 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47951 Notes ~ - The stable/wallaby, stable/victoria, stable/ussuri, and stable/train branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy where possible. -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org
[openstack-announce] [OSSA-2023-001] Swift: Arbitrary file access through custom S3 XML entities (CVE-2022-47950)
=== OSSA-2023-001: Arbitrary file access through custom S3 XML entities === :Date: January 17, 2023 :CVE: CVE-2022-47950 Affects ~~~ - Swift: <2.28.1, >=2.29.0 <2.29.2, ==2.30.0 Description ~~~ Sébastien Meriot (OVH) reported a vulnerability in Swift's S3 XML parser. By supplying specially crafted XML files an authenticated user may coerce the S3 API into returning arbitrary file contents from the host server resulting in unauthorized read access to potentially sensitive data; this impacts both s3api deployments (Rocky or later), and swift3 deployments (Queens and earlier, no longer actively developed). Only deployments with S3 compatibility enabled are affected. Patches ~~~ - https://review.opendev.org/870823 (2023.1/antelope) - https://review.opendev.org/870828 (Wallaby) - https://review.opendev.org/870827 (Xena) - https://review.opendev.org/870826 (Yoga) - https://review.opendev.org/870825 (Zed) Credits ~~~ - Sébastien Meriot from OVH (CVE-2022-47950) References ~~ - https://launchpad.net/bugs/1998625 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-47950 Notes ~ - The stable/wallaby branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org
[openstack-announce] [OSSA-2021-002] Nova: Open Redirect in noVNC proxy (CVE-2021-3654)
=== OSSA-2021-002: Open Redirect in noVNC proxy === :Date: July 29, 2021 :CVE: CVE-2021-3654 Affects ~~~ - Nova: <21.2.3, >=22.0.0 <22.2.3, >=23.0.0 <23.0.3 Description ~~~ Swe Aung, Shahaan Ayyub, and Salman Khan with the Monash University Cyber Security team reported a vulnerability affecting Nova's noVNC proxying implementation which exposed access to a well-known redirect behavior in the Python standard library's http.server.SimpleHTTPRequestHandler and thus noVNC's WebSockifyRequestHandler which uses it. By convincing a user to follow a specially-crafted novncproxy URL, the user could be redirected to an unrelated site under control of the attacker in an attempt to convince them to divulge credentials or other sensitive data. All Nova deployments with novncproxy enabled are affected. Errata ~~ The initial fix did not take into account the possibility of bypass using exactly three slashes. This update provides a more thorough revised fix for the issue. The affected versions list has been updated to indicate versions expected to include the newer solution. Patches ~~~ - https://review.opendev.org/791807 (Train) - https://review.opendev.org/806629 (errata 1) (Train) - https://review.opendev.org/791806 (Ussuri) - https://review.opendev.org/806628 (errata 1) (Ussuri) - https://review.opendev.org/791805 (Victoria) - https://review.opendev.org/806626 (errata 1) (Victoria) - https://review.opendev.org/791577 (Wallaby) - https://review.opendev.org/805818 (errata 1) (Wallaby) - https://review.opendev.org/791297 (Xena) - https://review.opendev.org/805654 (errata 1) (Xena) Credits ~~~ - Swe Aung from Monash University Cyber Security team (CVE-2021-3654) - Shahaan Ayyub from Monash University Cyber Security team (CVE-2021-3654) - Salman Khan from Monash University Cyber Security team (CVE-2021-3654) References ~~ - https://launchpad.net/bugs/1927677 - https://bugs.python.org/issue32084 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3654 Notes ~ - The stable/train branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. OSSA History - 2021-09-27 - Errata 1 - 2021-07-29 - Original Version -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2021-006] Neutron: Routes middleware memory leak for nonexistent controllers (CVE-2021-40797)
OSSA-2021-006: Routes middleware memory leak for nonexistent controllers :Date: September 09, 2021 :CVE: CVE-2021-40797 Affects ~~~ - Neutron: <16.4.1, >=17.0.0 <17.2.1, >=18.0.0 <18.1.1 Description ~~~ Slawek Kaplonski with Red Hat reported a vulnerability in Neutron's routes middleware. By making API requests involving nonexistent controllers, an authenticated user may cause the API worker to consume increasing amounts of memory, resulting in API performance degradation or denial of service. All Neutron deployments are affected. Patches ~~~ - https://review.opendev.org/807638 (Queens) - https://review.opendev.org/807637 (Rocky) - https://review.opendev.org/807636 (Stein) - https://review.opendev.org/807635 (Train) - https://review.opendev.org/807634 (Ussuri) - https://review.opendev.org/807633 (Victoria) - https://review.opendev.org/807632 (Wallaby) - https://review.opendev.org/807335 (Xena) Credits ~~~ - Slawek Kaplonski from Red Hat (CVE-2021-40797) References ~~ - https://launchpad.net/bugs/1942179 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40797 Notes ~ - The stable/train, stable/stein, stable/rocky, and stable/queens branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2021-005] Neutron: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts (CVE-2021-40085)
OSSA-2021-005: Arbitrary dnsmasq reconfiguration via extra_dhcp_opts :Date: August 31, 2021 :CVE: CVE-2021-40085 Affects ~~~ - Neutron: <16.4.1, >=17.0.0 <17.2.1, >=18.0.0 <18.1.1 Description ~~~ Pavel Toporkov reported a vulnerability in Neutron. By supplying a specially crafted extra_dhcp_opts value, an authenticated user may add arbitrary configuration to the dnsmasq process in order to crash the service, change parameters for other tenants sharing the same interface, or otherwise alter that daemon's behavior. This vulnerability may also be used to trigger a configuration parsing buffer overflow in versions of dnsmasq prior to 2.81, which could lead to remote code execution. All Neutron deployments are affected. Patches ~~~ - https://review.opendev.org/806750 (Ussuri) - https://review.opendev.org/806749 (Victoria) - https://review.opendev.org/806748 (Wallaby) - https://review.opendev.org/806746 (Xena) Credits ~~~ - Pavel Toporkov (CVE-2021-40085) References ~~ - https://launchpad.net/bugs/1939733 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40085 -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2021-004] Neutron: Linuxbridge ARP filter bypass on Netfilter platforms (CVE-2021-38598)
=== OSSA-2021-004: Linuxbridge ARP filter bypass on Netfilter platforms === :Date: August 17, 2021 :CVE: CVE-2021-38598 Affects ~~~ - Neutron: <16.4.1, >=17.0.0 <17.1.3, ==18.0.0 Description ~~~ Jake Yip with ARDC and Justin Mammarella with the University of Melbourne reported a vulnerability in Neutron's linuxbridge driver on newer Netfilter-based platforms (the successor to IPTables). By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the hardware addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the linuxbridge driver with ebtables-nft are affected. Patches ~~~ - https://review.opendev.org/804058 (Train) - https://review.opendev.org/804057 (Ussuri) - https://review.opendev.org/804056 (Victoria) - https://review.opendev.org/785917 (Wallaby) - https://review.opendev.org/785177 (Xena) Credits ~~~ - Jake Yip from ARDC (CVE-2021-38598) - Justin Mammarella from University of Melbourne (CVE-2021-38598) References ~~ - https://launchpad.net/bugs/1938670 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38598 Notes ~ - The stable/train branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2021-003] Keystone: Account name and UUID oracles in account locking (CVE-2021-38155)
=== OSSA-2021-003: Account name and UUID oracles in account locking === :Date: August 10, 2021 :CVE: CVE-2021-38155 Affects ~~~ - Keystone: >=10.0.0 <16.0.2, >=17.0.0 <17.0.1, >=18.0.0 <18.0.1, >=19.0.0 <19.0.1 Description ~~~ Samuel de Medeiros Queiroz with Oi Cloud reported a vulnerability affecting Keystone account locking. By guessing the name of an account and failing to authenticate multiple times, any unauthenticated actor could both confirm the account exists and obtain that account's corresponding UUID, which might be leveraged for other unrelated attacks. All Keystone deployments enabling security_compliance.lockout_failure_attempts are affected. Patches ~~~ - https://review.opendev.org/790444 (Train) - https://review.opendev.org/790443 (Ussuri) - https://review.opendev.org/790442 (Victoria) - https://review.opendev.org/790440 (Wallaby) - https://review.opendev.org/759940 (Xena) Credits ~~~ - Samuel de Medeiros Queiroz from Oi Cloud (CVE-2021-38155) References ~~ - https://launchpad.net/bugs/1688137 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38155 -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2021-002] Nova: Open Redirect in noVNC proxy (CVE-2021-3654)
=== OSSA-2021-002: Open Redirect in noVNC proxy === :Date: July 29, 2021 :CVE: CVE-2021-3654 Affects ~~~ - Nova: <21.2.3, >=22.0.0 <22.2.3, >=23.0.0 <23.0.2 Description ~~~ Swe Aung, Shahaan Ayyub, and Salman Khan with the Monash University Cyber Security team reported a vulnerability affecting Nova's noVNC proxying implementation which exposed access to a well-known redirect behavior in the Python standard library's http.server.SimpleHTTPRequestHandler and thus noVNC's WebSockifyRequestHandler which uses it. By convincing a user to follow a specially-crafted novncproxy URL, the user could be redirected to an unrelated site under control of the attacker in an attempt to convince them to divulge credentials or other sensitive data. All Nova deployments with novncproxy enabled are affected. Patches ~~~ - https://review.opendev.org/791807 (Train) - https://review.opendev.org/791806 (Ussuri) - https://review.opendev.org/791805 (Victoria) - https://review.opendev.org/791577 (Wallaby) - https://review.opendev.org/791297 (Xena) Credits ~~~ - Swe Aung from Monash University Cyber Security team (CVE-2021-3654) - Shahaan Ayyub from Monash University Cyber Security team (CVE-2021-3654) - Salman Khan from Monash University Cyber Security team (CVE-2021-3654) References ~~ - https://launchpad.net/bugs/1927677 - https://bugs.python.org/issue32084 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3654 Notes ~ - The stable/train branch is under extended maintenance and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2021-001] Neutron: Anti-spoofing bypass for Open vSwitch networks (CVE-2021-20267)
= OSSA-2021-001: Anti-spoofing bypass for Open vSwitch networks = :Date: July 12, 2021 :CVE: CVE-2021-20267 Affects ~~~ - Neutron: <16.3.3, >=17.0.0 <17.1.3, =18.0.0 Description ~~~ David Sinquin with Gandi.net reported a vulnerability in Neutron's default Open vSwitch firewall rules. By sending carefully crafted packets, anyone in control of a server instance connected to the virtual switch can impersonate the IPv6 addresses of other systems on the network, resulting in denial of service or in some cases possibly interception of traffic intended for other destinations. Only deployments using the Open vSwitch driver are affected. Patches ~~~ - https://review.opendev.org/777873 (Queens) - https://review.opendev.org/791470 (Queens) - https://review.opendev.org/86 (Rocky) - https://review.opendev.org/791469 (Rocky) - https://review.opendev.org/777872 (Stein) - https://review.opendev.org/791500 (Stein) - https://review.opendev.org/85 (Train) - https://review.opendev.org/791468 (Train) - https://review.opendev.org/84 (Ussuri) - https://review.opendev.org/791467 (Ussuri) - https://review.opendev.org/83 (Victoria) - https://review.opendev.org/791465 (Victoria) - https://review.opendev.org/776599 (Wallaby) - https://review.opendev.org/791464 (Wallaby) - https://review.opendev.org/783743 (Xena) Credits ~~~ - David Sinquin from Gandi.net (CVE-2021-20267) References ~~ - https://launchpad.net/bugs/1902917 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20267 Notes ~ - The stable/train, stable/stein, stable/rocky, and stable/queens branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [all][elections][ptl] Project Team Lead Election Conclusion and Results
Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant : Adrian Turjak * Barbican : Douglas Mendizábal * Blazar: Pierre Riteau * Cinder: Brian Rosmaita * Cyborg: Yumeng Bao * Designate : Michael Johnson * Ec2 Api : Andrey Pavlov * Freezer : cai hui * Glance: Abhishek Kekane * Heat : Rico Lin * Horizon : Ivan Kolodyazhny * Ironic: Julia Kreger * Keystone : Kristi Nikolla * Kolla : Mark Goddard * Kuryr : Maysa de Macedo Souza * Magnum: Spyros Trigazis * Manila: Goutham Pacha Ravi * Masakari : Radosław Piliszek * Mistral : Renat Akhmerov * Monasca : Martin Chacon Piza * Murano: Rong Zhu * Neutron : Sławek Kapłoński * Nova : Balazs Gibizer * Openstack Chef: Lance Albertson * OpenStack Helm: Gage Hugo * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Puppet OpenStack : Shengping Zhong * Quality Assurance : Masayuki Igawa * Rally : Andrey Kurilin * Release Management: Hervé Beraud * Requirements : Matthew Thode * Sahara: Jeremy Freudberg * Solum : Rong Zhu * Storlets : Takashi Kajinami * Swift : Tim Burke * Tacker: Yasufumi Ogawa * Telemetry : Matthias Runge * Tripleo : Marios Andreou * Trove : Lingxian Kong * Vitrage : Eyal Bar-Ilan * Watcher : canwei li * Winstackers : Lucian Petrut * Zaqar : wang hao * Zun : Feng Shengqin Elections: * Telemetry: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_2428aa2ecc67cc17 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process, -- Jeremy Stanley on behalf of the OpenStack Technical Election Officials signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [all][elections][tc] Technical Committee Election Results
Please join me in congratulating the 4 newly elected members of the Technical Committe (TC). Dan Smith Ghanshyam Mann (gmann) Jay Bryant (jungleboyj) Kendall Nelson (diablo_rojo) Full results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_f3d92f86f4254553 Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. -- Jeremy Stanley on behalf of the OpenStack Technical Election Officials signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2020-006] Nova: Live migration fails to update persistent domain XML (CVE-2020-17376)
=== OSSA-2020-006: Live migration fails to update persistent domain XML === :Date: August 25, 2020 :CVE: CVE-2020-17376 Affects ~~~ - Nova: <19.3.1, >=20.0.0 <20.3.1, ==21.0.0 Description ~~~ Tadayoshi Hosoya (NEC) and Lee Yarwood (Red Hat) reported a vulnerability in Nova live migration. By performing a soft reboot of an instance which has previously undergone live migration, a user may gain access to destination host devices that share the same paths as host devices previously referenced by the virtual machine on the source. This can include block devices that map to different Cinder volumes on the destination than the source. The risk is increased significantly in non-default configurations allowing untrusted users to initiate live migrations, so administrators may consider temporarily disabling this in policy if they cannot upgrade immediately. This only impacts deployments where users are allowed to perform soft reboots of server instances; it is recommended to disable soft reboots in policy (only allowing hard reboots) until the fix can be applied. Patches ~~~ - https://review.opendev.org/747978 (Pike) - https://review.opendev.org/747976 (Queens) - https://review.opendev.org/747975 (Rocky) - https://review.opendev.org/747974 (Stein) - https://review.opendev.org/747973 (Train) - https://review.opendev.org/747972 (Ussuri) - https://review.opendev.org/747969 (Victoria) Credits ~~~ - Tadayoshi Hosoya from NEC (CVE-2020-17376) - Lee Yarwood from Red Hat (CVE-2020-17376) References ~~ - https://launchpad.net/bugs/1890501 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-17376 Notes ~ - The stable/rocky, stable/queens, and stable/pike branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[OpenStack-Infra] This list is now closed
This mailing list will no longer receive new messages, and its address is forwarded to the openstack-discuss mailing list instead: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss The old list archives will remain published here for posterity: http://lists.openstack.org/pipermail/openstack-infra/ -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Merging this list into openstack-discuss
As covered in the most recent infra meeting[0], we seem to have consensus that this mailing list should be closed down and subsequent conversations moved to the more general openstack-discuss mailing list[1]. I propose on Wendesday, July 15, 2020 we merge a change[2] to forward any subsequent messages destined for this list to openstack-discuss and remove the current ML (leaving its archive published for posterity of course). The TaCT SIG already indicates[3] that its discussions should take place on openstack-discuss, and OpenDev service announcements[4] and discussion[5] have long moved to their own mailing lists. Does anyone disagree with this plan? [0] http://eavesdrop.openstack.org/meetings/infra/2020/infra.2020-06-30-19.01.log.html#l-177 [1] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [2] https://review.opendev.org/739152 [3] https://governance.openstack.org/sigs/tact-sig.html#contact [4] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-announce [5] http://lists.opendev.org/cgi-bin/mailman/listinfo/service-discuss -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Can we use short domain names for build log servers?
On 2020-06-02 10:08:49 +0100 (+0100), Sorin Sbarnea wrote: [...] > Current URLs are backend urls, something that was not designed to > be facing the consumer. [...] James addressed the other points pretty thoroughly, but I wanted to raise a slight objection to this assertion. Public-facing object storage is intended precisely for cases of serving various files/media to browsers so as to offload the traffic from your normal Web server. Maybe instead of backend you meant background? I don't consider there to be anything wrong with sites telling browsers to directly fetch some files from object storage rather than proxying their requests (most frequent use of this is for images and videos). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Should we use pip install --user ... in CI?
On 2020-03-19 09:26:23 + (+), Sorin Sbarnea wrote: [...] > I know that we already had talks about migrating zuul-jobs to > install tools inside virtualenvs but this did not happen yet. It actually has, tox is already available /usr/tox-env/bin/tox on our systems, we just haven't yet merged the change to stop installing a copy of tox into the system context (but that's coming). There's also a /usr/bindep-env/bin/bindep, a /usr/os-testr-env/ostestr and a /usr/glean/bin/glean (that last one could stand to become consistent with the others, I suppose). > I was told that the idea was to install each tool into each own > virtulaenv in order to better isolate it from conflicts with > others but I have some concerns regarding : > > a) making very hard or even impossible to use multiple tools in > the same script, as they would exist in different envs. We're talking about installing Python-based utilities into dedicated venvs. What you note is a concern for Python libraries. When is the last time you "imported" tox in a Python script? How about bindep? Remember that tox in one venv can call bindep from another venv just fine because those are being treated as command-line tools not Python modules (it's how I run them together on my own workstation even). Things which need to import each other should of course be installed into the same venv, that's just common sense. > b) extra footprint on disk and install time. [...] We're not planning on pre-installing more than a handful. Our node images are around 9GB in size, most of which is pre-cached data (Git repositories), and the venvs I listed account for 24KB of excess copies of files. That's something like a quarter of one percent of the image size you're concerned about optimizing. > There are lots of places in tripleo* where pip --user is used and > before trying to propose any changes there, I would like to know > where are we going towards with zuul-jobs as I would like to avoid > divergence in behaviours. If TripleO is installing things at job runtime, that seems like a different case than whatever we bake into our node images, and so doing it a different way is probably fine? -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Your review.opendev.org account is temporarily disabled
You seem to have a misconfigured Zuul service using your Gerrit account, leaving errors like the following on many projects for the past ~12 hours: Unable to freeze job graph: Decryption failed. https://review.opendev.org/707499 I have temporarily deactivated your account (ID 30112) and closed all established Gerrit API connections for it. Please reply when you have corrected the problem and we can reenable your account at that time. Thanks for your attention in this matter. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] docs.airshipit.org setup
[I'm leaving the Cc list intact because I'm not sure which of you are subscribed to this mailing list; my apologies for any duplicate copies you may receive.] On 2020-02-05 15:10:27 + (+), SCHIEFELBEIN, ANDREW wrote: [...] > We would like to get the docs.airshipit.org vhost setup so that we > can start to propagate docs out to this vanity url. Is this > something that someone can assist with? [...] We're in a bit of a transitional phase at the moment to a new and much improved publication workflow, so I took the liberty of trying to do this myself in order to make sure I understand it thoroughly rather than possibly giving you bad/incomplete advice. The rough steps are as follows (reviewers will hopefully tell me where I've gotten it wrong): 0. Create a new volume in AFS to hold your content (done). 1. Add a job to our trusted Zuul config to push your content into this new AFS volume; it has to be in the trusted config repo because it gets access to a shared Kerberos principal. This is change https://review.opendev.org/706598 . 2. Run the new publication job along with corresponding build jobs in relevant pipelines from your airship/treasuremap repository's Zuul configuration. The different docs build job is necessary as it creates a content tarball artifact which is then passed directly to the publication job in the promote pipeline rather than rerunning the same build again after merge. This is change https://review.opendev.org/706598 . 3. Add CNAME RRs in the airshipit.org DNS zone for the server which will eventually serve your content and also for our automation around Let's Encrypt domain validation (done). 4. Set up SSL cert management for the new site. This is change https://review.opendev.org/706600 (it can merge in parallel with steps 1-3 as it's independent of them). 5. Add an Apache vhost configuration on the server which will act as a front-end for your content. This is change https://review.opendev.org/706601 . 6. Enjoy an efficient, automated publication workflow to your own custom documentation site. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] tarballs.openstack.org to AFS publishing gameplan
On 2020-01-29 05:18:55 + (+), Jeremy Stanley wrote: > On 2020-01-29 15:56:24 +1100 (+1100), Ian Wienand wrote: > [...] > > 3) I propose we make tarballs.openstack.org a vhost on > > static.opendev.org that serves the > > /afs/openstack.org/project/tarballs.opendev.org/openstack/ > > directory. > > > > Because > > > > * This is transparent for tarballs.openstack.org; all URLs work with > >no redirection, etc. > > * anyone hitting tarballs.opendev.org will see top-level project > >directories (openstack, zuul, airship, etc.) which makes sense. > [...] > > While it could be a later step, if the OpenStack project leadership > agrees I think I'd rather see the tarballs.openstack.org just host a > permanent redirect from /(.*) to tarballs.opendev.org/$1 so that we > might eventually be able to consider dropping the > tarballs.openstack.org hostname entirely. Also continuing to host > that tree as a separate white-labeled site may encourage other > projects to request similar vanity tarball sites. Of course I meant from /(.*) to tarballs.opendev.org/openstack/$1 so that clients actually get directed to the correct files. ;) -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] tarballs.openstack.org to AFS publishing gameplan
On 2020-01-29 15:56:24 +1100 (+1100), Ian Wienand wrote: [...] > 3) I propose we make tarballs.openstack.org a vhost on > static.opendev.org that serves the > /afs/openstack.org/project/tarballs.opendev.org/openstack/ > directory. > > Because > > * This is transparent for tarballs.openstack.org; all URLs work with >no redirection, etc. > * anyone hitting tarballs.opendev.org will see top-level project >directories (openstack, zuul, airship, etc.) which makes sense. [...] While it could be a later step, if the OpenStack project leadership agrees I think I'd rather see the tarballs.openstack.org just host a permanent redirect from /(.*) to tarballs.opendev.org/$1 so that we might eventually be able to consider dropping the tarballs.openstack.org hostname entirely. Also continuing to host that tree as a separate white-labeled site may encourage other projects to request similar vanity tarball sites. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Question regarding access to OpenDev
On 2020-01-23 23:10:06 + (+), Tommy Chaoping Li wrote: > We are from IBM and we contributed to several open source projects > such as KubeFlow. We found out that the OpenStack team had > developed a great dashboard for capturing the GitHub metrics for > various Open Source projects. We found it very helpful and we want > to propose a few changes on the list of projects on stackalytics; > however, we weren't able to fork or create new propose changes to > the stackalytics project at https://opendev.org/x/stackalytics. Do > we have to apply for certain permission in order to create an > account on OpenDev? Thank you very much in advance. [Apologies for the direct Cc... I approved this message out of the moderation queue because you weren't a subscriber to the mailing list, and therefore suspect you may not see any replies which are only on-list; if you choose not to subscribe, please at least continue to include the mailing list's address in your replies so others have a chance to see them as well.] OpenDev's code contribution workflow can be found in the OpenStack Infrastructure Developer's Guide here (this probably merits adding to our FAQ on the main page for the opendev.org site): https://docs.openstack.org/infra/manual/developers.html > As evidenced by the name of the mailing list on which we're communicating and the domain name where that document is hosted, OpenDev is still in the midst of an identity shift. Some of the information you'll find in that guide is likely to be OpenStack-specific and less applicable to projects which aren't in the "openstack" Git namespace, but the lines are a bit blurry at times (for example, it looks like the x/stackalytics project is set to require contributors to agree to the OSF ICLA before they'll be able to push patches). Regardless, the basic workflow documented there using the `git-review` tool to push proposed patches to Gerrit is correct for all Git repositories hosted in OpenDev. The x/stackalytics maintainers would probably benefit from incorporating a standard CONTRIBUTING.rst document in the root of their Git tree. There's a template for a very basic one OpenStack uses here if you wanted to propose one for them to review along with the other changes you're considering, though it warrants further editing to make it less OpenStack-specific: https://opendev.org/openstack/cookiecutter/src/branch/master/%7b%7bcookiecutter.repo_name%7d%7d/CONTRIBUTING.rst > As always, let us know if you have questions or encounter any roadblocks and we're happy to try to help either here on this mailing list or in the #openstack-infra channel on the Freenode IRC network. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Checking release approvals automatically
On 2019-12-13 18:01:03 +0100 (+0100), Thierry Carrez wrote: [...] > Ideally I would define my own narrow playbook to run the script, without > inheriting from the standard tox job. However the current script requires > some dependencies to be installed (openstack-governance, yaml...). > > Here are the options I see: > > 1- reimplementing most of the unittests/tox job logic in "hosts:localhost" > playbook(s) -- would mean lots of copypaste, does not rhyme so well with > "lightweight", and increases execution times significantly > > 2- rewrite the Python script so that it can run on stdlib -- not sure I want > to write a YAML parser from scratch though > > 3- Abandon the idea of running on the executor -- the trick is that for such > a short job the overhead of requesting a test node is a bit heavy, and we > want to run the job on every vote change on release requests > > Other ideas? Stepping back and thinking about the overall goal (at least what I recall originally discussing), you basically want to look at what the change proposes to update in the releases repo, join that with project information in openstack-governance to get the list of liaisons, then contact Gerrit and add those liaisons as requested reviewers on the change or leave a review comment listing them (or maybe both), right? Assuming that's the case, the repos and Git and pyyaml are available to the workspace on the executor easily enough. Gerrit has a REST API and we have requests already importable too if Ansible's built-in HTTP module isn't sufficiently flexible... is that enough to get it done? That's basically what I was thinking about when I originally suggested a job "lightweight enough to run on the executor." I assumed it would work similar to some other jobs we already have which use an Ansible playbook to call a remote REST API with some supplied credentials based on some information in a change. Speculatively testing changes to the job will be tough of course because of the need to avoid leaking the Gerrit secret, but that's going to be the case with any playbook which needs to authenticate to a remote service. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Resigning from infra-core
Thanks for all the help these many years, I'm glad to know you'll at least still be keeping an eye on us! -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] OpenDev Independence and Governance
On 2019-12-04 09:45:48 -0500 (-0500), Mohammed Naser wrote: > On Wed, Dec 4, 2019 at 5:47 AM Thierry Carrez wrote: [...] > > I'm also wondering if the advisory board should not also include seats > > for the infrastructure donors... Since we should definitely be making > > sure Opendev goes in a direction that encourages them to continue > > investing in (or increase) the resources that they give us. > > I wanted to bring this up but indeed, I think that as an infrastructure > donor, there is a significant investment from our side and knowing > where and how that's going is important Yep, you mentioned it at the PTG and I think it's a great idea. Not only does it provide a means for technical representatives from our resource donors to give more direct feedback and even debate topics between one another, it also gives the OpenDev sysadmins a clearer point of contact when they need to reach out to those same donors. Combining with Thierry's idea, perhaps there are two advisory boards for OpenDev, one for the projects participating in it and one for the resource donors? Or would they be better combined into a single advisory board? And yeah, on the earlier "PTL" point, I agree we could stand to come up with a better term (service coordinator?). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] helping openstack-infra
On 2019-11-25 09:48:20 -0800 (-0800), Clark Boylan wrote: [...] > For the config management updates we've been converting > deployments of services from puppet to ansible [...] It also merits pointing out that this is in part driven by our inability to easily apply our existing Puppet manifests with any of the versions of Puppet available for newer operating systems like Ubuntu 18.04 LTS, so if there is a desire to do something which needs a newer operating system than (rapidly aging) Ubuntu 16.04 LTS, replacing the Puppet automation with Ansible is a necessary prerequisite. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Checking release approvals automatically
On 2019-11-14 17:14:35 + (+), Jeremy Stanley wrote: > On 2019-11-14 17:54:45 +0100 (+0100), Thierry Carrez wrote: > [...] > > "checking that the PTL or designated liaisons have actually +1 the > > request, before casting our own +2 vote." > [...] > > Not that I have a better alternative implementation to suggest, but > just to clarify it seems like the underlying problem statement is > really "block merging a release request without confirmation by a > corresponding PTL or release liaison" (and the Gerrit votes > themselves are more of an implementation detail). Or is it maybe "avoid spending release team review time on release requests until a corresponding PTL/liaison has confirmed them" rather than blocking merge? -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Checking release approvals automatically
On 2019-11-14 17:54:45 +0100 (+0100), Thierry Carrez wrote: [...] > "checking that the PTL or designated liaisons have actually +1 the > request, before casting our own +2 vote." [...] Not that I have a better alternative implementation to suggest, but just to clarify it seems like the underlying problem statement is really "block merging a release request without confirmation by a corresponding PTL or release liaison" (and the Gerrit votes themselves are more of an implementation detail). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] ask.openstack.org down for some days
On 2019-11-09 10:35:07 +0900 (+0900), Bernd Bausch wrote: > ask.openstack.org has been down for most of the week: > >/Firefox can’t establish a connection to the server at >ask.openstack.org./ > > I wouldn't mind helping if I knew how. For some reason Apache has been failing to restart during daily log rotation all week. I've manually started it again. Most of the sysadmins have been busy with other things in Shanghai (myself included), but I had a few free minutes on a layover just now. It's worth keeping in mind that the ask.openstack.org site has basically been unmaintained for years, ever since the AskBot maintainer OSF was contracting to run it disappeared. If folks are still finding the service useful, then we probably need to have a conversation about finding a maintainer for it. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Please delete tag 2.0.1
[Cc'ing because it seems you're not subscribed, apologies for any duplicate copies you may receive] On 2019-10-17 21:15:01 + (+), Jeremy Stanley wrote: > On 2019-10-17 15:14:38 -0400 (-0400), Scott Little wrote: [...] > > The current 2.0.1 tag was pushed in error. Please delete the > > 2.0.1 tag from opendev.org/starlingx/manifest so that I can push > > the correct tag. [...] > Given the amount of manual effort involved, please consider > alternatives such as pushing a tag with a new (slightly higher) > version number. [...] Based on http://lists.starlingx.io/pipermail/starlingx-discuss/2019-October/006579.html it seems you settled on pushing a new 2.0.1b tag. Thank you for taking our workload into consideration, so we can better focus on other aspects of system maintenance and improvements. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Please delete tag 2.0.1
[Cc'ing because it seems you're not subscribed, apologies for any duplicate copies you may receive] On 2019-10-17 15:14:38 -0400 (-0400), Scott Little wrote: > Tag 2.0.1 should point to c89aeff3401fa37ca679bf170cd2f239a51b639f in repo > opendev.org/starlingx/manifest . > > The current 2.0.1 tag was pushed in error. Please delete the 2.0.1 tag from > opendev.org/starlingx/manifest so that I can push the correct tag. > > We realize the challenges of re-writing a tag, and will be informing our > users of the change and the manual steps to fix their repos. To recap the discussion from #openstack-infra on Freenode, doing this will leave Zuul and Nodepool repository caches in an inconsistent state from the official copy in Gerrit due to Git not communicating changes for tags. While it sounds like the CI jobs currently applied to or relying on the starlingx/manifest repository do not take any action on nor generate any artifacts from its Git tags, we would still need to perform cleanup under maintenance to wipe and replace Git caches on the following servers for consistency: 12 Zuul executors 8 Zuul mergers 3 Nodepool image builders This must be done with their respective services offline to force them to re-clone the repositories without erroneous tags when they start. Just as a reminder, these systems are designed with the assumption that Git tags won't be deleted or replaced because Git itself provides no mechanism for a client to discover that this has happened. Given the amount of manual effort involved, please consider alternatives such pushing a tag with a new (slightly higher) version number. While deleting that tag is something we *can* do, we need to know that the effort is justified, and not simply the OpenDev sysadmins taking on more work to save someone else from doing (perhaps a smaller amount of) work instead. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Bug: incorrect HTTP headers on Rackspace CDN S3 used by OS Infra
On 2019-10-12 16:02:55 +0200 (+0200), Roman Gorshunov wrote: > I’m experiencing problems accessing certain content served by > Rackspace CDN S3 used by OS Infra, and looking for help to get > problem resolved. [...] After some lengthy discussion, this workaround was implemented: https://review.opendev.org/688154 Any logs uploaded there for build which began after it merged at 22:02 UTC should no longer exhibit this behavior with browsers which are unable to correctly combine multiple list-type headers as allowed by IETF RFC 2616 section 4.2: "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list" https://tools.ietf.org/html/rfc2616#section-4.2 Note that while what the Rackspace CDN is doing may be atypical, it's allowed by accepted Internet standards. If the source code for your Web browser is readily available, then it may make sense to assist its maintainer community in resolving their lack of complete HTTP support. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] CentOS 8 as a Python 3-only base image
On 2019-09-30 16:30:53 +1000 (+1000), Ian Wienand wrote: > On Fri, Sep 27, 2019 at 11:09:22AM +0000, Jeremy Stanley wrote: > > I'd eventually love to see us stop preinstalling pip and virtualenv > > entirely, allowing jobs to take care of doing that at runtime if > > they need to use them. > > You'd think, right? :) But it is a bit of a can of worms ... [...] > * Python 2 first era (trusty/centos7) will use python2 pip and virtualenv > * Python 3 era (bionic/fedora) will use python3 pip and venv (*not* >virtualenv) > * RHEL8/CentOS 8 will use platform-python pip & venv [...] This is basically what I had in mind, yes. We could also clean up after ourselves on ubuntu/debian where python3-pip and python3-venv are in their own separate packages which aren't typically installed by default on those platforms. But at any rate, I think we're at least far enough along with the Python packaging ecosystem that the available versions of pip contemporary with the Python interpreters on new platforms (not trusty/centos7) are fairly stable when it comes to featureset... unless we want to start making use of some of the new PEP 517 work. As for venv, I've found that tox works great with it too, you just need to install the tox-venv plugin for tox and it doesn't bother with virtualenv at all (been using that with some personal projects for many months already). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] CentOS 8 as a Python 3-only base image
On 2019-09-27 17:26:15 +1000 (+1000), Ian Wienand wrote: [...] > Installing pip and virtualenv from upstream sources has a long history > full of bugs and workarounds nobody wants to think about (if you do > want to think about it, you can start at [2]). [...] > I'm thinking that CentOS 8 is a good place to stop this. We just > won't support, in dib, installing pip/virtualenv from source for > CentOS 8. We hope for the best that the packaged versions of tools > are always working, but *if* we do require fixes to the system > packages, we will implement that inside jobs directly, rather than on > the base images. [...] This seems like a reasonable shift to me. I'd eventually love to see us stop preinstalling pip and virtualenv entirely, allowing jobs to take care of doing that at runtime if they need to use them. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[openstack-announce] [all][elections][ptl] Combined Project Team Lead and Technical Committee Election Conclusion and Results
Thank you to all candidates who put their name forward for Project Team Lead (PTL) and Technical Committee (TC) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Adjutant : Adrian Turjak * Barbican : Douglas Mendizábal * Blazar: Pierre Riteau * Cinder: Brian Rosmaita * Cloudkitty: Luka Peschke * Congress : Eric Kao * Documentation : Alexandra Settle * Ec2 Api : Andrey Pavlov * Freezer : geng chc * Glance: Abhishek Kekane * Heat : Rico Lin * Horizon : Akihiro Motoki * Infrastructure: Clark Boylan * Ironic: Julia Kreger * Karbor: Pengju Jiao * Keystone : Colleen Murphy * Kolla : Mark Goddard * Kuryr : Michał Dulko * Loci : Pete Birley * Magnum: Feilong Wang * Manila: Goutham Pacha Ravi * Masakari : Sampath Priyankara * Mistral : Renat Akhmerov * Monasca : Witek Bedyk * Murano: Rong Zhu * Neutron : Sławek Kapłoński * Nova : Eric Fried * Octavia : Adam Harwell * OpenStack Charms : Frode Nordahl * Openstack Chef: Jens Harbott * OpenStack Helm: Pete Birley * OpenStackAnsible : Mohammed Naser * OpenStackClient : Dean Troyer * Oslo : Ben Nemec * Packaging Rpm : Javier Peña * Puppet OpenStack : Shengping Zhong * Qinling : Lingxian Kong * Quality Assurance : Ghanshyam Mann * Rally : Andrey Kurilin * Release Management: Sean McGinnis * Requirements : Matthew Thode * Sahara: Jeremy Freudberg * Searchlight : Trinh Nguyen * Senlin: XueFeng Liu * Solum : Rong Zhu * Storlets : Kota Tsuyuzaki * Swift : Tim Burke * Tacker: dharmendra kushwaha * Telemetry : Rong Zhu * Tricircle : chi zhang * Tripleo : Wes Hayutin * Trove : Lingxian Kong * Vitrage : Eyal Bar-Ilan * Watcher : canwei li * Zaqar : wang hao * Zun : Feng Shengqin Also please join me in congratulating the 6 newly elected members of the TC: Ghanshyam Mann (gmann) Jean-Philippe Evrard (evrardjp) Jay Bryant (jungleboyj) Kevin Carter (cloudnull) Kendall Nelson (diablo_rojo) Nate Johnston (njohnston) Full results: because there were only as many TC candidates as open seats, no poll was held and all candidates were acclaimed Elections: Election process details and results are also available here: https://governance.openstack.org/election/ -- Jeremy Stanley, on behalf of the OpenStack Technical Election Officials signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
Re: [OpenStack-Infra] is basic auth broken on our gerrit: review.opendev.org?
On 2019-09-02 16:58:48 +0100 (+0100), Sorin Sbarnea wrote: [...] > Considering that from 2.14 only BasicAuth will be supported, it > makes sense to make the move now. Yes, I find this a compelling argument, if only to flush out problems before we upgrade to 2.14. > PS. I stopped using pygerrit2 and I am using requests directly, as > I did not find many benefits in pygerrit so far. Pretty much all the OpenDev tools also just interface directly with the Gerrit API. Same for projects like Gertty. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] is basic auth broken on our gerrit: review.opendev.org?
On 2019-09-01 11:50:18 +0100 (+0100), Sorin Sbarnea wrote: > I was trying to query gerrit using pygerrit2, requests and later > curl just to find out that apparently our gerrit does not work > with basic-auth. [...] > Am I doing something wrong or if not, can we have this fixed? [...] https://review.opendev.org/Documentation/rest-api.html#authentication By default Gerrit uses HTTP digest authentication with the HTTP password from the user’s account settings page. HTTP basic authentication is used if auth.gitBasicAuth is set to true in the Gerrit configuration. It seems like turning that on is probably a reasonable choice if the default prevents pygerrit2 from working. This would, however, need a Gerrit restart to update. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Questions: openstack-ansible-ops -> multi-node-aio
On 2019-08-29 21:57:37 +0200 (+0200), Ich bins wrote: > looks good. The script continues > > But now my first question is still open: [...] Please continue this discussion elsewhere (for example the openstack-disc...@lists.openstack.org mailing list). As Clark tried to explain earlier, you seem to have accidentally found the mailing list used to coordinate maintaining the systems and services which are *used by* the OpenStack community. The mailing list you are mistakenly discussing this on is not intended for general discussions about how to install or use OpenStack, it's a list about things like the OpenDev source code hosting, code review and gating CI systems, as well as task tracking services, documentation hosting, mailing list servers, wiki... not actually about deploying and running OpenStack itself though. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[openstack-announce] [OSSA-2019-004] Ageing time of 0 disables linuxbridge MAC learning (CVE-2019-15753)
= OSSA-2019-004: Ageing time of 0 disables linuxbridge MAC learning = :Date: August 29, 2019 :CVE: CVE-2019-15753 Affects ~~~ - Os-vif: >=1.15.0<1.15.2, 1.16.0 Description ~~~ James Denton with Rackspace reported a vulnerability in os-vif, the Nova/Neutron network integration library. A hard-coded MAC ageing time of 0 disables MAC learning in linuxbridge, forcing obligatory Ethernet flooding for non-local destinations which both impedes network performance and allows users to possibly view the content of packets for instances belonging to other tenants sharing the same network. Only deployments using the linuxbridge backend are affected. Patches ~~~ - https://review.opendev.org/678098 (Stein) - https://review.opendev.org/672834 (Train) Credits ~~~ - James Denton from Rackspace (CVE-2019-15753) References ~~ - https://launchpad.net/bugs/1837252 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15753 -- Jeremy Stanley, on behalf of the OpenStack VMT signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
[openstack-announce] [OSSA-2019-003] Nova Server Resource Faults Leak External Exception Details (CVE-2019-14433)
== OSSA-2019-003: Nova Server Resource Faults Leak External Exception Details == :Date: August 06, 2019 :CVE: CVE-2019-14433 Affects ~~~ - Nova: <17.0.12,>=18.0.0<18.2.2,>=19.0.0<19.0.2 Description ~~~ Donny Davis with Intel reported a vulnerability in Nova Compute resource fault handling. If an API request from an authenticated user ends in a fault condition due to an external exception, details of the underlying environment may be leaked in the response and could include sensitive configuration or other data. Patches ~~~ - https://review.openstack.org/674908 (Ocata) - https://review.openstack.org/674877 (Pike) - https://review.openstack.org/674859 (Queens) - https://review.openstack.org/674848 (Rocky) - https://review.openstack.org/674828 (Stein) - https://review.openstack.org/674821 (Train) Credits ~~~ - Donny Davis from Intel (CVE-2019-14433) References ~~ - https://launchpad.net/bugs/1837877 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14433 Notes ~ - The stable/ocata and stable/pike branches are under extended maintenance and will receive no new point releases, but patches for them are provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team signature.asc Description: PGP signature ___ OpenStack-announce mailing list OpenStack-announce@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-announce
Re: [OpenStack-Infra] How can I have access to OpenStack source code?
On 2019-08-07 22:23:01 +0800 (+0800), jalali.h wrote: > Hello, We are developing our systems based on AWS. We are studying > other clouds beacause costs of AWS. Im interested to OpenStack. > According to your website, OpenStack is an open source software > but I couldnt find its source. Where can I find its source? > Thanks, Reza. Assuming you're looking at https://www.openstack.org/ when you refer to the site, at the top you should see a drop-down which says "Software" and if you click on that (or expand it and select "Overview") then the Software page has a link near the top for "Source Code" which should get you the list of sources for the latest release. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [release][infra] Supporting rget in our release process
On 2019-07-29 13:52:20 -0700 (-0700), James E. Blair wrote: > A colleague at Red Hat is working on an effort to record signatures of > release artifacts. Essentially it's a way to help users verify release > artifacts (or determine if they have been changed) independent of PGP > signatures. You can read about it here: > https://github.com/merklecounty/rget#rget [...] > As mentioned in the README this is very early stages and the author, > Brandon Philips, welcomes both further testing and feedback on the > process in general. > > Thoughts? I really like the way it leverages RFC 6962 Certificate Transparency logs for checksum distribution; the decision not to fall into the blockchain-all-things trap lends a lot of additional credibility to the idea. I agree this would be fairly trivial to integrate into our release publication jobs, and even to backfill with our existing archives. It would grant consumers of our release artifacts the ability to validate them against an open third-party registry, separately from checking the cryptographic release signatures we currently provide alongside them... it could even be used to detect tampering with the signatures themselves in the event of a signing key compromise. This seems like a great idea for URLs of artifacts we host, and I'm happy to hack on the implementation in OpenDev's CI system, likely via a new role in Zuul's standard library of job components. For artifacts we upload to third-party services like PyPI and Docker Hub on the other hand, assuming I've digested (pun intended) the relevant literature correctly, it might make more sense for the maintainers of those services to do something similar as they tend to perform a fair amount of URL indirection and so trying to keep up historical data for those URLs ourselves could be tricky. On the other hand if those third-party services were to integrate rget updating as part of their infrastructure it would be a lot more seamless (especially if they similarly integrated CT checks into the corresponding client-side tooling). Another challenge I see is that, due to the fact that most of what we host is source code, and most consumers of our source code are obtaining it via Git rather than release artifacts, rget wouldn't really do much for them as far as I can see... though once Git completes its planned transition to SHA2-256 in the coming years, I could see a call for some solution to publish known object hashes to a CT log in a similar fashion. I suppose it could be done now by re-checksumming all content over a Git object and submitting a certificate for that, but it seems a bit heavy-weight and I'll admit to not having thought through it completely so there are likely hidden gotchas with that idea. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [github] Request for deleting rsd-lib repo
On 2019-07-29 15:32:54 + (+), Zhang, Lei A wrote: > As mentioned in a mail thread[1], infra team could help us to > remove stole rsd-lib github repo. > > We now use Opendev to host code , could you please delete the copy > on github[2]. > > I'm in the admin-list of rsd-release[3] > > [1] > https://www.mail-archive.com/openstack-infra@lists.openstack.org/msg06382.html > [2] https://github.com/openstack/rsd-lib > [3] https://review.opendev.org/#/admin/groups/1827,members I have deleted the old copy of openstack/rsd-lib from GitHub at your request. Let us know if you need anything else. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [github] Please delete stole github networking-mlnx repo
On 2019-07-18 07:42:58 + (+), Lenny Verkhovsky wrote: [...] > Could you please, delete stale project of networking-mlnx [...] At your request, as a core reviewer of the project in OpenDev, I have removed the stale networking-mlnx repository mirror from the openstack organization on GitHub. Please let us know if you need any further assistance! -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] SPF enforcement on mailing lists
This is just a quick heads up that, in order to deal with recent spam flooding from spoofed E-mail addresses claiming to originate from domains which provide strict IETF RFC 7208 SPF records[*], we have instituted a change to reject messages failing SPF "-all" policies for their domains (not those with "?all" or "~all") at time of receipt to our listservs. If anyone encounters issues which look like a rejection resulting from this change in behavior, please reach out to us in the #openstack-infra channel on the Freenode IRC network. [*] https://tools.ietf.org/html/rfc7208 -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [Starlingx-discuss] Question: How to attach large files to LP bugs?
On 2019-05-31 19:56:30 + (+), Jones, Bruce E wrote: > Resending this query. Any thoughts or ideas? Thanks! [...] I'm intentionally keeping the cross-post between mailing lists on this reply (even though it's generally a bad idea), on the assumption your follow-up indicates you didn't see the original replies: http://lists.openstack.org/pipermail/openstack-infra/2019-May/006366.html http://lists.openstack.org/pipermail/openstack-infra/2019-May/006368.html That said, the OpenDev/OpenStack Infrastructure sysadmins don't maintain Launchpad so don't really have any inside information on it. For real answers you probably need to hit up https://askubuntu.com/questions/tagged/launchpad as Canonical's canonical (heh) place to ask questions about their service. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Problems cloning repos from opendev.org in CentOS7
On 2019-05-24 20:41:58 +0200 (+0200), Alfredo Moralejo Alonso wrote: > On Fri, May 24, 2019 at 8:33 PM Alfredo Moralejo Alonso > wrote: [...] > > For periodic jobs we run every 4 hours i see: > > - Last successful jobs started at 23-May-2019 21:06:42 UTC > > - First failed jobs with this issue started at 24-May-2019 03:06:37 UTC > > We just got one that failed and sarted at 24-May-2019 02:25:00 UTC [...] Thanks, between the timing and symptoms, we're starting to suspect this could be related to how older Git clients' requests are being distributed between our load-balanced backends with inconsistent packing. We're weighing some ideas for how to improve things there, so stay tuned. The good news is that within the next 24 hours the backends will be mostly in sync most of the time, so the symptoms you're observing may subside for the most part once that's the case (but to be entirely honest, we're still not quite sure just yet). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Problems cloning repos from opendev.org in CentOS7
On 2019-05-24 19:20:45 +0200 (+0200), Alfredo Moralejo Alonso wrote: > Since last hours puppet-openstack-integrating jobs in RDO are failing to > deploy puppet modules from https://opendev.org/openstack/puppet- > in CentOS7. [...] Can you be a little more clear on the timeframe? We've switched from the smart Git HTTP backend with Apache to Gitea as of April 20, 2019. We've upgraded the version of Gitea in use several times since then, most recently from 1.8.0 to a newer commit from their master branch as of 01:45 UTC on May 23. We also spent some hours pushing a lot of additional change and note refs into the Gitea service between 16:00 UTC on May 23 and 04:00 UTC on on May 24. Getting a tighter scope for when you saw problems arise may help us nail down which changes on our end might be involved. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] 2019 Denver Summit/Forum/PTG Recap
On 2019-05-14 14:23:51 -0700 (-0700), Clark Boylan wrote: > On Tue, May 14, 2019, at 11:41 AM, Jeremy Stanley wrote: > > On 2019-05-13 13:49:44 -0400 (-0400), Clark Boylan wrote: > > [...] > > > we discussed if OpenDev would be an appropriate location for > > > throwaway repos and unfortunately we don't think we are there yet. > > > Gerrit currently won't scale to that use case for us. > > [...] > > > > Thinking about this a little more, what if we allowed personal > > sandboxes in Gerrit and just didn't wrap them in all the other > > replication, CI and general formality we do for normal repositories? > > Gerrit will allow you to grant access to paths with "$user" in > > them[*], of which WMF's[**] and some other deployments take > > advantage to that end. > > These are ref paths not repo paths. Are you thinking every user > could have a single scratch space repo then have arbitrary refs > within that repo? [...] It looks like the way they're doing it is granting users the ability to create (via push) their own personal branches in a common Git repository... so not quite the solution to throwaway repositories, more like user-namespaced throwaway branches in a single existing repository (e.g. opendev/sandbox). -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] 2019 Denver Summit/Forum/PTG Recap
On 2019-05-13 13:49:44 -0400 (-0400), Clark Boylan wrote: [...] > we discussed if OpenDev would be an appropriate location for > throwaway repos and unfortunately we don't think we are there yet. > Gerrit currently won't scale to that use case for us. [...] Thinking about this a little more, what if we allowed personal sandboxes in Gerrit and just didn't wrap them in all the other replication, CI and general formality we do for normal repositories? Gerrit will allow you to grant access to paths with "$user" in them[*], of which WMF's[**] and some other deployments take advantage to that end. [*] https://gerrit-review.googlesource.com/Documentation/access-control.html#_project_access_control_lists [**] https://www.mediawiki.org/wiki/Gerrit/personal_sandbox -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Question: How to attach large files to LP bugs?
On 2019-05-13 12:48:53 -0400 (-0400), Clark Boylan wrote: [...] > compress multiple chunks and upload them separately? [...] I would go the other direction: compress as thoroughly as possible and then use the `split` utility specifying whatever the upload limit for LP is (I too have no idea what they limit attachment sizes to). Reassembly can be done with `cat` to stuff the chunks back together and then decompress the resulting file as usual. This is starting to remind me of splitting uuencoded data to overcome posting length limits on Usenet. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Train PTG for OpenDev/Infra in Denver
On 2019-05-02 04:51:06 + (+), Jeremy Stanley wrote: > For those joining the OpenDev/Infra team at the Train PTG in Denver > this week, don't forget we start tomorrow (Thursday) morning at 9:00 > AM MDT in room 105 of the Colorado Convention Center. [...] Just to update for those arriving late, we've temporarily relocated to room 106 so as not to compete with QA team discussions. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Train PTG for OpenDev/Infra in Denver
For those joining the OpenDev/Infra team at the Train PTG in Denver this week, don't forget we start tomorrow (Thursday) morning at 9:00 AM MDT in room 105 of the Colorado Convention Center. If you haven't checked in to get your badge yet, there should be folks at the PTG registration desk just past the main entrance lobby to help you out as early as 8:00 AM. Quick links to important PTG information can be found at http://ptg.openstack.org/ should you need it. See you soon! -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Post opendev git repo hosting status repo
On 2019-04-25 09:16:24 + (+), Xiao Mei GZ Zheng wrote: > Is there any suggestion for the bug in CI system since OpenDev git hosting > migration? Thanks. > > + git clone git://git.openstack.org/openstack-infra/devstack-gate > Cloning into 'devstack-gate'... > fatal: unable to connect to git.openstack.org: > git.openstack.org[0: 23.253.125.17]: errno=No route to host > git.openstack.org[1: 2001:4800:7817:103:be76:4eff:fe04:e3e3]: errno=Cannot > assign requested address [...] Yes, as announced in advance of the change, we are no longer able to support traditional git:// protocol connections. If you switch your clone URLs to https:// or http:// then they should otherwise work as before. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] OpenDev git hosting migration and Gerrit downtime April 19, 2019
On 2019-04-17 11:22:19 -0400 (-0400), Clark Boylan wrote: [...] > This plan works for me. I did note a few items in the x/ namespace > that probably do make sense under openstack/. We'll also need to > make a decision on storyboard. Any suggestions for storyboard? > fungi in particular may have thoughts on that. I brought it up in IRC and seems like we're leaning toward wanting storyboard repos in the opendev namespace (at least for the foreseeable future): http://eavesdrop.openstack.org/irclogs/%23storyboard/%23storyboard.2019-04-17.log.html#t2019-04-17T15:42:47 -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] can i Join the openstack.slack.com
On 2019-02-21 16:49:30 +0800 (+0800), 星光 wrote: > my name is mark,i want to join openstack.slack.com,my email is > 195446040@qq. can the admin invite me.thanks a lot. The OpenStack community does not use Slack for its discussions. I recommend either IRC, mailing lists or the ask service we maintain. Information on these can be found in our Users’ Contributor Guide here: https://docs.openstack.org/contributors/users/index.html I don't know much about Slack, but some colleagues have informed me the openstack.slack.com you found is not officially associated with the OpenStack community and is operated by a company named "Cloudify" but beyond that I have no other information about it. I've also heard from people who tried to monitor it at one time that it's basically just full of users asking confused questions and getting no answers. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] requesting update gerrit group member for ku.stella
On 2019-02-20 17:37:18 +0900 (+0900), Jea-Min Lim wrote: > Last year, I commit ku.stella and I think the initial import has been > finished. > (https://review.openstack.org/#/c/623396/) > > Please add me as the Gerrit group member for ku.stella. > If I missed something, reply to me plz. I have added your Gerrit account as the initial member of https://review.openstack.org/#/admin/groups/ku.stella-core and so you should now be able to add and remove any other members as needed. Let us know if you need anything else! -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Contribution as Infrastructure Support.
On 2019-02-07 10:29:26 -0800 (-0800), Clark Boylan wrote: [...] > updating our older servers to Xenial or Bionic from Precise [...] Not to be pedantic, but hopefully we haven't had any servers running Ubuntu Precise for a while now. We are still working to replace most of the ones running Ubuntu Trusty however, as it will be EOL soon. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Gitea next steps
On 2019-02-04 11:04:34 -0800 (-0800), James E. Blair wrote: [...] > I think these are the next steps: > > * Land the patches to manage the opendev k8s cluster with Ansible. > > * Pin the k8s-on-openstack repo to the current sha. > > * Add HTTPS termination to the cluster. > > * Update opendev.org DNS to point to the cluster. > > * Treat this as a soft-launch of the production service. Do not > publicise it or encourage people to switch to it yet, but continue to > observe it as we complete the rest of the tasks in [the spec] [...] I must confess having not been around much for the last two weeks so am still catching up, but this sounds good to me. Thanks for the careful planning! -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] [infra][storyboard] Project Update/Some New Things
On 2018-09-10 14:34:49 + (+), Jeremy Stanley wrote: > On 2018-09-10 14:43:18 +0100 (+0100), Adam Coldrick wrote: [...] > > # Finding stories from a task ID > > > > It is now possible to navigate to a story given just a task ID, > > if for whatever reason that's all the information you have > > available. A link like > > > > https://storyboard.openstack.org/#!/task/12389 > > > > will work. This will redirect to the story containing the task, > > and is the first part of work to support linking directly to an > > individual task in a story. > [...] > > As an aside, I think this makes it possible now for us to start > hyperlinking Task footers in commit messages within the Gerrit > change view. I'll try and figure out what we need to adjust in our > Gerrit commentlink and its-storyboard plugin configs to make that > happen. As of Friday (2018-12-21) our Gerrit instance at https://review.openstack.org/ has started hyperlinking task footers in commit messages, leveraging the above feature (the configuration change for it merged months ago but Gerrit has been so stable lately we've not gotten around to restarting it for that to take effect until now). At this point you can omit the story footer if you have a task footer, since all the story footer has been providing is a hyperlink anyway. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Cross-community/generic mailing lists
On 2018-12-10 18:39:44 -0600 (-0600), Jonathan Bryce wrote: > I was having a conversation with some people who are working > across multiple communities involved in virtualization and > container security and they were interested in having a higher > level mailing list for open discussions. It doesn’t necessarily > make sense to tie it to any particular project mailing list, and I > was wondering how others on the OpenDev team felt about creating > discussion lists along these lines on lists.opendev.org. This > isn’t the first time we’ve seen this use case, and seems like it > could be a nice service to a number of communities. > > Thoughts? As a straw man, I've proposed https://review.openstack.org/625096 to add a lists.opendev.org Mailman site to our existing mailing list server. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] [infra] OpenDev feedback forum session summary
inimize future repository renames is now not looking as attractive. Instead we're probably going to need to embrace an explosion of new namespaces and find better ways to cope with the pain of renames in Gerrit as projects want to move between them over time. We're planning to only run one Gerrit for simplicity, so artificially creating "tenants" in it through prefixes in repository names is really the simplest solution we have to avoid different projects stepping on one another's toes with their name choices. Then we got into some policy discussions about namespace creation. Jim Blair talked about the potential to map Git/Gerrit repository namespaces to distinct Zuul tenants, and someone (might have been me? I was fairly jet-lagged and so don't really remember) asked about who decides what the requirements are for projects to create repositories in a particular namespace. In the case of OpenStack, the answer is almost certainly the OpenStack Technical Committee or at least some group to whom they delegate that responsibility. The OpenStack TC needs to discuss fairly early what its policies are for the "openstack" namespace (whether existing unofficial projects will be allowed to remain, whether addition of new unofficial projects will be allowed there) as well as whether it wants to allow creation of multiple separate namespaces for official OpenStack projects. The suggestion of nested "deep" namespaces like openstack/nova/nova came up at this point too. We also resolved that we need to look back into the project rename plugin for Gerrit. The last time we evaluated it, there wasn't much there. We've heard it's improved with newer Gerrit releases, but if it's still lacking we might want to contribute to making it more effective so we can handle the inevitable renames more easily in the future. And finally, as happens with most forum sessions, we stopped abruptly because we ran over and it was Kendall Nelson's turn to start getting ops feedback for the Contributor Guide. ;) -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Hosting OpenStack Summit (among other) videos
On 2018-12-05 19:02:13 + (+), Jeremy Stanley wrote: > On 2018-12-05 19:40:16 +0100 (+0100), François Magimel wrote: [...] > > - what is the licence of summit videos ? > > Allison Price on the OSF staff confirmed for me that all the > official OpenStack Summit session recordings are supposed to be > distributed under CC-BY (unfortunately they're inconsistently > labeled in YouTube descriptions where some indicate a License of > "Creative Commons Attribution license (reuse allowed)" and others > don't currently mention any license). [...] And Allison has fixed them now, so hopefully the licenses should all be consistently showing up. Thanks, Allison! -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Hosting OpenStack Summit (among other) videos
On 2018-12-05 19:40:16 +0100 (+0100), François Magimel wrote: > My name is François and I would like to suggest a new service for > the OpenStack Foundation: video hosting. Today, video are hosted > in Youtube. But as OpenStack promotes free and open source > softwares, I would like to help installing an alternative for the > Foundation: Peertube [1], a decentralized video hosting network > based on libre software :). [...] Thanks! I find the idea compelling of course because it's free/libre open source software (unlike YouTube), but also because it turns out many of our contributors in mainland China are blocked from accessing YouTube and need us to host these videos somewhere else anyway. I'm curious, since PeerTube basically relies on an in-browser bittorrent client, whether bittorrent protocol works through the government-imposed Internet filters in China and would provide a good solution to that problem. > - what is the licence of summit videos ? Allison Price on the OSF staff confirmed for me that all the official OpenStack Summit session recordings are supposed to be distributed under CC-BY (unfortunately they're inconsistently labeled in YouTube descriptions where some indicate a License of "Creative Commons Attribution license (reuse allowed)" and others don't currently mention any license). I think this means we should have no legal problem at least serving copies of them. > - does the Foundation have some resources to host videos ? [...] It wouldn't be the OpenStack Foundation, but rather the community project infrastructure, which would need to obtain those resources. (If you're unfamiliar with the OpenStack Infrastructure project, in the process of switching to the name OpenDev, https://docs.openstack.org/infra/system-config/project.html provides an overview of who we are and how we collaborate.) We have a fair amount of "cloud" resources provided to us by many generous donor organizations, so ought to be able to come up with sufficient space to house these files and cover the bandwidth of serving them if we decide that's something we want to do. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[Openstack] IMPORTANT: This list is retired
This mailing list was replaced by a new openstack-disc...@lists.openstack.org mailing list[0] as of Monday November 19, 2018 and starting now will no longer receive any new messages. The archive of prior messages will remain published in the expected location indefinitely for future reference. For convenience posts to the old list address will be rerouted to the new list for an indeterminate period of time, but please correct it in your replies if you notice this. See my original notice[1] (and the many reminders sent in months since) for an explanation of this change. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack/2018-September/047005.html -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack-operators] IMPORTANT: This list is retired
This mailing list was replaced by a new openstack-disc...@lists.openstack.org mailing list[0] as of Monday November 19, 2018 and starting now will no longer receive any new messages. The archive of prior messages will remain published in the expected location indefinitely for future reference. For convenience posts to the old list address will be rerouted to the new list for an indeterminate period of time, but please correct it in your replies if you notice this. See my original notice[1] (and the many reminders sent in months since) for an explanation of this change. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-operators/2018-September/015919.html -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[openstack-dev] IMPORTANT: This list is retired
This mailing list was replaced by a new openstack-disc...@lists.openstack.org mailing list[0] as of Monday November 19, 2018 and starting now will no longer receive any new messages. The archive of prior messages will remain published in the expected location indefinitely for future reference. For convenience posts to the old list address will be rerouted to the new list for an indeterminate period of time, but please correct it in your replies if you notice this. See my original notice[1] (and the many reminders sent in months since) for an explanation of this change. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack-operators] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] has been open for posts from subscribers since Monday November 19, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 403 subscribers on openstack-discuss with six days to go before the old lists are closed down for good). I have updated the old list descriptions to indicate the openstack-discuss list is preferred, and added a custom "welcome message" with the same for anyone who subscribes to them over the next week. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [OpenStack-Infra] Proposed changes to how we run our meeting
On 2018-11-21 06:49:31 +1100 (+1100), Ian Wienand wrote: > On Sun, Nov 18, 2018 at 11:09:29AM -0800, Clark Boylan wrote: > > Both ideas seem sound to me and I think we should try to implement > > them for the Infra team. I propose that we require agenda updates 24 > > hours prior to the meeting start time and if there are no agenda > > updates we cancel the meeting. Curious to hear if others think this > > will be helpful and if 24 hours is enough lead time to be helpful. > > My concern here is that we have standing items of priority tasks > updates that are essentially always there, and action item follow-up > from the prior meeting. Personally I often find them very useful. [...] Back when I was chairing these meetings regularly, I urged participants to add info within each priority effort (or added some myself) in advance of the meeting. If there was nothing called out in our agenda under a given priority effort entry, I skipped over it. Going back to something like that could help us figure out when a meeting is warranted rather than ending up as a series of "nothing new here" comments. But this aside, I think the frequency with which we'd end up skipping meetings (based on history of our agenda updates) will be low enough that we shouldn't really focus on that part of the proposal. I agree what's important is having our agenda nailed down in advance so people can decide whether or not it's important for them to attend. We do sometimes skip meetings for various reasons anyway, so rarely announcing we won't hold one because nobody has any updates or topics on the agenda feels like an incentive for people to find relevant topics so that doesn't happen often. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[Openstack] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] is open for posts from subscribers starting now, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 280 subscribers on openstack-discuss with three weeks to go before the old lists are closed down for good). At the recommendation of David Medberry at the OpenStack Summit last week, this reminder is being sent individually to each of the old lists (not as a cross-post), and without any topic tag in case either might be resulting in subscribers missing it. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
[Openstack-operators] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] is open for posts from subscribers starting now, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 280 subscribers on openstack-discuss with three weeks to go before the old lists are closed down for good). At the recommendation of David Medberry at the OpenStack Summit last week, this reminder is being sent individually to each of the old lists (not as a cross-post), and without any topic tag in case either might be resulting in subscribers missing it. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[openstack-dev] IMPORTANT: We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list[0] is open for posts from subscribers starting now, and the old lists will be configured to no longer accept posts starting on Monday December 3. In the interim, posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them now and not miss any messages. See my previous notice[1] for details. As of the time of this announcement, we have 280 subscribers on openstack-discuss with three weeks to go before the old lists are closed down for good). At the recommendation of David Medberry at the OpenStack Summit last week, this reminder is being sent individually to each of the old lists (not as a cross-post), and without any topic tag in case either might be resulting in subscribers missing it. [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [OpenStack-Infra] Proposed changes to how we run our meeting
On 2018-11-18 11:09:29 -0800 (-0800), Clark Boylan wrote: [...] > I propose that we require agenda updates 24 hours prior to the > meeting start time and if there are no agenda updates we cancel > the meeting. Curious to hear if others think this will be helpful > and if 24 hours is enough lead time to be helpful. [...] Sounds great to me, thanks for considering putting these ideas into practice! -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [Openstack-operators] new SIGs to cover use cases
On 2018-11-12 15:46:38 + (+), arkady.kanev...@dell.com wrote: [...] > 1. Do we have or want to create a user community around Hybrid cloud. [...] > 2. As we target AI/ML as 2019 target application domain do we > want to create a SIG for it? Or do we extend scientific > community SIG to cover it? [...] It may also be worthwhile to ask this on the openstack-sigs mailing list. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack] [openstack-dev] [all] We're combining the lists!
On 2018-11-10 11:02:15 +0100 (+0100), Thierry Carrez wrote: [...] > As we are ultimately planning to move lists to mailman3 (which decided > to drop the "topics" concept altogether), I don't think we planned to > add serverside mailman topics to the new list. Correct, that was covered in more detail in the longer original announcement linked from my past couple of reminders: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html In short, we're recommending client-side filtering because server-side topic selection/management was not retained in Mailman 3 as Thierry indicates and we hope we might move our lists to an MM3 instance sometime in the not-too-distant future. > We'll still have standardized subject line topics. The current list > lives at: > > https://etherpad.openstack.org/p/common-openstack-ml-topics Which is its initial location for crowd-sourcing/brainstorming, but will get published to a more durable location like on lists.openstack.org itself or perhaps the Project-Team Guide once the list is in use. -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack-operators] [openstack-dev] [all] We're combining the lists!
On 2018-11-10 11:02:15 +0100 (+0100), Thierry Carrez wrote: [...] > As we are ultimately planning to move lists to mailman3 (which decided > to drop the "topics" concept altogether), I don't think we planned to > add serverside mailman topics to the new list. Correct, that was covered in more detail in the longer original announcement linked from my past couple of reminders: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html In short, we're recommending client-side filtering because server-side topic selection/management was not retained in Mailman 3 as Thierry indicates and we hope we might move our lists to an MM3 instance sometime in the not-too-distant future. > We'll still have standardized subject line topics. The current list > lives at: > > https://etherpad.openstack.org/p/common-openstack-ml-topics Which is its initial location for crowd-sourcing/brainstorming, but will get published to a more durable location like on lists.openstack.org itself or perhaps the Project-Team Guide once the list is in use. -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] We're combining the lists!
On 2018-11-10 11:02:15 +0100 (+0100), Thierry Carrez wrote: [...] > As we are ultimately planning to move lists to mailman3 (which decided > to drop the "topics" concept altogether), I don't think we planned to > add serverside mailman topics to the new list. Correct, that was covered in more detail in the longer original announcement linked from my past couple of reminders: http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html In short, we're recommending client-side filtering because server-side topic selection/management was not retained in Mailman 3 as Thierry indicates and we hope we might move our lists to an MM3 instance sometime in the not-too-distant future. > We'll still have standardized subject line topics. The current list > lives at: > > https://etherpad.openstack.org/p/common-openstack-ml-topics Which is its initial location for crowd-sourcing/brainstorming, but will get published to a more durable location like on lists.openstack.org itself or perhaps the Project-Team Guide once the list is in use. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack-operators] [all] We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 207 subscribers so far on openstack-discuss with a little over a week to go before it will be put into use (and less than a month before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack] [all] We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 207 subscribers so far on openstack-discuss with a little over a week to go before it will be put into use (and less than a month before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [all] We're combining the lists!
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 207 subscribers so far on openstack-discuss with a little over a week to go before it will be put into use (and less than a month before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][neutron-release] feature/graphql branch rebase
On 2018-11-09 16:35:22 +1100 (+1100), Gilles Dubreuil wrote: > Could you please provide permission [1] to upload commit merges? > > I'm getting the following error after merging HEAD: > > $ git review -R feature/graphql > remote: > remote: Processing changes: refs: 1 > remote: Processing changes: refs: 1, done > To ssh://review.openstack.org:29418/openstack/neutron.git > ! [remote rejected] HEAD -> refs/publish/feature/graphql/bug/1802101 > (you are not allowed to upload merges) > error: failed to push some refs to > 'ssh://q-1ille...@review.openstack.org:29418/openstack/neutron.git' [...] Per openstack/neutron's ACL[*] you need to be made a member of the neutron-release group in Gerrit[**]. (This permission is tightly controlled to avoid people accidentally pushing merge commits, which is all too easy if you're not careful to keep your branches clean.) [*] https://git.openstack.org/cgit/openstack-infra/project-config/tree/gerrit/acls/openstack/neutron.config [**] https://review.openstack.org/#/admin/groups/neutron-release -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cyborg]Weekly Meeting
On 2018-11-07 10:02:52 -0500 (-0500), Li Liu wrote: > It seems the meeting bot is having issues.. I would just paste the > meeting log here [...] The meetbot wasn't having any issues. The chair didn't issue an #endmeeting, and only a meeting chair is allowed to do so until an hour has elapsed from the #startmeeting. After an hour, anyone can so I did an #endmeeting in your channel and it wrapped up and wrote the minutes and logs as usual: http://eavesdrop.openstack.org/meetings/openstack_cyborg/2018/openstack_cyborg.2018-11-07-14.16.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][qa] Migrating devstack jobs to Bionic (Ubuntu LTS 18.04)
On 2018-11-06 22:05:49 +0100 (+0100), Slawek Kaplonski wrote: [...] > also add jobs like "devstack-xenial" and "tempest-full-xenial" > which projects can use still for some time if their job on Bionic > would be broken now? [...] That opens the door to piecemeal migration, which (as we similarly saw during the Trusty to Xenial switch) will inevitably lead to projects who no longer gate on Xenial being unable to integration test against projects who don't yet support Bionic. At the same time, projects which have switched to Bionic will start merging changes which only work on Bionic without realizing it, so that projects which test on Xenial can't use them. In short, you'll be broken either way. On top of that, you can end up with projects that don't get around to switching completely before release comes, and then they're stuck having to manage a test platform transition on a stable branch. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] [openstack client] command completion
On 2018-11-06 10:58:04 +0900 (+0900), Bernd Bausch wrote: [...] > By the way, there used to be a /python-openstackclient /section in > Launchpad. Doesn't exist anymore. Where are bugs tracked these days? At the top of https://launchpad.net/python-openstackclient it says, "Note that all Launchpad activity (just bugs & blueprints really) has been migrated to OpenStack's Storyboard: https://storyboard.openstack.org/#!/project_group/80; I suppose now that project group name URL support is in for SB, they could update that to the more memorable https://storyboard.openstack.org/#!/project_group/openstackclient instead. -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [all] 2019 summit during May holidays?
On 2018-11-05 11:06:14 -0800 (-0800), Julia Kreger wrote: [...] > I imagine that as a community, it is near impossible to schedule > something avoiding holidays for everyone in the community. [...] Scheduling events that time of year is particularly challenging anyway because of the proximity of Ramadan, Passover and Easter/Lent. (We've already conflicted with Passover at least once in the past, if memory serves.) So yes, any random week you pick is already likely to hit a major public or religious holiday for some part of the World, and then you also have to factor in availability of venues and other logistics. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
On 2018-11-01 09:27:03 -0400 (-0400), Doug Hellmann wrote: > Jeremy Stanley writes: > > > On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: > > [...] > >> Did I miss any options or issues with this approach? > > > > https://review.openstack.org/578557 > > How high of a priority is rolling that feature out? It does seem to > eliminate this particular issue (even the edge cases described in the > commit message shouldn't affect us based on our typical practices), but > until we have one of the two changes in place we're going to have this > issue with every release we tag. It was written as a potential solution to this problem back when we first discussed it in June, but at the time we thought it might be solvable via job configuration with minimal inconvenience so that feature was put on hold as a fallback option in case we ended up needing it. I expect since it's already seen some review and is passing tests it could probably be picked back up fairly quickly now that alternative solutions have proven more complex than originally envisioned. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures][release][infra] Tag of openstack/keystone failed
On 2018-11-01 08:52:05 -0400 (-0400), Doug Hellmann wrote: [...] > Did I miss any options or issues with this approach? https://review.openstack.org/578557 -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Storyboard python script
On 2018-10-31 22:39:01 + (+), Krishna Jain wrote: > I’m an animator with some coding experience picking up Python. I > came across your python-storyboardclient library, which would be > very helpful for automating our pipeline in Toon Boom Storyboard > Pro. [...] The python-storyboardclient library is for use with the free/libre open source StoryBoard task and defect tracker project described by the documentation located at https://docs.openstack.org/infra/storyboard/ and not the commercial "Toon Boom Storyboard Pro" animation software to which you seem to be referring. Sorry for the confusion! -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] We're combining the lists!
On 2018-10-29 12:58:09 -0400 (-0400), Jay Pipes wrote: > I'm not willing to subscribe with a password over a non-TLS > connection... [...] Up to you, certainly. You don't actually need to enter anything in the password fields on the subscription page (as the instructions on it also indicate). You can alternatively subscribe by sending E-mail to openstack-discuss-requ...@lists.openstack.org with a subject line of "subscribe" if you prefer. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] [all] We're combining the lists! (was: Bringing the community together...)
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 127 subscribers so far on openstack-discuss with 3 weeks to go before it will be put into use (and 5 weeks now before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [Openstack-operators] [all] We're combining the lists! (was: Bringing the community together...)
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 127 subscribers so far on openstack-discuss with 3 weeks to go before it will be put into use (and 5 weeks now before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [all] We're combining the lists! (was: Bringing the community together...)
REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this is being sent) will be replaced by a new openstack-disc...@lists.openstack.org mailing list. The new list is open for subscriptions[0] now, but is not yet accepting posts until Monday November 19 and it's strongly recommended to subscribe before that date so as not to miss any messages posted there. The old lists will be configured to no longer accept posts starting on Monday December 3, but in the interim posts to the old lists will also get copied to the new list so it's safe to unsubscribe from them any time after the 19th and not miss any messages. See my previous notice[1] for details. For those wondering, we have 127 subscribers so far on openstack-discuss with 3 weeks to go before it will be put into use (and 5 weeks now before the old lists are closed down for good). [0] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134911.html -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [Openstack] non public glance image can seen by all tenant
On 2018-10-26 11:29:27 +0700 (+0700), Adhi Priharmanto wrote: > I have setup rocky release at my openstack lab, now all of tenant > (user) can see non-public glance image create by another tenant > (user) [...] This sounds very similar to https://launchpad.net/bugs/1799588 which the Glance team has been asked to look into. See also the rather lengthy troubleshooting discussion on the Operators ML starting here: http://lists.openstack.org/pipermail/openstack-operators/2018-October/016039.html -- Jeremy Stanley signature.asc Description: PGP signature ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Release-job-failures] Release of openstack/python-apmecclient failed
On 2018-10-26 06:46:23 -0500 (-0500), Sean McGinnis wrote: [...] > Release failed for this due to openstackci not being properly configured > for the pypi package upload. If whoever "pineunity" is can add the "openstackci" account as another maintainer for https://pypi.org/project/python-apmecclient/ then I'm happy to reenqueue that tag into Zuul. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Release-job-failures] Release of openstack-infra/shade failed
On 2018-10-24 16:08:26 +1100 (+1100), Tony Breeds wrote: > On Wed, Oct 24, 2018 at 03:23:53AM +, z...@openstack.org wrote: > > Build failed. > > > > - release-openstack-python3 > > http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python3/e84da68/ > > : POST_FAILURE in 2m 18s > > So this failed because pypi thinks there was a name collision[1]: > HTTPError: 400 Client Error: File already exists. See > https://pypi.org/help/#file-name-reuse for url: > https://upload.pypi.org/legacy/ > > AFACIT the upload was successful: > > shade-1.27.2-py2-none-any.whl : 2018-10-24T03:20:00 > d30a230461ba276c8bc561a27e61dcfd6769ca00bb4c652a841f7148a0d74a5a > shade-1.27.2-py2.py3-none-any.whl : 2018-10-24T03:20:11 > 8942b56d7d02740fb9c799a57f0c4ff13d300680c89e6f04dadb5eaa854e1792 > shade-1.27.2.tar.gz: 2018-10-24T03:20:04 > ebf40040b892f3e9bd4229fd05fff7ea24a08c51e46b7f2d8b3901ce34f51cbf [...] I think PyPI is right. Note the fact that there are not two but *three* artifacts there. We shouldn't be building both a py2 and py2.py3 wheel. The log you linked is uploaded shade-1.27.2-py2.py3-none-any.whl and tried (but failed) to upload shade-1.27.2.tar.gz. So where did shade-1.27.2-py2-none-any.whl come from then? Hold onto your hats folks: http://logs.openstack.org/ab/abac67d7bb347e1caba4d74c81712de86790316b/release/release-openstack-python/f38f2b9/job-output.txt.gz#_2018-10-24_03_20_02_134223 I suppose we don't expect a project to run both the release-openstack-python and release-openstack-python3 jobs on the same tags. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
