From amy at demarco.com Fri Nov 2 15:14:24 2018 From: amy at demarco.com (Amy Marrich) Date: Fri, 2 Nov 2018 10:14:24 -0500 Subject: [Openstack-sigs] OpenStack Diversity and Inclusion Survey Message-ID: The Diversity and Inclusion WG is still looking for your assistance in reaching and including data from as many members of our community as possible. We revised the Diversity Survey that was originally distributed to the Community in the Fall of 2015 and reached out in August with our new survey. We are looking to update our view of the OpenStack community and it's diversity. We are pleased to be working with members of the CHAOSS project who have signed confidentiality agreements in order to assist us in the following ways: 1) Assistance in analyzing the results 2) And feeding the results into the CHAOSS software and metrics development work so that we can help other Open Source projects Please take the time to fill out the survey and share it with others in the community. The survey can be found at: https://www.surveymonkey.com/r/OpenStackDiversity Thank you for assisting us in this important task! Please feel free to reach out to me via email, in Berlin, or to myself or any WG member in #openstack-diversity! Amy Marrich (spotz) Diversity and Inclusion Working Group Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Mon Nov 5 17:51:57 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 5 Nov 2018 11:51:57 -0600 Subject: [Openstack-sigs] Dropping lazy translation support Message-ID: This is a follow up to a dev ML email [1] where I noticed that some implementations of the upgrade-checkers goal were failing because some projects still use the oslo_i18n.enable_lazy() hook for lazy log message translation (and maybe API responses?). The very old blueprints related to this can be found here [2][3][4]. If memory serves me correctly from my time working at IBM on this, this was needed to: 1. Generate logs translated in other languages. 2. Return REST API responses if the "Accept-Language" header was used and a suitable translation existed for that language. #1 is a dead horse since I think at least the Ocata summit when we agreed to no longer translate logs since no one used them. #2 is probably something no one knows about. I can't find end-user documentation about it anywhere. It's not tested and therefore I have no idea if it actually works anymore. I would like to (1) deprecate the oslo_i18n.enable_lazy() function so new projects don't use it and (2) start removing the enable_lazy() usage from existing projects like keystone, glance and cinder. Are there any users, deployments or vendor distributions that still rely on this feature? If so, please speak up now. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-November/136285.html [2] https://blueprints.launchpad.net/oslo-incubator/+spec/i18n-messages [3] https://blueprints.launchpad.net/nova/+spec/i18n-messages [4] https://blueprints.launchpad.net/nova/+spec/user-locale-api -- Thanks, Matt From doug at doughellmann.com Mon Nov 5 19:36:56 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 05 Nov 2018 14:36:56 -0500 Subject: [Openstack-sigs] Dropping lazy translation support In-Reply-To: References: Message-ID: Matt Riedemann writes: > This is a follow up to a dev ML email [1] where I noticed that some > implementations of the upgrade-checkers goal were failing because some > projects still use the oslo_i18n.enable_lazy() hook for lazy log message > translation (and maybe API responses?). > > The very old blueprints related to this can be found here [2][3][4]. > > If memory serves me correctly from my time working at IBM on this, this > was needed to: > > 1. Generate logs translated in other languages. > > 2. Return REST API responses if the "Accept-Language" header was used > and a suitable translation existed for that language. > > #1 is a dead horse since I think at least the Ocata summit when we > agreed to no longer translate logs since no one used them. > > #2 is probably something no one knows about. I can't find end-user > documentation about it anywhere. It's not tested and therefore I have no > idea if it actually works anymore. > > I would like to (1) deprecate the oslo_i18n.enable_lazy() function so > new projects don't use it and (2) start removing the enable_lazy() usage > from existing projects like keystone, glance and cinder. > > Are there any users, deployments or vendor distributions that still rely > on this feature? If so, please speak up now. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-November/136285.html > [2] https://blueprints.launchpad.net/oslo-incubator/+spec/i18n-messages > [3] https://blueprints.launchpad.net/nova/+spec/i18n-messages > [4] https://blueprints.launchpad.net/nova/+spec/user-locale-api > > -- > > Thanks, > > Matt > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs I think the lazy stuff was all about the API responses. The log translations worked a completely different way. Doug From zbitter at redhat.com Mon Nov 5 21:08:19 2018 From: zbitter at redhat.com (Zane Bitter) Date: Mon, 5 Nov 2018 16:08:19 -0500 Subject: [Openstack-sigs] Seeking user/operator feedback on the vision for OpenStack clouds Message-ID: <93badd06-a23b-d8bb-4a7b-7b091e9a42b0@redhat.com> The TC is leading an initiative to write down a vision for what OpenStack clouds could eventually look like - essentially interpreting the OpenStack Mission Statement at a level of detail that's sufficient to inform technical and governance decisions. You can read the current draft here: http://logs.openstack.org/05/592205/5/check/openstack-tox-docs/24a6785/html/reference/technical-vision.html Feedback from the technical community suggests to me that it's getting pretty close to accurately capturing what we thought we should have been building. However, there's obviously no point in developers doing this in isolation if the thing we describe isn't what actual or potential operators and users of OpenStack want. Thus, we're seeking feedback from the wider OpenStack community on the vision. There are a number of ways to get involved: * You can comment directly on the review https://review.openstack.org/592205 * Replies to this thread are also welcome. * There will be a brief presentation on this topic at the joint leadership meeting with the Board, UC, and TC in Berlin: https://wiki.openstack.org/wiki/Governance/Foundation/12Nov2018BoardMeeting * Attend this Forum session at the Summit in Berlin where we'll be listening to feedback and discussing the next steps: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22818/vision-for-openstack-clouds-discussion I look forward to hearing from y'all :) thanks, Zane. From mriedemos at gmail.com Mon Nov 5 21:13:56 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Mon, 5 Nov 2018 15:13:56 -0600 Subject: [Openstack-sigs] Dropping lazy translation support In-Reply-To: References: Message-ID: <2ae55c40-297d-3590-84de-665eae797522@gmail.com> On 11/5/2018 1:36 PM, Doug Hellmann wrote: > I think the lazy stuff was all about the API responses. The log > translations worked a completely different way. Yeah maybe. And if so, I came across this in one of the blueprints: https://etherpad.openstack.org/p/disable-lazy-translation Which says that because of a critical bug, the lazy translation was disabled in Havana to be fixed in Icehouse but I don't think that ever happened before IBM developers dropped it upstream, which is further justification for nuking this code from the various projects. -- Thanks, Matt From doug at doughellmann.com Mon Nov 5 21:36:40 2018 From: doug at doughellmann.com (Doug Hellmann) Date: Mon, 05 Nov 2018 16:36:40 -0500 Subject: [Openstack-sigs] Dropping lazy translation support In-Reply-To: <2ae55c40-297d-3590-84de-665eae797522@gmail.com> References: <2ae55c40-297d-3590-84de-665eae797522@gmail.com> Message-ID: Matt Riedemann writes: > On 11/5/2018 1:36 PM, Doug Hellmann wrote: >> I think the lazy stuff was all about the API responses. The log >> translations worked a completely different way. > > Yeah maybe. And if so, I came across this in one of the blueprints: > > https://etherpad.openstack.org/p/disable-lazy-translation > > Which says that because of a critical bug, the lazy translation was > disabled in Havana to be fixed in Icehouse but I don't think that ever > happened before IBM developers dropped it upstream, which is further > justification for nuking this code from the various projects. I agree. Doug From tony at bakeyournoodle.com Tue Nov 6 02:19:20 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Tue, 6 Nov 2018 13:19:20 +1100 Subject: [Openstack-sigs] [openstack-dev] [all]Naming the T release of OpenStack -- Poll open In-Reply-To: <20181030054024.GC2343@thor.bakeyournoodle.com> References: <20181030054024.GC2343@thor.bakeyournoodle.com> Message-ID: <20181106021919.GB20576@thor.bakeyournoodle.com> Hi all, Time is running out for you to have your say in the T release name poll. We have just under 3 days left. If you haven't voted please do! On Tue, Oct 30, 2018 at 04:40:25PM +1100, Tony Breeds wrote: > Hi folks, > > It is time again to cast your vote for the naming of the T Release. > As with last time we'll use a public polling option over per user private URLs > for voting. This means, everybody should proceed to use the following URL to > cast their vote: > > https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_aac97f1cbb6c61df&akey=b9e448b340787f0e > > We've selected a public poll to ensure that the whole community, not just gerrit > change owners get a vote. Also the size of our community has grown such that we > can overwhelm CIVS if using private urls. A public can mean that users > behind NAT, proxy servers or firewalls may receive an message saying > that your vote has already been lodged, if this happens please try > another IP. > > Because this is a public poll, results will currently be only viewable by myself > until the poll closes. Once closed, I'll post the URL making the results > viewable to everybody. This was done to avoid everybody seeing the results while > the public poll is running. > > The poll will officially end on 2018-11-08 00:00:00+00:00[1], and results will be > posted shortly after. > > [1] https://governance.openstack.org/tc/reference/release-naming.html > --- > > According to the Release Naming Process, this poll is to determine the > community preferences for the name of the T release of OpenStack. It is > possible that the top choice is not viable for legal reasons, so the second or > later community preference could wind up being the name. > > Release Name Criteria > --------------------- > > Each release name must start with the letter of the ISO basic Latin alphabet > following the initial letter of the previous release, starting with the > initial release of "Austin". After "Z", the next name should start with > "A" again. > > The name must be composed only of the 26 characters of the ISO basic Latin > alphabet. Names which can be transliterated into this character set are also > acceptable. > > The name must refer to the physical or human geography of the region > encompassing the location of the OpenStack design summit for the > corresponding release. The exact boundaries of the geographic region under > consideration must be declared before the opening of nominations, as part of > the initiation of the selection process. > > The name must be a single word with a maximum of 10 characters. Words that > describe the feature should not be included, so "Foo City" or "Foo Peak" > would both be eligible as "Foo". > > Names which do not meet these criteria but otherwise sound really cool > should be added to a separate section of the wiki page and the TC may make > an exception for one or more of them to be considered in the Condorcet poll. > The naming official is responsible for presenting the list of exceptional > names for consideration to the TC before the poll opens. > > Exact Geographic Region > ----------------------- > > The Geographic Region from where names for the S release will come is Colorado > > Proposed Names > -------------- > > * Tarryall > * Teakettle > * Teller > * Telluride > * Thomas : the Tank Engine > * Thornton > * Tiger > * Tincup > * Timnath > * Timber > * Tiny Town > * Torreys > * Trail > * Trinidad > * Treasure > * Troublesome > * Trussville > * Turret > * Tyrone > > Proposed Names that do not meet the criteria (accepted by the TC) > ----------------------------------------------------------------- > > * TrainπŸš‚ : Many Attendees of the first Denver PTG have a story to tell about the trains near the PTG hotel. We could celebrate those stories with this name > > Yours Tony. > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Yours Tony. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From openstack at nemebean.com Mon Nov 5 21:39:58 2018 From: openstack at nemebean.com (Ben Nemec) Date: Mon, 5 Nov 2018 15:39:58 -0600 Subject: [Openstack-sigs] [Openstack-operators] Dropping lazy translation support In-Reply-To: <2ae55c40-297d-3590-84de-665eae797522@gmail.com> References: <2ae55c40-297d-3590-84de-665eae797522@gmail.com> Message-ID: <8febca8b-d3d9-0f17-44dd-1a1fe8eddff0@nemebean.com> On 11/5/18 3:13 PM, Matt Riedemann wrote: > On 11/5/2018 1:36 PM, Doug Hellmann wrote: >> I think the lazy stuff was all about the API responses. The log >> translations worked a completely different way. > > Yeah maybe. And if so, I came across this in one of the blueprints: > > https://etherpad.openstack.org/p/disable-lazy-translation > > Which says that because of a critical bug, the lazy translation was > disabled in Havana to be fixed in Icehouse but I don't think that ever > happened before IBM developers dropped it upstream, which is further > justification for nuking this code from the various projects. > It was disabled last-minute, but I'm pretty sure it was turned back on (hence why we're hitting issues today). I still see coercion code in oslo.log that was added to fix the problem[1] (I think). I could be wrong about that since this code has undergone significant changes over the years, but it looks to me like we're still forcing things to be unicode.[2] 1: https://review.openstack.org/#/c/49230/3/openstack/common/log.py 2: https://github.com/openstack/oslo.log/blob/a9ba6c544cbbd4bd804dcd5e38d72106ea0b8b8f/oslo_log/formatters.py#L414 From rochelle.grober at huawei.com Tue Nov 6 23:24:19 2018 From: rochelle.grober at huawei.com (Rochelle Grober) Date: Tue, 6 Nov 2018 23:24:19 +0000 Subject: [Openstack-sigs] [openstack-dev] [Openstack-operators] Dropping lazy translation support In-Reply-To: <8febca8b-d3d9-0f17-44dd-1a1fe8eddff0@nemebean.com> References: <2ae55c40-297d-3590-84de-665eae797522@gmail.com> <8febca8b-d3d9-0f17-44dd-1a1fe8eddff0@nemebean.com> Message-ID: I seem to recall list discussion on this quite a ways back. I think most of it happened on the Docs ml, though. Maybe Juno/Kilo timeframe? If possible, it would be good to search over the code bases for places it was called to see its current footprint. I'm pretty sure it was the docs folks working with the oslo folks to make it work. But then the question was put to the ops folks about translations of logs (maybe the New York midcycle) and ops don't use translation. The ops input was broadcast to dev and docs and most efforts stopped at that point. But, I believe some projects had already done some work on lazy translation. I suspect the amount done, though was pretty low. Maybe the fastest way to get info would be to turn it off and see where the code barfs in a long run (to catch as many projects as possible)? --rocky > From: Ben Nemec > Sent: Monday, November 05, 2018 1:40 PM > > On 11/5/18 3:13 PM, Matt Riedemann wrote: > > On 11/5/2018 1:36 PM, Doug Hellmann wrote: > >> I think the lazy stuff was all about the API responses. The log > >> translations worked a completely different way. > > > > Yeah maybe. And if so, I came across this in one of the blueprints: > > > > https://etherpad.openstack.org/p/disable-lazy-translation > > > > Which says that because of a critical bug, the lazy translation was > > disabled in Havana to be fixed in Icehouse but I don't think that ever > > happened before IBM developers dropped it upstream, which is further > > justification for nuking this code from the various projects. > > > > It was disabled last-minute, but I'm pretty sure it was turned back on (hence > why we're hitting issues today). I still see coercion code in oslo.log that was > added to fix the problem[1] (I think). I could be wrong about that since this > code has undergone significant changes over the years, but it looks to me like > we're still forcing things to be unicode.[2] > > 1: https://review.openstack.org/#/c/49230/3/openstack/common/log.py > 2: > https://github.com/openstack/oslo.log/blob/a9ba6c544cbbd4bd804dcd5e38 > d72106ea0b8b8f/oslo_log/formatters.py#L414 > From mriedemos at gmail.com Wed Nov 7 00:28:14 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Tue, 6 Nov 2018 18:28:14 -0600 Subject: [Openstack-sigs] [openstack-dev] [Openstack-operators] Dropping lazy translation support In-Reply-To: References: <2ae55c40-297d-3590-84de-665eae797522@gmail.com> <8febca8b-d3d9-0f17-44dd-1a1fe8eddff0@nemebean.com> Message-ID: <5894b2cd-310c-04b4-1c90-859812bd47c9@gmail.com> On 11/6/2018 5:24 PM, Rochelle Grober wrote: > Maybe the fastest way to get info would be to turn it off and see where the code barfs in a long run (to catch as many projects as possible)? There is zero integration testing for lazy translation, so "turning it off and seeing what breaks" wouldn't result in anything breaking. -- Thanks, Matt From tony at bakeyournoodle.com Thu Nov 8 00:48:20 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Thu, 8 Nov 2018 11:48:20 +1100 Subject: [Openstack-sigs] [all] Results of the T release naming poll. open Message-ID: <20181108004819.GF20576@thor.bakeyournoodle.com> Hello all! The results of the naming poll are in! **PLEASE REMEMBER** that these now have to go through legal vetting. So it is too soon to say 'OpenStack Train' is our next release, given that previous polls have had some issues with the top choice. In any case, the names will be sent off to legal for vetting. As soon as we have a final winner, I'll let you all know. https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_aac97f1cbb6c61df&rkey=7c8b5588574494c1 Result 1. Train (Condorcet winner: wins contests with all other choices) 2. Tiger loses to Train by 142–70 3. Timber loses to Train by 142–72, loses to Tiger by 100–76 4. Trail loses to Train by 150–55, loses to Timber by 93–62 5. Telluride loses to Train by 155–56, loses to Trail by 81–69 6. Teller loses to Train by 158–46, loses to Telluride by 70–67 7. Treasure loses to Train by 151–52, loses to Teller by 68–67 8. Teakettle loses to Train by 158–49, loses to Treasure by 75–67 9. Tincup loses to Train by 157–47, loses to Teakettle by 67–60 10. Turret loses to Train by 158–48, loses to Tincup by 75–56 11. Thomas loses to Train by 159–42, loses to Turret by 66–63 12. Trinidad loses to Train by 153–44, loses to Thomas by 70–56 13. Troublesome loses to Train by 165–41, loses to Trinidad by 69–62 14. Thornton loses to Train by 163–35, loses to Troublesome by 62–59 15. Tyrone loses to Train by 163–35, loses to Thornton by 58–38 16. Tarryall loses to Train by 170–31, loses to Tyrone by 54–50 17. Timnath loses to Train by 170–23, loses to Tarryall by 60–32 18. Tiny Town loses to Train by 168–29, loses to Timnath by 45–43 19. Torreys loses to Train by 167–29, loses to Tiny Town by 48–40 20. Trussville loses to Train by 169–25, loses to Torreys by 43–34 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From gagehugo at gmail.com Fri Nov 9 18:10:29 2018 From: gagehugo at gmail.com (Gage Hugo) Date: Fri, 9 Nov 2018 12:10:29 -0600 Subject: [Openstack-sigs] [security][weekly-meeting] No Meeting Next Two Weeks Message-ID: Due to the Berlin OpenStack Summit next week, and Thanksgiving in the US the following week, the Nov 15th and Nov 22nd Security SIG meetings will be cancelled. We will resume on the 29th of November as scheduled. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fungi at yuggoth.org Fri Nov 9 18:14:47 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Fri, 9 Nov 2018 18:14:47 +0000 Subject: [Openstack-sigs] [all] We're combining the lists! In-Reply-To: <20181029165346.vm6ptoqq5wkqban6@yuggoth.org> References: <20180830170350.wrz4wlanb276kncb@yuggoth.org> <20180920163248.oia5t7zjqcfwluwz@yuggoth.org> <20181029165346.vm6ptoqq5wkqban6@yuggoth.org> Message-ID: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> 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-discuss at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From chris at openstack.org Mon Nov 12 09:27:22 2018 From: chris at openstack.org (Chris Hoge) Date: Mon, 12 Nov 2018 10:27:22 +0100 Subject: [Openstack-sigs] [docs] New Four Opens Project Message-ID: <19E45C45-2E7E-454B-8743-7B41B21B4701@openstack.org> Earlier this year, the OpenStack Foundation staff had the opportunity to brainstorm some ideas about how to express the values behind The Four Opens and how they are applied in practice. As the Foundation grows in scope to include new strategic focus areas and new projects, we felt it was important to provide explanation and guidance on the principles that guide our community. We’ve collected these notes and have written some seeds to start this document. I’ve staged this work into github and have prepared a review to move the work into OpenStack hosting, turning this over to the community to help guide and shape the document. This is very much a work in progress, but we have a goal to polish this up and make it an important document that captures our vision and values for the OpenStack development community, guides the establishment of governance for new top-level projects, and is a reference for the open-source development community as a whole. I also want to be clear that the original Four Opens, as listed in the OpenStack governance page, is an OpenStack TC document. This project doesn’t change that. Instead, it is meant to be applied to the Foundation as a whole and be a reference to the new projects that land both as pilot top-level projects and projects hosted by our new infrastructure efforts. Thanks to all of the original authors of the Four-Opens for your visionary work that started this process, and thanks in advance to the community members who will continue to grow and evolve this document. Chris Hoge OpenStack Foundation Four Opens: https://governance.openstack.org/tc/reference/opens.html New Project Review Patch: https://review.openstack.org/#/c/617005/ Four Opens Document Staging: https://github.com/hogepodge/four-opens -------------- next part -------------- An HTML attachment was scrubbed... URL: From Arkady.Kanevsky at dell.com Tue Nov 13 08:01:47 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Tue, 13 Nov 2018 08:01:47 +0000 Subject: [Openstack-sigs] [Openstack-operators] new SIGs to cover use cases In-Reply-To: <20181112224535.ofkgektadexifwzm@yuggoth.org> References: <2da0506287d64764bb4219b145518470@AUSX13MPS308.AMER.DELL.COM> <20181112224535.ofkgektadexifwzm@yuggoth.org> Message-ID: <91fe2241790443128cd9b7dc959468fe@AUSX13MPS308.AMER.DELL.COM> Good point. Adding SIG list. -----Original Message----- From: Jeremy Stanley [mailto:fungi at yuggoth.org] Sent: Monday, November 12, 2018 4:46 PM To: openstack-operators at lists.openstack.org Subject: Re: [Openstack-operators] new SIGs to cover use cases [EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information. On 2018-11-12 15:46:38 +0000 (+0000), Arkady.Kanevsky at 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 From stig.openstack at telfer.org Tue Nov 13 15:39:36 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Tue, 13 Nov 2018 16:39:36 +0100 Subject: [Openstack-sigs] [Openstack-operators] new SIGs to cover use cases In-Reply-To: <91fe2241790443128cd9b7dc959468fe@AUSX13MPS308.AMER.DELL.COM> References: <2da0506287d64764bb4219b145518470@AUSX13MPS308.AMER.DELL.COM> <20181112224535.ofkgektadexifwzm@yuggoth.org> <91fe2241790443128cd9b7dc959468fe@AUSX13MPS308.AMER.DELL.COM> Message-ID: <4E26EC12-087C-42AC-A207-696764077787@telfer.org> You are right to make the connection - this is a subject that regularly comes up in the discussions of the Scientific SIG, though it’s just one of many use cases for hybrid cloud. If a new SIG was created around hybrid cloud, it would be useful to have it closely connected with the Scientific SIG. Cheers, Stig > On 13 Nov 2018, at 09:01, wrote: > > Good point. > Adding SIG list. > > -----Original Message----- > From: Jeremy Stanley [mailto:fungi at yuggoth.org] > Sent: Monday, November 12, 2018 4:46 PM > To: openstack-operators at lists.openstack.org > Subject: Re: [Openstack-operators] new SIGs to cover use cases > > > [EXTERNAL EMAIL] > Please report any suspicious attachments, links, or requests for sensitive information. > > > On 2018-11-12 15:46:38 +0000 (+0000), Arkady.Kanevsky at 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 > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From stig at telfer.org Tue Nov 13 14:54:51 2018 From: stig at telfer.org (Stig Telfer) Date: Tue, 13 Nov 2018 15:54:51 +0100 Subject: [Openstack-sigs] [Openstack-operators] new SIGs to cover use cases In-Reply-To: <91fe2241790443128cd9b7dc959468fe@AUSX13MPS308.AMER.DELL.COM> References: <2da0506287d64764bb4219b145518470@AUSX13MPS308.AMER.DELL.COM> <20181112224535.ofkgektadexifwzm@yuggoth.org> <91fe2241790443128cd9b7dc959468fe@AUSX13MPS308.AMER.DELL.COM> Message-ID: <838DF2C6-02B1-4A97-BC65-C41671A1C604@telfer.org> You are right to make the connection - this is a subject that regularly comes up in the discussions of the Scientific SIG, though it’s just one of many use cases for hybrid cloud. If a new SIG was created around hybrid cloud, it would be useful to have it closely connected with the Scientific SIG. Cheers, Stig > On 13 Nov 2018, at 09:01, wrote: > > Good point. > Adding SIG list. > > -----Original Message----- > From: Jeremy Stanley [mailto:fungi at yuggoth.org] > Sent: Monday, November 12, 2018 4:46 PM > To: openstack-operators at lists.openstack.org > Subject: Re: [Openstack-operators] new SIGs to cover use cases > > > [EXTERNAL EMAIL] > Please report any suspicious attachments, links, or requests for sensitive information. > > > On 2018-11-12 15:46:38 +0000 (+0000), Arkady.Kanevsky at 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 > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators From yihleong at gmail.com Wed Nov 14 04:11:21 2018 From: yihleong at gmail.com (Yih Leong, Sun.) Date: Tue, 13 Nov 2018 20:11:21 -0800 Subject: [Openstack-sigs] [Openstack-operators] new SIGs to cover use cases In-Reply-To: <838DF2C6-02B1-4A97-BC65-C41671A1C604@telfer.org> References: <2da0506287d64764bb4219b145518470@AUSX13MPS308.AMER.DELL.COM> <20181112224535.ofkgektadexifwzm@yuggoth.org> <91fe2241790443128cd9b7dc959468fe@AUSX13MPS308.AMER.DELL.COM> <838DF2C6-02B1-4A97-BC65-C41671A1C604@telfer.org> Message-ID: Wondering if we should *up level* to Multi-Cloud, where Hybrid Cloud can be a subset of Multi-Cloud. I think Scientific SIG can still focus on Scientific and HPC, whereas Multi/Hybrid Cloud will support broader use cases. On Tue, Nov 13, 2018 at 8:22 AM Stig Telfer wrote: > You are right to make the connection - this is a subject that regularly > comes up in the discussions of the Scientific SIG, though it’s just one of > many use cases for hybrid cloud. If a new SIG was created around hybrid > cloud, it would be useful to have it closely connected with the Scientific > SIG. > > Cheers, > Stig > > > > On 13 Nov 2018, at 09:01, < > Arkady.Kanevsky at dell.com> wrote: > > > > Good point. > > Adding SIG list. > > > > -----Original Message----- > > From: Jeremy Stanley [mailto:fungi at yuggoth.org] > > Sent: Monday, November 12, 2018 4:46 PM > > To: openstack-operators at lists.openstack.org > > Subject: Re: [Openstack-operators] new SIGs to cover use cases > > > > > > [EXTERNAL EMAIL] > > Please report any suspicious attachments, links, or requests for > sensitive information. > > > > > > On 2018-11-12 15:46:38 +0000 (+0000), Arkady.Kanevsky at 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 > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Wed Nov 14 04:42:35 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 14 Nov 2018 05:42:35 +0100 Subject: [Openstack-sigs] [all] All Hail our Newest Release Name - OpenStack Train Message-ID: <20181114044233.GA10706@thor.bakeyournoodle.com> Hi everybody! As the subject reads, the "T" release of OpenStack is officially "Train". Unlike recent choices Train was the popular choice so congrats! Thanks to everybody who participated and help with the naming process. Lets make OpenStack Train the release so awesome that people can't help but choo-choo-choose to run it[1]! Yours Tony. [1] Too soon? Too much? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From jeremyfreudberg at gmail.com Wed Nov 14 05:12:43 2018 From: jeremyfreudberg at gmail.com (Jeremy Freudberg) Date: Wed, 14 Nov 2018 00:12:43 -0500 Subject: [Openstack-sigs] [openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train In-Reply-To: <20181114044233.GA10706@thor.bakeyournoodle.com> References: <20181114044233.GA10706@thor.bakeyournoodle.com> Message-ID: Hey Tony, What's the reason for the results of the poll not being public? Thanks, Jeremy On Tue, Nov 13, 2018 at 11:52 PM Tony Breeds wrote: > > > Hi everybody! > > As the subject reads, the "T" release of OpenStack is officially > "Train". Unlike recent choices Train was the popular choice so > congrats! > > Thanks to everybody who participated and help with the naming process. > > Lets make OpenStack Train the release so awesome that people can't help > but choo-choo-choose to run it[1]! > > > Yours Tony. > [1] Too soon? Too much? > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From skaplons at redhat.com Wed Nov 14 07:37:09 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Wed, 14 Nov 2018 08:37:09 +0100 Subject: [Openstack-sigs] [openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train In-Reply-To: References: <20181114044233.GA10706@thor.bakeyournoodle.com> Message-ID: <7064638E-4B0A-4572-A194-4FF6327DC6B1@redhat.com> Hi, I think it was published, see http://lists.openstack.org/pipermail/openstack/2018-November/047172.html > WiadomoΕ›Δ‡ napisana przez Jeremy Freudberg w dniu 14.11.2018, o godz. 06:12: > > Hey Tony, > > What's the reason for the results of the poll not being public? > > Thanks, > Jeremy > On Tue, Nov 13, 2018 at 11:52 PM Tony Breeds wrote: >> >> >> Hi everybody! >> >> As the subject reads, the "T" release of OpenStack is officially >> "Train". Unlike recent choices Train was the popular choice so >> congrats! >> >> Thanks to everybody who participated and help with the naming process. >> >> Lets make OpenStack Train the release so awesome that people can't help >> but choo-choo-choose to run it[1]! >> >> >> Yours Tony. >> [1] Too soon? Too much? >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev β€” Slawek Kaplonski Senior software engineer Red Hat From jeremyfreudberg at gmail.com Wed Nov 14 14:43:33 2018 From: jeremyfreudberg at gmail.com (Jeremy Freudberg) Date: Wed, 14 Nov 2018 08:43:33 -0600 Subject: [Openstack-sigs] [openstack-dev] [all] All Hail our Newest Release Name - OpenStack Train In-Reply-To: <7064638E-4B0A-4572-A194-4FF6327DC6B1@redhat.com> References: <20181114044233.GA10706@thor.bakeyournoodle.com> <7064638E-4B0A-4572-A194-4FF6327DC6B1@redhat.com> Message-ID: Thanks Slawomir-- you're right. My mistake. (I had been looking at http://lists.openstack.org/pipermail/openstack-dev/2018-November/136309.html , whose Condorcet link indicates private results.) On Wed, Nov 14, 2018 at 1:45 AM Slawomir Kaplonski wrote: > > Hi, > > I think it was published, see http://lists.openstack.org/pipermail/openstack/2018-November/047172.html > > > WiadomoΕ›Δ‡ napisana przez Jeremy Freudberg w dniu 14.11.2018, o godz. 06:12: > > > > Hey Tony, > > > > What's the reason for the results of the poll not being public? > > > > Thanks, > > Jeremy > > On Tue, Nov 13, 2018 at 11:52 PM Tony Breeds wrote: > >> > >> > >> Hi everybody! > >> > >> As the subject reads, the "T" release of OpenStack is officially > >> "Train". Unlike recent choices Train was the popular choice so > >> congrats! > >> > >> Thanks to everybody who participated and help with the naming process. > >> > >> Lets make OpenStack Train the release so awesome that people can't help > >> but choo-choo-choose to run it[1]! > >> > >> > >> Yours Tony. > >> [1] Too soon? Too much? > >> __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > β€” > Slawek Kaplonski > Senior software engineer > Red Hat > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev From fungi at yuggoth.org Mon Nov 19 00:04:03 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 19 Nov 2018 00:04:03 +0000 Subject: [Openstack-sigs] IMPORTANT: We're combining the lists! In-Reply-To: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> Message-ID: <20181119000403.xdl45y5ghkwndyor@yuggoth.org> REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From fungi at yuggoth.org Tue Nov 27 18:23:58 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 27 Nov 2018 18:23:58 +0000 Subject: [Openstack-sigs] IMPORTANT: We're combining the lists! In-Reply-To: <20181119000403.xdl45y5ghkwndyor@yuggoth.org> References: <20181109181447.qhutsauxl4fuinnh@yuggoth.org> <20181119000403.xdl45y5ghkwndyor@yuggoth.org> Message-ID: <20181127182358.hseunpye3wg37wzc@yuggoth.org> REMINDER: The openstack, openstack-dev, openstack-sigs and openstack-operators mailing lists (to which this was sent) are being replaced by a new openstack-discuss at 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: