Re: [openstack-dev] [horizon] PTG Summary
Hi forks, I added the English version which I had at the top of the page without deleting current one. As far as I see, there looks no points missing in former. but if anyone know the recent change and find differences, I'd be so happy if you reflect that diff. I'm so sorry and thanks for comments. Best regards, --- Kenji Ishii > -Original Message- > From: Kenji Ishii [mailto:ken-is...@sx.jp.nec.com] > Sent: Tuesday, February 28, 2017 8:39 AM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [horizon] PTG Summary > > Hi, forks > > I'm very very sorry that when I see this page, I'd translated to another > language with mistake.. > <https://etherpad.openstack.org/p/horizon-ptg-pike> > Can anyone do back to previous one? > > --- > Kenji Ishii > > > > -Original Message- > > From: Rob Cresswell [mailto:robert.cressw...@outlook.com] > > Sent: Tuesday, February 28, 2017 12:28 AM > > To: OpenStack Dev Mailer <openstack-dev@lists.openstack.org> > > Subject: [openstack-dev] [horizon] PTG Summary > > > > Hi everyone! > > > > Quick summary of the PTG for those who missed it. Here's the etherpad, > > with notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike > > > > We spent the first morning discussing plugins, with several plugin > > devs dropping in to discuss their issues. Several issues were > > mentioned that Horizon needs to improve upon to help the plugins: > > > > - Functional testing for JS > > - Extensible quotas > > - Use [horizon-plugin] mailer tag to keep people up to date > > > > Further specifics can be found in the etherpad notes. > > > > The afternoon and following morning were spent analysing specific > > blueprints, and then doing a general blueprint review. This has > > resulted in a really refined blueprint list: > > https://blueprints.launchpad.net/horizon, which we'll be using in > > place of a priorities etherpad this cycle. That's right, tracking > > tools actually being used for tracking. Huzzah! > > > > If there are any disagreements on blueprints, or you feel I have > > closed something unfairly, please get in touch on IRC (robcresswell) > > or email me. > > > > Two other cross project sessions are also linked in the etherpad; one > > with keystone and another with i18n. These were really helpful in > > understanding how Horizon can work better with these projects. Please > > review the etherpads to see what work needs to be done. > > > > Rob > _ > _ > 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] [horizon] PTG Summary
Hi, forks I'm very very sorry that when I see this page, I'd translated to another language with mistake.. <https://etherpad.openstack.org/p/horizon-ptg-pike> Can anyone do back to previous one? --- Kenji Ishii > -Original Message- > From: Rob Cresswell [mailto:robert.cressw...@outlook.com] > Sent: Tuesday, February 28, 2017 12:28 AM > To: OpenStack Dev Mailer <openstack-dev@lists.openstack.org> > Subject: [openstack-dev] [horizon] PTG Summary > > Hi everyone! > > Quick summary of the PTG for those who missed it. Here's the etherpad, > with notes inline: https://etherpad.openstack.org/p/horizon-ptg-pike > > We spent the first morning discussing plugins, with several plugin devs > dropping in to discuss their issues. Several issues were mentioned that > Horizon needs to improve upon to help the plugins: > > - Functional testing for JS > - Extensible quotas > - Use [horizon-plugin] mailer tag to keep people up to date > > Further specifics can be found in the etherpad notes. > > The afternoon and following morning were spent analysing specific > blueprints, and then doing a general blueprint review. This has resulted > in a really refined blueprint list: > https://blueprints.launchpad.net/horizon, which we'll be using in place > of a priorities etherpad this cycle. That's right, tracking tools actually > being used for tracking. Huzzah! > > If there are any disagreements on blueprints, or you feel I have closed > something unfairly, please get in touch on IRC (robcresswell) or email > me. > > Two other cross project sessions are also linked in the etherpad; one with > keystone and another with i18n. These were really helpful in understanding > how Horizon can work better with these projects. Please review the > etherpads to see what work needs to be done. > > Rob __ 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] [Horizon] Proposing Kenji Ishii for core
Hi forks, Thanks for inviting me to Core team! I'll do my best and I hope to contribute for Horizon than before. Best regards, --- Kenji Ishii > -Original Message- > From: Richard Jones [mailto:r1chardj0...@gmail.com] > Sent: Monday, November 21, 2016 1:31 PM > To: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core > > As a result of the unanimous vote here, I welcome Kenji to the Horizon > Core Team! > > > Richard > > On 19 November 2016 at 12:37, Tripp, Travis S <travis.tr...@hpe.com> > wrote: > > +1 > > > > > > > > From: Timur Sufiev <tsuf...@mirantis.com> > > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > > Date: Friday, November 18, 2016 at 1:34 AM > > To: OpenStack List <openstack-dev@lists.openstack.org> > > > > > > Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core > > > > > > > > +1 > > > > > > > > On Fri, Nov 18, 2016 at 12:35 AM Thai Q Tran <tqt...@us.ibm.com> wrote: > > > > +1 from me. Kenji is also very active in the plugin space. > > > > > > > > - Original message - > > From: David Lyle <dkly...@gmail.com> > > To: "OpenStack Development Mailing List (not for usage questions)" > > <openstack-dev@lists.openstack.org> > > Cc: > > Subject: Re: [openstack-dev] [Horizon] Proposing Kenji Ishii for core > > Date: Thu, Nov 17, 2016 11:51 AM > > > > > > +1 > > > > On Tue, Nov 15, 2016 at 5:02 AM, Akira Yoshiyama > > <akirayoshiy...@gmail.com> wrote: > >> +1 > >> > >> 2016年11月15日(火) 20:47 Rob Cresswell (rcresswe) > <rcres...@cisco.com>: > >>> > >>> Big +1 from me > >>> > >>> > On 14 Nov 2016, at 00:24, Richard Jones <r1chardj0...@gmail.com> > wrote: > >>> > > >>> > Hi Horizon core team, > >>> > > >>> > I propose Kenji Ishii as a new Horizon core reviewer. Kenji has > >>> > been a solid Horizon contributor for some time, with thoughtful > >>> > and helpful reviews showing good judgment and good knowledge of > >>> > Horizion and related systems. Please respond with your votes by > Friday. > >>> > > >>> > > >>> > Thanks, > >>> > > >>> >Richard > >>> > > >>> > > >>> > > >>> > > __ > >>> > 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 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 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 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] [Horizon][FFE]Support a param to specify subnet or fixed IP when creating port
Hi, horizoners I'd like to request a feature freeze exception for the feature. (This is a bug ticket, but the contents written in this ticket is a new feature.) https://bugs.launchpad.net/horizon/+bug/1588663 This is implemented by the following patch. https://review.openstack.org/#/c/325104/ It is useful to be able to create a port with using subnet or IP address which a user want to use. And this has already reviewed by many reviewers, so I think the risk in this patch is very few. --- Best regards, Kenji Ishii __ 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]Proposal for function to manage the resources available to each tenant
Thank you for reply! Not sure I fully understand but AggregateMultiTenancyIsolation filter already partially does the job (with a certain number of pitfalls, one being addressed in https://review.openstack.org/#/c/195783/ ) I understand that nova already has function to isolate resources for each tenant and the functional improvements is in progress. I will watch this blueprint and try to check AggregateMultiTenancyIsolation filter. https://review.openstack.org/#/c/195783/ Nova litterally knows nothing about Regions, that's a pure Keystone concept. From my perspective, you just have to make sure that your tenants are per region, you don't really need more to have the tenancy segregation at the region level. Caution, I'm not a Keystone expert. We had assumed that system configuration is single horizon and single keystone and multiple regions. In this case, a tenant has resources at all regions. My proposal is this precondition. Thanks. -Original Message- From: Sylvain Bauza [mailto:sba...@redhat.com] Sent: Friday, July 17, 2015 6:25 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova]Proposal for function to manage the resources available to each tenant Le 17/07/2015 10:42, Kenji Ishii a écrit : Hello! Please give me opinion in terms to be a valuable function for OpenStack Community. We believe that we need a mechanism to easily manage the resources available to the each tenant. In some case, we want to allow only the specific tenant to use the specific resources. We think the two architectures of the following. a. New concept called vDC vDC is virtual DC. It means collection of several logical resources : Availavility Zone(AZ). If we use it, we can control the resources to each tenant. For example, ___vDC_1 ___vDC_2 || || | AZ1, AZ2 | | AZ3 | || || tenant tenant_001 assigned vDC_1 tenant tenant_002 assigned vDC_2 tenant_001 can use AZ1 and AZ2, AZ3 is unavailable. tenant_002 can use AZ3 , AZ1 and AZ2 is unavailable. Not sure I fully understand but AggregateMultiTenancyIsolation filter already partially does the job (with a certain number of pitfalls, one being addressed in https://review.openstack.org/#/c/195783/ ) b. use region It will manage the relation between the Region and the tenant. The tenant can use only the resources in region that be allowed it to use. By the way, this proposal is several problems - Cost of system construction is higher than proposal a etc Nova litterally knows nothing about Regions, that's a pure Keystone concept. From my perspective, you just have to make sure that your tenants are per region, you don't really need more to have the tenancy segregation at the region level. Caution, I'm not a Keystone expert. -Sylvain each proposal's detail is following. https://wiki.openstack.org/wiki/Proposal_vDC -- Kenji Ishii __ 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 -- Kenji Ishii __ 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] [nova]Proposal for function to manage the resources available to each tenant
Hello! Please give me opinion in terms to be a valuable function for OpenStack Community. We believe that we need a mechanism to easily manage the resources available to the each tenant. In some case, we want to allow only the specific tenant to use the specific resources. We think the two architectures of the following. a. New concept called vDC vDC is virtual DC. It means collection of several logical resources : Availavility Zone(AZ). If we use it, we can control the resources to each tenant. For example, ___vDC_1 ___vDC_2 || || | AZ1, AZ2 | | AZ3 | || || tenant tenant_001 assigned vDC_1 tenant tenant_002 assigned vDC_2 tenant_001 can use AZ1 and AZ2, AZ3 is unavailable. tenant_002 can use AZ3 , AZ1 and AZ2 is unavailable. b. use region It will manage the relation between the Region and the tenant. The tenant can use only the resources in region that be allowed it to use. By the way, this proposal is several problems - Cost of system construction is higher than proposal a etc each proposal's detail is following. https://wiki.openstack.org/wiki/Proposal_vDC -- Kenji Ishii __ 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
