Re: [openstack-dev] [Fuel][Plugins] Feedback
2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena *From:* Evgeniy L [mailto:e...@mirantis.com] *Sent:* Tuesday, July 28, 2015 11:54 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able
Re: [openstack-dev] [Fuel][Plugins] Feedback
Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena *From:* Evgeniy L [mailto:e...@mirantis.com] *Sent:* Tuesday, July 28, 2015 11:54 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them. Thank you in advance. [1] https://wiki.openstack.org/wiki/Fuel/Plugins
Re: [openstack-dev] [Fuel][Plugins] Feedback
Hi, Please also change the structure of repository. I like using pip install git+https:// -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Thu, Jul 30, 2015 at 4:45 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson sgreg...@mirantis.com wrote: So the only cores are Igor and Evgeniy? Can one of you add tags for the new release versions? From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com] Sent: Thursday, July 30, 2015 8:02 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback 2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena From: Evgeniy L [mailto:e...@mirantis.com] Sent: Tuesday, July 28, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch
Re: [openstack-dev] [Fuel][Plugins] Feedback
So the only cores are Igor and Evgeniy? Can one of you add tags for the new release versions? *From:* Sebastian Kalinowski [mailto:skalinow...@mirantis.com] *Sent:* Thursday, July 30, 2015 8:02 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback 2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena *From:* Evgeniy L [mailto:e...@mirantis.com] *Sent:* Tuesday, July 28, 2015 11:54 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard
Re: [openstack-dev] [Fuel][Plugins] Feedback
Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson sgreg...@mirantis.com wrote: So the only cores are Igor and Evgeniy? Can one of you add tags for the new release versions? From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com] Sent: Thursday, July 30, 2015 8:02 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback 2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena From: Evgeniy L [mailto:e...@mirantis.com] Sent: Tuesday, July 28, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git
Re: [openstack-dev] [Fuel][Plugins] Feedback
I would imagine we would want tags for any releases that have plugins associated, or we are planning to have plugins associated (so, 6.0, 6.1, 7.0). -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 9:46 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson sgreg...@mirantis.com wrote: So the only cores are Igor and Evgeniy? Can one of you add tags for the new release versions? From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com] Sent: Thursday, July 30, 2015 8:02 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback 2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena From: Evgeniy L [mailto:e...@mirantis.com] Sent: Tuesday, July 28, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677 oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_bui lder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful
Re: [openstack-dev] [Fuel][Plugins] Feedback
Hi guys, @Sergii, you didn't pay attention. Evgeny Li has provided a ticket to fix it [1]. @Sheena, fuel_plugins_builder isn't associated with Fuel releases. Here's a list of all versions: fuel-plugin-builder 2.0.4 fuel-plugin-builder 2.0.3 fuel-plugin-builder 2.0.2 fuel-plugin-builder 2.0.1 fuel-plugin-builder 2.0.0 fuel-plugin-builder 1.0.2 fuel-plugin-builder 1.0.1 I can push tags for them. Thanks, Igor [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Thu, Jul 30, 2015 at 5:54 PM, Sheena Gregson sgreg...@mirantis.com wrote: I would imagine we would want tags for any releases that have plugins associated, or we are planning to have plugins associated (so, 6.0, 6.1, 7.0). -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 9:46 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson sgreg...@mirantis.com wrote: So the only cores are Igor and Evgeniy? Can one of you add tags for the new release versions? From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com] Sent: Thursday, July 30, 2015 8:02 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback 2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena From: Evgeniy L [mailto:e...@mirantis.com] Sent: Tuesday, July 28, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677 oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_bui lder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include
Re: [openstack-dev] [Fuel][Plugins] Feedback
Ah, my mistake - yes, please push tags for all of the plugin builder versions. -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 10:47 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi guys, @Sergii, you didn't pay attention. Evgeny Li has provided a ticket to fix it [1]. @Sheena, fuel_plugins_builder isn't associated with Fuel releases. Here's a list of all versions: fuel-plugin-builder 2.0.4 fuel-plugin-builder 2.0.3 fuel-plugin-builder 2.0.2 fuel-plugin-builder 2.0.1 fuel-plugin-builder 2.0.0 fuel-plugin-builder 1.0.2 fuel-plugin-builder 1.0.1 I can push tags for them. Thanks, Igor [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Thu, Jul 30, 2015 at 5:54 PM, Sheena Gregson sgreg...@mirantis.com wrote: I would imagine we would want tags for any releases that have plugins associated, or we are planning to have plugins associated (so, 6.0, 6.1, 7.0). -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 9:46 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson sgreg...@mirantis.com wrote: So the only cores are Igor and Evgeniy? Can one of you add tags for the new release versions? From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com] Sent: Thursday, July 30, 2015 8:02 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback 2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena From: Evgeniy L [mailto:e...@mirantis.com] Sent: Tuesday, July 28, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=7867 7 oldid=78204 [2] https
Re: [openstack-dev] [Fuel][Plugins] Feedback
Hi there, Tags have been pushed. They could be checked on the main Git repo [1] or GitHub mirror [2]. Thanks, igor [1]: http://git.openstack.org/cgit/stackforge/fuel-plugins/ [2]: https://github.com/stackforge/fuel-plugins/releases On Thu, Jul 30, 2015 at 7:02 PM, Sheena Gregson sgreg...@mirantis.com wrote: Ah, my mistake - yes, please push tags for all of the plugin builder versions. -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 10:47 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi guys, @Sergii, you didn't pay attention. Evgeny Li has provided a ticket to fix it [1]. @Sheena, fuel_plugins_builder isn't associated with Fuel releases. Here's a list of all versions: fuel-plugin-builder 2.0.4 fuel-plugin-builder 2.0.3 fuel-plugin-builder 2.0.2 fuel-plugin-builder 2.0.1 fuel-plugin-builder 2.0.0 fuel-plugin-builder 1.0.2 fuel-plugin-builder 1.0.1 I can push tags for them. Thanks, Igor [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Thu, Jul 30, 2015 at 5:54 PM, Sheena Gregson sgreg...@mirantis.com wrote: I would imagine we would want tags for any releases that have plugins associated, or we are planning to have plugins associated (so, 6.0, 6.1, 7.0). -Original Message- From: Igor Kalnitsky [mailto:ikalnit...@mirantis.com] Sent: Thursday, July 30, 2015 9:46 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sheena, Sure, I can do it. Should I push tag only for last release or for all releases that are available on PyPI? Thanks, Igor On Thu, Jul 30, 2015 at 5:29 PM, Sheena Gregson sgreg...@mirantis.com wrote: So the only cores are Igor and Evgeniy? Can one of you add tags for the new release versions? From: Sebastian Kalinowski [mailto:skalinow...@mirantis.com] Sent: Thursday, July 30, 2015 8:02 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback 2015-07-30 14:50 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Sheena, Created ticket to change the structure of the directories [1]. And as far as I know any core can push tags into the repository, Sebastian, Igor and I. One correction: I'm not a core in fuel-plugins ;) [1] https://bugs.launchpad.net/fuel/+bug/1479785 On Tue, Jul 28, 2015 at 8:44 PM, Sheena Gregson sgreg...@mirantis.com wrote: Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena From: Evgeniy L [mailto:e...@mirantis.com] Sent: Tuesday, July 28, 2015 11:54 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't
Re: [openstack-dev] [Fuel][Plugins] Feedback
On 29 Jul 2015 at 14:41:48, Sheena Gregson (sgreg...@mirantis.com) wrote: Hey Sergii – I don’t know if I agree with the statement that it’s bad practice to mix core and plugin functionality. From a user standpoint, if I’m trying to deploy something like Contrail, I would like to see all of my Networking configuration options together (including the Contrail plugin) so that I can make an intelligent selection in the context of networking. Agreed When plugins are not related to a specific space, I personally as a user would expect to see a generic “Plugins” grouping in the Settings tab to reduce sub-group proliferation (I probably don’t need a sub-group for every plugin). I know that in conversations with Patrick (cc’d for input) he has mentioned wanting to have the plugins define the space they should be displayed in, as well, including spaces where core component settings are made. Absolutely. I think the plugins paradigme should be considered more of an implementation artefact than a logical grouping of functionality. I think that what we need is a mechanism by which plugins are free to make that logical grouping of settings in a way that is meaningful and consistent from an end-user standpoint. I agree that name validation could probably be improved – the names right now correspond either to the plugin name or to the name of the section that existed in the previous version. This initial iteration breaks down subgroups but does not change any of the section naming conventions or do anything else to make the Settings space more manageable. Sheena From: Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] Sent: Wednesday, July 29, 2015 5:24 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Fuel][Plugins] Feedback Sheena, I still have concerns regarding #3. I am sending attachment how it's implemented. Firstly, it's bad practice to mix core and plugin functionality. Also we do not validate names. When there are several plugins it's very hard to find all of them I am giving a sketch how it should be IMO -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 28, 2015 at 6:25 PM, Sheena Gregson sgreg...@mirantis.com wrote: Hey Sergii – This is excellent feedback, thank you for taking the time to provide your thoughts. #1 I agree that the documentation lag is challenging – I’m not sure how to best address this. We could potentially prioritize updates to the Plugin SDK for soon-to-be-released features ahead of the standard release notes and user guide updates to ensure that plugin developers have access to this information earlier? A number of the docs team members will be getting together in late August to discuss how to improve documentation, I will add this as a topic if we don’t feel there is good resolution on the mailing list. +Alexander/Evgeny to cc for their input #3 Settings tab is getting a facelift in 7.0 and there are now subgroups in the tab which should make it significantly easier for a user to find plugin settings. Each plugin will create a new sub-group in the Settings tab, like Access (and others) in the screenshot below. I don’t have any insight on the GitHub issues, so I will wait for others to weigh in on your concerns there. Sheena From: Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] Sent: Tuesday, July 28, 2015 9:51 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [Fuel][Plugins] Feedback Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code
Re: [openstack-dev] [Fuel][Plugins] Feedback
It’s also worth mentioning that there has been discussion about transitioning current “core” components of Fuel to plugins (like Ceph or the current vCenter implementation). In these cases, as with others, displaying the plugin’s functionality in its logical location from a user perspective will be incredibly important to ensuring the user has a positive and successful experience. *From:* Patrick Petit [mailto:ppe...@mirantis.com] *Sent:* Wednesday, July 29, 2015 7:56 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org; Sheena Gregson sgreg...@mirantis.com *Subject:* RE: [openstack-dev] [Fuel][Plugins] Feedback On 29 Jul 2015 at 14:41:48, Sheena Gregson (sgreg...@mirantis.com) wrote: Hey Sergii – I don’t know if I agree with the statement that it’s bad practice to mix core and plugin functionality. From a user standpoint, if I’m trying to deploy something like Contrail, I would like to see all of my Networking configuration options together (including the Contrail plugin) so that I can make an intelligent selection in the context of networking. Agreed When plugins are not related to a specific space, I personally as a user would expect to see a generic “Plugins” grouping in the Settings tab to reduce sub-group proliferation (I probably don’t need a sub-group for every plugin). I know that in conversations with Patrick (cc’d for input) he has mentioned wanting to have the plugins define the space they should be displayed in, as well, including spaces where core component settings are made. Absolutely. I think the plugins paradigme should be considered more of an implementation artefact than a logical grouping of functionality. I think that what we need is a mechanism by which plugins are free to make that logical grouping of settings in a way that is meaningful and consistent from an end-user standpoint. I agree that name validation could probably be improved – the names right now correspond either to the plugin name or to the name of the section that existed in the previous version. This initial iteration breaks down subgroups but does not change any of the section naming conventions or do anything else to make the Settings space more manageable. Sheena *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] *Sent:* Wednesday, July 29, 2015 5:24 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback Sheena, I still have concerns regarding #3. I am sending attachment how it's implemented. Firstly, it's bad practice to mix core and plugin functionality. Also we do not validate names. When there are several plugins it's very hard to find all of them I am giving a sketch how it should be IMO -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 28, 2015 at 6:25 PM, Sheena Gregson sgreg...@mirantis.com wrote: Hey Sergii – This is excellent feedback, thank you for taking the time to provide your thoughts. #1 I agree that the documentation lag is challenging – I’m not sure how to best address this. We could potentially prioritize updates to the Plugin SDK for soon-to-be-released features ahead of the standard release notes and user guide updates to ensure that plugin developers have access to this information earlier? A number of the docs team members will be getting together in late August to discuss how to improve documentation, I will add this as a topic if we don’t feel there is good resolution on the mailing list. *+Alexander/Evgeny to cc for their input* #3 Settings tab is getting a facelift in 7.0 and there are now subgroups in the tab which should make it significantly easier for a user to find plugin settings. Each plugin will create a new sub-group in the Settings tab, like Access (and others) in the screenshot below. I don’t have any insight on the GitHub issues, so I will wait for others to weigh in on your concerns there. Sheena *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] *Sent:* Tuesday, July 28, 2015 9:51 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel][Plugins] Feedback Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation
Re: [openstack-dev] [Fuel][Plugins] Feedback
Hey Sergii – I don’t know if I agree with the statement that it’s bad practice to mix core and plugin functionality. From a user standpoint, if I’m trying to deploy something like Contrail, I would like to see all of my Networking configuration options together (including the Contrail plugin) so that I can make an intelligent selection in the context of networking. When plugins are not related to a specific space, I personally as a user would expect to see a generic “Plugins” grouping in the Settings tab to reduce sub-group proliferation (I probably don’t need a sub-group for every plugin). I know that in conversations with Patrick (cc’d for input) he has mentioned wanting to have the plugins define the space they should be displayed in, as well, including spaces where core component settings are made. I agree that name validation could probably be improved – the names right now correspond either to the plugin name or to the name of the section that existed in the previous version. This initial iteration breaks down subgroups but does not change any of the section naming conventions or do anything else to make the Settings space more manageable. Sheena *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] *Sent:* Wednesday, July 29, 2015 5:24 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback Sheena, I still have concerns regarding #3. I am sending attachment how it's implemented. Firstly, it's bad practice to mix core and plugin functionality. Also we do not validate names. When there are several plugins it's very hard to find all of them I am giving a sketch how it should be IMO -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Tue, Jul 28, 2015 at 6:25 PM, Sheena Gregson sgreg...@mirantis.com wrote: Hey Sergii – This is excellent feedback, thank you for taking the time to provide your thoughts. #1 I agree that the documentation lag is challenging – I’m not sure how to best address this. We could potentially prioritize updates to the Plugin SDK for soon-to-be-released features ahead of the standard release notes and user guide updates to ensure that plugin developers have access to this information earlier? A number of the docs team members will be getting together in late August to discuss how to improve documentation, I will add this as a topic if we don’t feel there is good resolution on the mailing list. *+Alexander/Evgeny to cc for their input* #3 Settings tab is getting a facelift in 7.0 and there are now subgroups in the tab which should make it significantly easier for a user to find plugin settings. Each plugin will create a new sub-group in the Settings tab, like Access (and others) in the screenshot below. I don’t have any insight on the GitHub issues, so I will wait for others to weigh in on your concerns there. Sheena *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] *Sent:* Tuesday, July 28, 2015 9:51 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel][Plugins] Feedback Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them
[openstack-dev] [Fuel][Plugins] Feedback
Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them. Thank you in advance. [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation [2] https://github.com/stackforge/fuel-plugins -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ 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] [Fuel][Plugins] Feedback
Hi Additional comments inside. Thanks Patrick On 28 Jul 2015 at 18:33:34, Sheena Gregson (sgreg...@mirantis.com) wrote: Hey Sergii – This is excellent feedback, thank you for taking the time to provide your thoughts. #1 I agree that the documentation lag is challenging – I’m not sure how to best address this. We could potentially prioritize updates to the Plugin SDK for soon-to-be-released features ahead of the standard release notes and user guide updates to ensure that plugin developers have access to this information earlier? A number of the docs team members will be getting together in late August to discuss how to improve documentation, I will add this as a topic if we don’t feel there is good resolution on the mailing list. +Alexander/Evgeny to cc for their input +1. Yes that’s a huge impediment! Struggling myself with the same issue since we are supposed to release Plugins at about the same time as the new Plugins SDK released in Fuel. It’s also true that Plugins documentation lacks information about how to build the fpb builder. #3 Settings tab is getting a facelift in 7.0 and there are now subgroups in the tab which should make it significantly easier for a user to find plugin settings. Each plugin will create a new sub-group in the Settings tab, like Access (and others) in the screenshot below. That’s certainly a very significant improvement compared to the previous version. But, as already stated in a retrospective meeting, going forward we’ll need an even more flexible way to link Plugins with settings in that settings could be made common to multiple plugins. I am thinking of more logical grouping (by feature category) independent of the underlying Plugins breakdown. For example, we could have an LMA monitoring settings category common to all LMA related plugins. This should be less confusing for users and avoid settings duplicates. Hope this is making sense… I don’t have any insight on the GitHub issues, so I will wait for others to weigh in on your concerns there. Sheena From: Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] Sent: Tuesday, July 28, 2015 9:51 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [Fuel][Plugins] Feedback Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them. Thank you in advance. [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation [2] https://github.com/stackforge/fuel-plugins -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ 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] [Fuel][Plugins] Feedback
Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them. Thank you in advance. [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation [2] https://github.com/stackforge/fuel-plugins -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ 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] [Fuel][Plugins] Feedback
Hey Sergii – This is excellent feedback, thank you for taking the time to provide your thoughts. #1 I agree that the documentation lag is challenging – I’m not sure how to best address this. We could potentially prioritize updates to the Plugin SDK for soon-to-be-released features ahead of the standard release notes and user guide updates to ensure that plugin developers have access to this information earlier? A number of the docs team members will be getting together in late August to discuss how to improve documentation, I will add this as a topic if we don’t feel there is good resolution on the mailing list. *+Alexander/Evgeny to cc for their input* #3 Settings tab is getting a facelift in 7.0 and there are now subgroups in the tab which should make it significantly easier for a user to find plugin settings. Each plugin will create a new sub-group in the Settings tab, like Access (and others) in the screenshot below. I don’t have any insight on the GitHub issues, so I will wait for others to weigh in on your concerns there. Sheena *From:* Sergii Golovatiuk [mailto:sgolovat...@mirantis.com] *Sent:* Tuesday, July 28, 2015 9:51 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel][Plugins] Feedback Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them. Thank you in advance. [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation [2] https://github.com/stackforge/fuel-plugins -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ 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] [Fuel][Plugins] Feedback
Evgeniy – For the items which you have listed actions, who should be responsible for next steps? Sheena *From:* Evgeniy L [mailto:e...@mirantis.com] *Sent:* Tuesday, July 28, 2015 11:54 AM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel][Plugins] Feedback Hi Sergii, thank you for feedback, c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something We had a documentation, but removed it because the newer fpb was released, probably we should add this information permanently [1]. a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? These plugins are the data which are required for integration testing, we test that plugin build is not broken, which we run when patch gets published. I see nothing wrong with having the data for integration testing in the same repository with product which should be tested. Also in previous release we *removed* all the plugins which are not related to the builder itself, lbaas and glusterfs. This breaks a couple of things Having data for testing in the repository doesn't break anything. b. I cannot build fpm with simple That is a good point, we should move code from fuel_plugin_builder directory on top level, and move data for testing into examples directory. c. There is no tags as I can see only stable/6.0 Correct, tags should be added. d. There are no tests to improve code quality pep8 flask8, code coverage That is not true, there are more then one hundreds unit tests which we run for each patch with python 2.6 and python 2.7, also there are integration tests which check that for each patch we don't break validation and that we can build plugins for previous versions. Plus there are functional tests which are written by fuel-qa team, those tests check that we perform deployment with plugins and required functionality works correctly. Also there *is* pep8 check [2]. e. Repository doesn't follow community standards. I think this issue should be resolved with moving fuel_plugin_builder directory on level higher, if not, please provide more specific description what is wrong. 3. Setting tab ... Agree. [1] https://wiki.openstack.org/w/index.php?title=Fuel%2FPluginsdiff=78677oldid=78204 [2] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/tox.ini#L17-L21 On Tue, Jul 28, 2015 at 5:51 PM, Sergii Golovatiuk sgolovat...@mirantis.com wrote: Hi, I have started digging into plugins recently. There are many positive things though I would like to point to some problem areas 1. Documentation a. It doesn't include the features of 7.0. There are many outstanding features, though I needed to ping the developers to ask how these features work. It means that it's almost impossible to develop plugins for upcoming releases. The external developer needs to wait for documentation so it creates a lag between release and plugin release. b. in [1] the statement about 'For Ubuntu 12.04.2 LTS' should be extended to 14.04. Also we don't need to add PATCH version as 12.04.2 is equivalent to 12.04 c. There is no documentation how to install fpb from github master branch. It's very useful for developers who want to use latest version. We should add something 2. Github repository [2] is messed up a. We are doing the same mistake putting all things into one basket. There should be 2 repositories. One for examples and one for fpb. What's the goal of keeping fpb in directory and examples on top? This breaks a couple of things b. I cannot build fpm with simple pip install git+https:// Instead I am forced to do git clone https:// cd fuel-plugins pip install . c. There is no tags as I can see only stable/6.0 d. There are no tests to improve code quality pep8 flask8, code coverage e. Repository doesn't follow community standards. 3. Setting tab When plugin is installed, it's very hard to find in. In setting tab it's somewhere between A and Z How is user supposed to find it? There should be a separator between Core features and plugins. User must easily find, configure, enable/disable them. P.S. I am asking everyone to add own concerns so we'll be able to make a plan how to address them. Thank you in advance. [1] https://wiki.openstack.org/wiki/Fuel/Plugins#Installation [2] https://github.com/stackforge/fuel-plugins -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser __ 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
