Re: [openstack-dev] [Horizon] Suggestions for handling new panels and refactors in the future
Personally, I¹d still vote for feature branching: I¹d really love to see an Angular Panels feature branch worked on separately and then merged back in; effectively, Travis¹ 2nd option. Pick 3(?) panels, like Users, Images, and the System Information one I¹ve seen around, iterate quickly, merge in M-1/M-2. There¹s not really any risk there, and it¹s very easy for people to toggle on or off in their existing workflows. Also, there isn¹t any spin up time in terms of setting up new repos and adding new core groups through infra etc. The ideal time to do this would be at the start of the cycle, too. New repos sounds like too big a split, and I¹m worried about where that leaves the community as a whole. Also, I¹m failing to see how mixing the angular work in with plugin challenges is going to speed to it upŠ sounds like a bit of a recipe for disaster, IMO. We should keep those concerns separate for now; there are multiple plugins being written in both AngularJS and Python already, so I think issues will arise organically as is. Rob On 09/10/2015 21:35, "Tripp, Travis S" wrote: >Hi Doug! > >I think the is a great discussion topic and you summarize your points >very nicely! > > I wish you¹d responded to this thread, though: >https://openstack.nimeyo.com/58582/openstack-dev-horizon-patterns-for-angu >lar-panels, because it is talking about the same problem. This is option >3 I mentioned there and I do think this is still a viable option to >consider, but we should discuss all the options. > >Please consider that thread as my initial response to your emailŠ and >let¹s keep discussing! > >Thanks, >Travis > >From: Douglas Fish >Reply-To: OpenStack List >Date: Friday, October 9, 2015 at 8:42 AM >To: OpenStack List >Subject: [openstack-dev] [Horizon] Suggestions for handling new panels >and refactors in the future > >I have two suggestions for handling both new panels and refactoring >existing panels that I think could benefit us in the future: >1) When we are creating a panel that's a major refactor of an existing it >should be a new separate panel, not a direct code replacement of the >existing panel >2) New panels (include the refactors of existing panels) should be >developed in an out of tree gerrit repository. > >Why make refactors a separate panel? > >I was taken a bit off guard after we merged the Network >Topology->Curvature improvement: this was a surprise to some people >outside of the Horizon community (though it had been discussed within >Horizon for as long as I've been on the project). In retrospect, I think >it would have been better to keep both the old Network Topology and new >curvature based topology in our Horizon codebase. Doing so would have >allowed operators to perform A-B/ Red-Black testing if they weren't >immediately convinced of the awesomeness of the panel. It also would have >allowed anyone with a customization of the Network Topology panel to have >some time to configure their Horizon instance to continue to use the >Legacy panel while they updated their customization to work with the new >panel. > >Perhaps we should treat panels more like an API element and take them >through a deprecation cycle before removing them completely. Giving time >for customizers to update their code is going to be especially important >as we build angular replacements for python panels. While we have much >better plugin support for angular there is still a learning curve for >those developers. > >Why build refactors and new panels out of tree? > >First off, it appears to me trying to build new panels in tree has been >fairly painful. I've seen big long lived patches pushed along without >being merged. It's quite acceptable and expected to quickly merge >half-complete patches into a brand new repository - but you can't behave >that way working in tree in Horizon. Horizon needs to be kept >production/operator ready. External repositories do not. Merging code >quickly can ease collaboration and avoid this kind of long lived patch >set. > >Secondly, keeping new panels/plugins in a separate repository >decentralizes decisions about which panels are "ready" and which aren't. >If one group feels a plugin is "ready" they can make it their default >version of the panel, and perhaps put resources toward translating it. If >we develop these panels in-tree we need to make a common decision about >what "ready" means - and once it's in everyone who wants a translated >Horizon will need to translate it. > >Finally, I believe developing new panels out of tree will help improve >our plugin support in Horizon. It's this whole "eating your own dog food" >idea. As soon as we start using our own Hori
Re: [openstack-dev] [Horizon] Suggestions for handling new panels and refactors in the future
Hi Doug! I think the is a great discussion topic and you summarize your points very nicely! I wish you’d responded to this thread, though: https://openstack.nimeyo.com/58582/openstack-dev-horizon-patterns-for-angular-panels, because it is talking about the same problem. This is option 3 I mentioned there and I do think this is still a viable option to consider, but we should discuss all the options. Please consider that thread as my initial response to your email… and let’s keep discussing! Thanks, Travis From: Douglas Fish Reply-To: OpenStack List Date: Friday, October 9, 2015 at 8:42 AM To: OpenStack List Subject: [openstack-dev] [Horizon] Suggestions for handling new panels and refactors in the future I have two suggestions for handling both new panels and refactoring existing panels that I think could benefit us in the future: 1) When we are creating a panel that's a major refactor of an existing it should be a new separate panel, not a direct code replacement of the existing panel 2) New panels (include the refactors of existing panels) should be developed in an out of tree gerrit repository. Why make refactors a separate panel? I was taken a bit off guard after we merged the Network Topology->Curvature improvement: this was a surprise to some people outside of the Horizon community (though it had been discussed within Horizon for as long as I've been on the project). In retrospect, I think it would have been better to keep both the old Network Topology and new curvature based topology in our Horizon codebase. Doing so would have allowed operators to perform A-B/ Red-Black testing if they weren't immediately convinced of the awesomeness of the panel. It also would have allowed anyone with a customization of the Network Topology panel to have some time to configure their Horizon instance to continue to use the Legacy panel while they updated their customization to work with the new panel. Perhaps we should treat panels more like an API element and take them through a deprecation cycle before removing them completely. Giving time for customizers to update their code is going to be especially important as we build angular replacements for python panels. While we have much better plugin support for angular there is still a learning curve for those developers. Why build refactors and new panels out of tree? First off, it appears to me trying to build new panels in tree has been fairly painful. I've seen big long lived patches pushed along without being merged. It's quite acceptable and expected to quickly merge half-complete patches into a brand new repository - but you can't behave that way working in tree in Horizon. Horizon needs to be kept production/operator ready. External repositories do not. Merging code quickly can ease collaboration and avoid this kind of long lived patch set. Secondly, keeping new panels/plugins in a separate repository decentralizes decisions about which panels are "ready" and which aren't. If one group feels a plugin is "ready" they can make it their default version of the panel, and perhaps put resources toward translating it. If we develop these panels in-tree we need to make a common decision about what "ready" means - and once it's in everyone who wants a translated Horizon will need to translate it. Finally, I believe developing new panels out of tree will help improve our plugin support in Horizon. It's this whole "eating your own dog food" idea. As soon as we start using our own Horizon plugin mechanism for our own development we are going to become aware of it's shortcomings (like quotas) and will be sufficiently motivated to fix them. Looking forward to further discussion and other ideas on this! Doug Fish __ 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] Suggestions for handling new panels and refactors in the future
I have two suggestions for handling both new panels and refactoring existing panels that I think could benefit us in the future: 1) When we are creating a panel that's a major refactor of an existing it should be a new separate panel, not a direct code replacement of the existing panel 2) New panels (include the refactors of existing panels) should be developed in an out of tree gerrit repository. Why make refactors a separate panel? I was taken a bit off guard after we merged the Network Topology->Curvature improvement: this was a surprise to some people outside of the Horizon community (though it had been discussed within Horizon for as long as I've been on the project). In retrospect, I think it would have been better to keep both the old Network Topology and new curvature based topology in our Horizon codebase. Doing so would have allowed operators to perform A-B/ Red-Black testing if they weren't immediately convinced of the awesomeness of the panel. It also would have allowed anyone with a customization of the Network Topology panel to have some time to configure their Horizon instance to continue to use the Legacy panel while they updated their customization to work with the new panel. Perhaps we should treat panels more like an API element and take them through a deprecation cycle before removing them completely. Giving time for customizers to update their code is going to be especially important as we build angular replacements for python panels. While we have much better plugin support for angular there is still a learning curve for those developers. Why build refactors and new panels out of tree? First off, it appears to me trying to build new panels in tree has been fairly painful. I've seen big long lived patches pushed along without being merged. It's quite acceptable and expected to quickly merge half-complete patches into a brand new repository - but you can't behave that way working in tree in Horizon. Horizon needs to be kept production/operator ready. External repositories do not. Merging code quickly can ease collaboration and avoid this kind of long lived patch set. Secondly, keeping new panels/plugins in a separate repository decentralizes decisions about which panels are "ready" and which aren't. If one group feels a plugin is "ready" they can make it their default version of the panel, and perhaps put resources toward translating it. If we develop these panels in-tree we need to make a common decision about what "ready" means - and once it's in everyone who wants a translated Horizon will need to translate it. Finally, I believe developing new panels out of tree will help improve our plugin support in Horizon. It's this whole "eating your own dog food" idea. As soon as we start using our own Horizon plugin mechanism for our own development we are going to become aware of it's shortcomings (like quotas) and will be sufficiently motivated to fix them. Looking forward to further discussion and other ideas on this! Doug Fish __ 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
