From tobias.rydberg at citynetwork.eu Tue Oct 2 21:24:18 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Tue, 2 Oct 2018 23:24:18 +0200 Subject: [Openstack-sigs] [publiccloud-wg] Reminder weekly meeting Public Cloud WG Message-ID: Hi everyone, Time for a new meeting for PCWG - 3rd October 0700 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg Talk to you in a couple of hours! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED From majopela at redhat.com Tue Oct 9 07:17:35 2018 From: majopela at redhat.com (Miguel Angel Ajo Pelayo) Date: Tue, 9 Oct 2018 09:17:35 +0200 Subject: [Openstack-sigs] [SIGS] Ops Tools SIG Message-ID: Hello Yesterday, during the Oslo meeting we discussed [6] the possibility of creating a new Special Interest Group [1][2] to provide home and release means for operator related tools [3] [4] [5] I continued the discussion with M.Hillsman later, and he made me aware of the operator working group and mailing list, which existed even before the SIGs. I believe it could be a very good idea, to give life and more visibility to all those very useful tools (for example, I didn't know some of them existed ...). Give this, I have two questions: 1) Do you know or more tools which could find home under an Ops Tools SIG umbrella? 2) Do you want to join us? Best regards and have a great day. [1] https://governance.openstack.org/sigs/ [2] http://git.openstack.org/cgit/openstack/governance-sigs/tree/sigs.yaml [3] https://wiki.openstack.org/wiki/Osops [4] http://git.openstack.org/cgit/openstack/ospurge/tree/ [5] http://git.openstack.org/cgit/openstack/os-log-merger/tree/ [6] http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-10-08-15.00.log.html#l-130 -- Miguel Ángel Ajo OSP / Networking DFG, OVN Squad Engineering -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Wed Oct 10 10:18:18 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 10 Oct 2018 11:18:18 +0100 Subject: [Openstack-sigs] [scientific] IRC meeting: Parallel Filesystems, SIG meetups Message-ID: <1F483359-258B-4785-A3BF-524E7DF7F2A6@telfer.org> Hi All - We have a Scientific SIG IRC meeting coming up at 1100UTC in channel #openstack-meeting (about 45 minutes time). Everyone is welcome. Today’s agenda is available at: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_October_10th_2018 We’d like to gather latest experiences for using parallel filesystems in OpenStack environments - what works best and what performs? Also, we’ve got a round-up of SIG activities at a few events coming up. Cheers, Stig -------------- next part -------------- An HTML attachment was scrubbed... URL: From majopela at redhat.com Thu Oct 11 14:19:38 2018 From: majopela at redhat.com (Miguel Angel Ajo Pelayo) Date: Thu, 11 Oct 2018 16:19:38 +0200 Subject: [Openstack-sigs] [Openstack-operators] [SIGS] Ops Tools SIG In-Reply-To: <79A31C5A-F4C1-478E-AEE5-B9CB4693543F@gmail.com> References: <79A31C5A-F4C1-478E-AEE5-B9CB4693543F@gmail.com> Message-ID: Adding the mailing lists back to your reply, thank you :) I guess that +melvin.hillsman at huawei.com can help us a little bit organizing the SIG, but I guess the first thing would be collecting a list of tools which could be published under the umbrella of the SIG, starting by the ones already in Osops. Publishing documentation for those tools, and the catalog under docs.openstack.org is possibly the next step (or a parallel step). On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister wrote: > Hi Miguel, > > I would love to join this. What do I need to do? > > Sent from my iPhone > > On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo > wrote: > > Hello > > Yesterday, during the Oslo meeting we discussed [6] the possibility of > creating a new Special Interest Group [1][2] to provide home and release > means for operator related tools [3] [4] [5] > > I continued the discussion with M.Hillsman later, and he made me aware > of the operator working group and mailing list, which existed even before > the SIGs. > > I believe it could be a very good idea, to give life and more > visibility to all those very useful tools (for example, I didn't know some > of them existed ...). > > Give this, I have two questions: > > 1) Do you know or more tools which could find home under an Ops Tools > SIG umbrella? > > 2) Do you want to join us? > > > Best regards and have a great day. > > > [1] https://governance.openstack.org/sigs/ > [2] http://git.openstack.org/cgit/openstack/governance-sigs/tree/sigs.yaml > [3] https://wiki.openstack.org/wiki/Osops > [4] http://git.openstack.org/cgit/openstack/ospurge/tree/ > [5] http://git.openstack.org/cgit/openstack/os-log-merger/tree/ > [6] > http://eavesdrop.openstack.org/meetings/oslo/2018/oslo.2018-10-08-15.00.log.html#l-130 > > > > -- > Miguel Ángel Ajo > OSP / Networking DFG, OVN Squad Engineering > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Miguel Ángel Ajo OSP / Networking DFG, OVN Squad Engineering -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mcginnis at gmx.com Fri Oct 12 12:21:00 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Fri, 12 Oct 2018 07:21:00 -0500 Subject: [Openstack-sigs] [openstack-dev] [Openstack-operators] [SIGS] Ops Tools SIG In-Reply-To: References: <79A31C5A-F4C1-478E-AEE5-B9CB4693543F@gmail.com> Message-ID: <20181012122059.GB3532@sm-xps> On Fri, Oct 12, 2018 at 11:25:20AM +0200, Martin Magr wrote: > Greetings guys, > > On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo < > majopela at redhat.com> wrote: > > > Adding the mailing lists back to your reply, thank you :) > > > > I guess that +melvin.hillsman at huawei.com can > > help us a little bit organizing the SIG, > > but I guess the first thing would be collecting a list of tools which > > could be published > > under the umbrella of the SIG, starting by the ones already in Osops. > > > > Publishing documentation for those tools, and the catalog under > > docs.openstack.org > > is possibly the next step (or a parallel step). > > > > > > On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister > > wrote: > > > >> Hi Miguel, > >> > >> I would love to join this. What do I need to do? > >> > >> Sent from my iPhone > >> > >> On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo > >> wrote: > >> > >> Hello > >> > >> Yesterday, during the Oslo meeting we discussed [6] the possibility > >> of creating a new Special Interest Group [1][2] to provide home and release > >> means for operator related tools [3] [4] [5] > >> > >> > all of those tools have python dependencies related to openstack such as > python-openstackclient or python-pbr. Which is exactly the reason why we > moved osops-tools-monitoring-oschecks packaging away from OpsTools SIG to > Cloud SIG. AFAIR we had some issues of having opstools SIG being dependent > on openstack SIG. I believe that Cloud SIG is proper home for tools like > [3][4][5] as they are related to OpenStack anyway. OpsTools SIG contains > general tools like fluentd, sensu, collectd. > > > Hope this helps, > Martin > Hey Martin, I'm not sure I understand the issue with these tools have dependencies on other packages and the relationship to SIG ownership. Is your concern (or the history of a concern you are pointing out) that the tools would have a more difficult time if they required updates to dependencies if they are owned by a different group? Thanks! Sean From mmagr at redhat.com Fri Oct 12 09:25:20 2018 From: mmagr at redhat.com (Martin Magr) Date: Fri, 12 Oct 2018 11:25:20 +0200 Subject: [Openstack-sigs] [openstack-dev] [Openstack-operators] [SIGS] Ops Tools SIG In-Reply-To: References: <79A31C5A-F4C1-478E-AEE5-B9CB4693543F@gmail.com> Message-ID: Greetings guys, On Thu, Oct 11, 2018 at 4:19 PM, Miguel Angel Ajo Pelayo < majopela at redhat.com> wrote: > Adding the mailing lists back to your reply, thank you :) > > I guess that +melvin.hillsman at huawei.com can > help us a little bit organizing the SIG, > but I guess the first thing would be collecting a list of tools which > could be published > under the umbrella of the SIG, starting by the ones already in Osops. > > Publishing documentation for those tools, and the catalog under > docs.openstack.org > is possibly the next step (or a parallel step). > > > On Wed, Oct 10, 2018 at 4:43 PM Rob McAllister > wrote: > >> Hi Miguel, >> >> I would love to join this. What do I need to do? >> >> Sent from my iPhone >> >> On Oct 9, 2018, at 03:17, Miguel Angel Ajo Pelayo >> wrote: >> >> Hello >> >> Yesterday, during the Oslo meeting we discussed [6] the possibility >> of creating a new Special Interest Group [1][2] to provide home and release >> means for operator related tools [3] [4] [5] >> >> all of those tools have python dependencies related to openstack such as python-openstackclient or python-pbr. Which is exactly the reason why we moved osops-tools-monitoring-oschecks packaging away from OpsTools SIG to Cloud SIG. AFAIR we had some issues of having opstools SIG being dependent on openstack SIG. I believe that Cloud SIG is proper home for tools like [3][4][5] as they are related to OpenStack anyway. OpsTools SIG contains general tools like fluentd, sensu, collectd. Hope this helps, Martin > >> I continued the discussion with M.Hillsman later, and he made me >> aware of the operator working group and mailing list, which existed even >> before the SIGs. >> >> I believe it could be a very good idea, to give life and more >> visibility to all those very useful tools (for example, I didn't know some >> of them existed ...). >> >> Give this, I have two questions: >> >> 1) Do you know or more tools which could find home under an Ops Tools >> SIG umbrella? >> >> 2) Do you want to join us? >> >> >> Best regards and have a great day. >> >> >> [1] https://governance.openstack.org/sigs/ >> [2] http://git.openstack.org/cgit/openstack/governance- >> sigs/tree/sigs.yaml >> [3] https://wiki.openstack.org/wiki/Osops >> [4] http://git.openstack.org/cgit/openstack/ospurge/tree/ >> [5] http://git.openstack.org/cgit/openstack/os-log-merger/tree/ >> [6] http://eavesdrop.openstack.org/meetings/oslo/ >> 2018/oslo.2018-10-08-15.00.log.html#l-130 >> >> >> >> -- >> Miguel Ángel Ajo >> OSP / Networking DFG, OVN Squad Engineering >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > > -- > Miguel Ángel Ajo > OSP / Networking DFG, OVN Squad Engineering > > __________________________________________________________________________ > 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 > > -- Martin Mágr Senior Software Engineer Red Hat Czech -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.rydberg at citynetwork.eu Tue Oct 16 15:05:10 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Tue, 16 Oct 2018 17:05:10 +0200 Subject: [Openstack-sigs] [publiccloud-wg] Reminder weekly meeting Public Cloud WG Message-ID: <5c2a917d-2a77-b7da-46d5-9fb02c6018ba@citynetwork.eu> Hi everyone, Time for a new meeting for PCWG - tomorrow Wednesday 0700 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED From stig.openstack at telfer.org Tue Oct 16 19:52:18 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Tue, 16 Oct 2018 20:52:18 +0100 Subject: [Openstack-sigs] [scientific] IRC Meeting today 2100 UTC Message-ID: <34460CDA-89A1-4EEE-B52B-22621D5F3F9C@telfer.org> Hi All - We have a Scientific SIG IRC meeting today at 2100 UTC (about an hours time) in #openstack-meeting. Everyone is welcome. Today’s agenda (such as it is) can be found here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_October_16th_2018 Cheers, Stig From chengfeiyoiua at gmail.com Wed Oct 17 14:43:13 2018 From: chengfeiyoiua at gmail.com (TING PANG) Date: Wed, 17 Oct 2018 22:43:13 +0800 Subject: [Openstack-sigs] [security] A Security Project Proposal Message-ID: Dear all, As we all known, security has always been a hot topic among people. In OpenStack, if an attacker make a system un-trustworthy, it will make a risk for entire infrastructure and affect customers confidence. Fortunately, more and more vendors start providing security solutions with the trusted computing. It is a security technology based on a hardware trust format to improve system integrity and trustworthy. The risks and threats on cloud can be mitigated and managed with trusted computing technology, which can make a customer more confident when utilizing OpenStack. However, there are some mainstream trusted formats (e.g. TPM, TCM) and some special trusted formats provided by vendors (e.g. Google, Microsoft ) in the world, which cause huge development costs and interoperability issues for vendors to support various trusted formats. To resolve problems above, we want to create a new security project named "Hawthorn" that provides a general unified trust management framework to be compatible with different trust formats in OpenStack. More general information can be found here: *https://wiki.openstack.org/wiki/Hawthorn * Please feel free to contact me if you are interested in this proposal or have questions and suggestion. Best regards, Ting -------------- next part -------------- An HTML attachment was scrubbed... URL: From lhinds at redhat.com Wed Oct 17 15:24:39 2018 From: lhinds at redhat.com (Luke Hinds) Date: Wed, 17 Oct 2018 16:24:39 +0100 Subject: [Openstack-sigs] [security] A Security Project Proposal In-Reply-To: References: Message-ID: Hi Ting, Here's my thoughts on the topic / proposal. To jump straight to my main concern, I am sceptical of storing a 'trust state' in yet another API, especially for trusted compute, as we then need to trust an API and it's less secure (than a TPM) components (database, memory, disc etc). Up to present the trusted compute approach in OpenStack has been always been some type of API query to establish if a node can be 'trusted' and hooking that into nova's scheduler. One current approach being the traits API. The problem with this is that the stored state of 'trusted' is then on disc or volatile memory , typically a row in a mariaDB table somewhere on the controller - this then means we immediately lose all of the true attractiveness of a TPM, that being a tamper proof hardware route of trust , unlike an API which sets the 'trust state' in a datastore on disc or memory (which can be hacked to spoof trust). So I can't really comment on the current proposal or really get behind it, as its to vague at present in why it should provide unified trust and how we would trust it. On the face of it, this proposal appears to be another actor susceptible to the flaws outlined above. I would need to know how the above concern would be resolved, so that there is implicit hardware routed trust presented to the workload wanting a trusted node to schedule upon, without a go between actor hosting the trust state of compute nodes. Perhaps you have already solved this, if so I would recommend you outline it in your proposal. Best Regards, Luke On Wed, Oct 17, 2018 at 3:48 PM TING PANG wrote: > Dear all, > > As we all known, security has always been a hot topic among people. In > OpenStack, if an attacker make a system un-trustworthy, it will make a > risk for entire infrastructure and affect customers confidence. > Fortunately, more and more vendors start providing security solutions with > the trusted computing. It is a security technology based on a hardware > trust format to improve system integrity and trustworthy. The risks and > threats on cloud can be mitigated and managed with trusted computing > technology, which can make a customer more confident when utilizing > OpenStack. > > However, there are some mainstream trusted formats (e.g. TPM, TCM) and > some special trusted formats provided by vendors (e.g. Google, Microsoft ) > in the world, which cause huge development costs and interoperability > issues for vendors to support various trusted formats. > > To resolve problems above, we want to create a new security project named > "Hawthorn" that provides a general unified trust management framework to be > compatible with different trust formats in OpenStack. > > More general information can be found here: *https://wiki.openstack.org/wiki/Hawthorn > * > > Please feel free to contact me if you are interested in this proposal or > have questions and suggestion. > > Best regards, > > Ting > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mriedemos at gmail.com Wed Oct 17 15:41:36 2018 From: mriedemos at gmail.com (Matt Riedemann) Date: Wed, 17 Oct 2018 10:41:36 -0500 Subject: [Openstack-sigs] [openstack-dev] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps In-Reply-To: References: Message-ID: <45d48394-4605-5ea4-f14d-48c1422b54cc@gmail.com> On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote: > > As you may know, unfortunately, Horizon doesn't support all features > provided by APIs. That's why we created feature gaps list [1]. > > I'd got a lot of great conversations with projects teams during the PTG > and we tried to figure out what should be done prioritize these tasks. > It's really helpful for Horizon to get feedback from other teams to > understand what features should be implemented next. > > While I'm filling launchpad with new bugs and blueprints for [1], it > would be good to review this list again and find some volunteers to > decrease feature gaps. > > [1] https://etherpad.openstack.org/p/horizon-feature-gap > > Thanks everybody for any of your contributions to Horizon. +openstack-sigs +openstack-operators I've left some notes for nova. This looks very similar to the compute API OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what to really work on without some user/operator feedback - maybe we can get the user work group involved in trying to help prioritize what people really want that is missing from horizon, at least for compute? [1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc -- Thanks, Matt From tony at bakeyournoodle.com Thu Oct 18 06:35:39 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Thu, 18 Oct 2018 17:35:39 +1100 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack Message-ID: <20181018063539.GC6589@thor.bakeyournoodle.com> Hello all, As per [1] the nomination period for names for the T release have now closed (actually 3 days ago sorry). The nominated names and any qualifying remarks can be seen at2]. Proposed Names * Tarryall * Teakettle * Teller * Telluride * Thomas * Thornton * Tiger * Tincup * Timnath * Timber * Tiny Town * Torreys * Trail * Trinidad * Treasure * Troublesome * Trussville * Turret * Tyrone Proposed Names that do not meet the criteria * Train However I'd like to suggest we skip the CIVS poll and select 'Train' as the release name by TC resolution[3]. My think for this is * It's fun and celebrates a humorous moment in our community * As a developer I've heard the T release called Train for quite sometime, and was used often at the PTG[4]. * As the *next* PTG is also in Colorado we can still choose a geographic based name for U[5] * If train causes a problem for trademark reasons then we can always run the poll I'll leave[3] for marked -W for a week for discussion to happen before the TC can consider / vote on it. Yours Tony. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals [3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 [4] https://twitter.com/vkmc/status/1040321043959754752 [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From sean.mcginnis at gmx.com Thu Oct 18 12:21:57 2018 From: sean.mcginnis at gmx.com (Sean McGinnis) Date: Thu, 18 Oct 2018 07:21:57 -0500 Subject: [Openstack-sigs] [openstack-dev] [horizon][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps In-Reply-To: <45d48394-4605-5ea4-f14d-48c1422b54cc@gmail.com> References: <45d48394-4605-5ea4-f14d-48c1422b54cc@gmail.com> Message-ID: <20181018122157.GA3125@sm-workstation> On Wed, Oct 17, 2018 at 10:41:36AM -0500, Matt Riedemann wrote: > On 10/17/2018 9:24 AM, Ivan Kolodyazhny wrote: > > > > As you may know, unfortunately, Horizon doesn't support all features > > provided by APIs. That's why we created feature gaps list [1]. > > > > I'd got a lot of great conversations with projects teams during the PTG > > and we tried to figure out what should be done prioritize these tasks. > > It's really helpful for Horizon to get feedback from other teams to > > understand what features should be implemented next. > > > > While I'm filling launchpad with new bugs and blueprints for [1], it > > would be good to review this list again and find some volunteers to > > decrease feature gaps. > > > > [1] https://etherpad.openstack.org/p/horizon-feature-gap > > > > Thanks everybody for any of your contributions to Horizon. > > +openstack-sigs > +openstack-operators > > I've left some notes for nova. This looks very similar to the compute API > OSC gap analysis I did [1]. Unfortunately it's hard to prioritize what to > really work on without some user/operator feedback - maybe we can get the > user work group involved in trying to help prioritize what people really > want that is missing from horizon, at least for compute? > > [1] https://etherpad.openstack.org/p/compute-api-microversion-gap-in-osc > > -- > > Thanks, > > Matt I also have a cinderclient OSC gap analysis I've started working on. It might be useful to add a Horizon column to this list too. https://ethercalc.openstack.org/cinderclient-osc-gap Sean From dtantsur at redhat.com Thu Oct 18 14:23:17 2018 From: dtantsur at redhat.com (Dmitry Tantsur) Date: Thu, 18 Oct 2018 16:23:17 +0200 Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" Message-ID: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Hi all, Sorry for chiming in really late in this topic, but I think $subj is worth discussing until we settle harder on the potentially confusing terminology. I think the difference between "Edge" and "Far Edge" is too vague to use these terms in practice. Think about the "edge" metaphor itself: something rarely has several layers of edges. A knife has an edge, there are no far edges. I imagine zooming in and seeing more edges at the edge, and then it's quite cool indeed, but is it really a useful metaphor for those who never used a strong microscope? :) I think in the trivial sense "Far Edge" is a tautology, and should be avoided. As a weak proof of my words, I already see a lot of smart people confusing these two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we adopt a different terminology, even if it less consistent with typical marketing term around the "Edge" movement. Now, I don't have really great suggestions. Something that came up in TripleO discussions [1] is Core/Hub/Edge, which I think reflects the idea better. I'd be very interested to hear your ideas. Dmitry [1] https://etherpad.openstack.org/p/tripleo-edge-mvp From Arkady.Kanevsky at dell.com Thu Oct 18 14:33:41 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Thu, 18 Oct 2018 14:33:41 +0000 Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Message-ID: <2262e154f7a940368d8aff5c55b579f1@AUSX13MPS308.AMER.DELL.COM> Love the idea to have clearer terminology. Suggest we let telco folks to suggest terminology to use. This is not a 3 level hierarchy but much more. There are several layers of aggregation from local to metro, to regional, to DC. And potential multiple layers in each. -----Original Message----- From: Dmitry Tantsur Sent: Thursday, October 18, 2018 9:23 AM To: OpenStack Development Mailing List (not for usage questions); openstack-sigs at lists.openstack.org Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" [EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information. Hi all, Sorry for chiming in really late in this topic, but I think $subj is worth discussing until we settle harder on the potentially confusing terminology. I think the difference between "Edge" and "Far Edge" is too vague to use these terms in practice. Think about the "edge" metaphor itself: something rarely has several layers of edges. A knife has an edge, there are no far edges. I imagine zooming in and seeing more edges at the edge, and then it's quite cool indeed, but is it really a useful metaphor for those who never used a strong microscope? :) I think in the trivial sense "Far Edge" is a tautology, and should be avoided. As a weak proof of my words, I already see a lot of smart people confusing these two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we adopt a different terminology, even if it less consistent with typical marketing term around the "Edge" movement. Now, I don't have really great suggestions. Something that came up in TripleO discussions [1] is Core/Hub/Edge, which I think reflects the idea better. I'd be very interested to hear your ideas. Dmitry [1] https://etherpad.openstack.org/p/tripleo-edge-mvp _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs From bdobreli at redhat.com Thu Oct 18 14:40:19 2018 From: bdobreli at redhat.com (Bogdan Dobrelya) Date: Thu, 18 Oct 2018 16:40:19 +0200 Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: <2262e154f7a940368d8aff5c55b579f1@AUSX13MPS308.AMER.DELL.COM> References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> <2262e154f7a940368d8aff5c55b579f1@AUSX13MPS308.AMER.DELL.COM> Message-ID: <711be4b1-8ace-8e7c-d650-37f30ca03395@redhat.com> On 10/18/18 4:33 PM, Arkady.Kanevsky at dell.com wrote: > Love the idea to have clearer terminology. > Suggest we let telco folks to suggest terminology to use. > This is not a 3 level hierarchy but much more. > There are several layers of aggregation from local to metro, to regional, to DC. And potential multiple layers in each. > > -----Original Message----- > From: Dmitry Tantsur > Sent: Thursday, October 18, 2018 9:23 AM > To: OpenStack Development Mailing List (not for usage questions); openstack-sigs at lists.openstack.org > Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" > > > [EXTERNAL EMAIL] > Please report any suspicious attachments, links, or requests for sensitive information. > > > Hi all, > > Sorry for chiming in really late in this topic, but I think $subj is worth > discussing until we settle harder on the potentially confusing terminology. > > I think the difference between "Edge" and "Far Edge" is too vague to use these > terms in practice. Think about the "edge" metaphor itself: something rarely has > several layers of edges. A knife has an edge, there are no far edges. I imagine > zooming in and seeing more edges at the edge, and then it's quite cool indeed, > but is it really a useful metaphor for those who never used a strong microscope? :) > > I think in the trivial sense "Far Edge" is a tautology, and should be avoided. > As a weak proof of my words, I already see a lot of smart people confusing these > two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we > adopt a different terminology, even if it less consistent with typical marketing > term around the "Edge" movement. > > Now, I don't have really great suggestions. Something that came up in TripleO > discussions [1] is Core/Hub/Edge, which I think reflects the idea better. > > I'd be very interested to hear your ideas. Similarly to NUMA distance is equal to the shortest path between the NUMA nodes, we could think of edges as facets and Edge distance as the shortest path between edge sites, counting from the central Edge (distance 0), or central Edges, if we have those decentralized and there is no a single central Edge? > > Dmitry > > [1] https://etherpad.openstack.org/p/tripleo-edge-mvp > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > -- Best regards, Bogdan Dobrelya, Irc #bogdando From openstack at medberry.net Thu Oct 18 15:39:13 2018 From: openstack at medberry.net (David Medberry) Date: Thu, 18 Oct 2018 09:39:13 -0600 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack In-Reply-To: <20181018063539.GC6589@thor.bakeyournoodle.com> References: <20181018063539.GC6589@thor.bakeyournoodle.com> Message-ID: I'm fine with Train but I'm also fine with just adding it to the list and voting on it. It will win. Also, for those not familiar with the debian/ubuntu command "sl", now is the time to become so. apt install sl sl -Flea #ftw On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds wrote: > Hello all, > As per [1] the nomination period for names for the T release have > now closed (actually 3 days ago sorry). The nominated names and any > qualifying remarks can be seen at2]. > > Proposed Names > * Tarryall > * Teakettle > * Teller > * Telluride > * Thomas > * Thornton > * Tiger > * Tincup > * Timnath > * Timber > * Tiny Town > * Torreys > * Trail > * Trinidad > * Treasure > * Troublesome > * Trussville > * Turret > * Tyrone > > Proposed Names that do not meet the criteria > * Train > > However I'd like to suggest we skip the CIVS poll and select 'Train' as > the release name by TC resolution[3]. My think for this is > > * It's fun and celebrates a humorous moment in our community > * As a developer I've heard the T release called Train for quite > sometime, and was used often at the PTG[4]. > * As the *next* PTG is also in Colorado we can still choose a > geographic based name for U[5] > * If train causes a problem for trademark reasons then we can always > run the poll > > I'll leave[3] for marked -W for a week for discussion to happen before the > TC can consider / vote on it. > > Yours Tony. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html > [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals > [3] > https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 > [4] https://twitter.com/vkmc/status/1040321043959754752 > [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z > _______________________________________________ > 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 openstack at medberry.net Thu Oct 18 15:41:16 2018 From: openstack at medberry.net (David Medberry) Date: Thu, 18 Oct 2018 09:41:16 -0600 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack In-Reply-To: References: <20181018063539.GC6589@thor.bakeyournoodle.com> Message-ID: and any talks I give in Denver (Forum, Ops, Main) will include "sl". It's handy in a variety of ways. On Thu, Oct 18, 2018 at 9:39 AM David Medberry wrote: > I'm fine with Train but I'm also fine with just adding it to the list and > voting on it. It will win. > > Also, for those not familiar with the debian/ubuntu command "sl", now is > the time to become so. > > apt install sl > sl -Flea #ftw > > On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds > wrote: > >> Hello all, >> As per [1] the nomination period for names for the T release have >> now closed (actually 3 days ago sorry). The nominated names and any >> qualifying remarks can be seen at2]. >> >> Proposed Names >> * Tarryall >> * Teakettle >> * Teller >> * Telluride >> * Thomas >> * Thornton >> * Tiger >> * Tincup >> * Timnath >> * Timber >> * Tiny Town >> * Torreys >> * Trail >> * Trinidad >> * Treasure >> * Troublesome >> * Trussville >> * Turret >> * Tyrone >> >> Proposed Names that do not meet the criteria >> * Train >> >> However I'd like to suggest we skip the CIVS poll and select 'Train' as >> the release name by TC resolution[3]. My think for this is >> >> * It's fun and celebrates a humorous moment in our community >> * As a developer I've heard the T release called Train for quite >> sometime, and was used often at the PTG[4]. >> * As the *next* PTG is also in Colorado we can still choose a >> geographic based name for U[5] >> * If train causes a problem for trademark reasons then we can always >> run the poll >> >> I'll leave[3] for marked -W for a week for discussion to happen before the >> TC can consider / vote on it. >> >> Yours Tony. >> >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html >> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals >> [3] >> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 >> [4] https://twitter.com/vkmc/status/1040321043959754752 >> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z >> _______________________________________________ >> 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 jonmills at gmail.com Thu Oct 18 15:49:14 2018 From: jonmills at gmail.com (Jonathan Mills) Date: Thu, 18 Oct 2018 11:49:14 -0400 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack In-Reply-To: References: <20181018063539.GC6589@thor.bakeyournoodle.com> Message-ID: +1 for just having a poll On Thu, Oct 18, 2018 at 11:39 AM David Medberry wrote: > I'm fine with Train but I'm also fine with just adding it to the list and > voting on it. It will win. > > Also, for those not familiar with the debian/ubuntu command "sl", now is > the time to become so. > > apt install sl > sl -Flea #ftw > > On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds > wrote: > >> Hello all, >> As per [1] the nomination period for names for the T release have >> now closed (actually 3 days ago sorry). The nominated names and any >> qualifying remarks can be seen at2]. >> >> Proposed Names >> * Tarryall >> * Teakettle >> * Teller >> * Telluride >> * Thomas >> * Thornton >> * Tiger >> * Tincup >> * Timnath >> * Timber >> * Tiny Town >> * Torreys >> * Trail >> * Trinidad >> * Treasure >> * Troublesome >> * Trussville >> * Turret >> * Tyrone >> >> Proposed Names that do not meet the criteria >> * Train >> >> However I'd like to suggest we skip the CIVS poll and select 'Train' as >> the release name by TC resolution[3]. My think for this is >> >> * It's fun and celebrates a humorous moment in our community >> * As a developer I've heard the T release called Train for quite >> sometime, and was used often at the PTG[4]. >> * As the *next* PTG is also in Colorado we can still choose a >> geographic based name for U[5] >> * If train causes a problem for trademark reasons then we can always >> run the poll >> >> I'll leave[3] for marked -W for a week for discussion to happen before the >> TC can consider / vote on it. >> >> Yours Tony. >> >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html >> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals >> [3] >> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 >> [4] https://twitter.com/vkmc/status/1040321043959754752 >> [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > _______________________________________________ > 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 Arkady.Kanevsky at dell.com Thu Oct 18 15:52:17 2018 From: Arkady.Kanevsky at dell.com (Arkady.Kanevsky at dell.com) Date: Thu, 18 Oct 2018 15:52:17 +0000 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack In-Reply-To: References: <20181018063539.GC6589@thor.bakeyournoodle.com> Message-ID: <4b02964cfa8a43b29a11d98a6606ccd6@AUSX13MPS308.AMER.DELL.COM> +1 for the poll. Let’s follow well established process. If we want to add Train as one of the options for the name I am OK with it. From: Jonathan Mills Sent: Thursday, October 18, 2018 10:49 AM To: openstack-sigs at lists.openstack.org Subject: Re: [Openstack-sigs] [all] Naming the T release of OpenStack [EXTERNAL EMAIL] Please report any suspicious attachments, links, or requests for sensitive information. +1 for just having a poll On Thu, Oct 18, 2018 at 11:39 AM David Medberry > wrote: I'm fine with Train but I'm also fine with just adding it to the list and voting on it. It will win. Also, for those not familiar with the debian/ubuntu command "sl", now is the time to become so. apt install sl sl -Flea #ftw On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds > wrote: Hello all, As per [1] the nomination period for names for the T release have now closed (actually 3 days ago sorry). The nominated names and any qualifying remarks can be seen at2]. Proposed Names * Tarryall * Teakettle * Teller * Telluride * Thomas * Thornton * Tiger * Tincup * Timnath * Timber * Tiny Town * Torreys * Trail * Trinidad * Treasure * Troublesome * Trussville * Turret * Tyrone Proposed Names that do not meet the criteria * Train However I'd like to suggest we skip the CIVS poll and select 'Train' as the release name by TC resolution[3]. My think for this is * It's fun and celebrates a humorous moment in our community * As a developer I've heard the T release called Train for quite sometime, and was used often at the PTG[4]. * As the *next* PTG is also in Colorado we can still choose a geographic based name for U[5] * If train causes a problem for trademark reasons then we can always run the poll I'll leave[3] for marked -W for a week for discussion to happen before the TC can consider / vote on it. Yours Tony. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals [3] https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 [4] https://twitter.com/vkmc/status/1040321043959754752 [5] https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z _______________________________________________ openstack-sigs mailing list openstack-sigs at lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs _______________________________________________ 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 jim at jimrollenhagen.com Thu Oct 18 15:55:02 2018 From: jim at jimrollenhagen.com (Jim Rollenhagen) Date: Thu, 18 Oct 2018 11:55:02 -0400 Subject: [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Message-ID: On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur wrote: > Hi all, > > Sorry for chiming in really late in this topic, but I think $subj is worth > discussing until we settle harder on the potentially confusing terminology. > > I think the difference between "Edge" and "Far Edge" is too vague to use > these > terms in practice. Think about the "edge" metaphor itself: something > rarely has > several layers of edges. A knife has an edge, there are no far edges. I > imagine > zooming in and seeing more edges at the edge, and then it's quite cool > indeed, > but is it really a useful metaphor for those who never used a strong > microscope? :) > > I think in the trivial sense "Far Edge" is a tautology, and should be > avoided. > As a weak proof of my words, I already see a lot of smart people confusing > these > two and actually use Central/Edge where they mean Edge/Far Edge. I suggest > we > adopt a different terminology, even if it less consistent with typical > marketing > term around the "Edge" movement. > FWIW, we created rough definitions of "edge" and "far edge" during the edge WG session in Denver. It's mostly based on latency to the end user, though we also talked about quantities of compute resources, if someone can find the pictures. See the picture and table here: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview > > Now, I don't have really great suggestions. Something that came up in > TripleO > discussions [1] is Core/Hub/Edge, which I think reflects the idea better. > I'm also fine with these names, as they do describe the concepts well. :) // jim > I'd be very interested to hear your ideas. > > Dmitry > > [1] https://etherpad.openstack.org/p/tripleo-edge-mvp > > _______________________________________________ > 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 openstack at fried.cc Thu Oct 18 16:43:33 2018 From: openstack at fried.cc (Eric Fried) Date: Thu, 18 Oct 2018 11:43:33 -0500 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack In-Reply-To: <4b02964cfa8a43b29a11d98a6606ccd6@AUSX13MPS308.AMER.DELL.COM> References: <20181018063539.GC6589@thor.bakeyournoodle.com> <4b02964cfa8a43b29a11d98a6606ccd6@AUSX13MPS308.AMER.DELL.COM> Message-ID: <6befdfa3-66ef-2e2d-1d9a-b1ba01f19b79@fried.cc> Sorry, I'm opposed to this idea. I admit I don't understand the political framework, nor have I read the governing documents beyond [1], but that document makes it clear that this is supposed to be a community-wide vote. Is it really legal for the TC (or whoever has merge rights on [2]) to merge a patch that gives that same body the power to take the decision out of the hands of the community? So it's really an oligarchy that gives its constituency the illusion of democracy until something comes up that it feels like not having a vote on? The fact that it's something relatively "unimportant" (this time) is not a comfort. Not that I think the TC would necessarily move forward with [2] in the face of substantial opposition from non-TC "cores" or whatever. I will vote enthusiastically for "Train". But a vote it should be. -efried [1] https://governance.openstack.org/tc/reference/release-naming.html [2] https://review.openstack.org/#/c/611511/ On 10/18/2018 10:52 AM, Arkady.Kanevsky at dell.com wrote: > +1 for the poll. > > Let’s follow well established process. > > If we want to add Train as one of the options for the name I am OK with it. > >   > > *From:* Jonathan Mills > *Sent:* Thursday, October 18, 2018 10:49 AM > *To:* openstack-sigs at lists.openstack.org > *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack > >   > > [EXTERNAL EMAIL] > Please report any suspicious attachments, links, or requests for > sensitive information. > > +1 for just having a poll > >   > > On Thu, Oct 18, 2018 at 11:39 AM David Medberry > wrote: > > I'm fine with Train but I'm also fine with just adding it to the > list and voting on it. It will win. > >   > > Also, for those not familiar with the debian/ubuntu command "sl", > now is the time to become so. > >   > > apt install sl > > sl -Flea #ftw > >   > > On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds > > wrote: > > Hello all, >     As per [1] the nomination period for names for the T release > have > now closed (actually 3 days ago sorry).  The nominated names and any > qualifying remarks can be seen at2]. > > Proposed Names >  * Tarryall >  * Teakettle >  * Teller >  * Telluride >  * Thomas >  * Thornton >  * Tiger >  * Tincup >  * Timnath >  * Timber >  * Tiny Town >  * Torreys >  * Trail >  * Trinidad >  * Treasure >  * Troublesome >  * Trussville >  * Turret >  * Tyrone > > Proposed Names that do not meet the criteria >  * Train > > However I'd like to suggest we skip the CIVS poll and select > 'Train' as > the release name by TC resolution[3].  My think for this is > >  * It's fun and celebrates a humorous moment in our community >  * As a developer I've heard the T release called Train for quite >    sometime, and was used often at the PTG[4]. >  * As the *next* PTG is also in Colorado we can still choose a >    geographic based name for U[5] >  * If train causes a problem for trademark reasons then we can > always >    run the poll > > I'll leave[3] for marked -W for a week for discussion to happen > before the > TC can consider / vote on it. > > Yours Tony. > > [1] > http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html > [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals > [3] > https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 > [4] https://twitter.com/vkmc/status/1040321043959754752 > [5] > https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > > > _______________________________________________ > openstack-sigs mailing list > openstack-sigs at lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > From remo at rm.ht Thu Oct 18 17:08:12 2018 From: remo at rm.ht (Remo Mattei) Date: Thu, 18 Oct 2018 10:08:12 -0700 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack In-Reply-To: <6befdfa3-66ef-2e2d-1d9a-b1ba01f19b79@fried.cc> References: <20181018063539.GC6589@thor.bakeyournoodle.com> <4b02964cfa8a43b29a11d98a6606ccd6@AUSX13MPS308.AMER.DELL.COM> <6befdfa3-66ef-2e2d-1d9a-b1ba01f19b79@fried.cc> Message-ID: <78F870CF-14EA-4BC5-BA97-FF0D871ED141@rm.ht> Michal, that will never work it’s 11 characters long > On Oct 18, 2018, at 09:43, Eric Fried wrote: > > Sorry, I'm opposed to this idea. > > I admit I don't understand the political framework, nor have I read the > governing documents beyond [1], but that document makes it clear that > this is supposed to be a community-wide vote. Is it really legal for > the TC (or whoever has merge rights on [2]) to merge a patch that gives > that same body the power to take the decision out of the hands of the > community? So it's really an oligarchy that gives its constituency the > illusion of democracy until something comes up that it feels like not > having a vote on? The fact that it's something relatively "unimportant" > (this time) is not a comfort. > > Not that I think the TC would necessarily move forward with [2] in the > face of substantial opposition from non-TC "cores" or whatever. > > I will vote enthusiastically for "Train". But a vote it should be. > > -efried > > [1] https://governance.openstack.org/tc/reference/release-naming.html > [2] https://review.openstack.org/#/c/611511/ > > On 10/18/2018 10:52 AM, Arkady.Kanevsky at dell.com wrote: >> +1 for the poll. >> >> Let’s follow well established process. >> >> If we want to add Train as one of the options for the name I am OK with it. >> >> >> >> *From:* Jonathan Mills >> *Sent:* Thursday, October 18, 2018 10:49 AM >> *To:* openstack-sigs at lists.openstack.org >> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack >> >> >> >> [EXTERNAL EMAIL] >> Please report any suspicious attachments, links, or requests for >> sensitive information. >> >> +1 for just having a poll >> >> >> >> On Thu, Oct 18, 2018 at 11:39 AM David Medberry > >> wrote: >> >> I'm fine with Train but I'm also fine with just adding it to the >> list and voting on it. It will win. >> >> >> >> Also, for those not familiar with the debian/ubuntu command "sl", >> now is the time to become so. >> >> >> >> apt install sl >> >> sl -Flea #ftw >> >> >> >> On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds >> >> wrote: >> >> Hello all, >> As per [1] the nomination period for names for the T release >> have >> now closed (actually 3 days ago sorry). The nominated names and any >> qualifying remarks can be seen at2]. >> >> Proposed Names >> * Tarryall >> * Teakettle >> * Teller >> * Telluride >> * Thomas >> * Thornton >> * Tiger >> * Tincup >> * Timnath >> * Timber >> * Tiny Town >> * Torreys >> * Trail >> * Trinidad >> * Treasure >> * Troublesome >> * Trussville >> * Turret >> * Tyrone >> >> Proposed Names that do not meet the criteria >> * Train >> >> However I'd like to suggest we skip the CIVS poll and select >> 'Train' as >> the release name by TC resolution[3]. My think for this is >> >> * It's fun and celebrates a humorous moment in our community >> * As a developer I've heard the T release called Train for quite >> sometime, and was used often at the PTG[4]. >> * As the *next* PTG is also in Colorado we can still choose a >> geographic based name for U[5] >> * If train causes a problem for trademark reasons then we can >> always >> run the poll >> >> I'll leave[3] for marked -W for a week for discussion to happen >> before the >> TC can consider / vote on it. >> >> Yours Tony. >> >> [1] >> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html >> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals >> [3] >> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 >> [4] https://twitter.com/vkmc/status/1040321043959754752 >> [5] >> https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z >> > >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> >> >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > _______________________________________________ > 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 jim at jimrollenhagen.com Thu Oct 18 21:43:29 2018 From: jim at jimrollenhagen.com (Jim Rollenhagen) Date: Thu, 18 Oct 2018 17:43:29 -0400 Subject: [Openstack-sigs] [openstack-dev] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Message-ID: On Thu, Oct 18, 2018 at 4:45 PM John Fulton wrote: > On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen > wrote: > > > > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur > wrote: > >> > >> Hi all, > >> > >> Sorry for chiming in really late in this topic, but I think $subj is > worth > >> discussing until we settle harder on the potentially confusing > terminology. > >> > >> I think the difference between "Edge" and "Far Edge" is too vague to > use these > >> terms in practice. Think about the "edge" metaphor itself: something > rarely has > >> several layers of edges. A knife has an edge, there are no far edges. I > imagine > >> zooming in and seeing more edges at the edge, and then it's quite cool > indeed, > >> but is it really a useful metaphor for those who never used a strong > microscope? :) > >> > >> I think in the trivial sense "Far Edge" is a tautology, and should be > avoided. > >> As a weak proof of my words, I already see a lot of smart people > confusing these > >> two and actually use Central/Edge where they mean Edge/Far Edge. I > suggest we > >> adopt a different terminology, even if it less consistent with typical > marketing > >> term around the "Edge" movement. > > > > > > FWIW, we created rough definitions of "edge" and "far edge" during the > edge WG session in Denver. > > It's mostly based on latency to the end user, though we also talked > about quantities of compute resources, if someone can find the pictures. > > Perhaps these are the pictures Jim was referring to? > > https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0# That's it, thank you! // jim > > > I'm involved in some TripleO work called the split control plane: > > https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html > > After the PTG I saw that the split control plane was compatible with > the type of deployment discussed at the edge WG session in Denver and > described the compatibility at: > > https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane > > > See the picture and table here: > https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview > > > >> Now, I don't have really great suggestions. Something that came up in > TripleO > >> discussions [1] is Core/Hub/Edge, which I think reflects the idea > better. > > > > > > I'm also fine with these names, as they do describe the concepts well. :) > > > > // jim > > I'm fine with these terms too. In split control plane there's a > deployment method for deploying a central site and then deploying > remote sites independently. That deployment method could be used to > deploy Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack > N. Deploy a Hub using stack N+1 and then deploy an Edge using stack > N+2 etc. > > John > > >> > >> I'd be very interested to hear your ideas. > >> > >> Dmitry > >> > >> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp > >> > >> _______________________________________________ > >> openstack-sigs mailing list > >> openstack-sigs at lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > > > > __________________________________________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From skaplons at redhat.com Thu Oct 18 20:10:48 2018 From: skaplons at redhat.com (Slawomir Kaplonski) Date: Thu, 18 Oct 2018 22:10:48 +0200 Subject: [Openstack-sigs] [openstack-dev] [all] Naming the T release of OpenStack In-Reply-To: <78F870CF-14EA-4BC5-BA97-FF0D871ED141@rm.ht> References: <20181018063539.GC6589@thor.bakeyournoodle.com> <4b02964cfa8a43b29a11d98a6606ccd6@AUSX13MPS308.AMER.DELL.COM> <6befdfa3-66ef-2e2d-1d9a-b1ba01f19b79@fried.cc> <78F870CF-14EA-4BC5-BA97-FF0D871ED141@rm.ht> Message-ID: > Wiadomość napisana przez Remo Mattei w dniu 18.10.2018, o godz. 19:08: > > Michal, that will never work it’s 11 characters long Shorter could be Openstack Trouble ;) > > > > >> On Oct 18, 2018, at 09:43, Eric Fried wrote: >> >> Sorry, I'm opposed to this idea. >> >> I admit I don't understand the political framework, nor have I read the >> governing documents beyond [1], but that document makes it clear that >> this is supposed to be a community-wide vote. Is it really legal for >> the TC (or whoever has merge rights on [2]) to merge a patch that gives >> that same body the power to take the decision out of the hands of the >> community? So it's really an oligarchy that gives its constituency the >> illusion of democracy until something comes up that it feels like not >> having a vote on? The fact that it's something relatively "unimportant" >> (this time) is not a comfort. >> >> Not that I think the TC would necessarily move forward with [2] in the >> face of substantial opposition from non-TC "cores" or whatever. >> >> I will vote enthusiastically for "Train". But a vote it should be. >> >> -efried >> >> [1] https://governance.openstack.org/tc/reference/release-naming.html >> [2] https://review.openstack.org/#/c/611511/ >> >> On 10/18/2018 10:52 AM, Arkady.Kanevsky at dell.com wrote: >>> +1 for the poll. >>> >>> Let’s follow well established process. >>> >>> If we want to add Train as one of the options for the name I am OK with it. >>> >>> >>> >>> *From:* Jonathan Mills >>> *Sent:* Thursday, October 18, 2018 10:49 AM >>> *To:* openstack-sigs at lists.openstack.org >>> *Subject:* Re: [Openstack-sigs] [all] Naming the T release of OpenStack >>> >>> >>> >>> [EXTERNAL EMAIL] >>> Please report any suspicious attachments, links, or requests for >>> sensitive information. >>> >>> +1 for just having a poll >>> >>> >>> >>> On Thu, Oct 18, 2018 at 11:39 AM David Medberry >> > wrote: >>> >>> I'm fine with Train but I'm also fine with just adding it to the >>> list and voting on it. It will win. >>> >>> >>> >>> Also, for those not familiar with the debian/ubuntu command "sl", >>> now is the time to become so. >>> >>> >>> >>> apt install sl >>> >>> sl -Flea #ftw >>> >>> >>> >>> On Thu, Oct 18, 2018 at 12:35 AM Tony Breeds >>> > wrote: >>> >>> Hello all, >>> As per [1] the nomination period for names for the T release >>> have >>> now closed (actually 3 days ago sorry). The nominated names and any >>> qualifying remarks can be seen at2]. >>> >>> Proposed Names >>> * Tarryall >>> * Teakettle >>> * Teller >>> * Telluride >>> * Thomas >>> * Thornton >>> * Tiger >>> * Tincup >>> * Timnath >>> * Timber >>> * Tiny Town >>> * Torreys >>> * Trail >>> * Trinidad >>> * Treasure >>> * Troublesome >>> * Trussville >>> * Turret >>> * Tyrone >>> >>> Proposed Names that do not meet the criteria >>> * Train >>> >>> However I'd like to suggest we skip the CIVS poll and select >>> 'Train' as >>> the release name by TC resolution[3]. My think for this is >>> >>> * It's fun and celebrates a humorous moment in our community >>> * As a developer I've heard the T release called Train for quite >>> sometime, and was used often at the PTG[4]. >>> * As the *next* PTG is also in Colorado we can still choose a >>> geographic based name for U[5] >>> * If train causes a problem for trademark reasons then we can >>> always >>> run the poll >>> >>> I'll leave[3] for marked -W for a week for discussion to happen >>> before the >>> TC can consider / vote on it. >>> >>> Yours Tony. >>> >>> [1] >>> http://lists.openstack.org/pipermail/openstack-dev/2018-September/134995.html >>> [2] https://wiki.openstack.org/wiki/Release_Naming/T_Proposals >>> [3] >>> https://review.openstack.org/#/q/I0d8d3f24af0ee8578712878a3d6617aad1e55e53 >>> [4] https://twitter.com/vkmc/status/1040321043959754752 >>> [5] >>> https://en.wikipedia.org/wiki/List_of_places_in_Colorado:_T–Z >>> >>> _______________________________________________ >>> openstack-sigs mailing list >>> openstack-sigs at lists.openstack.org >>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> >>> _______________________________________________ >>> openstack-sigs mailing list >>> openstack-sigs at lists.openstack.org >>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> >>> >>> >>> _______________________________________________ >>> openstack-sigs mailing list >>> openstack-sigs at lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >>> >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > __________________________________________________________________________ > 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 johfulto at redhat.com Thu Oct 18 20:45:09 2018 From: johfulto at redhat.com (John Fulton) Date: Thu, 18 Oct 2018 16:45:09 -0400 Subject: [Openstack-sigs] [openstack-dev] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Message-ID: On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen wrote: > > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur wrote: >> >> Hi all, >> >> Sorry for chiming in really late in this topic, but I think $subj is worth >> discussing until we settle harder on the potentially confusing terminology. >> >> I think the difference between "Edge" and "Far Edge" is too vague to use these >> terms in practice. Think about the "edge" metaphor itself: something rarely has >> several layers of edges. A knife has an edge, there are no far edges. I imagine >> zooming in and seeing more edges at the edge, and then it's quite cool indeed, >> but is it really a useful metaphor for those who never used a strong microscope? :) >> >> I think in the trivial sense "Far Edge" is a tautology, and should be avoided. >> As a weak proof of my words, I already see a lot of smart people confusing these >> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we >> adopt a different terminology, even if it less consistent with typical marketing >> term around the "Edge" movement. > > > FWIW, we created rough definitions of "edge" and "far edge" during the edge WG session in Denver. > It's mostly based on latency to the end user, though we also talked about quantities of compute resources, if someone can find the pictures. Perhaps these are the pictures Jim was referring to? https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0# I'm involved in some TripleO work called the split control plane: https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html After the PTG I saw that the split control plane was compatible with the type of deployment discussed at the edge WG session in Denver and described the compatibility at: https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane > See the picture and table here: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview > >> Now, I don't have really great suggestions. Something that came up in TripleO >> discussions [1] is Core/Hub/Edge, which I think reflects the idea better. > > > I'm also fine with these names, as they do describe the concepts well. :) > > // jim I'm fine with these terms too. In split control plane there's a deployment method for deploying a central site and then deploying remote sites independently. That deployment method could be used to deploy Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack N. Deploy a Hub using stack N+1 and then deploy an Edge using stack N+2 etc. John >> >> I'd be very interested to hear your ideas. >> >> Dmitry >> >> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > __________________________________________________________________________ > 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 gergely.csatari at nokia.com Fri Oct 19 08:05:24 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Fri, 19 Oct 2018 08:05:24 +0000 Subject: [Openstack-sigs] [openstack-dev] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Message-ID: Hi, I’m adding the ECG mailing list to the discussion. I think the root of the problem is that there is no single definition of „the edge” (except for [1]), but it changes from group to group or use case to use case. What I recognise as the commonalities in these edge definitions, are 1) a distributed cloud infrastructure (kind of a cloud of clouds) 2) need for automation or everything 3) resource constraints for the control plane. The different edge variants are putting different emphasis on these common needs based ont he use case discussed. To have a more clear understanding of these definitions we could try the following: 1. Always add the definition of these to the given context 2. Check what other groups are using and adopt to that 3. Define our own language and expect everyone else to adopt Br, Gerg0 [1]: https://en.wikipedia.org/wiki/The_Edge From: Jim Rollenhagen Sent: Thursday, October 18, 2018 11:43 PM To: fulton at redhat.com; OpenStack Development Mailing List (not for usage questions) Cc: openstack-sigs at lists.openstack.org Subject: Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" On Thu, Oct 18, 2018 at 4:45 PM John Fulton > wrote: On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen > wrote: > > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur > wrote: >> >> Hi all, >> >> Sorry for chiming in really late in this topic, but I think $subj is worth >> discussing until we settle harder on the potentially confusing terminology. >> >> I think the difference between "Edge" and "Far Edge" is too vague to use these >> terms in practice. Think about the "edge" metaphor itself: something rarely has >> several layers of edges. A knife has an edge, there are no far edges. I imagine >> zooming in and seeing more edges at the edge, and then it's quite cool indeed, >> but is it really a useful metaphor for those who never used a strong microscope? :) >> >> I think in the trivial sense "Far Edge" is a tautology, and should be avoided. >> As a weak proof of my words, I already see a lot of smart people confusing these >> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we >> adopt a different terminology, even if it less consistent with typical marketing >> term around the "Edge" movement. > > > FWIW, we created rough definitions of "edge" and "far edge" during the edge WG session in Denver. > It's mostly based on latency to the end user, though we also talked about quantities of compute resources, if someone can find the pictures. Perhaps these are the pictures Jim was referring to? https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0# That's it, thank you! // jim I'm involved in some TripleO work called the split control plane: https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html After the PTG I saw that the split control plane was compatible with the type of deployment discussed at the edge WG session in Denver and described the compatibility at: https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane > See the picture and table here: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview > >> Now, I don't have really great suggestions. Something that came up in TripleO >> discussions [1] is Core/Hub/Edge, which I think reflects the idea better. > > > I'm also fine with these names, as they do describe the concepts well. :) > > // jim I'm fine with these terms too. In split control plane there's a deployment method for deploying a central site and then deploying remote sites independently. That deployment method could be used to deploy Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack N. Deploy a Hub using stack N+1 and then deploy an Edge using stack N+2 etc. John >> >> I'd be very interested to hear your ideas. >> >> Dmitry >> >> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > __________________________________________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Fri Oct 19 09:54:29 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Fri, 19 Oct 2018 20:54:29 +1100 Subject: [Openstack-sigs] [all] Naming the T release of OpenStack In-Reply-To: <20181018063539.GC6589@thor.bakeyournoodle.com> References: <20181018063539.GC6589@thor.bakeyournoodle.com> Message-ID: <20181019095428.GA9399@thor.bakeyournoodle.com> On Thu, Oct 18, 2018 at 05:35:39PM +1100, Tony Breeds wrote: > Hello all, > As per [1] the nomination period for names for the T release have > now closed (actually 3 days ago sorry). The nominated names and any > qualifying remarks can be seen at2]. > > Proposed Names > * Tarryall > * Teakettle > * Teller > * Telluride > * Thomas > * Thornton > * Tiger > * Tincup > * Timnath > * Timber > * Tiny Town > * Torreys > * Trail > * Trinidad > * Treasure > * Troublesome > * Trussville > * Turret > * Tyrone > > Proposed Names that do not meet the criteria > * Train I have re-worked my openstack/governance change[1] to ask the TC to accept adding Train to the poll as (partially) described in [2]. I present the names above to the community and Foundation marketing team for consideration. The list above does contain Train, clearly if the TC do not approve [1] Train will not be included in the poll when created. I apologise for any offence or slight caused by my previous email in this thread. It was well intentioned albeit, with hindsight, poorly thought through. Yours Tony. [1] https://review.openstack.org/#/c/611511/ [2] https://governance.openstack.org/tc/reference/release-naming.html#release-name-criteria -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From tpeluso at equinix.com Fri Oct 19 15:38:33 2018 From: tpeluso at equinix.com (Teresa Peluso) Date: Fri, 19 Oct 2018 15:38:33 +0000 Subject: [Openstack-sigs] [openstack-dev] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Message-ID: Fyi – could this help? https://www.linuxfoundation.org/blog/2018/06/edge-computing-just-got-its-rosetta-stone/ https://imasons.org/ starting to host workshops about this as well https://imasons.org/events/2018-im-edge-congress/ From: Csatari, Gergely (Nokia - HU/Budapest) Sent: Friday, October 19, 2018 1:05 AM To: OpenStack Development Mailing List (not for usage questions) ; fulton at redhat.com; edge-computing at lists.openstack.org Cc: openstack-sigs at lists.openstack.org Subject: [EXTERNAL] Re: [Edge-computing] [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" Hi, I’m adding the ECG mailing list to the discussion. I think the root of the problem is that there is no single definition of „the edge” (except for [1]), but it changes from group to group or use case to use case. What I recognise as the commonalities in these edge definitions, are 1) a distributed cloud infrastructure (kind of a cloud of clouds) 2) need for automation or everything 3) resource constraints for the control plane. The different edge variants are putting different emphasis on these common needs based ont he use case discussed. To have a more clear understanding of these definitions we could try the following: 1. Always add the definition of these to the given context 2. Check what other groups are using and adopt to that 3. Define our own language and expect everyone else to adopt Br, Gerg0 [1]: https://en.wikipedia.org/wiki/The_Edge From: Jim Rollenhagen > Sent: Thursday, October 18, 2018 11:43 PM To: fulton at redhat.com; OpenStack Development Mailing List (not for usage questions) > Cc: openstack-sigs at lists.openstack.org Subject: Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" On Thu, Oct 18, 2018 at 4:45 PM John Fulton > wrote: On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen > wrote: > > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur > wrote: >> >> Hi all, >> >> Sorry for chiming in really late in this topic, but I think $subj is worth >> discussing until we settle harder on the potentially confusing terminology. >> >> I think the difference between "Edge" and "Far Edge" is too vague to use these >> terms in practice. Think about the "edge" metaphor itself: something rarely has >> several layers of edges. A knife has an edge, there are no far edges. I imagine >> zooming in and seeing more edges at the edge, and then it's quite cool indeed, >> but is it really a useful metaphor for those who never used a strong microscope? :) >> >> I think in the trivial sense "Far Edge" is a tautology, and should be avoided. >> As a weak proof of my words, I already see a lot of smart people confusing these >> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we >> adopt a different terminology, even if it less consistent with typical marketing >> term around the "Edge" movement. > > > FWIW, we created rough definitions of "edge" and "far edge" during the edge WG session in Denver. > It's mostly based on latency to the end user, though we also talked about quantities of compute resources, if someone can find the pictures. Perhaps these are the pictures Jim was referring to? https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0# That's it, thank you! // jim I'm involved in some TripleO work called the split control plane: https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html After the PTG I saw that the split control plane was compatible with the type of deployment discussed at the edge WG session in Denver and described the compatibility at: https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane > See the picture and table here: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview > >> Now, I don't have really great suggestions. Something that came up in TripleO >> discussions [1] is Core/Hub/Edge, which I think reflects the idea better. > > > I'm also fine with these names, as they do describe the concepts well. :) > > // jim I'm fine with these terms too. In split control plane there's a deployment method for deploying a central site and then deploying remote sites independently. That deployment method could be used to deploy Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack N. Deploy a Hub using stack N+1 and then deploy an Edge using stack N+2 etc. John >> >> I'd be very interested to hear your ideas. >> >> Dmitry >> >> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > __________________________________________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gergely.csatari at nokia.com Tue Oct 23 09:26:12 2018 From: gergely.csatari at nokia.com (Csatari, Gergely (Nokia - HU/Budapest)) Date: Tue, 23 Oct 2018 09:26:12 +0000 Subject: [Openstack-sigs] [openstack-dev] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" In-Reply-To: References: <713a4c9a-d628-ee6d-49e8-c8e9763cdbfe@redhat.com> Message-ID: Hi, Yes, https://github.com/State-of-the-Edge/glossary is a good initiative. Maybe we should all just start using the terms defined there and contribute if we have problems with the definitions. Br, Gerg0 From: Teresa Peluso Sent: Friday, October 19, 2018 4:39 PM To: Csatari, Gergely (Nokia - HU/Budapest) ; OpenStack Development Mailing List (not for usage questions) ; fulton at redhat.com; edge-computing at lists.openstack.org Cc: openstack-sigs at lists.openstack.org Subject: RE: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" Fyi – could this help? https://www.linuxfoundation.org/blog/2018/06/edge-computing-just-got-its-rosetta-stone/ https://imasons.org/ starting to host workshops about this as well https://imasons.org/events/2018-im-edge-congress/ From: Csatari, Gergely (Nokia - HU/Budapest) > Sent: Friday, October 19, 2018 1:05 AM To: OpenStack Development Mailing List (not for usage questions) >; fulton at redhat.com; edge-computing at lists.openstack.org Cc: openstack-sigs at lists.openstack.org Subject: [EXTERNAL] Re: [Edge-computing] [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" Hi, I’m adding the ECG mailing list to the discussion. I think the root of the problem is that there is no single definition of „the edge” (except for [1]), but it changes from group to group or use case to use case. What I recognise as the commonalities in these edge definitions, are 1) a distributed cloud infrastructure (kind of a cloud of clouds) 2) need for automation or everything 3) resource constraints for the control plane. The different edge variants are putting different emphasis on these common needs based ont he use case discussed. To have a more clear understanding of these definitions we could try the following: 1. Always add the definition of these to the given context 2. Check what other groups are using and adopt to that 3. Define our own language and expect everyone else to adopt Br, Gerg0 [1]: https://en.wikipedia.org/wiki/The_Edge From: Jim Rollenhagen > Sent: Thursday, October 18, 2018 11:43 PM To: fulton at redhat.com; OpenStack Development Mailing List (not for usage questions) > Cc: openstack-sigs at lists.openstack.org Subject: Re: [openstack-dev] [Openstack-sigs] [FEMDC] [Edge] [tripleo] On the use of terms "Edge" and "Far Edge" On Thu, Oct 18, 2018 at 4:45 PM John Fulton > wrote: On Thu, Oct 18, 2018 at 11:56 AM Jim Rollenhagen > wrote: > > On Thu, Oct 18, 2018 at 10:23 AM Dmitry Tantsur > wrote: >> >> Hi all, >> >> Sorry for chiming in really late in this topic, but I think $subj is worth >> discussing until we settle harder on the potentially confusing terminology. >> >> I think the difference between "Edge" and "Far Edge" is too vague to use these >> terms in practice. Think about the "edge" metaphor itself: something rarely has >> several layers of edges. A knife has an edge, there are no far edges. I imagine >> zooming in and seeing more edges at the edge, and then it's quite cool indeed, >> but is it really a useful metaphor for those who never used a strong microscope? :) >> >> I think in the trivial sense "Far Edge" is a tautology, and should be avoided. >> As a weak proof of my words, I already see a lot of smart people confusing these >> two and actually use Central/Edge where they mean Edge/Far Edge. I suggest we >> adopt a different terminology, even if it less consistent with typical marketing >> term around the "Edge" movement. > > > FWIW, we created rough definitions of "edge" and "far edge" during the edge WG session in Denver. > It's mostly based on latency to the end user, though we also talked about quantities of compute resources, if someone can find the pictures. Perhaps these are the pictures Jim was referring to? https://www.dropbox.com/s/255x1cao14taer3/MVP-Architecture_edge-computing_PTG.pptx?dl=0# That's it, thank you! // jim I'm involved in some TripleO work called the split control plane: https://specs.openstack.org/openstack/tripleo-specs/specs/rocky/split-controlplane.html After the PTG I saw that the split control plane was compatible with the type of deployment discussed at the edge WG session in Denver and described the compatibility at: https://etherpad.openstack.org/p/tripleo-edge-working-group-split-control-plane > See the picture and table here: https://wiki.openstack.org/wiki/Edge_Computing_Group/Edge_Reference_Architectures#Overview > >> Now, I don't have really great suggestions. Something that came up in TripleO >> discussions [1] is Core/Hub/Edge, which I think reflects the idea better. > > > I'm also fine with these names, as they do describe the concepts well. :) > > // jim I'm fine with these terms too. In split control plane there's a deployment method for deploying a central site and then deploying remote sites independently. That deployment method could be used to deploy Core/Hub/Edge sites too. E.g. deploy the Core using Heat stack N. Deploy a Hub using stack N+1 and then deploy an Edge using stack N+2 etc. John >> >> I'd be very interested to hear your ideas. >> >> Dmitry >> >> [1] https://etherpad.openstack.org/p/tripleo-edge-mvp >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs > > __________________________________________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stig.openstack at telfer.org Wed Oct 24 10:14:13 2018 From: stig.openstack at telfer.org (Stig Telfer) Date: Wed, 24 Oct 2018 11:14:13 +0100 Subject: [Openstack-sigs] [scientific] IRC Meeting: Mixing bare metal and virt on an Ironic cloud Message-ID: Hi All - We have a Scientific SIG IRC meeting at 1100 UTC (about an hour's time) in channel #openstack-meeting. Everyone is welcome. Today we have Jacob Anders from CSIRO in Australia presenting his dynamic solution for mixed bare metal and virtualisation. The full agenda for today is available here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_October_24th_2018 Cheers, Stig From tobias.rydberg at citynetwork.eu Thu Oct 25 09:20:04 2018 From: tobias.rydberg at citynetwork.eu (Tobias Rydberg) Date: Thu, 25 Oct 2018 11:20:04 +0200 Subject: [Openstack-sigs] [publiccloud-wg] Reminder weekly meeting Public Cloud WG Message-ID: <1e16eefd-142b-9a3b-4812-baf463e1fa03@citynetwork.eu> Hi everyone, Time for a new meeting for PCWG - today 1400 UTC in #openstack-publiccloud! Agenda found at https://etherpad.openstack.org/p/publiccloud-wg Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED From fungi at yuggoth.org Mon Oct 29 16:53:47 2018 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 29 Oct 2018 16:53:47 +0000 Subject: [Openstack-sigs] [all] We're combining the lists! (was: Bringing the community together...) In-Reply-To: <20180920163248.oia5t7zjqcfwluwz@yuggoth.org> References: <20180830170350.wrz4wlanb276kncb@yuggoth.org> <20180920163248.oia5t7zjqcfwluwz@yuggoth.org> Message-ID: <20181029165346.vm6ptoqq5wkqban6@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 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 963 bytes Desc: not available URL: From tony at bakeyournoodle.com Tue Oct 30 05:40:25 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Tue, 30 Oct 2018 16:40:25 +1100 Subject: [Openstack-sigs] [all]Naming the T release of OpenStack -- Poll open Message-ID: <20181030054024.GC2343@thor.bakeyournoodle.com> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From rico.lin.guanyu at gmail.com Tue Oct 30 11:15:21 2018 From: rico.lin.guanyu at gmail.com (Rico Lin) Date: Tue, 30 Oct 2018 19:15:21 +0800 Subject: [Openstack-sigs] [openstack-sigs][all] Berlin Forum for `expose SIGs and WGs` Message-ID: Hi all To continue our discussion in Denver, we will have a forum [1] in Berlin on *Wednesday, November 14, 11:50am-12:30pm CityCube Berlin - Level 3 - M-Räume 8* We will host the forum in an open discussion format, and try to get actions from forum to make sure we can keep push what people need. So if you have any feedback or idea, please join us. I created an etherpad for this forum so we can collect information, get feedback, and mark actions. *https://etherpad.openstack.org/p/expose-sigs-and-wgs * *For who don't know what is `expose SIGs and WGs`* There is some started discussion in ML [2] , and in PTG session [3]. The basic concept for this is to allow users/ops get a single window for important scenario/user cases or issues into traceable tasks in single story/place and ask developers be responsible (by changing the mission of government policy) to co-work on that task. SIGs/WGs are so desired to get feedbacks or use cases, so as for project teams (not gonna speak for all projects/SIGs/WGs but we like to collect for more idea for sure). And project teams got a central place to develop for specific user requirements, or give document for more general OpenStack information. So would like to have more discussion on how can we reach the goal by actions? How can we change in TC, UC, Projects, SIGs, WGs's policy to bridge up from user/ops to developers. [1] https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22750/expose-sigs-and-wgs [2] http://lists.openstack.org/pipermail/openstack-sigs/2018-August/000453.html [3] http://lists.openstack.org/pipermail/openstack-dev/2018-September/134689.html -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony at bakeyournoodle.com Wed Oct 31 01:01:31 2018 From: tony at bakeyournoodle.com (Tony Breeds) Date: Wed, 31 Oct 2018 12:01:31 +1100 Subject: [Openstack-sigs] [openstack-dev] [all]Naming the T release of OpenStack -- Poll open In-Reply-To: References: <20181030054024.GC2343@thor.bakeyournoodle.com> Message-ID: <20181031010130.GE2343@thor.bakeyournoodle.com> On Tue, Oct 30, 2018 at 11:25:02AM -0700, iain macdonnell wrote: > I must be losing it. On what planet is "Tiny Town" a single word, and > "Troublesome" not more than 10 characters? Sorry for the mistake. Should either of these names win the popular vote clearly they would not be viable. 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-dev at dseven.org Tue Oct 30 18:25:02 2018 From: openstack-dev at dseven.org (iain macdonnell) Date: Tue, 30 Oct 2018 11:25:02 -0700 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: I must be losing it. On what planet is "Tiny Town" a single word, and "Troublesome" not more than 10 characters? ~iain On Mon, Oct 29, 2018 at 10:41 PM 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 From chengfeiyoiua at gmail.com Wed Oct 31 13:45:57 2018 From: chengfeiyoiua at gmail.com (TING PANG) Date: Wed, 31 Oct 2018 21:45:57 +0800 Subject: [Openstack-sigs] [security] A Security Project Proposal In-Reply-To: References: Message-ID: Hi Luke, Apologize for the delay getting back to you. I have been on a business trip for the last two weeks. The problem you concerned does exist and it needs to be addressed. We have some preliminary ideas, for example, encrypting the state "trusted" before storing it on the disc, storing the state "trusted" on the non-volatile memory provided by a trusted chip. Perhaps you have a better idea and we hope we can solve this problem through active community discussions. I also bring up about the main focus of our proposal. In recent years, the trusted computing technology has been widely used and there are several different trusted formats in the world. It is necessary for OpenStack to schedule various trusted resources on the cloud side. So we want to have the same management plane for various trusted computing hardware (such as TPM, TCM, Titan, ... ) in OpenStack. If you have any further questions or concerns, please don't hesitate to contact me. Looking forward to your insight. Best Regard, Ting Luke Hinds 于2018年10月17日周三 下午11:24写道: > Hi Ting, > > Here's my thoughts on the topic / proposal. > > To jump straight to my main concern, I am sceptical of storing a 'trust > state' in yet another API, especially for trusted compute, as we then need > to trust an API and it's less secure (than a TPM) components (database, > memory, disc etc). > > Up to present the trusted compute approach in OpenStack has been always > been some type of API query to establish if a node can be 'trusted' and > hooking that into nova's scheduler. One current approach being the traits > API. > > The problem with this is that the stored state of 'trusted' is then on > disc or volatile memory , typically a row in a mariaDB table somewhere on > the controller - this then means we immediately lose all of the true > attractiveness of a TPM, that being a tamper proof hardware route of trust > , unlike an API which sets the 'trust state' in a datastore on disc or > memory (which can be hacked to spoof trust). > > So I can't really comment on the current proposal or really get behind it, > as its to vague at present in why it should provide unified trust and how > we would trust it. On the face of it, this proposal appears to be another > actor susceptible to the flaws outlined above. I would need to know how the > above concern would be resolved, so that there is implicit hardware routed > trust presented to the workload wanting a trusted node to schedule upon, > without a go between actor hosting the trust state of compute nodes. > > Perhaps you have already solved this, if so I would recommend you outline > it in your proposal. > > Best Regards, > > Luke > > On Wed, Oct 17, 2018 at 3:48 PM TING PANG wrote: > >> Dear all, >> >> As we all known, security has always been a hot topic among people. In >> OpenStack, if an attacker make a system un-trustworthy, it will make a >> risk for entire infrastructure and affect customers confidence. >> Fortunately, more and more vendors start providing security solutions with >> the trusted computing. It is a security technology based on a hardware >> trust format to improve system integrity and trustworthy. The risks and >> threats on cloud can be mitigated and managed with trusted computing >> technology, which can make a customer more confident when utilizing >> OpenStack. >> >> However, there are some mainstream trusted formats (e.g. TPM, TCM) and >> some special trusted formats provided by vendors (e.g. Google, Microsoft ) >> in the world, which cause huge development costs and interoperability >> issues for vendors to support various trusted formats. >> >> To resolve problems above, we want to create a new security project named >> "Hawthorn" that provides a general unified trust management framework to be >> compatible with different trust formats in OpenStack. >> >> More general information can be found here: *https://wiki.openstack.org/wiki/Hawthorn >> * >> >> Please feel free to contact me if you are interested in this proposal or >> have questions and suggestion. >> >> Best regards, >> >> Ting >> >> _______________________________________________ >> openstack-sigs mailing list >> openstack-sigs at lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-sigs >> > > > -- > Luke Hinds | NFV Partner Engineering | CTO Office | Red Hat > e: lhinds at redhat.com | irc: lhinds @freenode | t: +44 12 52 36 2483 > -------------- next part -------------- An HTML attachment was scrubbed... URL: