Re: [openstack-dev] [election][tc]Question for candidates about global reachout
As a non-native English speaker, it is nice-to-have that some TC or BoD can stay in the local social media, like wechat group in China. But it is also very difficult for non-native Chinese speakers to stay find useful information in ton of Chinese chats. My thoughts (even I am not a TC candidate) on this is, 1. it is kind of you to stay in the local group. 2. if we know that you are in, we will say English if we want you to notice. 3. since there is local OpenStack operation manager, hope he/she can identify some information and help to translate, or remind them to translate. My one cent. On Sun, Sep 16, 2018 at 2:21 AM, Zhipeng Huang wrote: > Ya I think the whole point here (the question per se )is just to gauge if > TC Candidates are willing to engage with regional developer in a way that > is best fitting for that region. > > It surly will take other measures to make this entire effort work . On > that I totally agree with you that there should be ambassadors to help > facilitate the discussion, and the end goal is always to go to upstream > instead of the convo ending in local or downstream. > > > On Sat, Sep 15, 2018, 9:52 AM Matt Riedemann wrote: > >> On 9/14/2018 1:52 PM, Zhipeng Huang wrote: >> > This is a joint question from mnaser and me :) >> > >> > For the candidates who are running for tc seats, please reply to this >> > email to indicate if you are open to use certain social media app in >> > certain region (like Wechat in China, Line in Japan, etc.), in order to >> > reach out to the OpenStack developers in that region and help them to >> > connect to the upstream community as well as answering questions or >> > other activities that will help. (sorry for the long sentence ... ) >> > >> > Rico and I already sign up for Wechat communication for sure :) >> >> Having had some experience with WeChat, I can't imagine I'd be very >> useful in a nova channel in WeChat since the majority of people in that >> group wouldn't be speaking English so I wouldn't be of much help, unless >> someone directly asked me a question in English. I realize the double >> standard here with expecting non-native English speakers to show up in >> the #openstack-nova freenode IRC channel to ask questions. It's >> definitely a hard problem when people simply can't speak the same >> language and I don't have a great solution. Probably the best common >> solution we have is having more people across time zones and language >> barriers engaging in more discussion in the mailing list (and Gerrit >> reviews of course). So maybe that means if you're in WeChat and someone >> is blocked or has a bigger question for a specific project team, >> encourage them to send an email to the dev ML - but that requires >> ambassadors to be in WeChat channels to make that suggestion. I think of >> this like working with product teams within your own company. Lots of >> those people aren't active upstream contributors and to avoid being the >> middleman (and thus bottleneck) for all communication between upstream >> and downstream teams, I've encouraged the downstream folk to send an >> email upstream to start a discussion. >> >> -- >> >> Thanks, >> >> Matt >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: >> unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Regards Fred Li (李永乐) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc]Question for candidates about global reachout
Ya I think the whole point here (the question per se )is just to gauge if TC Candidates are willing to engage with regional developer in a way that is best fitting for that region. It surly will take other measures to make this entire effort work . On that I totally agree with you that there should be ambassadors to help facilitate the discussion, and the end goal is always to go to upstream instead of the convo ending in local or downstream. On Sat, Sep 15, 2018, 9:52 AM Matt Riedemann wrote: > On 9/14/2018 1:52 PM, Zhipeng Huang wrote: > > This is a joint question from mnaser and me :) > > > > For the candidates who are running for tc seats, please reply to this > > email to indicate if you are open to use certain social media app in > > certain region (like Wechat in China, Line in Japan, etc.), in order to > > reach out to the OpenStack developers in that region and help them to > > connect to the upstream community as well as answering questions or > > other activities that will help. (sorry for the long sentence ... ) > > > > Rico and I already sign up for Wechat communication for sure :) > > Having had some experience with WeChat, I can't imagine I'd be very > useful in a nova channel in WeChat since the majority of people in that > group wouldn't be speaking English so I wouldn't be of much help, unless > someone directly asked me a question in English. I realize the double > standard here with expecting non-native English speakers to show up in > the #openstack-nova freenode IRC channel to ask questions. It's > definitely a hard problem when people simply can't speak the same > language and I don't have a great solution. Probably the best common > solution we have is having more people across time zones and language > barriers engaging in more discussion in the mailing list (and Gerrit > reviews of course). So maybe that means if you're in WeChat and someone > is blocked or has a bigger question for a specific project team, > encourage them to send an email to the dev ML - but that requires > ambassadors to be in WeChat channels to make that suggestion. I think of > this like working with product teams within your own company. Lots of > those people aren't active upstream contributors and to avoid being the > middleman (and thus bottleneck) for all communication between upstream > and downstream teams, I've encouraged the downstream folk to send an > email upstream to start a discussion. > > -- > > Thanks, > > Matt > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [puppet] [placement]
I'm currently taking care of creating puppet-placement: https://review.openstack.org/#/c/602870/ https://review.openstack.org/#/c/602871/ https://review.openstack.org/#/c/602869/ Once these merge, we'll use cookiecutter, and move things from puppet-nova. We'll also find a way to call puppet-placement from nova::placement class, eventually. Hopefully we can make the switch to new placement during Stein! Thanks, -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [election][tc]Question for candidates about global reachout
On 9/14/2018 1:52 PM, Zhipeng Huang wrote: This is a joint question from mnaser and me :) For the candidates who are running for tc seats, please reply to this email to indicate if you are open to use certain social media app in certain region (like Wechat in China, Line in Japan, etc.), in order to reach out to the OpenStack developers in that region and help them to connect to the upstream community as well as answering questions or other activities that will help. (sorry for the long sentence ... ) Rico and I already sign up for Wechat communication for sure :) Having had some experience with WeChat, I can't imagine I'd be very useful in a nova channel in WeChat since the majority of people in that group wouldn't be speaking English so I wouldn't be of much help, unless someone directly asked me a question in English. I realize the double standard here with expecting non-native English speakers to show up in the #openstack-nova freenode IRC channel to ask questions. It's definitely a hard problem when people simply can't speak the same language and I don't have a great solution. Probably the best common solution we have is having more people across time zones and language barriers engaging in more discussion in the mailing list (and Gerrit reviews of course). So maybe that means if you're in WeChat and someone is blocked or has a bigger question for a specific project team, encourage them to send an email to the dev ML - but that requires ambassadors to be in WeChat channels to make that suggestion. I think of this like working with product teams within your own company. Lots of those people aren't active upstream contributors and to avoid being the middleman (and thus bottleneck) for all communication between upstream and downstream teams, I've encouraged the downstream folk to send an email upstream to start a discussion. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [goals][upgrade-checkers] Week R-30 update
Just a couple of updates this week. * I have assigned PTLs (for projects that have PTLs [1]) to their respective tasks in StoryBoard [2]. If someone else on your team is planning on working on the pre-upgrade check goal then please just reassign ownership of the task. * I have started going through some project release notes looking for upgrade impacts and leaving notes in the task assigned per project. There were some questions at the PTG about what some projects could add for pre-upgrade checks so check your task to see if I've left any thoughts. I have not gone through all projects yet. * Ben Nemec has extracted the common upgrade check CLI framework into a library [3] (thanks Ben!) and is working on getting that imported into Gerrit. It would be great if projects that start working on the goal can try using that library and provide feedback. [1] https://governance.openstack.org/election/results/stein/ptl.html [2] https://storyboard.openstack.org/#!/story/2003657 [3] https://github.com/cybertron/oslo.upgradecheck -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [all] Consistent policy names
I am generally opposed to needlessly prefixing things with "os". I would advocate to drop it. On Fri, Sep 14, 2018, 20:17 Lance Bragstad wrote: > Ok - yeah, I'm not sure what the history behind that is either... > > I'm mainly curious if that's something we can/should keep or if we are > opposed to dropping 'os' and 'api' from the convention (e.g. > load-balancer:loadbalancer:post as opposed to > os_load-balancer_api:loadbalancer:post) and just sticking with the > service-type? > > On Fri, Sep 14, 2018 at 2:16 PM Michael Johnson > wrote: > >> I don't know for sure, but I assume it is short for "OpenStack" and >> prefixing OpenStack policies vs. third party plugin policies for >> documentation purposes. >> >> I am guilty of borrowing this from existing code examples[0]. >> >> [0] >> http://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/policy-in-code.html >> >> Michael >> On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad >> wrote: >> > >> > >> > >> > On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson >> wrote: >> >> >> >> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post" >> >> which maps to the "os--api::" format. >> > >> > >> > Thanks for explaining the justification, Michael. >> > >> > I'm curious if anyone has context on the "os-" part of the format? I've >> seen that pattern in a couple different projects. Does anyone know about >> its origin? Was it something we converted to our policy names because of >> API names/paths? >> > >> >> >> >> >> >> I selected it as it uses the service-type[1], references the API >> >> resource, and then the method. So it maps well to the API reference[2] >> >> for the service. >> >> >> >> [0] >> https://docs.openstack.org/octavia/latest/configuration/policy.html >> >> [1] https://service-types.openstack.org/ >> >> [2] >> https://developer.openstack.org/api-ref/load-balancer/v2/index.html#create-a-load-balancer >> >> >> >> Michael >> >> On Wed, Sep 12, 2018 at 12:52 PM Tim Bell wrote: >> >> > >> >> > So +1 >> >> > >> >> > >> >> > >> >> > Tim >> >> > >> >> > >> >> > >> >> > From: Lance Bragstad >> >> > Reply-To: "OpenStack Development Mailing List (not for usage >> questions)" >> >> > Date: Wednesday, 12 September 2018 at 20:43 >> >> > To: "OpenStack Development Mailing List (not for usage questions)" < >> openstack-dev@lists.openstack.org>, OpenStack Operators < >> openstack-operat...@lists.openstack.org> >> >> > Subject: [openstack-dev] [all] Consistent policy names >> >> > >> >> > >> >> > >> >> > The topic of having consistent policy names has popped up a few >> times this week. Ultimately, if we are to move forward with this, we'll >> need a convention. To help with that a little bit I started an etherpad [0] >> that includes links to policy references, basic conventions *within* that >> service, and some examples of each. I got through quite a few projects this >> morning, but there are still a couple left. >> >> > >> >> > >> >> > >> >> > The idea is to look at what we do today and see what conventions we >> can come up with to move towards, which should also help us determine how >> much each convention is going to impact services (e.g. picking a convention >> that will cause 70% of services to rename policies). >> >> > >> >> > >> >> > >> >> > Please have a look and we can discuss conventions in this thread. If >> we come to agreement, I'll start working on some documentation in >> oslo.policy so that it's somewhat official because starting to renaming >> policies. >> >> > >> >> > >> >> > >> >> > [0] https://etherpad.openstack.org/p/consistent-policy-names >> >> > >> >> > ___ >> >> > OpenStack-operators mailing list >> >> > openstack-operat...@lists.openstack.org >> >> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> >> >> >> __ >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > ___ >> > OpenStack-operators mailing list >> > openstack-operat...@lists.openstack.org >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend
Found the previous discussion at http://lists.openstack.org/pipermail/openstack-operators/2016-August/011321.html from 2016. Tim -Original Message- From: Tim Bell Date: Saturday, 15 September 2018 at 14:38 To: "OpenStack Development Mailing List (not for usage questions)" , "openstack-operat...@lists.openstack.org" , "openstack-s...@lists.openstack.org" Subject: Re: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend One extra user motivation that came up during past forums was to have a different quota for shelved instances (or remove them from the project quota all together). Currently, I believe that a shelved instance still counts towards the instances/cores quota thus the reduction of usage by the user is not reflected in the quotas. One discussion at the time was that the user is still reserving IPs so it is not zero resource usage and the instances still occupy storage. (We disabled shelving for other reasons so I'm not able to check easily) Tim -Original Message- From: Matt Riedemann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Saturday, 15 September 2018 at 01:27 To: "OpenStack Development Mailing List (not for usage questions)" , "openstack-operat...@lists.openstack.org" , "openstack-s...@lists.openstack.org" Subject: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend tl;dr: I'm proposing a new parameter to the server stop (and suspend?) APIs to control if nova shelve offloads the server. Long form: This came up during the public cloud WG session this week based on a couple of feature requests [1][2]. When a user stops/suspends a server, the hypervisor frees up resources on the host but nova continues to track those resources as being used on the host so the scheduler can't put more servers there. What operators would like to do is that when a user stops a server, nova actually shelve offloads the server from the host so they can schedule new servers on that host. On start/resume of the server, nova would find a new host for the server. This also came up in Vancouver where operators would like to free up limited expensive resources like GPUs when the server is stopped. This is also the behavior in AWS. The problem with shelve is that it's great for operators but users just don't use it, maybe because they don't know what it is and stop works just fine. So how do you get users to opt into shelving their server? I've proposed a high-level blueprint [3] where we'd add a new (microversioned) parameter to the stop API with three options: * auto * offload * retain Naming is obviously up for debate. The point is we would default to auto and if auto is used, the API checks a config option to determine the behavior - offload or retain. By default we would retain for backward compatibility. For users that don't care, they get auto and it's fine. For users that do care, they either (1) don't opt into the microversion or (2) specify the specific behavior they want. I don't think we need to expose what the cloud's configuration for auto is because again, if you don't care then it doesn't matter and if you do care, you can opt out of this. "How do we get users to use the new microversion?" I'm glad you asked. Well, nova CLI defaults to using the latest available microversion negotiated between the client and the server, so by default, anyone using "nova stop" would get the 'auto' behavior (assuming the client and server are new enough to support it). Long-term, openstack client plans on doing the same version negotiation. As for the server status changes, if the server is stopped and shelved, the status would be 'SHELVED_OFFLOADED' rather than 'SHUTDOWN'. I believe this is fine especially if a user is not being specific and doesn't care about the actual backend behavior. On start, the API would allow starting (unshelving) shelved offloaded (rather than just stopped) instances. Trying to hide shelved servers as stopped in the API would be overly complex IMO so I don't want to try and mask that. It is possible that a user that stopped and shelved their server could hit a NoValidHost when starting (unshelving) the server, but that really shouldn't happen in a cloud that's configuring nova to shelve by default because if they are doing this, their SLA needs to reflect they have the capacity to unshelve the server. If you can'
[openstack-dev] [cinder][ptg] Team Photos Posted ...
Team, Wanted to share the team photos from the PTG. You can get them here: https://www.dropbox.com/sh/2pmvfkstudih2wf/AADynEnPDJiWIOE2nwjzBgtla/Cinder?dl=0&subfolder_nav_tracking=1 Jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend
One extra user motivation that came up during past forums was to have a different quota for shelved instances (or remove them from the project quota all together). Currently, I believe that a shelved instance still counts towards the instances/cores quota thus the reduction of usage by the user is not reflected in the quotas. One discussion at the time was that the user is still reserving IPs so it is not zero resource usage and the instances still occupy storage. (We disabled shelving for other reasons so I'm not able to check easily) Tim -Original Message- From: Matt Riedemann Reply-To: "OpenStack Development Mailing List (not for usage questions)" Date: Saturday, 15 September 2018 at 01:27 To: "OpenStack Development Mailing List (not for usage questions)" , "openstack-operat...@lists.openstack.org" , "openstack-s...@lists.openstack.org" Subject: [openstack-dev] [nova][publiccloud-wg] Proposal to shelve on stop/suspend tl;dr: I'm proposing a new parameter to the server stop (and suspend?) APIs to control if nova shelve offloads the server. Long form: This came up during the public cloud WG session this week based on a couple of feature requests [1][2]. When a user stops/suspends a server, the hypervisor frees up resources on the host but nova continues to track those resources as being used on the host so the scheduler can't put more servers there. What operators would like to do is that when a user stops a server, nova actually shelve offloads the server from the host so they can schedule new servers on that host. On start/resume of the server, nova would find a new host for the server. This also came up in Vancouver where operators would like to free up limited expensive resources like GPUs when the server is stopped. This is also the behavior in AWS. The problem with shelve is that it's great for operators but users just don't use it, maybe because they don't know what it is and stop works just fine. So how do you get users to opt into shelving their server? I've proposed a high-level blueprint [3] where we'd add a new (microversioned) parameter to the stop API with three options: * auto * offload * retain Naming is obviously up for debate. The point is we would default to auto and if auto is used, the API checks a config option to determine the behavior - offload or retain. By default we would retain for backward compatibility. For users that don't care, they get auto and it's fine. For users that do care, they either (1) don't opt into the microversion or (2) specify the specific behavior they want. I don't think we need to expose what the cloud's configuration for auto is because again, if you don't care then it doesn't matter and if you do care, you can opt out of this. "How do we get users to use the new microversion?" I'm glad you asked. Well, nova CLI defaults to using the latest available microversion negotiated between the client and the server, so by default, anyone using "nova stop" would get the 'auto' behavior (assuming the client and server are new enough to support it). Long-term, openstack client plans on doing the same version negotiation. As for the server status changes, if the server is stopped and shelved, the status would be 'SHELVED_OFFLOADED' rather than 'SHUTDOWN'. I believe this is fine especially if a user is not being specific and doesn't care about the actual backend behavior. On start, the API would allow starting (unshelving) shelved offloaded (rather than just stopped) instances. Trying to hide shelved servers as stopped in the API would be overly complex IMO so I don't want to try and mask that. It is possible that a user that stopped and shelved their server could hit a NoValidHost when starting (unshelving) the server, but that really shouldn't happen in a cloud that's configuring nova to shelve by default because if they are doing this, their SLA needs to reflect they have the capacity to unshelve the server. If you can't honor that SLA, don't shelve by default. So, what are the general feelings on this before I go off and start writing up a spec? [1] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791681 [2] https://bugs.launchpad.net/openstack-publiccloud-wg/+bug/1791679 [3] https://blueprints.launchpad.net/nova/+spec/shelve-on-stop -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _
Re: [openstack-dev] [neutron] Pep8 job failures
Hi, As patch [1] is finally merged You can now rebase Your neutron patches and pep8 tests should be good. [1] https://review.openstack.org/#/c/589382/ > Wiadomość napisana przez Slawomir Kaplonski w dniu > 07.09.2018, o godz. 01:30: > > Hi, > > Recently bump of eventlet to 0.24.0 was merged in requirements repo [1]. > That caused issue in Neutron and pep8 job is now failing. See [2]. So if You > have pep8 failed in Your patch with error like in [3] please don’t recheck > job - it will not help :) > Patch to fix that is already proposed [4]. When it will be merged, please > rebase Your patch and this issue should be solved. > > [1] https://review.openstack.org/#/c/589382/ > [2] https://bugs.launchpad.net/neutron/+bug/1791178 > [3] > http://logs.openstack.org/37/382037/73/gate/openstack-tox-pep8/7f200e6/job-output.txt.gz#_2018-09-06_17_48_34_700485 > [4] https://review.openstack.org/600565 > > — > Slawek Kaplonski > Senior software engineer > Red Hat > — Slawek Kaplonski Senior software engineer Red Hat __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
