Re: [openstack-dev] [horizon] Do we want new meeting time?
Hi all, Due to the low activity on our weekly meeting, I would like to raise this question again. Do we want a new meeting day and/or time? I'm available any day except Tuesday and Wednesday. I'm going to get some feedback before I create a new poll. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Apr 5, 2018 at 1:42 PM Ivan Kolodyazhny wrote: > Hi team, > > It's a friendly reminder that we've got voting open [1] until next > meeting. If you would like to attend Horizon meetings, please, select > comfortable options for you. > > [1] https://doodle.com/poll/ei5gstt73d8v3a35 > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Wed, Mar 21, 2018 at 6:40 PM, Ivan Kolodyazhny wrote: > >> Hi team, >> >> As was discussed at PTG, usually we've got a very few participants on our >> weekly meetings. I hope, mostly it's because of not comfort meeting time >> for many of us. >> >> Let's try to re-schedule Horizon weekly meetings and get more attendees >> there. I've created a doodle for it [1]. Please, vote for the best time for >> you. >> >> >> [1] https://doodle.com/poll/ei5gstt73d8v3a35 >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> > > __ 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] No meeting this week
Hi team, Let's skip the meeting tomorrow due to the OpenStack Summit. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [cinder][manila] Cinder and Friends Dinner at Berlin Summit ...
Thanks for organizing this, Jay, Just in case if you missed it, Matrix Party hosted by Trilio + Red Hat will be on Tuesday too. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Nov 8, 2018 at 12:43 AM Jay S Bryant wrote: > All, > > I am working on scheduling a dinner for the Cinder team (and our extended > family that work on and around Cinder) during the Summit in Berlin. I have > created an etherpad for people to RSVP for dinner [1]. > > It seemed like Tuesday night after the Marketplace Mixer was the best time > for most people. > > So, it will be a little later dinner ... 8 pm. Here is the place: > Location: http://www.dicke-wirtin.de/ > Address: Carmerstraße 9, 10623 Berlin, Germany > > It looks like the kind of place that will fit for our usual group. > > If planning to attend please add your name to the etherpad and I will get > a reservation in over the weekend. > > Hope to see you all on Tuesday! > > Jay > > [1] https://etherpad.openstack.org/p/BER-cinder-outing-planning > __ > 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][plugins] Horizon plugins validation on CI
Hi Tony, I like the idea to get functional tests instead of tempest. We can extend our functional tests to plugins. Personally, I don't have a strong opinion on what way we should go forward. I'll support any community decision which helps us to get cross projects CI up and running. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Oct 18, 2018 at 4:55 AM Tony Breeds wrote: > On Wed, Oct 17, 2018 at 04:18:26PM +0300, Ivan Kolodyazhny wrote: > > Hi all, > > > > We discussed this topic at PTG both with Horizon and other teams. Sounds > > like everybody is interested to have some cross-project CI jobs to verify > > that plugins are not broken with the latest Horizon changes. > > > > The initial idea was to use tempest plugins for this effort like we do > for > > Horizon [1]. We've got a very simple test to verify that Horizon is up > and > > running and a user is able to login. > > > > It's easy to implement such tests for any existing horizon plugin. I > tried > > it for Heat and Manila dashboards. > > Given that I know very little about this but isn't it just as simple as > running the say the octavia-dashboard[1] npm tests on all horizon changes? > This would be similar to the way we run the nova[2] functional tests on all > constraints changes in openstack/requirements. > > Yours Tony. > > [1] Of course all dashbaords/plugins > [2] Not just nova but you get the idea > __ > 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][nova][cinder][keystone][glance][neutron][swift] Horizon feature gaps
Hi teams, 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. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][plugins] Horizon plugins validation on CI
Hi all, We discussed this topic at PTG both with Horizon and other teams. Sounds like everybody is interested to have some cross-project CI jobs to verify that plugins are not broken with the latest Horizon changes. The initial idea was to use tempest plugins for this effort like we do for Horizon [1]. We've got a very simple test to verify that Horizon is up and running and a user is able to login. It's easy to implement such tests for any existing horizon plugin. I tried it for Heat and Manila dashboards. If I understand correctly how tempest plugins work, for such case we've got such options: a) to create the same tempest plugins for each plugin - it this case, we need to maintain new repos for tempest plugins b) add these tests to Horizon tempest plugin - in such case, it will be harder for plugin maintainers to support these tests. If we don't want to go forward with tempest plugins, we can create similar tests based on Horizon functional tests. I want to get more feedback both from Horizon and plugins teams on which direction we should go and start implementation. [1] https://github.com/openstack/tempest-horizon/blob/master/tempest_horizon/tests/scenario/test_dashboard_basic_ops.py#L138 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] Horizon tutorial didn`t work
Hi Jea-Min, I filed a bug [1] and proposed a fix for it [2] [1] https://bugs.launchpad.net/horizon/+bug/1796312 [2] https://review.openstack.org/608274 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Oct 2, 2018 at 6:55 AM Jea-Min Lim wrote: > Thanks for the reply. > > If you need any detailed information, let me know. > > Regards, > > 2018년 10월 1일 (월) 오후 6:53, Ivan Kolodyazhny 님이 작성: > >> Hi Jea-Min, >> >> Thank you for your report. I'll check the manual and fix it asap. >> >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> >> On Mon, Oct 1, 2018 at 9:38 AM Jea-Min Lim wrote: >> >>> Hello everyone, >>> >>> I`m following a tutorial of Building a Dashboard using Horizon. >>> (link: >>> https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html#tutorials-dashboard >>> ) >>> >>> However, provided custom management command doesn't create boilerplate >>> code. >>> >>> I typed tox -e manage -- startdash mydashboard --target >>> openstack_dashboard/dashboards/mydashboard >>> >>> and the attached screenshot file is the execution result. >>> >>> Are there any recommendations to solve this problem? >>> >>> Regards. >>> >>> [image: result_jmlim.PNG] >>> >>> __ >>> 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
Re: [openstack-dev] [cinder] Proposing Gorka Eguileor to Stable Core ...
+1 from me to Gorka! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Oct 3, 2018 at 5:47 PM Jay S. Bryant wrote: > Team, > > We had discussed the possibility of adding Gorka to the stable core team > during the PTG. He does review a number of our backport patches and is > active in that area. > > If there are no objections in the next week I will add him to the list. > > Thanks! > > Jay (jungleboyj) > > > __ > 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][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)
Thanks for working on it, Shu. Let's unblock gates and find a better long-term solution Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Oct 1, 2018 at 7:55 PM Duc Truong wrote: > Hi Shu, > > Thanks for proposing your fix. It looks good to me. I have submitted > a similar patch for senlin-dashboard to unblock the broken gate test [1]. > > [1] https://review.openstack.org/#/c/607003/ > > Regards, > > Duc (dtruong) > On Fri, Sep 28, 2018 at 2:24 AM Shu M. wrote: > > > > Hi Ivan, > > > > Thank you for your help to our plugins and sorry for bothering you. > > I found problem on installing horizon in "post-install", e.g. we should > install horizon with upper-constraints.txt in "post-install". > > I proposed patch[1] in zun-ui, please check it. If we can merge this, I > will expand it the other remaining plugins. > > > > [1] https://review.openstack.org/#/c/606010/ > > > > Thanks, > > Shu Muto > > > > 2018年9月28日(金) 3:34 Ivan Kolodyazhny : > >> > >> Hi, > >> > >> Unfortunately, this issue affects some of the plugins too :(. At least > gates for the magnum-ui, senlin-dashboard, zaqar-ui and zun-ui are broken > now. I'm working both with project teams to fix it asap. Let's wait if [5] > helps for senlin-dashboard and fix all the rest of plugins. > >> > >> > >> [5] https://review.openstack.org/#/c/605826/ > >> > >> Regards, > >> Ivan Kolodyazhny, > >> http://blog.e0ne.info/ > >> > >> > >> On Wed, Sep 26, 2018 at 4:50 PM Ivan Kolodyazhny > wrote: > >>> > >>> Hi all, > >>> > >>> Patch [1] is merged and our gates are un-blocked now. I went throw > review list and post 'recheck' where it was needed. > >>> > >>> We need to cherry-pick this fix to stable releases too. I'll do it asap > >>> > >>> Regards, > >>> Ivan Kolodyazhny, > >>> http://blog.e0ne.info/ > >>> > >>> > >>> On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny > wrote: > >>>> > >>>> Hi team, > >>>> > >>>> Unfortunately, horizon gates are broken now. We can't merge any patch > due to the -1 from CI. > >>>> I don't want to disable tests now, that's why I proposed a fix [1]. > >>>> > >>>> We'd got released some of XStatic-* packages last week. At least new > XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for > requirements repo [4] to prevent such issues in the future. > >>>> > >>>> Please, do not try 'recheck' until [1] will be merged. > >>>> > >>>> [1] https://review.openstack.org/#/c/604611/ > >>>> [2] https://pypi.org/project/XStatic-jQuery/#history > >>>> [3] https://bugs.launchpad.net/horizon/+bug/1794028 > >>>> [4] https://review.openstack.org/#/c/604613/ > >>>> > >>>> Regards, > >>>> Ivan Kolodyazhny, > >>>> http://blog.e0ne.info/ > >> > >> > __ > >> 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
Re: [openstack-dev] [Horizon] Horizon tutorial didn`t work
Hi Jea-Min, Thank you for your report. I'll check the manual and fix it asap. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Oct 1, 2018 at 9:38 AM Jea-Min Lim wrote: > Hello everyone, > > I`m following a tutorial of Building a Dashboard using Horizon. > (link: > https://docs.openstack.org/horizon/latest/contributor/tutorials/dashboard.html#tutorials-dashboard > ) > > However, provided custom management command doesn't create boilerplate > code. > > I typed tox -e manage -- startdash mydashboard --target > openstack_dashboard/dashboards/mydashboard > > and the attached screenshot file is the execution result. > > Are there any recommendations to solve this problem? > > Regards. > > [image: result_jmlim.PNG] > __ > 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][plugins] npm jobs fail due to new XStatic-jQuery release (was: Horizon gates are broken)
Hi, Unfortunately, this issue affects some of the plugins too :(. At least gates for the magnum-ui, senlin-dashboard, zaqar-ui and zun-ui are broken now. I'm working both with project teams to fix it asap. Let's wait if [5] helps for senlin-dashboard and fix all the rest of plugins. [5] https://review.openstack.org/#/c/605826/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Sep 26, 2018 at 4:50 PM Ivan Kolodyazhny wrote: > Hi all, > > Patch [1] is merged and our gates are un-blocked now. I went throw review > list and post 'recheck' where it was needed. > > We need to cherry-pick this fix to stable releases too. I'll do it asap > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > > On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny wrote: > >> Hi team, >> >> Unfortunately, horizon gates are broken now. We can't merge any patch due >> to the -1 from CI. >> I don't want to disable tests now, that's why I proposed a fix [1]. >> >> We'd got released some of XStatic-* packages last week. At least new >> XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for >> requirements repo [4] to prevent such issues in the future. >> >> Please, do not try 'recheck' until [1] will be merged. >> >> [1] https://review.openstack.org/#/c/604611/ >> [2] https://pypi.org/project/XStatic-jQuery/#history >> [3] https://bugs.launchpad.net/horizon/+bug/1794028 >> [4] https://review.openstack.org/#/c/604613/ >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> > __ 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] Horizon gates are broken
Hi all, Patch [1] is merged and our gates are un-blocked now. I went throw review list and post 'recheck' where it was needed. We need to cherry-pick this fix to stable releases too. I'll do it asap Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Sep 24, 2018 at 11:18 AM Ivan Kolodyazhny wrote: > Hi team, > > Unfortunately, horizon gates are broken now. We can't merge any patch due > to the -1 from CI. > I don't want to disable tests now, that's why I proposed a fix [1]. > > We'd got released some of XStatic-* packages last week. At least new > XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for > requirements repo [4] to prevent such issues in the future. > > Please, do not try 'recheck' until [1] will be merged. > > [1] https://review.openstack.org/#/c/604611/ > [2] https://pypi.org/project/XStatic-jQuery/#history > [3] https://bugs.launchpad.net/horizon/+bug/1794028 > [4] https://review.openstack.org/#/c/604613/ > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > __ 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] Horizon gates are broken
Hi team, Unfortunately, horizon gates are broken now. We can't merge any patch due to the -1 from CI. I don't want to disable tests now, that's why I proposed a fix [1]. We'd got released some of XStatic-* packages last week. At least new XStatic-jQuery [2] breaks horizon [3]. I'm working on a new job for requirements repo [4] to prevent such issues in the future. Please, do not try 'recheck' until [1] will be merged. [1] https://review.openstack.org/#/c/604611/ [2] https://pypi.org/project/XStatic-jQuery/#history [3] https://bugs.launchpad.net/horizon/+bug/1794028 [4] https://review.openstack.org/#/c/604613/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][plugins] Development environment for Horizon plugins
Hi team, Some time ago we've found an issue that there is no simple way to test Horizon plugin locally with the current version of Horizon [1], [2]. It leads to the situation when plugins developers use the latest released Horizon version instead of the latest master during new features development. This issue is not reproduced on CI because Zuul does a great job here. We discussed this issue at the PTG [2] (line #163) and decided to go forward with a such [3] solution for now instead of a custom solution in each plugin like [4]. If anybody has any other ideas or concerns, please let me know. [1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html [2] https://etherpad.openstack.org/p/horizon-ptg-planning-denver-2018 [3] https://review.openstack.org/#/c/601836/ [4] https://github.com/openstack/magnum-ui/blob/master/tox.ini#L23 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] No meeting next week
Hi team, A lot of us will attend PTG in Denver next week so we skip the meeting on 9/12. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][stable] Removing Inactive Cores
Hi team, Since we're at the beginning of Stein release cycle, I think it's a good time to do some cleanup in our core teams. First of all, I would like to say a big Thank you to everybody who contributed as Core Reviewer to Horizon. Unfortunately, some people became inactive as reviewers during the last few cycles, that's why I propose to remove them from Horizon Core and Horizon Stable Core teams. I'm pretty sure that you could be added to the teams again once your contribution will be active again. Changes to horizon-core team: - Kenji Ishii - Tatiana Ovchinnikova - Ying Zuo Changes to horizon-stable-maint team: - Doug Fish - Lin Hua Cheng - Matthias Runge - Richard Jones - Rob Cresswell - Thai Tran - Ying Zuo Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [Cinder] How to mount NFS volume?
Hi Clay, Unfortunately, local-attach doesn't support NFS-based volumes due to the security reasons. We haven't the good solution now for multi-tenant environments. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Fri, Aug 17, 2018 at 12:03 PM, Chang, Clay (HPS OE-Linux TDC) < cl...@hpe.com> wrote: > Hi, > > > > I have Cinder configured with NFS backend. On one bare metal node, I can > use ‘cinder create’ to create the volume with specified size – I saw a > volume file create on the NFS server, so I suppose the NFS was configured > correctly. > > > > My question is, how could I mount the NFS volume on the bare metal node? > > > > I tried: > > > > cinder local-attach 3f66c360-e2e1-471e-aa36-57db3fcf3bdb –mountpoint > /mnt/tmp > > > > it says: > > > > “ERROR: Connect to volume via protocol NFS not supported” > > > > I looked at https://github.com/openstack/python-brick-cinderclient-ext/b > lob/master/brick_cinderclient_ext/volume_actions.py, found only iSCSI, > RBD and FIBRE_CHANNEL were supported. > > > > Wondering if there are ways to mount the NFS volume? > > > > Thanks, > > Clay > > __ > 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] [freezer][tc] removing freezer from governance
Hi Rog, If your company uses Freezer in production clouds, maybe you can help the community with supporting it? I know, that it could be a long and not easy decision but it's the only way you can be sure that the project is alive. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Sat, Aug 4, 2018 at 5:33 AM, Rong Zhu wrote: > Hi, all > > I think backup restore and disaster recovery is one the import things in > OpenStack, And our > company(ZTE) has already integrated freezer in our production. And did > some features base on > freezer, we could push those features to community. Could you give us a > chance to take over > freezer in Stein cycle, If things still no progress, we cloud do this > action after Stein cycle. > > Thank you for your consideration. > > -- > Thanks, > Rong Zhu > > On Sat, Aug 4, 2018 at 3:16 AM Doug Hellmann > wrote: > >> Based on the fact that the Freezer team missed the Rocky release and >> Stein PTL elections, I have proposed a patch to remove the project from >> governance. If the project is still being actively maintained and >> someone wants to take over leadership, please let us know here in this >> thread or on the patch. >> >> Doug >> >> https://review.openstack.org/#/c/588645/ >> >> >> __ >> 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
Re: [openstack-dev] [infra][horizon][osc] ClientImpact tag automation
Hi all, Auto-created bugs could help in this effort. Honestly, nobody can say will it work or not before we try it. >From a Horizon's perspective, we need to have some solution which helps us to know about new features that would be good to add them to UI in the future. We started with an etherpad [1] as a first step for now. [1] https://etherpad.openstack.org/p/horizon-feature-gap Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Aug 2, 2018 at 11:38 PM, Jeremy Stanley wrote: > On 2018-08-02 14:16:10 -0500 (-0500), Sean McGinnis wrote: > [...] > > Interesting... I hadn't looked into Gerrit functionality enough to know > about > > these. Looks like this is probably what you are referring to? > > > > https://gerrit.googlesource.com/plugins/its-storyboard/ > > Yes, that. Khai Do (zaro) did the bulk of the work implementing it > for us but isn't around as much these days (we miss you!). > > > It's been awhile since I did anything significant with Java, but that > might be > > an option. Maybe a fun weekend project at least to see what it would > take to > > create an its-launchpad plugin. > [...] > > Careful; if you let anyone know you've touched a Gerrit plug-in the > requests for more help will never end. > -- > Jeremy Stanley > > __ > 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] [requirements][ffe] Critical bug found in python-cinderclient
Hi, I'm OK with this release both from Cinder and Horizon perspective. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Jul 31, 2018 at 10:50 PM, Doug Hellmann wrote: > Excerpts from Sean McGinnis's message of 2018-07-31 14:15:08 -0500: > > A critical bug has been found in python-cinderclient that is impacting > both > > horizon and python-openstackclient (at least). > > > > https://bugs.launchpad.net/cinder/+bug/1784703 > > > > tl;dr is, something new was added with a microversion, but support for > that was > > done incorrectly such that nothing less than that new microversion would > be > > allowed. This patch addresses the issue: > > > > https://review.openstack.org/587601 > > > > Once that lands we will need a new python-cinderclient release to unbreak > > clients. We may want to blacklist python-cinderclient 4.0.0, but I think > at > > least just raising the upper-constraints should get things working again. > > > > Sean > > > > Both adding the exclusion and changing the upper constraint makes sense, > since it will ensure that bad version never makes it back into the > constraints list. > > We don't need to sync the exclusion setting into all of the projects > that depend on the client, so we won't need a new release of any of the > downstream consumers. > > We could add the exclusion to OSC on master, just for accuracy's sake. > > Doug > > __ > 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] PTL on vacation: what to do with meeting and RC1?
Hi team, I'll be on PTO next week. Are we OK to cancel the next meeting? I remember that next week is a deadline for RC1, so I'm going to propose a patch to release it a bit later next week: Tuesday or Wednesday. In an emergency case, please, reach me via e-mail because I'll have a limited internet access so I'll be mostly offline in IRC. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [election][horizon][ptl] PTL Candidacy for Stein Release
Hello everyone, I would like to announce my candidacy for PTL of Horizon for Stein release. I had the honor to serve PTL role in the Rocky timeframe and I want to continue work with such a great team with PTL hat. During Rocky release cycle we worked mostly on the technical dept. We improved our CI with new jobs for Selenium tests. Some work is still in progress on getting integration tests working again. We're pretty close to reaching mox to mock migration community goal. I would like to work on these areas in Stein release too. In addition to this, as PTL I'm going to work on the following areas: * Finish work on mox to mock migrations and integration tests CI job. * More cross projects work should be done: cross-project CI jobs for plugins, work closely with projects teams to understand which features should be implemented in Horizon. * We need to help to contributors to get patches merged faster: work closely with new contributors, improve documentation to get it friendly both for JavaScript and Python developers. I'm looking forward to working together with all of you on Stein release and hope for your help with my efforts. Thank you, Ivan Kolodyazhny (e0ne) __ 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] [cinder] about block device driver
Do you use the volumes on the same nodes where instances are located? Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Jul 17, 2018 at 11:52 AM, Rambo wrote: > yes,My cinder driver is LVM+LIO.I have upload the test result in > appendix.Can you show me your test results?Thank you! > > > > -- Original -- > *From: * "Ivan Kolodyazhny"; > *Date: * Tue, Jul 17, 2018 04:09 PM > *To: * "OpenStack Developmen"; > *Subject: * Re: [openstack-dev] [cinder] about block device driver > > Rambo, > > Did you try to use LVM+LIO target driver? It shows pretty good performance > comparing to BlockDeviceDriver, > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Tue, Jul 17, 2018 at 10:24 AM, Rambo wrote: > >> Oh,the instances using Cinder perform intense I/O, thus iSCSI or LVM is >> not a viable option - benchmarked them several times, unsatisfactory >> results.Sometimes it's IOPS is twice as bad,could you show me your test >> data?Thank you! >> >> >> >> Cheers, >> Rambo >> >> >> -- Original -- >> *From:* "Sean McGinnis"; >> *Date:* 2018年7月16日(星期一) 晚上9:32 >> *To:* "OpenStack Developmen"; >> *Subject:* Re: [openstack-dev] [cinder] about block device driver >> >> On Mon, Jul 16, 2018 at 01:32:26PM +0200, Gorka Eguileor wrote: >> > On 16/07, Rambo wrote: >> > > Well,in my opinion,the BlockDeviceDriver is more suitable than any >> other solution for data processing scenarios.Does the community will agree >> to merge the BlockDeviceDriver to the Cinder repository again if our >> company hold the maintainer and CI? >> > > >> > >> > Hi, >> > >> > I'm sure the community will be happy to merge the driver back into the >> > repository. >> > >> >> The other reason for its removal was its inability to meet the minimum >> feature >> set required for Cinder drivers along with benchmarks showing the LVM and >> iSCSI >> driver could be tweaked to have similar or better performance. >> >> The other option would be to not use Cinder volumes so you just use local >> storage on your compute nodes. >> >> Readding the block device driver is not likely an option. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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:unsubscrib >> e >> 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 > > 99BB7964@8738C509.52AE4D5B.png Description: Binary data __ 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] [cinder] about block device driver
Rambo, Did you try to use LVM+LIO target driver? It shows pretty good performance comparing to BlockDeviceDriver, Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Jul 17, 2018 at 10:24 AM, Rambo wrote: > Oh,the instances using Cinder perform intense I/O, thus iSCSI or LVM is > not a viable option - benchmarked them several times, unsatisfactory > results.Sometimes it's IOPS is twice as bad,could you show me your test > data?Thank you! > > > > Cheers, > Rambo > > > -- Original -- > *From:* "Sean McGinnis"; > *Date:* 2018年7月16日(星期一) 晚上9:32 > *To:* "OpenStack Developmen"; > *Subject:* Re: [openstack-dev] [cinder] about block device driver > > On Mon, Jul 16, 2018 at 01:32:26PM +0200, Gorka Eguileor wrote: > > On 16/07, Rambo wrote: > > > Well,in my opinion,the BlockDeviceDriver is more suitable than any > other solution for data processing scenarios.Does the community will agree > to merge the BlockDeviceDriver to the Cinder repository again if our > company hold the maintainer and CI? > > > > > > > Hi, > > > > I'm sure the community will be happy to merge the driver back into the > > repository. > > > > The other reason for its removal was its inability to meet the minimum > feature > set required for Cinder drivers along with benchmarks showing the LVM and > iSCSI > driver could be tweaked to have similar or better performance. > > The other option would be to not use Cinder volumes so you just use local > storage on your compute nodes. > > Readding the block device driver is not likely an option. > > __ > 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] Planning Etherpad for Denver PTG
Hi team, I've created an etherpad [1] to gather topics for PTG discussions in Denver. Please, do not hesitate to add any topic you think is valuable even you won't attend PTG. I hope to see all of you in September! [1] https://etherpad.openstack.org/p/horizon-ptg-planning-denver-2018 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] Cinder volume Troubleshoot
Hi Kevin, Do you have any errors or tracebacks in /var/log/cinder/cinder-volume.log? Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Sun, Jul 1, 2018 at 12:02 PM, Kevin Kwon wrote: > > Dear All! > > > would you please let me know how can troubleshoot below case? > > i don't know why below Storage server is down. > > Please help to figure it out.. > > > root@OpenStack-Controller:~# openstack volume service list > +--+---+--+- > +---++ > | Binary | Host | Zone | Status | State | > Updated At | > +--+---+--+- > +---++ > | cinder-scheduler | OpenStack-Controller | nova | enabled | up| > 2018-07-01T08:58:19.00 | > | cinder-volume| OpenStack-Storage@lvm | nova | enabled | down | > 2018-07-01T07:28:59.00 | > +--+---+--+- > +---++ > root@OpenStack-Controller:~# > > > Kevin > > > ___ > Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/ > openstack > Post to : openst...@lists.openstack.org > Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/ > openstack > > __ 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] [stable][horizon] Adding Ivan Kolodyazhny to horizon-stable-maint
Thank you Tony and Team! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Jun 25, 2018 at 3:06 AM, Tony Breeds wrote: > On Mon, Jun 18, 2018 at 12:03:52PM +1000, Tony Breeds wrote: > > > Without strong objections I'll do that on (my) Monday 25th June. > > Done. > > Yours Tony. > > __ > 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][plugins] Introduce horizonlib (again)
Hi Doug, We discussed this option a bit too. Maybe we need to think about this again. >From my point of view, it would be better to keep current release model for now, because we've got a very small amount of active horizon contributors, so current release model helps us deliver the project in time. From the other side, your option is less complicated and could be easier to implement. Let's get more feedback from the team before further discussion. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Jun 13, 2018 at 6:43 PM, Doug Hellmann wrote: > Excerpts from Ivan Kolodyazhny's message of 2018-06-13 18:01:26 +0300: > > Hi team, > > > > Last week on the Horizon meeting we discussed [1] possible options for > > Horizon release model to address current issues for plugins maintainers. > > Some background could be found here [2]. > > > > The main issue is that we should have some stable API for plugins and be > > able to release it as needed. We're trying to cover several use cases > with > > this effort. E.g: > > - do not break plugins with Horizon changes (cross-project CI would help > > with some issues here too) > > - provide an easy way to develop plugins which require specific Horizon > > version and features > > > > For now, most of the plugins use 'horizon' package to implement > > dashboard extensions. Some plugins use parts of 'openstack_dashboard' > > package. In such case, it becomes complicated to develop plugins based on > > current master and have CI up and running. > > > > The idea is to introduce something like 'horizonlib' or 'horizon-sdk' > with > > a stable API for plugin development. We're going to collect everything > > needed for this library, so plugins developers could consume only it and > do > > not relate on any internal Horizon things. > > > > We'd got horizonlib in the past. Unfortunately, we missed information > about > > what was good or bad but we'll do our best to succeed in this. > > > > > > If you have any comments or questions, please do not hesitate to drop few > > words into this conversation or ping me in IRC. We're going to collect as > > much feedback as we can before we'll discuss it in details during the > next > > PTG. > > > > > > [1] > > http://eavesdrop.openstack.org/meetings/horizon/2018/ > horizon.2018-06-06-15.01.log.html#l-29 > > [2] > > http://lists.openstack.org/pipermail/openstack-dev/2018- > March/128310.html > > > > Regards, > > Ivan Kolodyazhny, > > http://blog.e0ne.info/ > > Another solution that may end up being less work is to release Horizon > using the cycle-with-intermediary model and publish the releases to > PyPI. Those two changes would let you release changes at any point in > the cycle, to support your plugin authors, and would not require > reorganizing the code in Horizon to build a new release artifact. > > The release team would be happy to offer advice about how to make the > changes, if you want to talk about it. > > Doug > > __ > 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][plugins] Third-party JavaScript libraries and Xstatic Python packages
Fixed horizon tag in the subject :( Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Jun 18, 2018 at 4:11 PM, Ivan Kolodyazhny wrote: > Hi team, > > As you may know, Horizon uses both Python and JavaScript dependencies as > well. All of our JS dependencies are packed into the xstatic-* packages > which could be installed like a regular python package. All current > xstatic-* packages could be found on the Horizon's deliverables list [1]. > > We need all of these things to make development and packaging processes > easier. > > Of course, we can't cover all cases and JS libs, so there is a manual on > how to create new xstatic package [2]. > > > Historically, all xstatic-* projects were maintained by Horizon Core > team. Probably, they were introduced even before we've got plugins > implemented but it doesn't matter at this point. > > Today, when we've got dozens of horizon plugins [3], some of them would > like to use new xstatic packages which are not existing at the moment. E.g.: > - heat-dashboard uses some JS libs which are nor required by Horizon > itself. > - vitrage-dashboard team is going to use React in their plugin. > > We discussed it briefly on the last meeting [4], As Horizon team, we don't > want to forbid using some 3rd-party JS lib if it's acceptable by license. > From the other side, Horizon Core team can't maintain all xstatic-* > packages which could be needed by plugins. That's why we decided to add > some folks form heat-dashboard team to xstatic-* core for that projects, > which are used only be Heat Dashboard now. IMO, it looks like a reasonable > and fair enough solution. > > I think we're OK if plugin teams will share the responsibility to maintain > their xstatic-* dependencies both with Horizon team following current > guidelines [2]. > > Maintaining xstatic-* project means: > - create this repo according to the current guidelines > - follow community rules according to stable policy > - publish a new version of xstatic project if it's required by bugfixes, > security fixes, new features > - help other teams to integrate this project into their plugin. > > > I hope if we agree on things above it helps both Horizon and plugin teams > to deliver new versions faster with a limited teams capacity. > > > > [1] https://governance.openstack.org/tc/reference/projects/horizon.html# > deliverables > [2] https://docs.openstack.org/horizon/latest/contributor/ > contributing.html#javascript-and-css-libraries-using-xstatic > [3] https://docs.openstack.org/horizon/latest/install/plugin-registry.html > [4] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06- > 13-15.04.log.html#l-124 > > > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > __ 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] [horiozn][plugins] Third-party JavaScript libraries and Xstatic Python packages
Hi team, As you may know, Horizon uses both Python and JavaScript dependencies as well. All of our JS dependencies are packed into the xstatic-* packages which could be installed like a regular python package. All current xstatic-* packages could be found on the Horizon's deliverables list [1]. We need all of these things to make development and packaging processes easier. Of course, we can't cover all cases and JS libs, so there is a manual on how to create new xstatic package [2]. Historically, all xstatic-* projects were maintained by Horizon Core team. Probably, they were introduced even before we've got plugins implemented but it doesn't matter at this point. Today, when we've got dozens of horizon plugins [3], some of them would like to use new xstatic packages which are not existing at the moment. E.g.: - heat-dashboard uses some JS libs which are nor required by Horizon itself. - vitrage-dashboard team is going to use React in their plugin. We discussed it briefly on the last meeting [4], As Horizon team, we don't want to forbid using some 3rd-party JS lib if it's acceptable by license. >From the other side, Horizon Core team can't maintain all xstatic-* packages which could be needed by plugins. That's why we decided to add some folks form heat-dashboard team to xstatic-* core for that projects, which are used only be Heat Dashboard now. IMO, it looks like a reasonable and fair enough solution. I think we're OK if plugin teams will share the responsibility to maintain their xstatic-* dependencies both with Horizon team following current guidelines [2]. Maintaining xstatic-* project means: - create this repo according to the current guidelines - follow community rules according to stable policy - publish a new version of xstatic project if it's required by bugfixes, security fixes, new features - help other teams to integrate this project into their plugin. I hope if we agree on things above it helps both Horizon and plugin teams to deliver new versions faster with a limited teams capacity. [1] https://governance.openstack.org/tc/reference/projects/horizon.html#deliverables [2] https://docs.openstack.org/horizon/latest/contributor/contributing.html#javascript-and-css-libraries-using-xstatic [3] https://docs.openstack.org/horizon/latest/install/plugin-registry.html [4] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-13-15.04.log.html#l-124 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][plugins] Introduce horizonlib (again)
Hi team, Last week on the Horizon meeting we discussed [1] possible options for Horizon release model to address current issues for plugins maintainers. Some background could be found here [2]. The main issue is that we should have some stable API for plugins and be able to release it as needed. We're trying to cover several use cases with this effort. E.g: - do not break plugins with Horizon changes (cross-project CI would help with some issues here too) - provide an easy way to develop plugins which require specific Horizon version and features For now, most of the plugins use 'horizon' package to implement dashboard extensions. Some plugins use parts of 'openstack_dashboard' package. In such case, it becomes complicated to develop plugins based on current master and have CI up and running. The idea is to introduce something like 'horizonlib' or 'horizon-sdk' with a stable API for plugin development. We're going to collect everything needed for this library, so plugins developers could consume only it and do not relate on any internal Horizon things. We'd got horizonlib in the past. Unfortunately, we missed information about what was good or bad but we'll do our best to succeed in this. If you have any comments or questions, please do not hesitate to drop few words into this conversation or ping me in IRC. We're going to collect as much feedback as we can before we'll discuss it in details during the next PTG. [1] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-06-06-15.01.log.html#l-29 [2] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][plugins][heat][searchlight][murano][sahara][watcher] Use default Django test runner instead of nose
Hi team, In Horizon, we're going to get rid of unsupported Nose and use Django Test Runner instead of it [1]. Nose has some issues and limitations which blocks us in our testing improvement efforts. Nose has different test discovery mechanism than Django does. So, there was a chance to break some Horizon Plugins:(. Unfortunately, we haven't cross-project CI yet (TBH, I'm working on it and it's one of the first steps to get it done), that's why I tested this change [2] against all known plugins [3]. Most of the projects don't need any changes. I proposed few changed to plugins repositories [4] and most of them are merged already. Thanks a lot to everybody who helped me with it. Patches for heat-dashboard [5] and searchlight-ui [6] are under review. Additional efforts are needed for murano-dashboard, sahara-dashboard, and watcher-dashboard projects. murano-dashboard has Nose test runner enabled in the config, so Horizon change won't affect it. I proposed patches for sahara-dashboard [7] and watcher-dashboard [8] to explicitly enable Nose test runner there until we'll fix all related issues. I hope we'll have a good number of cross-project activities with these teams. Once all patches above will be merged, we'll be ready to the next step to make Horizon and plugins CI better. [1] https://review.openstack.org/#/c/544296/ [2] https://docs.google.com/spreadsheets/d/17Yiso6JLeRHBSqJhAiQYkqIAvQhvNFM8NgTkrPxovMo/edit?usp=sharing [3] https://docs.openstack.org/horizon/latest/install/plugin-registry.html [4] https://review.openstack.org/#/q/topic:bp/improve-horizon-testing+(status:open+OR+status:merged) [5] https://review.openstack.org/572095 [6] https://review.openstack.org/572124 [7] https://review.openstack.org/572390 [8] https://review.openstack.org/572391 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [TC] Stein Goal Selection
Hi Sean, These goals look reasonable for me. On Mon, Jun 4, 2018 at 9:07 PM, Sean McGinnis wrote: > Hi everyone, > > This is to continue the discussion of the goal selection for the Stein > release. > I had previously sent out a recap of our discussion at the Forum here: > > http://lists.openstack.org/pipermail/openstack-dev/2018-May/130999.html > > Now we need to actually narrow things down and pick a couple goals. > > Strawman > > > Just to set a starting point for debate, I propose the following two as > goals > for Stein: > > - Cold Upgade Support > - Python 3 first > > As a reminder of other ideas, here is the link to the backlog of goal ideas > we've kept so far: > > https://etherpad.openstack.org/p/community-goals > > Feel free to add more to that list, and if you have been involved in any > of the > things that have been completed there, please remove things you don't think > should still be there. > > This is by no means an exhaustive list of what we could or should do for > goals. > > With that, I'll go over the choices that I've proposed for the strawman. > > Python 3 First > == > > One of the things brought up in the session was picking things that bring > excitement and are obvious benefits to deployers and users of OpenStack > services. While this one is maybe not as immediately obvious, I think this > is something that will end up helping deployers and also falls into the > tech > debt reduction category that will help us move quicker long term. > > Python 2 is going away soon, so I think we need something to help compel > folks > to work on making sure we are ready to transition. This will also be a good > point to help switch the mindset over to Python 3 being the default used > everywhere, with our Python 2 compatibility being just to continue legacy > support. > I hope we'll have Ubuntu 18.04 LTS on our gates for this activity soon. It becomes important not only for developers but for operators and vendors too. > Cold Upgrade Support > > > The other suggestion in the Forum session related to upgrades was the > addition > of "upgrade check" CLIs for each project, and I was tempted to suggest > that as > my second strawman choice. For some projects that would be a very minimal > or > NOOP check, so it would probably be easy to complete the goal. But > ultimately > what I think would bring the most value would be the work on supporting > cold > upgrade, even if it will be more of a stretch for some projects to > accomplish. > > Upgrades have been a major focus of discussion lately, especially as our > operators have been trying to get closer to the latest work upstream. This > has > been an ongoing challenge. > > A big +1 from my side on it. There has also been a lot of talk about LTS releases. We've landed on fast > forward upgrade to get between several releases, but I think improving > upgrades > eases the way both for easier and more frequent upgrades and also getting > to > the point some day where maybe we can think about upgrading over several > releases to be able to do something like an LTS to LTS upgrade. > > Neither one of these upgrade goals really has a clearly defined plan that > projects can pick up now and start working on, but I think with those > involved > in these areas we should be able to come up with a perscriptive plan for > projects to follow. > > And it would really move our fast forward upgrade story forward. > > Next Steps > == > > I'm hoping with a strawman proposal we have a basis for debating the > merits of > these and getting closer to being able to officially select Stein goals. We > still have some time, but I would like to avoid making late-cycle > selections so > teams can start planning ahead for what will need to be done in Stein. > > Please feel free to promote other ideas for goals. That would be a good > way for > us to weigh the pro's and con's between these and whatever else you have in > mind. Then hopefully we can come to some consensus and work towards clearly > defining what needs to be done and getting things well documented for > teams to > pick up as soon as they wrap up Rocky (or sooner). > > --- > Sean (smcginnis) > > __ > 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] Font awesome currently broken with Debian Sid and Horizon
Hi Thomas, > As my python3-xstatic-font-awesome removes the embedded fonts It sounds like you broke xstatic-* packages for Debian and use something we don't test with Horizon at all. Speaking about Rocky/master version, our upper-constraint XStatic-Font-Awesome===4.7.0.0 [1]. We don't test horizon with font awesome v 5.0.10. Second, it'd be nice if Horizon could adapt and use the new v5 > font-awesome, so that the problem is completely solved. +1. I'll put my +2/A once somebody provides a patch for it with a detailed description how can I test it. Unfortunately, Horizon team has a very limited set of resources, so we can't adopt new version of xstatic-* fast :(. [1] https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L61 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, May 30, 2018 at 4:27 PM, Thomas Goirand wrote: > Hi Radomir, > > I'm adding the debian bug as Cc. > > On 05/28/2018 08:35 AM, Radomir Dopieralski wrote: > > I did a quick search for all the glyphs we are using: > > > > ~/dev/horizon(master)> ag 'fa-' | egrep -o 'fa-[a-z-]*' | sort | uniq > > fa- > > fa-angle-left > > [...] > > Thanks for your investigation. > > I did a quick test, and loaded all of these glyphs into a test HTML > page. As much as I can see, only 4 glyphs aren't in fa-solid-900: > > fa-cloud-upload > fa-pencil > fa-share-square-o > fa-sign-out > > It'd be nice if we could replace these by glyphs present in fa-solid-900 > so we could simply replace the old v4 font by fa-solid-900 only. > > Your thoughts? > > Cheers, > > Thomas Goirand (zigo) > > __ > 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] FW: [cinder]
Hello, Please, try `cinder --os-volume-api-versio=3 manageable-list openstack-dev@VMAX_ISCSI_DIAMOND#Diamond+DSS+SRP_1+000297000333` or `OS_VOLUME_API_VERSION=3 cinder manageable-list openstack-dev@VMAX_ISCSI_ DIAMOND#Diamond+DSS+SRP_1+000297000333` Devstack used Cinder API v2 by default before https://review.openstack.org/#/c/566747/ was merged Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, May 24, 2018 at 2:34 AM, Walsh, Helen wrote: > Sending on Michael’s behalf… > > > > > > *From:* McAleer, Michael > *Sent:* Monday 21 May 2018 15:18 > *To:* 'openstack-dev@lists.openstack.org' > *Subject:* FW: [openstack-dev] [cinder] > > > > Hi Cinder Devs, > > > > I would like to ask a question concerning Cinder CLI commands in DevStack > 13.0.0.0b2.dev167. > > > > I stacked a clean environment this morning to run through some sanity > tests of new features, two of which are list manageable volumes > <https://docs.openstack.org/python-cinderclient/latest/cli/details.html#cinder-manageable-list> > and snapshots > <https://docs.openstack.org/python-cinderclient/latest/cli/details.html#cinder-snapshot-manageable-list>. > When I attempt to run this command using Cinder CLI I am getting an invalid > choice error in response: > > > > stack@openstack-dev:~/devstack$ cinder manageable-list > openstack-dev@VMAX_ISCSI_DIAMOND#Diamond+DSS+SRP_1+000297000333 > > [usage output omitted] > > error: argument : invalid choice: u'manageable-list' > > > > The same behaviour can be seen for listing manageable-snapshots also, > invalid choice error. I looked for a similar command using the OpenStack > Volume CLI but there wasn’t any similar commands found which would return a > list of manageable volumes or snapshots. > > > I didn’t see any deprecation notices for the command, and the commands > worked fine in earlier DevStack environments in this Rocky dev cycle, so > just wondering what the status is of the commands and if this is possibly > an oversight. > > > > Thanks! > > Michael > > > > *Michael McAleer* > > Software Engineer 1, Core Technologies > > *Dell **EMC **| *Enterprise Storage Division > > Phone: +353 21 428 1729 > > michael.mcal...@dell.com > > Ireland COE, Ovens, Co. Cork, Ireland > > __ > 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] No meeting on May 23rd
Hi all, Some of the team will be attending the OpenStack summit in Vancouver, so I am canceling the weekly IRC meeting for the 23rd. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] Scheduling switch to django >= 2.0
Hi all, >From the Horizon's perspective, it would be good to support Django 1.11 as long as we can since it's an LTS release [2]. Django 2.0 support is also extremely important because of it's the first step in a python3-only environment and step forward on supporting next Django 2.2 LTS release which will be released next April. We have to be careful to not break existing plugins and deployments by introducing new Django version requirement. We need to work more closely with plugins teams to getting everything ready for Django 2.0+ before we change our requirements.txt. I don't want to introduce any breaking changes for current plugins so we need to to be sure that each plugin supports Django 2.0. It means plugins have to have voting Django 2.0 jobs on their gates at least. I'll do my best on this effort and will work with plugins teams to do as much as we can in Rocky timeframe. [2] https://www.djangoproject.com/download/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, May 14, 2018 at 4:30 PM, Akihiro Motoki wrote: > > > 2018年5月14日(月) 21:42 Doug Hellmann : > >> Excerpts from Akihiro Motoki's message of 2018-05-14 18:52:55 +0900: >> > 2018年5月12日(土) 3:04 Doug Hellmann : >> > >> > > Excerpts from Akihiro Motoki's message of 2018-05-12 00:14:33 +0900: >> > > > Hi zigo and horizon plugin maintainers, >> > > > >> > > > Horizon itself already supports Django 2.0 and horizon unit test >> covers >> > > > Django 2.0 with Python 3.5. >> > > > >> > > > A question to all is whether we change the upper bound of Django >> from >> > > <2.0 >> > > > to <2.1. >> > > > My proposal is to bump the upper bound of Django to <2.1 in Rocky-2. >> > > > (Note that Django 1.11 will continue to be used for python 2.7 >> > > environment.) >> > > >> > > Do we need to cap it at all? We've been trying to express our >> > > dependencies without caps and rely on the constraints list to >> > > test using a common version because this offers the most flexibility >> as >> > > we move to newer versions over time. >> > > >> > >> > The main reason we cap django version so far is that django minor >> version >> > releases >> > contain some backward incompatible changes and also drop deprecated >> > features. >> > A new django minor version release like 1.11 usually breaks horizon and >> > plugins >> > as horizon developers are not always checking django deprecations. >> >> OK. Having the cap in place makes it more complicated to test >> upgrading, and then upgrade. Because we no longer synchronize >> requirements, changing openstack/requirements does not trigger the >> bot to propose the same change to all of the projects using the >> dependency. Someone will have to do that by hand in the future, as we >> are doing with eventlet right now >> (https://review.openstack.org/#/q/topic:uncap-eventlet). >> >> Without the cap, we can test the upgrade by proposing a constraint >> update and running the horizon (and/or plugin) unit tests. When those >> tests pass, we can then step forward all at once by approving the >> constraint change. >> > > Thanks for the detail context. > > Honestly I am not sure which is better to cap or uncap the django version. > We can try uncapping now and see what happens in the community. > > cross-horizon-(py27|py35) jobs of openstack/requirements checks > if horizon works with a new version. it works for horizon, but perhaps it > potentially > break horizon plugins as it takes time to catch up with such changes. > On the other hand, a version bump in upper-constraints.txt would be > a good trigger for horizon plugin maintainers to sync all requirements. > > In addition, requirements are not synchronized automatically, > so it seems not feasible to propose requirements changes per django > version change. > > >> >> > >> > I have a question on uncapping the django version. >> > How can users/operators know which versions are supported? >> > Do they need to check upper-constraints.txt? >> >> We do tell downstream consumers that the upper-constraints.txt file is >> the set of things we test with, and that any other combination of >> packages would need to be tested on their systems separately. >> >> > >> > > > There are several points we should consider: >> > > > - If we change it in global-requirements.txt, it means Django 2.0 >> w
[openstack-dev] [horizon] No meeting this week
Hi team, Due to the Victory Day, I won't be able to chair the meeting this week. After a short conversation in the IRC, we decided to skip this meeting. Feel free to add your topic to https://wiki.openstack.org/wiki/Meetings/Horizon and see you next week! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][nova][cinder] Horizon support for multiattach volumes
Matt, thank you for all your efforts! I'm going to work on Horizon blueprint soon to get it implemented in Rocky Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Apr 25, 2018 at 4:57 PM, Matt Riedemann wrote: > I wanted to advertise the need for some help in adding multiattach volume > support to Horizon. There is a blueprint tracking the changes [1]. I > started the ball rolling with [2] but there is more work to do, listed in > the work items section of the blueprint. > > [2] was I think my first real code contribution to Horizon and it wasn't > terrible (thanks for Akihiro's patience), so I'm sure others could easily > jump in here and slice this up if we have people looking for something to > hack on. > > [1] https://blueprints.launchpad.net/horizon/+spec/multi-attach-volume > [2] https://review.openstack.org/#/c/547856/ > > -- > > 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
Re: [openstack-dev] [requirements][horizon][neutron] plugins depending on services
Hi team, I'm speaking mostly from Horizon side, but it should be pretty the same for others. We started a discussion today at the Horizon's meeting but we don't have any decision now. For the current release cycle, it looks reasonable to test plugins over the latest master on gates. We're thinking to introduce horizon-lib but we need further discussions on it. Horizon follows stable policy and we try to do our best to not break any existing plugin. Unfortunately, due to some cross-projects miscommunications, there were some issues with plugins this cycle. I'm ready to work with plugins team to fix these issues asap. To prevent such issues in the future, I think it would be good to have cross-project jobs on Horizon's gates too. We should run at least plugins unit-tests against Horizon's proposed patch to make sure that we don't break anything in plugins. E.g. if we drop some deprecated feature or make an incompatible change, such job will notify us that we need to update a plugin first before merging patch to Horizon. I don't know what is the best way to implement such jobs so it would be good to get some inputs and help from Infra team here. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Apr 25, 2018 at 7:40 PM, Jeremy Stanley wrote: > On 2018-04-25 12:03:54 -0400 (-0400), Doug Hellmann wrote: > [...] > > Especially now with lower-constraints jobs in place, having plugins > > rely on features only available in unreleased versions of service > > projects doesn't make a lot of sense. We test that way *between* > > services using integration tests that use the REST APIs, but we > > also have some pretty strong stability requirements in place for > > those APIs. > [...] > > This came up again a few days ago for sahara-dashboard. We talked > through some obvious alternatives to keep its master branch from > depending on an unreleased state of horizon and the situation today > is that plugin developers have been relying on developing their > releases in parallel with the services. Not merging an entire > development cycle's worth of work until release day (whether that's > by way of a feature branch or by just continually rebasing and > stacking in Gerrit) would be a very painful workflow for them, and > having to wait a full release cycle before they could start > integrating support for new features in the service would be equally > unfortunate. > > As for merging the plugin and service repositories, they tend to be > developed by completely disparate teams so that could require a fair > amount of political work to solve. Extracting the plugin interface > into a separate library which releases more frequently than the > service does indeed sound like the sanest option, but will also > probably take quite a while for some teams to achieve (I gather > neutron-lib is getting there, but I haven't heard about any work > toward that end in Horizon yet). > -- > Jeremy Stanley > > __ > 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] Meeting time and location are changed
Hi, It's just a reminder that we've got our meeting today at 15.00UTC at openstack-meeting-alt channel. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Apr 16, 2018 at 12:01 PM, Ivan Kolodyazhny wrote: > Hi team, > > Please be informed that Horizon meeting time has been changed [1]. We'll > have our weekly meetings at 15.00 UTC starting this week at > 'openstack-meeting-alt' channel. We had to change meeting channel too due > to the conflict with others. > > > [1] https://review.openstack.org/#/c/560979/ > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > __ 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] Meeting time and location are changed
Hi team, Please be informed that Horizon meeting time has been changed [1]. We'll have our weekly meetings at 15.00 UTC starting this week at 'openstack-meeting-alt' channel. We had to change meeting channel too due to the conflict with others. [1] https://review.openstack.org/#/c/560979/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][plugins] Improve Horizon testing
Hi all, Let me introduce my proposal about Horizon testing improvements[1]. We started this discussion at the last PTG [2] and had a good conversation at the previous meeting [3]. The idea is simple: to have CI that verifies Horizon changes across supported plugins. As a side-effect of this activity, we'll have a list of maintained and supported plugins per each release. For now, we have a static list in Horizon Install Guide only [4] We don't have Selenium-based tests now. the selenium-headless job always reports success. Integration tests are totally broken and we even don't run them on gates. We need to fix selenium-headless job and integration tests too. It would be great to have new gate job per each plugin per any Horizon code change to be sure that we don't break anything. The same job with plugin-specific selenium or integration tests should be executed against each Horizon plugin's change request. To make this happen, we need to fix horizon's selenium and integration tests first. One of the first steps is to get rid of nose from Horizon and plugins. Initially, I tried to use Django Test Runner but XMLTestRunner [5] looks better for me because of it generates a report in xunit format. Ideally, it would be great to use pytest for it, but it requires more efforts now. stestr requires some work to get it working with Django too. I know that Horizon team already introduced some new things in Rocky which require action from plugins developers like moving to Mock (it's one of the community goals for this release for all projects) and support Django<2.0,>=1.11. That's why I'm ready to help plugins with test runner migration and propose a patch for each plugin in a list [4]. Since it's supposed to be a cross-project activity, I would like to get feedback from Horizon Plugins developers. [1] https://blueprints.launchpad.net/horizon/+spec/improve-horizon-testing [2] https://etherpad.openstack.org/p/horizon-ptg-rocky [3] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-04-04-20.01.log.html#l-25 [4] https://docs.openstack.org/horizon/latest/install/plugin-registry.html [5] https://review.openstack.org/#/c/544296/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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][xstatic]How to handle xstatic if upstream files are modified
Hi, Xinni,
I absolutely agree with Radomir. We should keep xstatic files without
modifications. We don't know if they are used outside of OpenStack or not,
so they should be the same as NPM packages
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
On Mon, Apr 9, 2018 at 12:32 PM, Radomir Dopieralski wrote:
> The whole idea about xstatic files is that they are generic, not specific
> to Horizon or OpenStack, usable by other projects that need those static
> files. In fact, at the time we started using xstatic, it was being used by
> the MoinMoin wiki project (which is now dead, sadly). The modifications you
> made are very specific to your usecase and would make it impossible to
> reuse the packages by other applications (or even by other Horizon
> plugins). The whole idea of a library is that you are using it as it is
> provided, and not modifying it.
>
> We generally try to use all the libraries as they are, and if there are
> any modifications necessary, we push them upstream, to the original
> library. Otherwise there would be quite a bit of maintenance overhead
> necessary to keep all our downstream patches. When considerable
> modification is necessary that can't be pushed upstream, we fork the
> library either into its own repository, or include it in the repository of
> the application that is using it.
>
> On Mon, Apr 9, 2018 at 2:54 AM, Xinni Ge wrote:
>
>> Hello, team.
>>
>> Sorry for talking about xstatic repo for so many times.
>>
>> I didn't realize xstatic repositories should be provided with exactly the
>> same file as upstream, and should have talked about it at very first.
>>
>> I modified several upstream files because some of them files couldn't be
>> used directly under my expectation.
>>
>> For example, {{ }} are used in some original files as template tags, but
>> Horizon adopts {$ $} in angular module, so I modified them to be recognized
>> properly.
>>
>> Another major modification is that css files are converted into scss
>> files to solve some css import issue previously.
>> Besides, after collecting statics, some png file paths in css cannot be
>> referenced properly and shown as 404 errors, I also modified css itself to
>> handle this issues.
>>
>> I will recheck all the un-matched xstatic repositories and try to replace
>> with upstream files as much as I can.
>> But I if I really have to modify some original files, is it acceptable to
>> still use it as embedded files with license info appeared at the top?
>>
>>
>> Best Regards,
>> Xinni Ge
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> 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
Re: [openstack-dev] [horizon] Do we want new meeting time?
Hi team, It's a friendly reminder that we've got voting open [1] until next meeting. If you would like to attend Horizon meetings, please, select comfortable options for you. [1] https://doodle.com/poll/ei5gstt73d8v3a35 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 21, 2018 at 6:40 PM, Ivan Kolodyazhny wrote: > Hi team, > > As was discussed at PTG, usually we've got a very few participants on our > weekly meetings. I hope, mostly it's because of not comfort meeting time > for many of us. > > Let's try to re-schedule Horizon weekly meetings and get more attendees > there. I've created a doodle for it [1]. Please, vote for the best time for > you. > > > [1] https://doodle.com/poll/ei5gstt73d8v3a35 > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > __ 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] [heat-dashboard] Horizon plugin settings for new xstatic modules
Hi Xinni, Please, send me a list of packages which should be released. In general, release-* groups are different from core-*. We should discuss how to go forward with it Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Apr 4, 2018 at 8:34 AM, Xinni Ge wrote: > Hi Ivan and other Horizon team member, > > Thanks for adding us into xstatic-core group. > But I still need your opinion and help to release the newly-added xstatic > packages to pypi index. > > Current `xstatic-core` group doesn't have the permission to PUSH SIGNED > TAG, and I cannot release the first non-trivial version. > > If I (or maybe Kaz) could be added into xstatic-release group, we can > release all the 8 packages by ourselves. > > Or, we are very appreciate if any member of xstatic-release could help to > do it. > > Just for your quick access, here is the link of access permission page of > one xstatic package. > https://review.openstack.org/#/admin/projects/openstack/ > xstatic-angular-material,access > > -- > Best Regards, > Xinni > > On Thu, Mar 29, 2018 at 9:59 AM, Kaz Shinohara > wrote: > >> Hi Ivan, >> >> >> Thank you very much. >> I've confirmed that all of us have been added to xstatic-core. >> >> As discussed, we will focus on the followings what we added for >> heat-dashboard, will not touch other xstatic repos as core. >> >> xstatic-angular-material >> xstatic-angular-notify >> xstatic-angular-uuid >> xstatic-angular-vis >> xstatic-filesaver >> xstatic-js-yaml >> xstatic-json2yaml >> xstatic-vis >> >> Regards, >> Kaz >> >> 2018-03-29 5:40 GMT+09:00 Ivan Kolodyazhny : >> > Hi Kuz, >> > >> > Don't worry, we're on the same page with you. I added both you, Xinni >> and >> > Keichii to the xstatic-core group. Thank you for your contributions! >> > >> > Regards, >> > Ivan Kolodyazhny, >> > http://blog.e0ne.info/ >> > >> > On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara >> wrote: >> >> >> >> Hi Ivan & Horizon folks >> >> >> >> >> >> AFAIK, Horizon team had conclusion that you will add the specific >> >> members to xstatic-core, correct ? >> >> Can I ask you to add the following members ? >> >> # All of tree are heat-dashboard core. >> >> >> >> Kazunori Shinohara / ksnhr.t...@gmail.com #myself >> >> Xinni Ge / xinni.ge1...@gmail.com >> >> Keiichi Hikita / keiichi.hik...@gmail.com >> >> >> >> Please give me a shout, if we are not on same page or any concern. >> >> >> >> Regards, >> >> Kaz >> >> >> >> >> >> 2018-03-21 22:29 GMT+09:00 Kaz Shinohara : >> >> > Hi Ivan, Akihiro, >> >> > >> >> > >> >> > Thanks for your kind arrangement. >> >> > Looking forward to hearing your decision soon. >> >> > >> >> > Regards, >> >> > Kaz >> >> > >> >> > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny : >> >> >> HI Team, >> >> >> >> >> >> From my perspective, I'm OK both with #2 and #3 options. I agree >> that >> >> >> #4 >> >> >> could be too complicated for us. Anyway, we've got this topic on the >> >> >> meeting >> >> >> agenda [1] so we'll discuss it there too. I'll share our decision >> after >> >> >> the >> >> >> meeting. >> >> >> >> >> >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon >> >> >> >> >> >> >> >> >> >> >> >> Regards, >> >> >> Ivan Kolodyazhny, >> >> >> http://blog.e0ne.info/ >> >> >> >> >> >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki > > >> >> >> wrote: >> >> >>> >> >> >>> Hi Kaz and Ivan, >> >> >>> >> >> >>> Yeah, it is worth discussed officially in the horizon team meeting >> or >> >> >>> the >> >> >>> mailing list thread to get a consensus. >> >> >>> Hopefully you can add this topic to the horizon meeting agenda. >> >> >>> >> >> >>> After sending the previous mail, I noticed anther option. I see >> there
Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules
Hi Kuz, Don't worry, we're on the same page with you. I added both you, Xinni and Keichii to the xstatic-core group. Thank you for your contributions! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 28, 2018 at 5:18 PM, Kaz Shinohara wrote: > Hi Ivan & Horizon folks > > > AFAIK, Horizon team had conclusion that you will add the specific > members to xstatic-core, correct ? > Can I ask you to add the following members ? > # All of tree are heat-dashboard core. > > Kazunori Shinohara / ksnhr.t...@gmail.com #myself > Xinni Ge / xinni.ge1...@gmail.com > Keiichi Hikita / keiichi.hik...@gmail.com > > Please give me a shout, if we are not on same page or any concern. > > Regards, > Kaz > > > 2018-03-21 22:29 GMT+09:00 Kaz Shinohara : > > Hi Ivan, Akihiro, > > > > > > Thanks for your kind arrangement. > > Looking forward to hearing your decision soon. > > > > Regards, > > Kaz > > > > 2018-03-21 21:43 GMT+09:00 Ivan Kolodyazhny : > >> HI Team, > >> > >> From my perspective, I'm OK both with #2 and #3 options. I agree that #4 > >> could be too complicated for us. Anyway, we've got this topic on the > meeting > >> agenda [1] so we'll discuss it there too. I'll share our decision after > the > >> meeting. > >> > >> [1] https://wiki.openstack.org/wiki/Meetings/Horizon > >> > >> > >> > >> Regards, > >> Ivan Kolodyazhny, > >> http://blog.e0ne.info/ > >> > >> On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki > wrote: > >>> > >>> Hi Kaz and Ivan, > >>> > >>> Yeah, it is worth discussed officially in the horizon team meeting or > the > >>> mailing list thread to get a consensus. > >>> Hopefully you can add this topic to the horizon meeting agenda. > >>> > >>> After sending the previous mail, I noticed anther option. I see there > are > >>> several options now. > >>> (1) Keep xstatic-core and horizon-core same. > >>> (2) Add specific members to xstatic-core > >>> (3) Add specific horizon-plugin core to xstatic-core > >>> (4) Split core membership into per-repo basis (perhaps too > complicated!!) > >>> > >>> My current vote is (2) as xstatic-core needs to understand what is > xstatic > >>> and how it is maintained. > >>> > >>> Thanks, > >>> Akihiro > >>> > >>> > >>> 2018-03-20 17:17 GMT+09:00 Kaz Shinohara : > >>>> > >>>> Hi Akihiro, > >>>> > >>>> > >>>> Thanks for your comment. > >>>> The background of my request to add us to xstatic-core comes from > >>>> Ivan's comment in last PTG's etherpad for heat-dashboard discussion. > >>>> > >>>> https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion > >>>> Line135, "we can share ownership if needed - e0ne" > >>>> > >>>> Just in case, could you guys confirm unified opinion on this matter as > >>>> Horizon team ? > >>>> > >>>> Frankly speaking I'm feeling the benefit to make us xstatic-core > >>>> because it's easier & smoother to manage what we are taking for > >>>> heat-dashboard. > >>>> On the other hand, I can understand what Akihiro you are saying, the > >>>> newly added repos belong to Horizon project & being managed by not > >>>> Horizon core is not consistent. > >>>> Also having exception might make unexpected confusion in near future. > >>>> > >>>> Eventually we will follow your opinion, let me hear Horizon team's > >>>> conclusion. > >>>> > >>>> Regards, > >>>> Kaz > >>>> > >>>> > >>>> 2018-03-20 12:58 GMT+09:00 Akihiro Motoki : > >>>> > Hi Kaz, > >>>> > > >>>> > These repositories are under horizon project. It looks better to > keep > >>>> > the > >>>> > current core team. > >>>> > It potentially brings some confusion if we treat some horizon plugin > >>>> > team > >>>> > specially. > >>>> > Reviewing xstatic repos would be a small burden, wo I think it would > >>>> > work > >>>> > witho
[openstack-dev] [horizon] Do we want new meeting time?
Hi team, As was discussed at PTG, usually we've got a very few participants on our weekly meetings. I hope, mostly it's because of not comfort meeting time for many of us. Let's try to re-schedule Horizon weekly meetings and get more attendees there. I've created a doodle for it [1]. Please, vote for the best time for you. [1] https://doodle.com/poll/ei5gstt73d8v3a35 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [heat-dashboard] Horizon plugin settings for new xstatic modules
HI Team, >From my perspective, I'm OK both with #2 and #3 options. I agree that #4 could be too complicated for us. Anyway, we've got this topic on the meeting agenda [1] so we'll discuss it there too. I'll share our decision after the meeting. [1] https://wiki.openstack.org/wiki/Meetings/Horizon Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Mar 20, 2018 at 10:45 AM, Akihiro Motoki wrote: > Hi Kaz and Ivan, > > Yeah, it is worth discussed officially in the horizon team meeting or the > mailing list thread to get a consensus. > Hopefully you can add this topic to the horizon meeting agenda. > > After sending the previous mail, I noticed anther option. I see there are > several options now. > (1) Keep xstatic-core and horizon-core same. > (2) Add specific members to xstatic-core > (3) Add specific horizon-plugin core to xstatic-core > (4) Split core membership into per-repo basis (perhaps too complicated!!) > > My current vote is (2) as xstatic-core needs to understand what is xstatic > and how it is maintained. > > Thanks, > Akihiro > > > 2018-03-20 17:17 GMT+09:00 Kaz Shinohara : > >> Hi Akihiro, >> >> >> Thanks for your comment. >> The background of my request to add us to xstatic-core comes from >> Ivan's comment in last PTG's etherpad for heat-dashboard discussion. >> >> https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussion >> Line135 >> <https://etherpad.openstack.org/p/heat-dashboard-ptg-rocky-discussionLine135>, >> "we can share ownership if needed - e0ne" >> >> Just in case, could you guys confirm unified opinion on this matter as >> Horizon team ? >> >> Frankly speaking I'm feeling the benefit to make us xstatic-core >> because it's easier & smoother to manage what we are taking for >> heat-dashboard. >> On the other hand, I can understand what Akihiro you are saying, the >> newly added repos belong to Horizon project & being managed by not >> Horizon core is not consistent. >> Also having exception might make unexpected confusion in near future. >> >> Eventually we will follow your opinion, let me hear Horizon team's >> conclusion. >> >> Regards, >> Kaz >> >> >> 2018-03-20 12:58 GMT+09:00 Akihiro Motoki : >> > Hi Kaz, >> > >> > These repositories are under horizon project. It looks better to keep >> the >> > current core team. >> > It potentially brings some confusion if we treat some horizon plugin >> team >> > specially. >> > Reviewing xstatic repos would be a small burden, wo I think it would >> work >> > without problem even if only horizon-core can approve xstatic reviews. >> > >> > >> > 2018-03-20 10:02 GMT+09:00 Kaz Shinohara : >> >> >> >> Hi Ivan, Horizon folks, >> >> >> >> >> >> Now totally 8 xstatic-** repos for heat-dashboard have been landed. >> >> >> >> In project-config for them, I've set same acl-config as the existing >> >> xstatic repos. >> >> It means only "xstatic-core" can manage the newly created repos on >> gerrit. >> >> Could you kindly add "heat-dashboard-core" into "xstatic-core" like as >> >> what horizon-core is doing ? >> >> >> >> xstatic-core >> >> https://review.openstack.org/#/admin/groups/385,members >> >> >> >> heat-dashboard-core >> >> https://review.openstack.org/#/admin/groups/1844,members >> >> >> >> Of course, we will surely touch only what we made, just would like to >> >> manage them smoothly by ourselves. >> >> In case we need to touch the other ones, will ask Horizon team for >> help. >> >> >> >> Thanks in advance. >> >> >> >> Regards, >> >> Kaz >> >> >> >> >> >> 2018-03-14 15:12 GMT+09:00 Xinni Ge : >> >> > Hi Horizon Team, >> >> > >> >> > I reported a bug about lack of ``ADD_XSTATIC_MODULES`` plugin option, >> >> > and submitted a patch for it. >> >> > Could you please help to review the patch. >> >> > >> >> > https://bugs.launchpad.net/horizon/+bug/1755339 >> >> > https://review.openstack.org/#/c/552259/ >> >> > >> >> > Thank you very much. >> >> > >> >> > Best Regards, >> >> > Xinni >> >> >
Re: [openstack-dev] [horizon] [heat-dashboard] Horizon plugin settings for new xstatic modules
Hi Kaz, Thanks for cleaning this up. I put +1 on both of these patches Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Mar 13, 2018 at 4:48 AM, Kaz Shinohara wrote: > Hi Ivan & Horizon folks, > > > Now we are submitting a couple of patches to have the new xstatic modules. > Let me request you to have review the following patches. > We need Horizon PTL's +1 to move these forward. > > project-config > https://review.openstack.org/#/c/551978/ > > governance > https://review.openstack.org/#/c/551980/ > > Thanks in advance:) > > Regards, > Kaz > > > 2018-03-12 20:00 GMT+09:00 Radomir Dopieralski : > > Yes, please do that. We can then discuss in the review about technical > > details. > > > > On Mon, Mar 12, 2018 at 2:54 AM, Xinni Ge > wrote: > >> > >> Hi, Akihiro > >> > >> Thanks for the quick reply. > >> > >> I agree with your opinion that BASE_XSTATIC_MODULES should not be > >> modified. > >> It is much better to enhance horizon plugin settings, > >> and I think maybe there could be one option like ADD_XSTATIC_MODULES. > >> This option adds the plugin's xstatic files in STATICFILES_DIRS. > >> I am considering to add a bug report to describe it at first, and give a > >> patch later maybe. > >> Is that ok with the Horizon team? > >> > >> Best Regards. > >> Xinni > >> > >> On Fri, Mar 9, 2018 at 11:47 PM, Akihiro Motoki > wrote: > >>> > >>> Hi Xinni, > >>> > >>> 2018-03-09 12:05 GMT+09:00 Xinni Ge : > >>> > Hello Horizon Team, > >>> > > >>> > I would like to hear about your opinions about how to add new xstatic > >>> > modules to horizon settings. > >>> > > >>> > As for Heat-dashboard project embedded 3rd-party files issue, thanks > >>> > for > >>> > your advices in Dublin PTG, we are now removing them and referencing > as > >>> > new > >>> > xstatic-* libs. > >>> > >>> Thanks for moving this forward. > >>> > >>> > So we installed the new xstatic files (not uploaded as openstack > >>> > official > >>> > repos yet) in our development environment now, but hesitate to decide > >>> > how to > >>> > add the new installed xstatic lib path to STATICFILES_DIRS in > >>> > openstack_dashboard.settings so that the static files could be > >>> > automatically > >>> > collected by *collectstatic* process. > >>> > > >>> > Currently Horizon defines BASE_XSTATIC_MODULES in > >>> > openstack_dashboard/utils/settings.py and the relevant static fils > are > >>> > added > >>> > to STATICFILES_DIRS before it updates any Horizon plugin dashboard. > >>> > We may want new plugin setting keywords ( something similar to > >>> > ADD_JS_FILES) > >>> > to update horizon XSTATIC_MODULES (or directly update > >>> > STATICFILES_DIRS). > >>> > >>> IMHO it is better to allow horizon plugins to add xstatic modules > >>> through horizon plugin settings. I don't think it is a good idea to > >>> add a new entry in BASE_XSTATIC_MODULES based on horizon plugin > >>> usages. It makes difficult to track why and where a xstatic module in > >>> BASE_XSTATIC_MODULES is used. > >>> Multiple horizon plugins can add a same entry, so horizon code to > >>> handle plugin settings should merge multiple entries to a single one > >>> hopefully. > >>> My vote is to enhance the horizon plugin settings. > >>> > >>> Akihiro > >>> > >>> > > >>> > Looking forward to hearing any suggestions from you guys, and > >>> > Best Regards, > >>> > > >>> > Xinni Ge > >>> > > >>> > > >>> > > __ > >>> > 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 > >>> > > >>> > >>> > >>> > __ > >>> OpenS
[openstack-dev] [horizon][ptg] Horizon PTG Highlights
Hi team, First of all, I would like to say a thank you to all who was able to attend PTG this time. We'd got very productive discussions with a great team. Below is my short summary related on the etherpad [1]: - Current blueprints and features proposals: - we agreed to allow new blueprints and feature proposals due to the dev cycle before Feature Freeze milestone [2] - it should help contributors who are interested in feature development propose and implement new features for Horizon - Bugs and reviews list maintaining: - we did a good progress on Launchpad bugs list cleanup in Queens - it would be good to have a Bug triage days - I'll start to do it on a weekly basis - we created an etherpad for review priorities [3] - I'll review this list before weekly meeting - feel free to add anything you think is important to merge it soon - we can discuss this list on IRC meeting if needed - Should we stop rewriting existing panels with Angular? - there are a lot of concerns about re-writing current features with Angular JS - we've got a lot of not implemented features but do re-implementation of the current - It would be great to have new features implemented with Angular JS but it's not a requirement at the moment - seems that we're OK to not block current patches with features re-implementation with Angular JS but do not want to start new patches with re-implementation - there is no final decision on this topic yet - Fetch resources in parallel - we agreed to make go forward with Eventlet by default and make it configurable to allow native Python threads which are used now - let's ask the community about their experience with Eventlet - Eventlet is not the best option for Python 3 at the moment - An interaction between Horizon and other projects - project teams have troubles with Horizon integration - we've got features gap between Horizon and other projects - Horizon would like to use project capabilities - we need to be more active in cross-project communications - Horizon needs to fix integration tests - Ironic UI team wants to have their integration tests based on Horizon tests - it would be good to have Horizon plugins jobs per each Horizon commit to being sure that we don't break anything - Heat team asked for a help with new XStatic packages - Current state in Horizon testing - we want to fix our Selenium and Integration tests - there is some progress on this - once general integration tests framework will be ready, we can start fix tests one by one - need to figure out why tempest job is not stable enough - translations are not enabled in unit-tests - having test cases with some non-default locale seems to be good - add an option to enable localization in unit-tests - Angular and XStatic packages versions - testing and updating were done mostly manually by Radomir and Rob - we agreed to update XStatic packages in Rocky if they have suitable for Horizon versions and we've got capacity for this - Horizon accessibility - This initiative was started some time ago but isn't maintained now - Error handling - We need better user-facing error messages - We don't log every exception, so it makes hard for operators to investigate what went wrong - Bandit [3] - we're OK to get bandit job like some other projects do My general feeling is: we're trying to balance between bug-fixing/stabilization and new features development with a limited number of resources. And last, but not least, I want to say thank you to everybody who attends PTG, does review or proposes patches. [1] https://etherpad.openstack.org/p/horizon-ptg-rocky [2] https://releases.openstack.org/rocky/schedule.html#r-ff [3] https://etherpad.openstack.org/p/horizon-reviews-priority [4] https://github.com/openstack/bandit Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [cinder][ptg] PTG Summary Now Available ...
Jay, thanks a lot for this great summary! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Mar 6, 2018 at 10:02 PM, Jay S Bryant wrote: > Team, > > I have collected all of our actions and agreements out of the three days > of etherpads into the following summary page: [1] . The etherpad includes > links to the original etherpads and video clips. > > I am planning to use the wiki to help guide our development during Rocky. > > Let me know if you have any questions or concerns over the content. > > Thanks! > > Jay > > (jungleboyj) > > [1] https://wiki.openstack.org/wiki/CinderRockyPTGSummary > > > __ > 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] [cinder][ptg] Dinner Outing Update and Photo Reminder ...
Hi Jay, Will Fagans serve us tonight? Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Mar 1, 2018 at 3:00 PM, Jay S Bryant wrote: > > > On 3/1/2018 6:50 AM, Sean McGinnis wrote: > >> On Feb 28, 2018, at 16:58, Jay S Bryant wrote: >>> >>> Team, >>> >>> Just a reminder that we will be having our team photo at 9 am tomorrow >>> before the Cinder/Nova cross project session. Please be at the >>> registration desk before 9 to be in the photo. >>> >>> We will then have the Cross Project session in the Nova room as it >>> sounds like it is somewhat larger. I will have sound clips in hand to make >>> sure things don't get too serious. >>> >>> Finally, an update on dinner for tomorrow night. I have moved dinner to >>> a closer venue: >>> >>> Fagan's Bar and Restaurant: 146 Drumcondra Rd Lower, Drumcondra, Dublin >>> 9 >>> >>> I have reservations for 7:30 pm. It isn't too difficult a walk from >>> Croke Park (even in a blizzard) and it is a great pub. >>> >>> Thanks for a great day today! >>> >>> See you all tomorrow! Let's make it a great one! ;-) >>> Jay >>> >>> Any plan now that there is a 4pm curfew? >> >> Dinner has been rescheduled for Friday night 3/2 or 2/3 depending on your > country of origin. 6:30 at Fagans. > > I will update the etherpad. > > 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 > __ 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] [cinder] about clone the volume
Hi Lijie, We use Create Volume API for this with 'source_volid' param. It's available in Rest API and cinderclient. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Fri, Mar 2, 2018 at 8:31 AM, 李杰 wrote: > Hi,all > > This is the spec [0] about clone a volume.And I find the clone > function in cinder driver.py.But I don't know why we don't provide a > restful api about it.Can you tell me more about this ?Thank you very much. > The link is here. > Re:https://blueprints.launchpad.net/cinder/+spec/ > add-cloning-support-to-cinder > > > > > > > > Best Regards > Lijie > > __ > 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][plugins] Supported Django versions for Horizon in Rocky
Hi team, As was discussed at the weekly meeting on December, 20th, Horizon team is going to bump minimum Django version to the next LTS release which is 1.11. Django 1.8 will be supported at least until April 2018 [2]. In Rocky release, we agreed to support Django 1.11 and Django 2.x as experimental [3]. We're going to drop Django <= 1.10 support early in Rocky [4] to get plugins maintainers more time to adapt their project to the latest supported Django. Unfortunately, we can't support both Django 1.8 and 2.0 because of Django's deprecations and removals. so we need to bump minimum version. Debian will switch the default Django version to 2.x soon. Although Django 2.0 is not LTS, it seems worth considering support of Django 2.0. We'll have continuation of this conversation at PTG [5]/ [1] http://eavesdrop.openstack.org/meetings/horizon/2017/horizon.2017-12-20-20.00.log.html#l-39 [2] https://www.djangoproject.com/download/ [3] https://blueprints.launchpad.net/horizon/+spec/django2-support [4] https://review.openstack.org/#/q/topic:bp/django2-support+(status:open+OR+status:merged) [5] https://etherpad.openstack.org/p/horizon-ptg-rocky Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] PTG Planning Etherpad
Hi team, In case if you missed it, it's a friendly reminder that we've got etherpad [1] with Rocky PTG topics proposals. If you're going to attend it or want to get some topic discussed, please add your name and topic to the list [1]. Hope to see you all in Dublin. [1] https://etherpad.openstack.org/p/horizon-ptg-rocky Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [OpenStackClient][Security][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][masakari][neutron][senlin][shade][solum][swift][tacker][tricircle][vitrage][watcher][winstackers]
Hi Matt, As discussed earlier today at the Horizon's meeting [2], we're not going to release horizon-cisco-ui and django_openstack_auth because of projects retirement [3] and [4]. [2] http://eavesdrop.openstack.org/meetings/horizon/2018/horizon.2018-02- 07-20.02.html [3] https://review.openstack.org/#/c/541803/ [4] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126428.html Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Feb 7, 2018 at 11:31 PM, Tony Breeds wrote: > On Thu, Feb 08, 2018 at 08:18:37AM +1100, Tony Breeds wrote: > > > Okay It's safe to ignore then ;P We should probably remove it from > > projects.txt if it really is empty I'll propose that. > > Oh my bad, ironic-python-agent-builder was included as it's included as > an ironic project[1] NOT because it;s listed in projects.txt. Given > that it's clearly not for me to remove anything. > > Having said that if the project hasn't had any updates at all since it's > creation in July 2017 perhaps it's no longer needed and could be > removed? > > Yours Tony. > > [1] http://git.openstack.org/cgit/openstack/governance/tree/ > reference/projects.yaml#n1539 > > __ > 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][ptl] Rocky PTL Candidacy
Hello Team, I would like to announce my candidacy for PTL of Horizon for Rocky release. I use Horizon since I begin to work with OpenStack in Diablo timeframe. I wasn't active contributor before Pike release, nevertheless, I can see how both Horizon project and community changed over the times. I became Core Reviewer in Queens and worked mostly on bug-fixing and other improvements. Being a PTL is a challenging task especially for such project as Horizon. We should be close both to the other OpenStack components and provide a great user experience for cloud users and operators. As a PTL I will focus on the following areas: * Continue to work on Horizon stabilization and improvements to bring great UX for large-scale deployments. * Finish work on mox to mock migrations in unit tests. * Improve our integrational tests. * Help everybody to contribute to Horizon via reviews, features implementations and bugfixes. I know, that being a PTL is a hard job, but we've got a good team and we'll do our best to make Horizon a bit better during the next cycle. Thank you, Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] Adding Ivan Kolodyazhny to the Horizon Core team
Thanks Ying and the team! I'm happy to be a part of our Horizon Core Reviewers team. I have a bit more opportunity to make Horizon better now. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Dec 18, 2017 at 2:39 PM, Chenjun Shen wrote: > Congratulations to Ivan! > > On Sun, Dec 17, 2017 at 1:39 PM, Akihiro Motoki wrote: > >> Welcome Ivan to the team! >> >> Akihiro >> >> 2017-12-16 1:52 GMT+09:00 Ying Zuo (yinzuo) : >> > Hi everyone, >> > >> > >> > >> > After some discussion with the Horizon Core team, I am pleased to >> announce >> > that we are adding Ivan Kolodyazhny to the team. Ivan has been actively >> > contributing to Horizon since the beginning of the Pike release. He has >> > worked on many bug fixes, blueprints, and performed thorough code >> reviews. >> > You may have known him by his IRC nickname e0ne since he's one of the >> most >> > active members on #openstack-horizon. Please join me in welcoming Ivan >> to >> > the Horizon Core team :) >> > >> > >> > >> > >> > >> > Regards, >> > >> > Ying >> > >> > >> > >> > >> > >> __ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: openstack-dev-requ...@lists.op >> enstack.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:unsubscrib >> e >> 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
Re: [openstack-dev] [horizon] Fetch resources in parallel
Hi Team, It's me again and I've got some new tests results [3]. I'd got the following test environment: - 3 controllers - 2 computes - 1 node with horizon - 60 items per page - 60 instances launched with only 3 different images. As always, any feedback is welcome [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit#gid=0 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Dec 6, 2017 at 12:47 PM, Ivan Kolodyazhny wrote: > Hi Team, > > Last week we had a hot discussion about this topic at the meeting [6]. We > still don't have an agreement how to go forward with it. As was requested, > I did some perf testing with a current approach [3]. TBH, these tests > results don't show real data but look realistic. I used the same VM with > the same code (just checked out to the previous commit of horizon). To > get better results, we need to re-test all but I don't have enough time > now:(. I hope, these results are good enoudh and we can make our final > decision on this topic. > > [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ > ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit#gid=0 > [6] http://eavesdrop.openstack.org/meetings/horizon/2017/ > horizon.2017-11-29-20.00.log.html#l-12 > > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Tue, Oct 31, 2017 at 11:06 PM, Ivan Kolodyazhny wrote: > >> Just forgot to mention one other option: we can use celery [6] too but I >> didn't do any performance testing with it. This solution will be more >> complex. >> >> [6] http://www.celeryproject.org/ >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> On Tue, Oct 31, 2017 at 7:15 PM, Ivan Kolodyazhny wrote: >> >>> Hi team, >>> >>> We all know that unfortunately Horizon's performance not good enough in >>> some cases. That's why we try to fix it on both sides: client-side and >>> server-side. >>> >>> I would like to talk mostly about server-side now. On some views, we use >>> 'futurist' library [1] to fetch resources from API's in parallel. I've >>> filed a blueprint for this effort [2]. You can find some work in progress >>> patches in the Gerrit. >>> >>> For now, we use futurist.ThreadPoolExecutor in Horizon to fetch >>> resources from APIs. It requires some specific Apache configuration changes >>> to allow WSGI app to create threads. It means, our code execution depends >>> on Apache mod_wsgi configuration. >>> >>> To avoid this, we can use futurist.GreenThreadPoolExecutor. It >>> uses eventlet green threads which can be used to speed-up I/O operations >>> like 'call external API'. >>> >>> I did very simple performance testing [3] with proposed patch [4] for >>> volumes views. My tests are not ideal but you can see how it's going with >>> green thread. I propose to switch to the futurist.GreenThreadPoolExecutor >>> and add 'eventlet.monkey_patch()' call to the wsgi app for Horizon. It will >>> speed up parallel API calls and make Horizon independent on Apache or other >>> web server configuration. >>> >>> I added this topic to the next weekly meeting agenda [5] so we can >>> discuss it there too. >>> >>> >>> [1] https://github.com/openstack/futurist/ >>> [2] https://blueprints.launchpad.net/horizon/+spec/fetch-res >>> ources-in-parallel >>> [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ZycaGUo >>> T64kHsGi1gL9JOha8n5PVeg/edit?usp=sharing >>> [4] https://review.openstack.org/#/c/426493/ >>> [5] https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_ >>> for_Next_Meeting >>> >>> Regards, >>> Ivan Kolodyazhny, >>> http://blog.e0ne.info/ >>> >> >> > __ 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] Fetch resources in parallel
Hi Team, Last week we had a hot discussion about this topic at the meeting [6]. We still don't have an agreement how to go forward with it. As was requested, I did some perf testing with a current approach [3]. TBH, these tests results don't show real data but look realistic. I used the same VM with the same code (just checked out to the previous commit of horizon). To get better results, we need to re-test all but I don't have enough time now:(. I hope, these results are good enoudh and we can make our final decision on this topic. [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit#gid=0 [6] http://eavesdrop.openstack.org/meetings/horizon/2017/horizon.2017-11-29-20.00.log.html#l-12 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Oct 31, 2017 at 11:06 PM, Ivan Kolodyazhny wrote: > Just forgot to mention one other option: we can use celery [6] too but I > didn't do any performance testing with it. This solution will be more > complex. > > [6] http://www.celeryproject.org/ > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Tue, Oct 31, 2017 at 7:15 PM, Ivan Kolodyazhny wrote: > >> Hi team, >> >> We all know that unfortunately Horizon's performance not good enough in >> some cases. That's why we try to fix it on both sides: client-side and >> server-side. >> >> I would like to talk mostly about server-side now. On some views, we use >> 'futurist' library [1] to fetch resources from API's in parallel. I've >> filed a blueprint for this effort [2]. You can find some work in progress >> patches in the Gerrit. >> >> For now, we use futurist.ThreadPoolExecutor in Horizon to fetch resources >> from APIs. It requires some specific Apache configuration changes to allow >> WSGI app to create threads. It means, our code execution depends on Apache >> mod_wsgi configuration. >> >> To avoid this, we can use futurist.GreenThreadPoolExecutor. It >> uses eventlet green threads which can be used to speed-up I/O operations >> like 'call external API'. >> >> I did very simple performance testing [3] with proposed patch [4] for >> volumes views. My tests are not ideal but you can see how it's going with >> green thread. I propose to switch to the futurist.GreenThreadPoolExecutor >> and add 'eventlet.monkey_patch()' call to the wsgi app for Horizon. It will >> speed up parallel API calls and make Horizon independent on Apache or other >> web server configuration. >> >> I added this topic to the next weekly meeting agenda [5] so we can >> discuss it there too. >> >> >> [1] https://github.com/openstack/futurist/ >> [2] https://blueprints.launchpad.net/horizon/+spec/fetch- >> resources-in-parallel >> [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ZycaGUo >> T64kHsGi1gL9JOha8n5PVeg/edit?usp=sharing >> [4] https://review.openstack.org/#/c/426493/ >> [5] https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_ >> for_Next_Meeting >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> > > __ 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] Pagination issues and resource deletion
Hi team, Pagination issues are a hot topic for Horizon. We had a good discussion at PTG [1] for it. Also, I would like to say thanks to Ferenc for working on it [2]. As a long-term solution, we decided to implement 'Show more' button and improve filtering at PTG [1]. This will help us to fix current issues but requires a lot of work and time for everybody of us. As a hotfix, I would like to propose my dirty hack for it [3]. It just redirects to the 1st page on instances view after deletion. We could do the same for all or only needed table. I know, that it makes UX worse, but, TBH, it's not ideal at the moment. I'm going to fix unit tests if the community decides to forward with it. [1] https://etherpad.openstack.org/p/horizon-ptg-queens [2] https://review.openstack.org/498018 [3] https://review.openstack.org/517614 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] Fetch resources in parallel
Just forgot to mention one other option: we can use celery [6] too but I didn't do any performance testing with it. This solution will be more complex. [6] http://www.celeryproject.org/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Oct 31, 2017 at 7:15 PM, Ivan Kolodyazhny wrote: > Hi team, > > We all know that unfortunately Horizon's performance not good enough in > some cases. That's why we try to fix it on both sides: client-side and > server-side. > > I would like to talk mostly about server-side now. On some views, we use > 'futurist' library [1] to fetch resources from API's in parallel. I've > filed a blueprint for this effort [2]. You can find some work in progress > patches in the Gerrit. > > For now, we use futurist.ThreadPoolExecutor in Horizon to fetch resources > from APIs. It requires some specific Apache configuration changes to allow > WSGI app to create threads. It means, our code execution depends on Apache > mod_wsgi configuration. > > To avoid this, we can use futurist.GreenThreadPoolExecutor. It > uses eventlet green threads which can be used to speed-up I/O operations > like 'call external API'. > > I did very simple performance testing [3] with proposed patch [4] for > volumes views. My tests are not ideal but you can see how it's going with > green thread. I propose to switch to the futurist.GreenThreadPoolExecutor > and add 'eventlet.monkey_patch()' call to the wsgi app for Horizon. It will > speed up parallel API calls and make Horizon independent on Apache or other > web server configuration. > > I added this topic to the next weekly meeting agenda [5] so we can discuss > it there too. > > > [1] https://github.com/openstack/futurist/ > [2] https://blueprints.launchpad.net/horizon/+spec/ > fetch-resources-in-parallel > [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ > ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit?usp=sharing > [4] https://review.openstack.org/#/c/426493/ > [5] https://wiki.openstack.org/wiki/Meetings/Horizon# > Agenda_for_Next_Meeting > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > __ 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] Fetch resources in parallel
Hi team, We all know that unfortunately Horizon's performance not good enough in some cases. That's why we try to fix it on both sides: client-side and server-side. I would like to talk mostly about server-side now. On some views, we use 'futurist' library [1] to fetch resources from API's in parallel. I've filed a blueprint for this effort [2]. You can find some work in progress patches in the Gerrit. For now, we use futurist.ThreadPoolExecutor in Horizon to fetch resources from APIs. It requires some specific Apache configuration changes to allow WSGI app to create threads. It means, our code execution depends on Apache mod_wsgi configuration. To avoid this, we can use futurist.GreenThreadPoolExecutor. It uses eventlet green threads which can be used to speed-up I/O operations like 'call external API'. I did very simple performance testing [3] with proposed patch [4] for volumes views. My tests are not ideal but you can see how it's going with green thread. I propose to switch to the futurist.GreenThreadPoolExecutor and add 'eventlet.monkey_patch()' call to the wsgi app for Horizon. It will speed up parallel API calls and make Horizon independent on Apache or other web server configuration. I added this topic to the next weekly meeting agenda [5] so we can discuss it there too. [1] https://github.com/openstack/futurist/ [2] https://blueprints.launchpad.net/horizon/+spec/fetch-resources-in-parallel [3] https://docs.google.com/spreadsheets/d/14zDpdkPUfGDR_ZycaGUoT64kHsGi1gL9JOha8n5PVeg/edit?usp=sharing [4] https://review.openstack.org/#/c/426493/ [5] https://wiki.openstack.org/wiki/Meetings/Horizon#Agenda_for_Next_Meeting Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [cinder][3rd-party ci] Voting INSPUR-CI
Thank you, Sean! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Sep 18, 2017 at 11:49 PM, Sean McGinnis wrote: > On Mon, Sep 18, 2017 at 12:20:24PM -0500, Jay S Bryant wrote: > > All, > > > > I am adding the e-mails from the Inspur CI in the OpenStack 3rd Party CI > > Wiki in case they do not monitor the mailing list. > > > > Inspur CI team, > > > > Please see the e-mails below. Your job is currently voting and should > not > > be. Please update your config to be non-voting. > > > > Thank you! > > > > Jay > > > > Sorry, I think I caused this by adding them to the cinder-ci group in an > attempt to get them to stop showing up even when Filter CI was toggled. I > noticed that this morning and had removed them again before the gerrit down > time. It should not show up anymore. > > Although I still need to remember how they need to be registered to get > them > out of the filtered comments. > > > __ > 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] [cinder][3rd-party ci] Voting INSPUR-CI
Erlon, Unfortunately, gerrit is unavailable now due to the maintainence. Lenny, I didn't find anything related to INSPUR in the project-config. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Sep 18, 2017 at 5:13 PM, Erlon Cruz wrote: > Do you have the patch link? I don't see any report of it[1]. > > > > [1] http://ci-watch.tintri.com/project?project=cinder&time=7+days > > On Mon, Sep 18, 2017 at 6:40 AM, Lenny Verkhovsky > wrote: > >> You can do it in your Zuul layout.yaml configuration file >> >> >> >> Ex: >> >> - name: Nova-ML2-Sriov >> >> branch: ^(master|stable/ocata|stable/newton|stable/pike).*$ >> >> voting: false >> >> skip-if: >> >> >> >> >> >> *From:* Ivan Kolodyazhny [mailto:e...@e0ne.info] >> *Sent:* Monday, September 18, 2017 1:05 PM >> *To:* OpenStack Development Mailing List > .org> >> *Cc:* wangyong2...@inspur.com; inspur...@inspur.com; >> jiaohao...@inspur.com >> *Subject:* [openstack-dev] [cinder][3rd-party ci] Voting INSPUR-CI >> >> >> >> Hi Team, >> >> >> >> Looks like we incidentally made INSPUR-CI voting for Cinder. For now, it >> puts -1 for all patches. According to [1] please make it non-voting. >> >> >> >> >> >> [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty- >> drivers#When_thirdparty_CI_voting_will_be_required.3F >> <https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openstack.org%2Fwiki%2FCinder%2Ftested-3rdParty-drivers%23When_thirdparty_CI_voting_will_be_required.3F&data=02%7C01%7Clennyb%40mellanox.com%7C44e71295331a40e1843008d4fe7ce153%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636413259696316004&sdata=%2F3fZ2gnWRRpOt0PXBA0MMXdwx5KfRZZkqcD%2BwUIKmCc%3D&reserved=0> >> >> >> >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> <https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblog.e0ne.info%2F&data=02%7C01%7Clennyb%40mellanox.com%7C44e71295331a40e1843008d4fe7ce153%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636413259696316004&sdata=8VEkOwYfM20auYmdPQqhYUUiEIJryMeEU0FmDui9b0w%3D&reserved=0> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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] [cinder][3rd-party ci] Voting INSPUR-CI
Hi Team, Looks like we incidentally made INSPUR-CI voting for Cinder. For now, it puts -1 for all patches. According to [1] please make it non-voting. [1] https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers#When_thirdparty_CI_voting_will_be_required.3F Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [kolla] [cinder] [ironic] PTG cross-platform meetup possibility
Hi team, Monday at 4pm sounds great for me. I hope, it will work well both for Cinder and Kolla teams. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Aug 31, 2017 at 4:25 PM, Richard Wellum wrote: > Hi, > > How does Monday at 4pm sound? Kolla already has a cross-platform > discussion with Triple-O at 2pm, so this would dovetail nicely. > > Thanks, > > ||Rich > > On Wed, Aug 30, 2017 at 2:48 PM Ivan Kolodyazhny wrote: > >> Hi team, >> >> I'm interested in cinder containerization too. It would be great if we >> can schedule our meetup after 3pm or even 4pm, It will increase my chances >> to attend it. >> >> Thanks in advance. >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur >> wrote: >> >>> Hi! >>> >>> I'm all for it. Monday sounds okay to me, though I'll have to manage >>> some conflicts, of course. >>> >>> >>> On 08/29/2017 05:56 PM, Richard Wellum wrote: >>> >>>> Hi Folks, >>>> >>>> Would there be some interest from Cinder and Ironic (and others of >>>> course) team members to have a quick session at the PTG with the Kolla team >>>> on the latest developments in Kolla (like the new kolla-ansible devmode for >>>> example)? >>>> >>>> Also it would give the Kolla team an opportunity to hear about your >>>> teams interest and experiences in containerization and what you need from >>>> Kolla going forward. >>>> >>>> I'm thinking an hour or two on Monday afternoon, the first day of the >>>> PTG? >>>> >>>> Thanks, >>>> >>>> ||Rich >>>> >>>> >>>> >>>> __ >>>> 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
Re: [openstack-dev] [kolla] [cinder] [ironic] PTG cross-platform meetup possibility
Hi team, I'm interested in cinder containerization too. It would be great if we can schedule our meetup after 3pm or even 4pm, It will increase my chances to attend it. Thanks in advance. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Aug 30, 2017 at 4:23 PM, Dmitry Tantsur wrote: > Hi! > > I'm all for it. Monday sounds okay to me, though I'll have to manage some > conflicts, of course. > > > On 08/29/2017 05:56 PM, Richard Wellum wrote: > >> Hi Folks, >> >> Would there be some interest from Cinder and Ironic (and others of >> course) team members to have a quick session at the PTG with the Kolla team >> on the latest developments in Kolla (like the new kolla-ansible devmode for >> example)? >> >> Also it would give the Kolla team an opportunity to hear about your teams >> interest and experiences in containerization and what you need from Kolla >> going forward. >> >> I'm thinking an hour or two on Monday afternoon, the first day of the PTG? >> >> Thanks, >> >> ||Rich >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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
Re: [openstack-dev] [Cinder][Nova][Requirements] Lib freeze exception for os-brick
Sounds reasonable for me too.
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
On Mon, Jul 31, 2017 at 5:40 PM, Davanum Srinivas wrote:
> I'd support this Sean. +1
>
> Thanks,
> Dims
>
> On Mon, Jul 31, 2017 at 10:37 AM, Sean McGinnis
> wrote:
> > I am requesting a library release of os-brick during the feature freeze
> > in order to fix an issue with the recently landed online volume extend
> > feature across Nova and Cinder.
> >
> > Patches have landed in both projects to add this feature. It wasn't until
> > later that Matt was able to get tempest tests in that found an issue with
> > some of the logic in the os-brick library. That has now been fixed in the
> > stable/pike branch in os-brick with this patch:
> >
> > https://review.openstack.org/#/c/489227/
> >
> > We can get a new library release out as soon as the freeze is over, but
> > due to the fact that we do not raise global requirements for stable
> > branches after release, there could be some deployments that would still
> > use the old ("broken") lib. We would need to get this release out before
> > the final pike branching of Cinder and Nova to be able to raise G-R to
> > make sure the new release is used with this fix.
> >
> > I see this change as a low risk for other regression, and it would allow
> > us to not ship a broken feature.
> >
> > Thanks,
> > Sean
> >
> >
> __
> > 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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __
> 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] [Cinder] Proposing TommyLikeHu for Cinder core
+1, Tommy did a good job contributing both in reviews and code Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Jul 25, 2017 at 7:21 PM, Tom Barron wrote: > On 07/25/2017 04:07 AM, Sean McGinnis wrote: > > I am proposing we add TommyLike as a Cinder core. > > > > DISCLAIMER: We work for the same company. > > > > I have held back on proposing him for some time because of this > conflict. But > > I think from his number of reviews [1] and code contributions [2] it's > > hopefully clear that my motivation does not have anything to do with > this. > > > > TommyLike has consistently done quality code reviews. He has contributed > a > > lot of bug fixes and features. And he has been available in the IRC > channel > > answering questions and helping out, despite some serious timezone > > challenges. > > > > I think it would be great to add someone from this region so we can get > more > > perspective from the APAC area, as well as having someone around that may > > help as more developers get involved in non-US and non-EU timezones. > > > > Cinder cores, please respond with your opinion. If no reason is given to > do > > otherwise, I will add TommyLike to the core group in one week. > > > > And absolutely call me out if you see any in bias in my proposal. > > > > Thanks, > > Sean > > > > [1] http://stackalytics.com/report/contribution/cinder-group/90 > > [2] https://review.openstack.org/#/q/owner:%22TommyLike+% > 253Ctommylikehu%2540gmail.com%253E%22++status:merged > > > > > __ > > 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 > > > > Not a cinder core but I work there from time to time and Tommy has > helped out with features and bugs that overlap with manila, where I am > more active these days. > > +1 > > I really like the way Tommy spends time to understand -1s and improve > code submissions rather than getting ego involved or just arguing like a > lawyer for the original code. Good role model. > > > __ > 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] [Cinder] Not not running for PTL
Sean, Thank you for all your hard work! It was a great 4 cycles. I hope, after you take some rest you'll be elected for PTL later. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Fri, Jul 21, 2017 at 2:05 PM, Sean McGinnis wrote: > Hey everyone, > > So this isn't an "I'm stepping down at the end of this cycle" message, but > it is an encouragement for anyone thinking about running to step forward. > > I'm fine with running again if needed. Pike is my 4th cycle as PTL, and I > think by now I've gotten the hang of most of it. But four cycles is more > than I had intended to do, and I do think it would be good for the project > to have some variety. > > If you've been thinking about running but didn't want to "offend" me by > running against me or anything like that, please don't worry about it. We > have a good team and I think it is a healthy thing to switch up the lead > role once and awhile. > > All that said, if no one else is in a position at the moment where they > can do this (job situation, other life commitments - please do think > about this!) then I'm certainly up for another round. > > Feel free to ping me if you have any questions or want any input. I would > be glad to help. > > Thanks! > Sean > > > __ > 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] [api][horizon][all] Poorly Pagination UX
Hi stackers, There are several bugs in Horizon [1], [2] and [3] related to pagination. TBH, these issues are reproducible via CLI too. Unfortunately, all of them are related to our API’s implementation [4]. Bugs [1] and [2] can’t be fixed in current API’s implementations because we use ‘marker’ object in them [4]. We can try to implement some hacks on the Horizon’s side to play with ‘sort order’ param, but even that in some cases we can fix all bugs because we don’t have necessary params to good paging implementation. What does it mean? E.g: You have 2 volumes and 1 item per page like described at [5]. In this case, when we remove volume B we can’t open a page with volume A because current ‘marker’ is volume B and regardless to sort order API will return zero volumes with this marker. As a double workaround, we can redirect to the first page. But this makes Horizon UX more terrible when user has a lot of pages of instances, volumes, etc and want to delete several of them without using filtering feature. As an another option, we can do some hacks on the Horizon side, but it requires to make more API calls what is not a good option in big production deployments. As a long-term solution it could be good to change our API’s to have better paging. E.g. use ‘page number’ param instead of ‘marker’. API could also return total_page number so Horizon will be able to use these options to render paged tables well. In the world of microversions, we can implement such changes without breaking any existing API users and change API Guidelines with note about these changes. I’m glad to get any feedback from Horizon users, API WG and component teams if community is interested in this big cross-project effort. [1] https://bugs.launchpad.net/horizon/+bug/1564498 [2] https://bugs.launchpad.net/horizon/+bug/1212174 [3] https://bugs.launchpad.net/horizon/+bug/1274427 [4] https://github.com/openstack/api-wg/blob/master/guidelines/pagination_filter_sort.rst [5] https://bugs.launchpad.net/horizon/+bug/1564498/comments/5 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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 OCATA , Horizon dashboard
Hi Dimitris, It's related to glance API version. Do you use v1 or v2? Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Mar 14, 2017 at 2:38 AM, Dimitris Theoharis wrote: > > Hello > this is a fresh install , when i try to upload an image i get the error i > have attached. > Is this a bug ? Thanks > > > > __ > 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] VMware Voting CI
Big +1 to Sean especially for Cinder-related issues Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, May 3, 2017 at 5:06 PM, Sean McGinnis wrote: > Hey everyone, > > I'm looking for some background on the VMware NSX CI. Specifically, > why this CI is enabled for voting. > > We had discussed whether to have "stable" CI's vote in the Cinder > project a while back, and other than potentially some benefit in > doing scripted reporting, we couldn't really think of a good > reason to have third party CI voting. > > This CI account, however, appears to be used for multiple projects. > I think it got voting rights via a different project. I'm just > wondering if there is still a valid reason for that. > > I think this has come up before, and to be clear, it does not block > anything when there ends up a -1 from this CI. The issue I have > with it is when looking in a summary list of patches, even if Jenkins > has voted +1, if the VMware NSX CI has failed, it ends up with a big > ol' red -1 in the Verified column, making it look like there is an > issue with the patch. Which likely means unless someone is > specifically interested in that patch, they will see the red -1 and > move on. > > Does anyone have the background as to why this CI has voting rights, > and whether it should still have them? > > Thanks, > Sean (smcginnis) > > > __ > 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] [cinder][sahara] LVM vs BDD drivers performance tests results
+ [sahara] because they are primary consumer of the BDD. John, Thanks for the answer. My comments are inline. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Sep 19, 2016 at 4:41 PM, John Griffith wrote: > > > On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny wrote: > >> Hi team, >> >> We did some performance tests [1] for LVM and BDD drivers. All tests were >> executed on real hardware with OpenStack Mitaka release. Unfortunately, we >> didn't have enough time to execute all tests and compare results. We used >> Sahara/Hadoop cluster with TestDFSIO and others tests. >> >> All tests were executed on the same hardware and OpenStack release. Only >> difference were in cinder.conf to enable needed backend and/or target >> driver. >> >> Tests were executed on following configurations: >> >>- LVM +TGT target >>- LVM+LocalTarget: PoC based on [2] spec >>- LVM+LIO >>- Block Device Driver. >> >> >> Feel free to ask question if any about our testing infrastructure, >> environment, etc. >> >> >> [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbD >> pdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing >> [2] https://review.openstack.org/#/c/247880/ >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a few > things (again): > > 1. Deprecate the BDD driver > Based on the data here LVM+LIO the delta in performance (with the > exception of the Terravalidate run against 3TB) doesn't seem significant > enough to warrant maintaining an additional driver that has only a subset > of features implemented. It would be good to understand why that > particular test has such a significant peformance gap. > What about Local Target? Does it make sense to implement it instead BDD? > > 2. Consider getting buy off to move the default implementation to use the > LIO driver and consider deprecating the TGT driver > +1. Let's bring this topic for the next weekly meeting. > > I realize this probably isn't a sufficient enough data set to make those > two decisions but I think it's at least enough to have a more informed > discussion this time. > > Thanks, > John > > > __ > 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] [cinder] LVM vs BDD drivers performance tests results
Hi team, We did some performance tests [1] for LVM and BDD drivers. All tests were executed on real hardware with OpenStack Mitaka release. Unfortunately, we didn't have enough time to execute all tests and compare results. We used Sahara/Hadoop cluster with TestDFSIO and others tests. All tests were executed on the same hardware and OpenStack release. Only difference were in cinder.conf to enable needed backend and/or target driver. Tests were executed on following configurations: - LVM +TGT target - LVM+LocalTarget: PoC based on [2] spec - LVM+LIO - Block Device Driver. Feel free to ask question if any about our testing infrastructure, environment, etc. [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbDpdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing [2] https://review.openstack.org/#/c/247880/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release][barbican][cinder][cloudkitty][ironic][magnum][monasca][searchlight][senlin][solum][swift][tripleo][watcher][winstackers] tags needed to be considered part of Newton
On Mon, Aug 29, 2016 at 10:37 PM, Sean McGinnis wrote: > python-cinderclient this week. It just doesn't have enough activity to > have needed a release any earlier > +1 to Sean on it. All features were merged last few weeks and it sounds good to get it released both with python-cinderclient. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [cinder] Volume Drivers unit tests
Eric, you're right.
I've disabled all such tests using '@unittest.skip("Skip until bug #1578986
is fixed")' decorator in my patch:
$ grep -r '1578986' cinder/tests/unit/ | grep -v 'pyc' | wc -l
37
Next step is to fix them.
[1] https://review.openstack.org/#/c/320148/
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
On Fri, Jul 22, 2016 at 4:13 PM, Eric Harney wrote:
> On 07/21/2016 05:26 PM, Knight, Clinton wrote:
> > Nate, you have to press Ctrl-C to see the in-progress test, that’s why
> you don’t
> > see it in the logs. The bug report shows this and points to the patch
> where it
> > appeared to begin. https://bugs.launchpad.net/cinder/+bug/1578986
> >
> > Clinton
> >
>
> I think this only gives a backtrace of the test runner and not the test.
>
> I attached gdb when this hang occured and see this. Looks like we still
> have a thread running the oslo.messaging fake driver.
>
> http://paste.openstack.org/raw/539769/
>
> (Linked in the bug report as well.)
>
> > *From: *"Potter, Nathaniel"
> > *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)"
> >
> > *Date: *Thursday, July 21, 2016 at 7:17 PM
> > *To: *"OpenStack Development Mailing List (not for usage questions)"
> >
> > *Subject: *Re: [openstack-dev] [cinder] Volume Drivers unit tests
> >
> > Hi all,
> >
> > I’m not totally sure that this is the same issue, but lately I’ve seen
> the gate
> > tests fail while hanging at this point [1], but they say ‘ok’ rather than
> > ‘inprogress’. Has anyone else come across this? It only happens
> sometimes, and a
> > recheck can get past it. The full log is here [2].
> >
> > [1] http://paste.openstack.org/show/539314/
> >
> > [2]
> >
> http://logs.openstack.org/90/341090/6/check/gate-cinder-python34-db/ea65de5/console.html
> >
> > Thanks,
> >
> > Nate
> >
> > *From:*yang, xing [mailto:xing.y...@emc.com]
> > *Sent:* Thursday, July 21, 2016 3:17 PM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> >
> > *Subject:* Re: [openstack-dev] [cinder] Volume Drivers unit tests
> >
> > Hi Ivan,
> >
> > Do you have any logs for the VMAX driver? We'll take a look.
> >
> > Thanks,
> >
> > Xing
> >
> >
> --------
> >
> > *From:*Ivan Kolodyazhny [e...@e0ne.info]
> > *Sent:* Thursday, July 21, 2016 4:44 PM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [cinder] Volume Drivers unit tests
> >
> > Thank you Xing,
> >
> > The issue is related both to VNX and VMAX EMC drivers
> >
> >
> > Regards,
> > Ivan Kolodyazhny,
> > http://blog.e0ne.info/
> >
> > On Thu, Jul 21, 2016 at 11:00 PM, yang, xing > <mailto:xing.y...@emc.com>> wrote:
> >
> > Hi Ivan,
> >
> > Thanks for sending this out. Regarding the issue in the EMC VNX
> driver unit
> > tests, it is tracked by this bug
> > https://bugs.launchpad.net/cinder/+bug/1578986. The driver was
> recently
> > refactored so this is probably a new issue introduced by the
> refactor.
> > We are investigating this issue.
> >
> > Thanks,
> >
> > Xing
> >
> >
>
>
> >
> > *From:*Ivan Kolodyazhny [e...@e0ne.info <mailto:e...@e0ne.info>]
> > *Sent:* Thursday, July 21, 2016 1:02 PM
> > *To:* OpenStack Development Mailing List
> > *Subject:* [openstack-dev] [cinder] Volume Drivers unit tests
> >
> > Hi team,
> >
> > First of all, I would like to apologize, if my mail is be too
> emotional. I
> > spent too much of time to fix it and failed.
> >
> > TL;DR;
> >
> > What I want to say is: "Let's spend some time to make our tests
> better and
> > fix all issues". Patch [1] is still unstable. Unit tests can pass or
> fail in
> > a in a random order. Also, I've disabled some tests to pass CI.
> >
> > Long version:
> >
> > While I was working on patch "Move drivers unit tests to
> unit.volume.drivers
> > directory" [1] I've found a lot of issues with our unit tests :(.
> Not all of
> > them are already fixed, so that patch is still in progress
> >
>
Re: [openstack-dev] [cinder] Volume Drivers unit tests
Thank you Xing, The issue is related both to VNX and VMAX EMC drivers Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Jul 21, 2016 at 11:00 PM, yang, xing wrote: > Hi Ivan, > > Thanks for sending this out. Regarding the issue in the EMC VNX driver > unit tests, it is tracked by this bug > https://bugs.launchpad.net/cinder/+bug/1578986. The driver was recently > refactored so this is probably a new issue introduced by the refactor. We are > investigating this issue. > > Thanks, > Xing > > > ------ > *From:* Ivan Kolodyazhny [e...@e0ne.info] > *Sent:* Thursday, July 21, 2016 1:02 PM > *To:* OpenStack Development Mailing List > *Subject:* [openstack-dev] [cinder] Volume Drivers unit tests > > Hi team, > > First of all, I would like to apologize, if my mail is be too emotional. > I spent too much of time to fix it and failed. > TL;DR; > > What I want to say is: "Let's spend some time to make our tests better and > fix all issues". Patch [1] is still unstable. Unit tests can pass or fail > in a in a random order. Also, I've disabled some tests to pass CI. > > > Long version: > > While I was working on patch "Move drivers unit tests to > unit.volume.drivers directory" [1] I've found a lot of issues with our unit > tests :(. Not all of them are already fixed, so that patch is still in > progress > > What did I found and what should we have to fix: > > 1) Execution time [2]. I don't want to argue what it unit tests, but 2-4 > seconds per tests should be non-acceptable, IMO. > > 2) Execution order. Seriously, do you know that our tests will fail or > hang if execution order will change? Even if one test for diver A failed, > some tests for driver B will fail too. > > 3) Lack of mock. It's a root cause for #2. We didn't mock sleeps and event > loops right. We don't mock RPC call well too [3]. We don't > have 'cinder.openstack.common.rpc.impl_fake' module in Cinder tree. > > In some drivers, we use oslo_service.loopingcall.FixedIntervalLoopingCall > [4]. We've go ZeroIntervalLoopingCall [5] class in Cinder. Do we use it > everywhere or mock FixedIntervalLoopingCall right? I don't think so, I've > hacked oslo_service in my env to rise an exception if interval > 0. 297 > tests failed. It means, our tests use sleep. We have to get rid of this. > TBH, not only volume drivers unit tests failed. E.g. some API unit tests > failed too. > > > 4) Due to #3, sometimes unit tests hangs even on master branch with a > minor changes.If I stop execution of such tests, usually I see something > like [6]. In most of cases I see that following drivers' tests hangs: EMC, > Huawei, Dell and RBD. > > It's hard to debug such failures because the lack of tooling for eventlet > debugging. Eventlet backdoors and gdb-python helps a bit. Maybe somebody > know better solution for it. > > [1] https://review.openstack.org/#/c/320148/ > [2] http://paste.openstack.org/show/539081/ > [3] https://github.com/openstack/cinder/search?utf8=%E2%9C%93&q=impl_fake > [4] use > https://github.com/openstack/oslo.service/blob/master/oslo_service/loopingcall.py#L162 > [5] > https://github.com/openstack/cinder/blob/cfbb5bde4d9b37c39f6813fe685f987f8a990483/cinder/tests/unit/utils.py#L289 > [6] http://paste.openstack.org/show/539090/ > > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > __ > 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] [cinder] Volume Drivers unit tests
Hi team, First of all, I would like to apologize, if my mail is be too emotional. I spent too much of time to fix it and failed. TL;DR; What I want to say is: "Let's spend some time to make our tests better and fix all issues". Patch [1] is still unstable. Unit tests can pass or fail in a in a random order. Also, I've disabled some tests to pass CI. Long version: While I was working on patch "Move drivers unit tests to unit.volume.drivers directory" [1] I've found a lot of issues with our unit tests :(. Not all of them are already fixed, so that patch is still in progress What did I found and what should we have to fix: 1) Execution time [2]. I don't want to argue what it unit tests, but 2-4 seconds per tests should be non-acceptable, IMO. 2) Execution order. Seriously, do you know that our tests will fail or hang if execution order will change? Even if one test for diver A failed, some tests for driver B will fail too. 3) Lack of mock. It's a root cause for #2. We didn't mock sleeps and event loops right. We don't mock RPC call well too [3]. We don't have 'cinder.openstack.common.rpc.impl_fake' module in Cinder tree. In some drivers, we use oslo_service.loopingcall.FixedIntervalLoopingCall [4]. We've go ZeroIntervalLoopingCall [5] class in Cinder. Do we use it everywhere or mock FixedIntervalLoopingCall right? I don't think so, I've hacked oslo_service in my env to rise an exception if interval > 0. 297 tests failed. It means, our tests use sleep. We have to get rid of this. TBH, not only volume drivers unit tests failed. E.g. some API unit tests failed too. 4) Due to #3, sometimes unit tests hangs even on master branch with a minor changes.If I stop execution of such tests, usually I see something like [6]. In most of cases I see that following drivers' tests hangs: EMC, Huawei, Dell and RBD. It's hard to debug such failures because the lack of tooling for eventlet debugging. Eventlet backdoors and gdb-python helps a bit. Maybe somebody know better solution for it. [1] https://review.openstack.org/#/c/320148/ [2] http://paste.openstack.org/show/539081/ [3] https://github.com/openstack/cinder/search?utf8=%E2%9C%93&q=impl_fake [4] use https://github.com/openstack/oslo.service/blob/master/oslo_service/loopingcall.py#L162 [5] https://github.com/openstack/cinder/blob/cfbb5bde4d9b37c39f6813fe685f987f8a990483/cinder/tests/unit/utils.py#L289 [6] http://paste.openstack.org/show/539090/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [cinder] [nova] os-brick privsep failures and an upgrade strategy?
Thanks for the update, Matt. I will join our meeting next week. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Jul 12, 2016 at 4:25 PM, Matt Riedemann wrote: > On 7/12/2016 6:29 AM, Ivan Kolodyazhny wrote: > >> Hi team, >> >> Do we have any decision on this issue? I've found few patches but both >> of them are -1'ed. >> >> From Cinder perspective, it blocks us to release new os-brick with >> features, which are needed for other projects like Cinder and >> python-brick-cinderclient-ext. >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> On Wed, Jun 22, 2016 at 5:47 PM, Matt Riedemann >> mailto:mrie...@linux.vnet.ibm.com>> wrote: >> >> On 6/21/2016 10:12 PM, Angus Lees wrote: >> >> On Wed, 22 Jun 2016 at 05:59 Matt Riedemann >> mailto:mrie...@linux.vnet.ibm.com> >> <mailto:mrie...@linux.vnet.ibm.com >> >> <mailto:mrie...@linux.vnet.ibm.com>>> wrote: >> >> Angus, what should we be looking at from the privsep side >> for debugging >> this? >> >> >> The line above the screen-n-cpu.txt.gz failure you linked to is: >> 2016-06-21 16:21:30.994 >> < >> http://logs.openstack.org/85/331885/2/check/gate-grenade-dsvm-multinode/415e1bc/logs/new/screen-n-cpu.txt.gz?level=TRACE#_2016-06-21_16_21_30_994 >> >1840 >> WARNING oslo.privsep.daemon [-] privsep log: >> /usr/local/bin/nova-rootwrap: Unauthorized command: privsep-helper >> --config-file /etc/nova/nova.conf --privsep_context >> os_brick.privileged.default --privsep_sock_path >> /tmp/tmpV5w2VC/privsep.sock (no filter matched) >> >> .. so nova-rootwrap is rejecting the privsep-helper command line >> because no filter matched. This indicates the nova >> compute.filters file >> has not been updated, or is incorrect. >> >> >> As was later pointed out by mtreinish, grenade is attempting to >> run the >> newton code against mitaka configs, and this includes using mitaka >> rootwrap filters. Unfortunately, the change to add privsep to >> nova's >> rootwrap filters wasn't approved until the newton cycle (so that >> all the >> os-brick privsep-related changes could be approved together), and >> so >> this doesn't Just Work. >> >> Digging in further, it appears that there *is* a mechanism in >> grenade to >> upgrade rootwrap filters between major releases, but this needs >> to be >> explicitly updated for each project+release and hasn't been for >> nova+mitaka->newton. I'm not sure how this is *meant* to work, >> since >> the grenade "theory of upgrade" doesn't mention when configs >> should be >> updated - the only mechanism provided is an "exception ... used >> sparingly." >> >> >> As noted in the review, my understanding of the config changes is >> deprecation of options across release boundaries so that you can't >> drop a config option that would break someone from release to >> release without it being deprecated first. So deprecate option foo >> in mitaka, people upgrading from liberty to mitaka aren't broken, >> but they get warnings in mitaka so that when you drop the option in >> newton it's not a surprise and consumers should have adjusted during >> mitaka. >> >> For rootwrap filters I agree this is more complicated. >> >> >> Anyway, I added an upgrade step for nova mitaka->newton that >> updates >> rootwrap filters appropriately(*). Again, I'm not sure what this >> communicates to deployers compared to cinder (which *did* have the >> updated rootwrap filter merged in mitaka, but of course that >> update >> still needs to be installed at some point). >> (*) https://review.openstack.org/#/c/332610 >> >> - Gus >> >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> < >> http:
Re: [openstack-dev] [cinder] [nova] os-brick privsep failures and an upgrade strategy?
Hi team, Do we have any decision on this issue? I've found few patches but both of them are -1'ed. >From Cinder perspective, it blocks us to release new os-brick with features, which are needed for other projects like Cinder and python-brick-cinderclient-ext. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Jun 22, 2016 at 5:47 PM, Matt Riedemann wrote: > On 6/21/2016 10:12 PM, Angus Lees wrote: > >> On Wed, 22 Jun 2016 at 05:59 Matt Riedemann > <mailto:mrie...@linux.vnet.ibm.com>> wrote: >> >> Angus, what should we be looking at from the privsep side for >> debugging >> this? >> >> >> The line above the screen-n-cpu.txt.gz failure you linked to is: >> 2016-06-21 16:21:30.994 >> < >> http://logs.openstack.org/85/331885/2/check/gate-grenade-dsvm-multinode/415e1bc/logs/new/screen-n-cpu.txt.gz?level=TRACE#_2016-06-21_16_21_30_994 >> >1840 >> WARNING oslo.privsep.daemon [-] privsep log: >> /usr/local/bin/nova-rootwrap: Unauthorized command: privsep-helper >> --config-file /etc/nova/nova.conf --privsep_context >> os_brick.privileged.default --privsep_sock_path >> /tmp/tmpV5w2VC/privsep.sock (no filter matched) >> >> .. so nova-rootwrap is rejecting the privsep-helper command line >> because no filter matched. This indicates the nova compute.filters file >> has not been updated, or is incorrect. >> >> >> As was later pointed out by mtreinish, grenade is attempting to run the >> newton code against mitaka configs, and this includes using mitaka >> rootwrap filters. Unfortunately, the change to add privsep to nova's >> rootwrap filters wasn't approved until the newton cycle (so that all the >> os-brick privsep-related changes could be approved together), and so >> this doesn't Just Work. >> >> Digging in further, it appears that there *is* a mechanism in grenade to >> upgrade rootwrap filters between major releases, but this needs to be >> explicitly updated for each project+release and hasn't been for >> nova+mitaka->newton. I'm not sure how this is *meant* to work, since >> the grenade "theory of upgrade" doesn't mention when configs should be >> updated - the only mechanism provided is an "exception ... used >> sparingly." >> > > As noted in the review, my understanding of the config changes is > deprecation of options across release boundaries so that you can't drop a > config option that would break someone from release to release without it > being deprecated first. So deprecate option foo in mitaka, people upgrading > from liberty to mitaka aren't broken, but they get warnings in mitaka so > that when you drop the option in newton it's not a surprise and consumers > should have adjusted during mitaka. > > For rootwrap filters I agree this is more complicated. > > >> Anyway, I added an upgrade step for nova mitaka->newton that updates >> rootwrap filters appropriately(*). Again, I'm not sure what this >> communicates to deployers compared to cinder (which *did* have the >> updated rootwrap filter merged in mitaka, but of course that update >> still needs to be installed at some point). >> (*) https://review.openstack.org/#/c/332610 >> >> - Gus >> >> >> __ >> 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 >> >> > Alternatively Walter had a potential workaround to fallback to rootwrap > for os-brick: > > https://review.openstack.org/#/c/329586/ > > So we could maybe use that for newton. But os-vif doesn't have anything > like that, so we'd have to see what kind of (immediately deprecated) > workaround could happen for os-vif in newton and then drop that in ocata. > > I'm told danpb is out until tomorrow though so we'll probably need to wait > to talk to him about options there. > > > -- > > Thanks, > > Matt Riedemann > > > __ > 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] [Cinder] Nominating Scott D'Angelo to Cinder core
+2. Welcome to the team! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Tue, Jun 28, 2016 at 1:48 PM, Erlon Cruz wrote: > +1 > Not a core but surely is well deserved. Congrats Scott!! > > On Tue, Jun 28, 2016 at 5:06 AM, Gorka Eguileor > wrote: > >> >> +2 >> >> Congrats Scott!! >> >> >> On 27/06, Sean McGinnis wrote: >> > I would like to nominate Scott D'Angelo to core. Scott has been very >> > involved in the project for a long time now and is always ready to help >> > folks out on IRC. His contributions [1] have been very valuable and he >> > is a thorough reviewer [2]. >> > >> > Please let me know if there are any objects to this within the next >> > week. If there are none I will switch Scott over by next week, unless >> > all cores approve prior to then. >> > >> > Thanks! >> > >> > Sean McGinnis (smcginnis) >> > >> > [1] >> https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged >> > [2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt >> > >> > >> __ >> > 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] [openstack-operators][cinder] max_concurrent_builds in Cinder
Hi developers and operators, I would like to get any feedback from you about my idea before I'll start work on spec. In Nova, we've got max_concurrent_builds option [1] to set 'Maximum number of instance builds to run concurrently' per each compute. There is no equivalent Cinder. Why do we need it for Cinder? IMO, it could help us to address following issues: - Creation of N volumes at the same time increases a lot of resource usage by cinder-volume service. Image caching feature [2] could help us a bit in case when we create volume form image. But we still have to upload N images to the volumes backend at the same time. - Deletion on N volumes at parallel. Usually, it's not very hard task for Cinder, but if you have to delete 100+ volumes at once, you can fit different issues with DB connections, CPU and memory usages. In case of LVM, it also could use 'dd' command to cleanup volumes. - It will be some kind of load balancing in HA mode: if cinder-volume process is busy with current operations, it will not catch message from RabbitMQ and other cinder-volume service will do it. - From users perspective, it seems that better way is to create/delete N volumes a bit slower than fail after X volumes were created/deleted. [1] https://github.com/openstack/nova/blob/283da2bbb74d0a131a66703516d16698a05817c7/nova/conf/compute.py#L161-L163 [2] https://specs.openstack.org/openstack/cinder-specs/specs/liberty/image-volume-cache.html Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [cinder] A friendly reminder about reviews
Thanks, Eric. I'm doing stable reviews on weekly basis, new gerrit dashboard will be very helpful for me. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, May 11, 2016 at 5:05 PM, Eric Harney wrote: > On 05/11/2016 05:16 AM, Ivan Kolodyazhny wrote: > > Hi all, > > > > I would like to kindly ask you to pay a bit more attention to the > following areas: > > > > * Specs: we don' reviews specs as well as code:(. TBH, my specs > reviews count > > is very low too. > > * os-brick and python-brick-cinderclient-ext - we've got a lack of > code and > > review contribution for python-brick-cinderclient-ext > > * stable branches - let's help our stable maintainers team to review > such > > patches; It's pretty sad for me and all contributors that we can't > merge > > patches until branch EoL just because we didn't review them in time > > > > Just as a useful tip, I've saved the following as a "Cinder stable" item > on my gerrit menu (in gerrit prefs): > > > #/q/status:open+AND+(project:openstack/cinder+OR+project:openstack/os-brick)+AND+NOT+branch:master > > > __ > 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] [cinder] A friendly reminder about reviews
Hi all, I would like to kindly ask you to pay a bit more attention to the following areas: - Specs: we don' reviews specs as well as code:(. TBH, my specs reviews count is very low too. - os-brick and python-brick-cinderclient-ext - we've got a lack of code and review contribution for python-brick-cinderclient-ext - stable branches - let's help our stable maintainers team to review such patches; It's pretty sad for me and all contributors that we can't merge patches until branch EoL just because we didn't review them in time Some useful links: - Cinder Projects Review Inbox <https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2F.%2Acinder.%2A+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%252D1+label%3AVerified%3E%3D1+NOT+label%3ACode%252DReview%3C%3D%252D1%252cself+NOT+label%3ACode%252DReview%3E%3D1%252cself&title=Cinder+Review+Inbox&Cinder+Specs=project%3Aopenstack%2Fcinder%252Dspecs&Bug+Fixes=topic%3A%5Ebug%2F.%2A&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%252DReview%3C%3D2+age%3A5d&You+are+a+reviewer%252c+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=label%3ACode%252DReview%3E%3D2+limit%3A50&New+Contributors=reviewer%3A10068&Passed+Jenkins%252c+No+Negative+Feedback=NOT+label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3C%3D%252D1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%252DReview%3C%3D2+age%3A2d> - os-brick Review Inbox <https://review.openstack.org/#/dashboard/?foreach=project%3A%5Eopenstack%2F.%2Aos-brick.%2A+status%3Aopen+NOT+owner%3Aself+NOT+label%3AWorkflow%3C%3D%252D1+label%3AVerified%3E%3D1+NOT+label%3ACode%252DReview%3C%3D%252D1%252cself+NOT+label%3ACode%252DReview%3E%3D1%252cself&title=OS-Brick+Review+Inbox&Cinder+Specs=project%3Aopenstack%2Fcinder%252Dspecs&Bug+Fixes=topic%3A%5Ebug%2F.%2A&Needs+Feedback+%28Changes+older+than+5+days+that+have+not+been+reviewed+by+anyone%29=NOT+label%3ACode%252DReview%3C%3D2+age%3A5d&You+are+a+reviewer%252c+but+haven%27t+voted+in+the+current+revision=reviewer%3Aself&Needs+final+%2B2=label%3ACode%252DReview%3E%3D2+limit%3A50&New+Contributors=reviewer%3A10068&Passed+Jenkins%252c+No+Negative+Feedback=NOT+label%3ACode%252DReview%3E%3D2+NOT+label%3ACode%252DReview%3C%3D%252D1+limit%3A50&Wayward+Changes+%28Changes+with+no+code+review+in+the+last+2days%29=NOT+label%3ACode%252DReview%3C%3D2+age%3A2d> - python-brick-cinderclient-ext Review Inbox <https://review.openstack.org/#/dashboard/?foreach=project:%5Eopenstack/.*python-brick-cinderclient-ext.*%20status:open%20NOT%20owner:self%20NOT%20label:Workflow%3C=%252D1%20label:Verified%3E=1%20NOT%20label:Code%252DReview%3C=%252D1%252cself%20NOT%20label:Code%252DReview%3E=1%252cself&title=python-brick-cinderclient-ext%20Review%20Inbox&Cinder%20Specs=project:openstack/cinder%252Dspecs&Bug%20Fixes=topic:%5Ebug/.*&Needs%20Feedback%20(Changes%20older%20than%205%20days%20that%20have%20not%20been%20reviewed%20by%20anyone)=NOT%20label:Code%252DReview%3C=2%20age:5d&You%20are%20a%20reviewer%252c%20but%20haven't%20voted%20in%20the%20current%20revision=reviewer:self&Needs%20final%20+2=label:Code%252DReview%3E=2%20limit:50&New%20Contributors=reviewer:10068&Passed%20Jenkins%252c%20No%20Negative%20Feedback=NOT%20label:Code%252DReview%3E=2%20NOT%20label:Code%252DReview%3C=%252D1%20limit:50&Wayward%20Changes%20(Changes%20with%20no%20code%20review%20in%20the%20last%202days)=NOT%20label:Code%252DReview%3C=2%20age:2d> - http://docs.openstack.org/project-team-guide/stable-branches.html - Cinder projects <https://github.com/openstack/governance/blob/master/reference/projects.yaml#L197> Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] Cinder as generic volume manager
Hi Team, I'd get several requests about this features in IRC last weeks. I didn't stop working on it but any help is welcome:). Here is the list of proposed patched that are related to 'Use Cinder without Nova' feature: https://etherpad.openstack.org/p/use-cinder-without-nova Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Jan 11, 2016 at 1:37 PM, Ivan Kolodyazhny wrote: > Hi Team, > > Let me introduce updates related to use-cinder-without-nova blueprint > [1]. According to spec [2] we've introduced new > python-brick-cinderclient-ext project [3]. It's an official Cinder project > and implemented as an extension to python-cinderclient. > > For now, it supports only 'get-connector' CLI and Python API. The next > steps are: > >- setup functional tests job for our CI to test it over each patch >- implement attach/detach API >- implement 'force detach' from the Cinder side. > > Any feedback, comments and contribution are welcome! > > [1] https://blueprints.launchpad.net/cinder/+spec/use-cinder-without-nova > [2] https://review.openstack.org/#/c/224124/ > [3] https://github.com/openstack/python-brick-cinderclient-ext > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > On Wed, Sep 16, 2015 at 5:33 PM, Ivan Kolodyazhny wrote: > >> Jan, all, >> >> I've started a work on this task to complete it in Mitaka. Here is a very >> draft spec [1] and PoC [2]. >> >> [1] https://review.openstack.org/224124 >> [2] https://review.openstack.org/223851 >> >> Regards, >> Ivan Kolodyazhny, >> Web Developer, >> http://blog.e0ne.info/, >> http://notacash.com/, >> http://kharkivpy.org.ua/ >> >> On Tue, Jul 14, 2015 at 4:59 PM, Jan Safranek >> wrote: >> >>> On 07/10/2015 12:19 AM, Walter A. Boring IV wrote: >>> > On 07/09/2015 12:21 PM, Tomoki Sekiyama wrote: >>> >> Hi all, >>> >> >>> >> Just FYI, here is a sample script I'm using for testing os-brick which >>> >> attaches/detaches the cinder volume to the host using cinderclient and >>> >> os-brick: >>> >> >>> >> https://gist.github.com/tsekiyama/ee56cc0a953368a179f9 >>> >> >>> >> "python attach.py " will attach the volume to the >>> executed >>> >> host and shows a volume path. When you hit the enter key, the volume >>> is >>> >> detached. >>> >> >>> >> Note this is skipping "reserve" or "start_detaching" APIs so the >>> volume >>> >> state is not changed to "Attaching" or "Detaching". >>> >> >>> >> Regards, >>> >> Tomoki >>> > >>> > Very cool Tomoki. After chatting with folks in the Cinder IRC channel >>> > it looks like we are going to look at going with something more like >>> what >>> > your script is doing. We are most likely going to create a separate >>> > command line tool that does this same orchestration, using cinder >>> client, a new >>> > Cinder API that John Griffith is working on, and os-brick. >>> >>> Very cool indeed, it looks exactly like as what I need. >>> >>> >>> Jan >>> >>> >>> >>> __ >>> 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] [Cinder] gate-cinder-tox-db-functional job faulires and non-voting jobs
Hi team, It's pretty sad to me, but it seems that nobody cares about non-voting jobs :(. Cinder functional tests job is broken about 5 days [1] and I didn't see any comments on it in the reviews. As decided at summit, we're going to make this job voting. Stats from [1] proves that it's stable enough but was broken by a new oslo.versionedobject release. Anyway, there is a fix [1] for it. IMO, we have to care about non-voting jobs too. If they are not stable enough, they should be moved to experimental queue. We have to pay attention on such non-voting jobs like functional tests, Cinder under Apache, Rally, LIO target, etc while reviewing the patches. Usually, we break these jobs because we ignore non-voting failures. [1] http://graphite.openstack.org/render/?width=586&height=308&_salt=1462445496.596&from=00%3A00_20160401&until=23%3A59_20160505&target=stats.zuul.pipeline.check.job.gate-cinder-tox-db-functional.FAILURE&target=stats.zuul.pipeline.check.job.gate-cinder-tox-db-functional.SUCCESS [2] https://review.openstack.org/#/c/312875/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [Cinder] Nominating Michał Dulko to Cinder Core
+1, welcome to the team. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, May 4, 2016 at 4:20 AM, John Griffith wrote: > Definitely a +1 from me > > On Tue, May 3, 2016 at 6:10 PM, Patrick East > wrote: > >> +1, Michal has done some awesome work on Cinder! >> >> -Patrick >> >> On Tue, May 3, 2016 at 11:16 AM, Sean McGinnis >> wrote: >> >>> Hey everyone, >>> >>> I would like to nominate Michał Dulko to the Cinder core team. Michał's >>> contributions with both code reviews [0] and code contributions [1] have >>> been significant for some time now. >>> >>> His persistence with versioned objects has been instrumental in getting >>> support in the Mitaka release for rolling upgrades. >>> >>> If there are no objections from current cores by next week, I will add >>> Michał to the core group. >>> >>> [0] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt >>> [1] >>> >>> https://review.openstack.org/#/q/owner:%22Michal+Dulko+%253Cmichal.dulko%2540intel.com%253E%22++status:merged >>> >>> Thanks! >>> >>> Sean McGinnis (smcginnis) >>> >>> >>> >>> __ >>> 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
Re: [openstack-dev] [Cinder] About snapshot Rollback?
Hi Chenzongliang, I still don't understand what is difference between proposed feature and 'restore volume from snapshot'? Could you please explain it? Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Thu, Apr 7, 2016 at 12:00 PM, Chenzongliang wrote: > Dear Cruz: > > > > Thanks for you kind support, I will review the previous spec > according to the following links. May be more user scenario we should > considered,such as backup,create volume from snapshot,consistency group and > etc,we will spend some time to gather > > the user's scenarios and determin what to do next step. > > > > Sincerely, > > zongliang chen > > > > *发件人:* Erlon Cruz [mailto:sombra...@gmail.com] > *发送时间:* 2016年4月5日 2:50 > *收件人:* OpenStack Development Mailing List (not for usage questions) > *抄送:* Zhangli (ISSP); Shenhong (C) > *主题:* Re: [openstack-dev] [Cinder] About snapshot Rollback? > > > > Hi Chen, > > > > Not sure if I got you right but I brought this topic in #openstack-cinder > some days ago. The idea is to be able to rollback a snapshot in Cinder. > Today what is possible to do is to create a volume from a snapshot. From > the user point of view, this is not ideal, as there are several cases, if > not the majority of, that the purpose of the snapshot is to revert to a > desired state, and not keep the original volume. For some backends, keeping > the original volume means space consumption. This space problem becomes > bold when we think about consistency groups. For consistency groups, some > backends might have to copy an entire filesystem for each snapshot, > consuming space and time. So, I think it would be desired to have the > ability to revert snapshots. > > > > I know there have been efforts in the past[1] to implement that, but for > some reason the work was stopped. If you want to retake the effort please > create a spec[2] sol everybody can provide feedback. > > > > Erlon > > > > > > [1] > https://blueprints.launchpad.net/cinder/+spec/cinder-volume-rollback-snapshot > > [2] https://github.com/openstack/cinder-specs > > > > On Thu, Mar 24, 2016 at 6:09 AM, Chenzongliang > wrote: > > Hi all: > > We are condering add a fucntion rollback_snapshot when we use backup. > In the end user's scenario. If a vm fails, we hope that we can use snapshot > to to recovery the volume's data. > > Beacuse it can quickly recovery our vm. But if we use the remote data > to recovery. We will spend more time. > > But i'm not sure if the data was recoveried from the backend. whether > the host need to rescan the volumes? At the same time. If a volume have > been extended, whether it can be roolback? > > > >I want to know whether the topic have been discussed or have other > recommendations to us? > > > >Thanks > > > __ > 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] [cinder][openstackclient] Required name option for volumes, snapshots and backups
Hi team, >From the Cinder point of view, both volumes, snapshots and backups APIs do not require name param. But python-openstackclient requires name param for these entities. I'm going to fix this inconsistency with patch [1]. Unfortunately, it's a bit more than changing required params to not required. We have to change CLI signatures. E.g. for create a volume: from [2]. Is it acceptable? What is the right way to do such changes for OpenStack Client? [1] https://review.openstack.org/#/c/294146/ [2] http://paste.openstack.org/show/491771/ [3] http://paste.openstack.org/show/491772/ Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ __ 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] [Tempest][cinder] jenkins fails due to server fault
Poornima,
Both Masayuki commented in the review request. For more details you can
check cinder-api logs.
Regards,
Ivan Kolodyazhny,
http://blog.e0ne.info/
On Mon, Mar 21, 2016 at 8:18 AM, Poornima Kshirsagar
wrote:
> Hi,
>
> Wrote a Tempest test to check force_delete_backup method [1].
>
> Check the tempest test run was successful see [2]
>
> However jenkins fails with below trace back
>
>
>
> Captured traceback:
> 2016-03-18 09:14:16.884 | ~~~
> 2016-03-18 09:14:16.884 | Traceback (most recent call last):
> 2016-03-18 09:14:16.884 | File
> "tempest/api/volume/admin/test_volumes_backup.py", line 55, in
> test_volume_backup_create_and_force_delete_when_available
> 2016-03-18 09:14:16.884 |
> self.backups_adm_client.force_delete_backup(backup['id'])
> 2016-03-18 09:14:16.884 | File
> "tempest/services/volume/base/base_backups_client.py", line 119, in
> force_delete_backup
> 2016-03-18 09:14:16.884 | resp, body =
> self.post('backups/%s/action' % (backup_id), post_body)
> 2016-03-18 09:14:16.884 | File "tempest/lib/common/rest_client.py",
> line 259, in post
> 2016-03-18 09:14:16.885 | return self.request('POST', url,
> extra_headers, headers, body)
> 2016-03-18 09:14:16.885 | File "tempest/lib/common/rest_client.py",
> line 642, in request
> 2016-03-18 09:14:16.885 | resp, resp_body)
> 2016-03-18 09:14:16.885 | File "tempest/lib/common/rest_client.py",
> line 761, in _error_checker
> 2016-03-18 09:14:16.885 | message=message)
> 2016-03-18 09:14:16.885 | tempest.lib.exceptions.ServerFault: Got
> server fault
> 2016-03-18 09:14:16.885 | Details: The server has either erred or is
> incapable of performing the requested operation.
> 2016-03-18 09:14:16.886 |
>
>
>
> is this known issue how do i fix it?
>
>
>
> [1] https://review.openstack.org/#/c/284106/
>
> [2] http://paste.openstack.org/show/491221/
>
>
> Regards
> Poornima
>
> __
> 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] [Cinder] Ivan Kolodyazhny PTL Candidacy
Hello Team, It's a big honor for me be a part of the our Cinder community and I do my best to make Cinder better. That's why I'm I'm announcing my candidacy for Cinder PTL for the Mitaka release. That doesn't mean that I'm working at half strength now. It means that I would like to give as much benefits to Cinder and OpenStack as I can. We as cinder community did great job to have Rolling Upgrades landed in Mitaka. It's really cool. We introduced new Replication v2.1 version in the middle of cycle but we've already got few drivers which implemented it. API microversions are also very useful thing. It allows us to change our API faster and do not break any existing API user. We started work on Active/Active HA for cinder-volume process. I really hope that we'll have this feature implemented in the next release. As PTL I would like to bring more attention to the following areas during Newton release cycle. These things are important not only for Cinder community but for any Cinder users and other OpenStack projects too. * Cinde quality and stability. I don't say that Cinder is not stable enough. I mean that it would be great if we'll improve our test coverage and testing strategy including 3-rd party CI. See my mail in openstack-dev mailing list for details [1]. * We've got a lot of technical debt and Newton could be a good time to fix it: finish started features like A/A HA, get more Replication v2.1 implementations from vendors, fix architectural issues which do not allow us to implement new features faster, fix Cinder-Nova related issues. * Make Cinder viable as a stand-alone volume manager. It means, Cinder will work without Nova and you'll be available to attach volumes to any host. We finished first part of this task in Mitaka, now we have to continue work on it. * Ironic integration: We talk with Ironic team about it for several last summits. I started work on attach feature in scope of 'Cinder Without Nova' initiative. Full integration with Ironic is very important for every Cinder and Ironic user. Let's do it. Last but not least, I do understand that being PTL is full-time job which will require a lot of communications in a different time-zones. I'd like to say, I'm ready for it. [1] http://lists.openstack.org/pipermail/openstack-dev/2016-March/088034.html Thank you, Ivan Kolodyazhny (e0ne) __ 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] [cinder] Proposal: changes to our current testing process
John, It's a good option. Let's try it! Also, we can try to find/implement something like [13] for ostestr. [13] https://github.com/mahmoudimus/nose-timer Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Mon, Mar 7, 2016 at 7:16 PM, John Griffith wrote: > > > On Mon, Mar 7, 2016 at 8:57 AM, Knight, Clinton > wrote: > >> >> >> On 3/7/16, 10:45 AM, "Eric Harney" wrote: >> >> >On 03/06/2016 09:35 PM, John Griffith wrote: >> >> On Sat, Mar 5, 2016 at 4:27 PM, Jay S. Bryant >> >>> >>> wrote: >> >> >> >>> Ivan, >> >>> >> >>> I agree that our testing needs improvement. Thanks for starting this >> >>> thread. >> >>> >> >>> With regards to adding a hacking check for tests that run too long ... >> >>>are >> >>> you thinking that we would have a timer that checks or long running >> >>>jobs or >> >>> something that checks for long sleeps in the testing code? Just >> >>>curious >> >>> your ideas for tackling that situation. Would be interested in >> helping >> >>> with that, perhaps. >> >>> >> >>> Thanks! >> >>> Jay >> >>> >> >>> >> >>> On 03/02/2016 05:25 AM, Ivan Kolodyazhny wrote: >> >>> >> >>> Hi Team, >> >>> >> >>> Here are my thoughts and proposals how to make Cinder testing process >> >>> better. I won't cover "3rd party CI's" topic here. I will share my >> >>>opinion >> >>> about current and feature jobs. >> >>> >> >>> >> >>> Unit-tests >> >>> >> >>>- Long-running tests. I hope, everybody will agree that unit-tests >> >>>must be quite simple and very fast. Unit tests which takes more >> >>>than 3-5 >> >>>seconds should be refactored and/or moved to 'integration' tests. >> >>>Thanks to Tom Barron for several fixes like [1]. IMO, we it would >> be >> >>>good to have some hacking checks to prevent such issues in a >> future. >> >>> >> >>>- Tests coverage. We don't check it in an automatic way on gates. >> >>>Usually, we require to add some unit-tests during code review >> >>>process. Why >> >>>can't we add coverage job to our CI and do not merge new patches, >> >>>with >> >>>will decrease tests coverage rate? Maybe, such job could be voting >> >>>in a >> >>>future to not ignore it. For now, there is not simple way to check >> >>>coverage >> >>>because 'tox -e cover' output is not useful [2]. >> >> The Manila project has a coverage job that may be of interest to Cinder. >> It’s not perfect, because sometimes the periodic loopingcall routines run >> during the test run and sometimes not, leading to false negatives. But >> most of the time it’s a handy confirmation that the unit test coverage >> didn’t decline due to a patch. Look at the manila-coverage job in this >> example: https://review.openstack.org/#/c/287575/ >> >> >>> >> >>> >> >>> Functional tests for Cinder >> >>> >> >>> We introduced some functional tests last month [3]. Here is a patch to >> >>> infra to add new job [4]. Because these tests were moved from >> >>>unit-tests, I >> >>> think we're OK to make this job voting. Such tests should not be a >> >>> replacement for Tempest. They even could tests Cinder with Fake Driver >> >>>to >> >>> make it faster and not related on storage backends issues. >> >>> >> >>> >> >>> Tempest in-tree tests >> >>> >> >>> Sean started work on it [5] and I think it's a good idea to get them >> in >> >>> Cinder repo to run them on Tempest jobs and 3-rd party CIs against a >> >>>real >> >>> backend. >> >>> >> >>> >> >>> Functional tests for python-brick-cinderclient-ext >> >>> >> >>> There are patches that introduces functional tests [6] and new job >> [7]. >> >>> >> >>> >> >>> Functional tests for python-cinderclient >
Re: [openstack-dev] [oslo] PTL for Newton and beyond
Thanks for your hard work, Dims! Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Fri, Mar 4, 2016 at 3:34 PM, Mehdi Abaakouk wrote: > Hi, > > Thanks for all the great work you have done, I have appreciated your > leadership on Oslo, > and a special thanks to bring in new people in oslo.messaging ;) > > > Le 2016-03-03 11:32, Davanum Srinivas a écrit : > >> Team, >> >> It has been great working with you all as PTL for Oslo. Looks like the >> nominations open up next week for elections and am hoping more than >> one of you will step up for the next cycle(s). I can show you the >> ropes and help smoothen the transition process if you let me know >> about your interest in being the next PTL. With the move to more >> automated testing in our CI (periodic jobs running against oslo.* >> master) and the adoption of the release process (logging reviews in >> /releases repo) the load should be considerably less on you. >> especially proud of all the new people joining as both oslo cores and >> project cores and hitting the ground running. Big shout out to Doug >> Hellmann for his help and guidance when i transitioned into the PTL >> role. >> >> Main challenges will be to get back confidence of all the projects >> that use the oslo libraries, NOT be the first thing they look for when >> things break (Better backward compat, better test matrix) and >> evangelizing that Oslo is still the common play ground for *all* >> projects and not just the headache of some nut jobs who are willing to >> take up the impossible task of defining and nurturing these libraries. >> There's a lot of great work ahead of us and i am looking forward to >> continue to work with you all. >> >> Thanks, >> Dims >> > > -- > Mehdi Abaakouk > mail: sil...@sileht.net > irc: sileht > > > __ > 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] [cinder] Proposal: changes to our current testing process
I'll try to implement such scenario and step-by-step guideline soon. Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 5:16 PM, Eric Harney wrote: > On 03/02/2016 10:07 AM, Ivan Kolodyazhny wrote: > > Eric, > > > > For now, we test Cinder API with some concurrency only with Rally, so, > IMO, > > it's reasonable get more scenarios for API races fixes. > > > > It's not a hard task to implement new scenarios, they are pretty simple: > > [11] and [12] > > > > Sure, these are simple, but I think it's nowhere near that simple to > write a scenario which will prove that "remove API races" works correctly. > > > [11] > > > https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/cinder/volumes.py#L535 > > [12] > > > https://github.com/openstack/rally/blob/master/rally-jobs/cinder.yaml#L516 > > > > Regards, > > Ivan Kolodyazhny, > > http://blog.e0ne.info/ > > > > On Wed, Mar 2, 2016 at 4:50 PM, Eric Harney wrote: > > > >> On 03/02/2016 09:36 AM, Ivan Kolodyazhny wrote: > >>> Eric, > >>> > >>> There are Gorka's patches [10] to remove API Races > >>> > >>> > >>> [10] > >>> > >> > https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified > >>> > >>> Regards, > >>> Ivan Kolodyazhny, > >>> http://blog.e0ne.info/ > >>> > >> > >> So the second part of my question is, is writing a Rally job to prove > >> out that code a reasonable task? > >> > >> How hard is that to do and what does it look like? > >> > >>> On Wed, Mar 2, 2016 at 4:27 PM, Eric Harney > wrote: > >>> > >>>> On 03/02/2016 06:25 AM, Ivan Kolodyazhny wrote: > >>>>> Hi Team, > >>>>> > >>>>> Here are my thoughts and proposals how to make Cinder testing process > >>>>> better. I won't cover "3rd party CI's" topic here. I will share my > >>>> opinion > >>>>> about current and feature jobs. > >>>>> > >>>>> > >>>>> Unit-tests > >>>>> > >>>>>- Long-running tests. I hope, everybody will agree that unit-tests > >>>> must > >>>>>be quite simple and very fast. Unit tests which takes more than > 3-5 > >>>> seconds > >>>>>should be refactored and/or moved to 'integration' tests. > >>>>>Thanks to Tom Barron for several fixes like [1]. IMO, we it would > be > >>>>>good to have some hacking checks to prevent such issues in a > future. > >>>>> > >>>>>- Tests coverage. We don't check it in an automatic way on gates. > >>>>>Usually, we require to add some unit-tests during code review > >>>> process. Why > >>>>>can't we add coverage job to our CI and do not merge new patches, > >> with > >>>>>will decrease tests coverage rate? Maybe, such job could be voting > >> in > >>>> a > >>>>>future to not ignore it. For now, there is not simple way to check > >>>> coverage > >>>>>because 'tox -e cover' output is not useful [2]. > >>>>> > >>>>> > >>>>> Functional tests for Cinder > >>>>> > >>>>> We introduced some functional tests last month [3]. Here is a patch > to > >>>>> infra to add new job [4]. Because these tests were moved from > >>>> unit-tests, I > >>>>> think we're OK to make this job voting. Such tests should not be a > >>>>> replacement for Tempest. They even could tests Cinder with Fake > Driver > >> to > >>>>> make it faster and not related on storage backends issues. > >>>>> > >>>>> > >>>>> Tempest in-tree tests > >>>>> > >>>>> Sean started work on it [5] and I think it's a good idea to get them > in > >>>>> Cinder repo to run them on Tempest jobs and 3-rd party CIs against a > >> real > >>>>> backend. > >>>>> > >>>>> > >>>>> Functional tests for python-brick-cinderclient-ext > &g
Re: [openstack-dev] [cinder] Proposal: changes to our current testing process
Eric, For now, we test Cinder API with some concurrency only with Rally, so, IMO, it's reasonable get more scenarios for API races fixes. It's not a hard task to implement new scenarios, they are pretty simple: [11] and [12] [11] https://github.com/openstack/rally/blob/master/rally/plugins/openstack/scenarios/cinder/volumes.py#L535 [12] https://github.com/openstack/rally/blob/master/rally-jobs/cinder.yaml#L516 Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 4:50 PM, Eric Harney wrote: > On 03/02/2016 09:36 AM, Ivan Kolodyazhny wrote: > > Eric, > > > > There are Gorka's patches [10] to remove API Races > > > > > > [10] > > > https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified > > > > Regards, > > Ivan Kolodyazhny, > > http://blog.e0ne.info/ > > > > So the second part of my question is, is writing a Rally job to prove > out that code a reasonable task? > > How hard is that to do and what does it look like? > > > On Wed, Mar 2, 2016 at 4:27 PM, Eric Harney wrote: > > > >> On 03/02/2016 06:25 AM, Ivan Kolodyazhny wrote: > >>> Hi Team, > >>> > >>> Here are my thoughts and proposals how to make Cinder testing process > >>> better. I won't cover "3rd party CI's" topic here. I will share my > >> opinion > >>> about current and feature jobs. > >>> > >>> > >>> Unit-tests > >>> > >>>- Long-running tests. I hope, everybody will agree that unit-tests > >> must > >>>be quite simple and very fast. Unit tests which takes more than 3-5 > >> seconds > >>>should be refactored and/or moved to 'integration' tests. > >>>Thanks to Tom Barron for several fixes like [1]. IMO, we it would be > >>>good to have some hacking checks to prevent such issues in a future. > >>> > >>>- Tests coverage. We don't check it in an automatic way on gates. > >>>Usually, we require to add some unit-tests during code review > >> process. Why > >>>can't we add coverage job to our CI and do not merge new patches, > with > >>>will decrease tests coverage rate? Maybe, such job could be voting > in > >> a > >>>future to not ignore it. For now, there is not simple way to check > >> coverage > >>>because 'tox -e cover' output is not useful [2]. > >>> > >>> > >>> Functional tests for Cinder > >>> > >>> We introduced some functional tests last month [3]. Here is a patch to > >>> infra to add new job [4]. Because these tests were moved from > >> unit-tests, I > >>> think we're OK to make this job voting. Such tests should not be a > >>> replacement for Tempest. They even could tests Cinder with Fake Driver > to > >>> make it faster and not related on storage backends issues. > >>> > >>> > >>> Tempest in-tree tests > >>> > >>> Sean started work on it [5] and I think it's a good idea to get them in > >>> Cinder repo to run them on Tempest jobs and 3-rd party CIs against a > real > >>> backend. > >>> > >>> > >>> Functional tests for python-brick-cinderclient-ext > >>> > >>> There are patches that introduces functional tests [6] and new job [7]. > >>> > >>> > >>> Functional tests for python-cinderclient > >>> > >>> We've got a very limited set of such tests and non-voting job. IMO, we > >> can > >>> run them even with Cinder Fake Driver to make them not depended on a > >>> storage backend and make it faster. I believe, we can make this job > >> voting > >>> soon. Also, we need more contributors to this kind of tests. > >>> > >>> > >>> Integrated tests for python-cinderclient > >>> > >>> We need such tests to make sure that we won't break Nova, Heat or other > >>> python-cinderclient consumers with a next merged patch. There is a > thread > >>> in openstack-dev ML about such tests [8] and proposal [9] to introduce > >> them > >>> to python-cinderclient. > >>> > >>> > >>> Rally tests > >>> > >>> IMO, it would be good to have new Rally scenarios for every patches > like > >>> 'i
Re: [openstack-dev] [cinder] Proposal: changes to our current testing process
Arkady, It's not true. We've got non-voting Rally job on Cinder gates called "gate-rally-dsvm-cinder". Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 4:52 PM, wrote: > Rally is not part of the gate. > > Also making performance test without 3rd party CI will not be very useful. > > It is a good idea to run Rally performance and scenario testing but > outside gate process. > > > > *From:* Ivan Kolodyazhny [mailto:e...@e0ne.info] > *Sent:* Wednesday, March 02, 2016 8:36 AM > *To:* OpenStack Development Mailing List (not for usage questions) < > openstack-dev@lists.openstack.org> > *Subject:* Re: [openstack-dev] [cinder] Proposal: changes to our current > testing process > > > > Eric, > > > > There are Gorka's patches [10] to remove API Races > > > > > > [10] > https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified > > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > > > > On Wed, Mar 2, 2016 at 4:27 PM, Eric Harney wrote: > > On 03/02/2016 06:25 AM, Ivan Kolodyazhny wrote: > > Hi Team, > > > > Here are my thoughts and proposals how to make Cinder testing process > > better. I won't cover "3rd party CI's" topic here. I will share my > opinion > > about current and feature jobs. > > > > > > Unit-tests > > > >- Long-running tests. I hope, everybody will agree that unit-tests > must > >be quite simple and very fast. Unit tests which takes more than 3-5 > seconds > >should be refactored and/or moved to 'integration' tests. > >Thanks to Tom Barron for several fixes like [1]. IMO, we it would be > >good to have some hacking checks to prevent such issues in a future. > > > >- Tests coverage. We don't check it in an automatic way on gates. > > >Usually, we require to add some unit-tests during code review > process. Why > >can't we add coverage job to our CI and do not merge new patches, with > >will decrease tests coverage rate? Maybe, such job could be voting in > a > >future to not ignore it. For now, there is not simple way to check > coverage > >because 'tox -e cover' output is not useful [2]. > > > > > > Functional tests for Cinder > > > > We introduced some functional tests last month [3]. Here is a patch to > > infra to add new job [4]. Because these tests were moved from > unit-tests, I > > think we're OK to make this job voting. Such tests should not be a > > replacement for Tempest. They even could tests Cinder with Fake Driver to > > make it faster and not related on storage backends issues. > > > > > > Tempest in-tree tests > > > > Sean started work on it [5] and I think it's a good idea to get them in > > Cinder repo to run them on Tempest jobs and 3-rd party CIs against a real > > backend. > > > > > > Functional tests for python-brick-cinderclient-ext > > > > There are patches that introduces functional tests [6] and new job [7]. > > > > > > Functional tests for python-cinderclient > > > > We've got a very limited set of such tests and non-voting job. IMO, we > can > > run them even with Cinder Fake Driver to make them not depended on a > > storage backend and make it faster. I believe, we can make this job > voting > > soon. Also, we need more contributors to this kind of tests. > > > > > > Integrated tests for python-cinderclient > > > > We need such tests to make sure that we won't break Nova, Heat or other > > python-cinderclient consumers with a next merged patch. There is a thread > > in openstack-dev ML about such tests [8] and proposal [9] to introduce > them > > to python-cinderclient. > > > > > > Rally tests > > > > IMO, it would be good to have new Rally scenarios for every patches like > > 'improves performance', 'fixes concurrency issues', etc. Even if we as a > > Cinder community don't have enough time to implement them, we have to ask > > for them in reviews, openstack-dev ML, file Rally bugs and blueprints if > > needed. > > > > Are there any recent examples of a fix like this recently where it would > seem like a reasonable task to write a Rally scenario along with the patch? > > Not being very familiar with Rally (as I think most of us aren't), I'm > having a hard time picturing this. > > > > > [1] https://review.openstack.org
Re: [openstack-dev] [cinder] Proposal: changes to our current testing process
Eric, There are Gorka's patches [10] to remove API Races [10] https://review.openstack.org/#/q/project:openstack/cinder+branch:master+topic:fix/api-races-simplified Regards, Ivan Kolodyazhny, http://blog.e0ne.info/ On Wed, Mar 2, 2016 at 4:27 PM, Eric Harney wrote: > On 03/02/2016 06:25 AM, Ivan Kolodyazhny wrote: > > Hi Team, > > > > Here are my thoughts and proposals how to make Cinder testing process > > better. I won't cover "3rd party CI's" topic here. I will share my > opinion > > about current and feature jobs. > > > > > > Unit-tests > > > >- Long-running tests. I hope, everybody will agree that unit-tests > must > >be quite simple and very fast. Unit tests which takes more than 3-5 > seconds > >should be refactored and/or moved to 'integration' tests. > >Thanks to Tom Barron for several fixes like [1]. IMO, we it would be > >good to have some hacking checks to prevent such issues in a future. > > > >- Tests coverage. We don't check it in an automatic way on gates. > >Usually, we require to add some unit-tests during code review > process. Why > >can't we add coverage job to our CI and do not merge new patches, with > >will decrease tests coverage rate? Maybe, such job could be voting in > a > >future to not ignore it. For now, there is not simple way to check > coverage > >because 'tox -e cover' output is not useful [2]. > > > > > > Functional tests for Cinder > > > > We introduced some functional tests last month [3]. Here is a patch to > > infra to add new job [4]. Because these tests were moved from > unit-tests, I > > think we're OK to make this job voting. Such tests should not be a > > replacement for Tempest. They even could tests Cinder with Fake Driver to > > make it faster and not related on storage backends issues. > > > > > > Tempest in-tree tests > > > > Sean started work on it [5] and I think it's a good idea to get them in > > Cinder repo to run them on Tempest jobs and 3-rd party CIs against a real > > backend. > > > > > > Functional tests for python-brick-cinderclient-ext > > > > There are patches that introduces functional tests [6] and new job [7]. > > > > > > Functional tests for python-cinderclient > > > > We've got a very limited set of such tests and non-voting job. IMO, we > can > > run them even with Cinder Fake Driver to make them not depended on a > > storage backend and make it faster. I believe, we can make this job > voting > > soon. Also, we need more contributors to this kind of tests. > > > > > > Integrated tests for python-cinderclient > > > > We need such tests to make sure that we won't break Nova, Heat or other > > python-cinderclient consumers with a next merged patch. There is a thread > > in openstack-dev ML about such tests [8] and proposal [9] to introduce > them > > to python-cinderclient. > > > > > > Rally tests > > > > IMO, it would be good to have new Rally scenarios for every patches like > > 'improves performance', 'fixes concurrency issues', etc. Even if we as a > > Cinder community don't have enough time to implement them, we have to ask > > for them in reviews, openstack-dev ML, file Rally bugs and blueprints if > > needed. > > > > Are there any recent examples of a fix like this recently where it would > seem like a reasonable task to write a Rally scenario along with the patch? > > Not being very familiar with Rally (as I think most of us aren't), I'm > having a hard time picturing this. > > > > > [1] https://review.openstack.org/#/c/282861/ > > [2] http://paste.openstack.org/show/488925/ > > [3] https://review.openstack.org/#/c/267801/ > > [4] https://review.openstack.org/#/c/287115/ > > [5] https://review.openstack.org/#/c/274471/ > > [6] https://review.openstack.org/#/c/265811/ > > [7] https://review.openstack.org/#/c/265925/ > > [8] > > > http://lists.openstack.org/pipermail/openstack-dev/2016-March/088027.html > > [9] https://review.openstack.org/#/c/279432/ > > > > > > Regards, > > Ivan Kolodyazhny, > > http://blog.e0ne.info/ > > > > > > > > > __ > > 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
