Re: [openstack-dev] [Fuel] Changing APIs and API versioning
2015-10-23 11:36 GMT+02:00 Igor Kalnitsky: > Roman, Vitaly, > > You're both saying right things, and you guys bring a sore topic up again. > > The thing is that Nailgun's API isn't the best one.. but we're trying > to improve it step-by-step, from release to release. We have so many > things to reconsider and to fix that it'd require a huge effort to > make backward compatible changes and support it. So we decided ignore > backward compatibility for clients for awhile and consider our API as > unstable. > > I agree with Roman that such changes must not be made secretly, and we > should at least announce about them. Moreover, every core must think > about consequences before approving them. > > So I propose to do the following things when backward incompatible > change to API is required: > > * Announce this change in openstack-dev ML. > * Wait 1 week before approving it, so anyone can prepare. > * Change author has to work with QA in order make sure they are > prepared for this change. > > Any thoughts? > +1. Although there is one thing that you didn't mention (but probably everyone know about it) is to solve the issue with fuelclient not beign tested against changes in nailgun. We need not only run it for every change in nailgun (or for only those that touch files under "api" dir) but also cover more endpoints with fuelclient tests against real API, not mocks, to discover such issues earlier. > > Thanks, > Igor > > On Wed, Oct 21, 2015 at 5:24 PM, Vitaly Kramskikh > wrote: > > JFYI: (re-)start of this discussion was instigated by merge of this > change > > (and here is revert). > > > > And this is actually not the first time when we make backward > incompatible > > changes in our API. AFAIR, the last time it was also about the network > > configuration handler. We decided not to consider our API frozen, make > the > > changes and break backward compatibility. So now is the time to > reconsider > > this. > > > > API backward compatibility is a must for good software, but we also need > to > > understand that introducing API versioning is not that easy and will > > increase efforts needed to make new changes in nailgun. > > > > I'd go this way: > > > > Estimate the priority of introducing API versioning - maybe we have other > > things we should invest our resources to > > Estimate all the disadvantages this decision might have > > Fix all the issues in the current API (like this one) > > Implement API versioning support (yes, we don't have this mechanism yet, > so > > we can't just "bump API version" like Sergii suggested in another thread) > > Consider the current API as frozen v1, so backward incompatible changes > (or > > maybe all the changes?) should go to v2 > > > > > > 2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko : > >> > >> Hi folks, > >> > >> I’d like to touch the aspect of Fuel development process that seems to > be > >> as wrong as possible. That aspect is how we change the API. > >> > >> The issue is that in Fuel anyone can change API at any point of time > >> without even warning the rest of the same component’s team. Relying on > this > >> kind of API is basically impossible. We constantly have problems when > even > >> components of Fuel stop working due to unexpected changes in the API. > >> Thinking about another software that must be integrated with Fuel is > hardly > >> possible with the current approach. > >> > >> As for a grown-up project there is a strong need for Fuel in general and > >> for Nailgun in particular to work on a policy for making changes to > their > >> APIs. Living in OpenStack ecosystem we must at least take a look how > it’s > >> done in its components and try to do something similar. After working > with > >> Nova, Keystone, Ironic and other components I would propose to start > with > >> the following: let’s not make any changes to the API. Instead, let’s > create > >> a new version of Nailgun’s API that will appear in Fuel 8.0 and make > all the > >> changes there. That is the thing that will instantaneously make lives of > >> other components much easier, if we make it now. > >> > >> After doing the essential part let’s think about how we are going to > live > >> with that in the future. There are several APIs in Fuel, the rest of the > >> email is only touching Nailgun’s REST API. I can see the things somehow > like > >> the following: > >> > >> - Introduce API documentation by embedding Swagger and Swagger UI. > >>The current approach when we leave API docs for documentation team is > >> not effective. Swagger generates the documentation and resolves this > issue. > >> - After releasing a version of Fuel, it’s API is called stable and > frozen > >> for any changes, unless they allign API to the documentation or > >> documentation to the API. > >> - All changes to a stable APIs must be backported to the stable version > >> of Fuel that introduced the corresponding API. > >> -
Re: [openstack-dev] [Fuel][QA][Plugins] Move functional tests from fuel-qa to the plugins
2015-10-21 8:11 GMT+02:00 Mike Scherbakov: > > Simon is asking a valid request: if you add his folder in the file, he > will be always added to the review request by script, once it's > implemented. Only in the case when contribution is made to his particular > area of responsibility. > Mike, when this sript will be implemented? It was promised long time ago [1]. It is a important part of whole review process change and I doubt that people would like to manually go through MAINTAINERS with every review they post. Also there was a request to add a job for validating MAINTAINERS file, how is the progress with that? [1] https://bugs.launchpad.net/fuel/+bug/1497655 __ 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] Proposal to freeze old Fuel CLI
Roman, this was already discussed in [1]. The conclusion was that we will implement new features in both places so user will not have to use "old" fuelclient to do some things and the "new" to others. There were no progress with moving old commands to new CLI and I didn't seen plans to do so. IMHO without a detailed plan on migrating old commands to new client and without a person (or people) that will drive this task we *cannot* freeze old fuelclient as new one is still not fully usable. Best, Sebastian [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/070279.html 2015-10-14 10:56 GMT+02:00 Roman Prykhodchenko: > Fuelers, > > as you know a big effort has been put into making Fuel Client’s CLI better > and as a result we got a new fuel2 utility with a new set of commands and > options. Some folks still put great effort to move everything that’s left > in the old CLI to the new CLI. > > Every new thing added to the old CLI moves the point where we can finally > remove it to the future. My proposal is to do a hard code freeze for the > old CLI and only add new stuff to the new one. > > > - romcheg > > > __ > 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] py.test vs testrepository
I've already wrote in the review that caused this thread that I do not want to blindly follow rules for using one or another. We should always consider technical requirements. And I do not see a reason to leave py.test (and nobody show me such reason) and replace it with something else. Additionally other folks showed that this is not a blocker for moving under big tent. Best, Sebastian __ 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] Nominate Denis Dmitriev for fuel-qa(devops) core
+1 2015-09-14 22:37 GMT+02:00 Ivan Kliuk: > +1 > > On Mon, Sep 14, 2015 at 10:19 PM, Anastasia Urlapova < > aurlap...@mirantis.com> wrote: > >> Folks, >> I would like to nominate Denis Dmitriev[1] for fuel-qa/fuel-devops core. >> >> Dennis spent three months in Fuel BugFix team, his velocity was between >> 150-200% per week. Thanks to his efforts we have won these old issues with >> time sync and ceph's clock skew. Dennis's ideas constantly help us to >> improve our functional system suite. >> >> Fuelers, please vote for Denis! >> >> Nastya. >> >> [1] >> http://stackalytics.com/?user_id=ddmitriev=all_type=all=fuel-qa >> >> -- >> You received this message because you are subscribed to the Google Groups >> "fuel-core-team" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to fuel-core-team+unsubscr...@mirantis.com. >> For more options, visit https://groups.google.com/a/mirantis.com/d/optout >> . >> > > > > -- > Best regards, > Ivan Kliuk > > -- > You received this message because you are subscribed to the Google Groups > "fuel-core-team" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to fuel-core-team+unsubscr...@mirantis.com. > For more options, visit https://groups.google.com/a/mirantis.com/d/optout. > __ 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][Fuel-Library] Nominating Alex Schultz to Fuel-Library Core
+1 2015-09-03 21:34 GMT+02:00 Bartlomiej Piotrowski: > I have no idea if I'm eligible to vote, but I'll do it anyway: > > +1 > > Bartłomiej > > On Thu, Sep 3, 2015 at 9:16 PM, Sergey Vasilenko > wrote: > >> +1 >> >> /sv >> >> __ >> 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] [Fuel] Great updates to tests and CI jobs
If there will be 4-5 patches, then I do not have anything against it. I'm just skeptic that we will have so many ;) 2015-08-20 14:05 GMT+02:00 Roman Prykhodchenko m...@romcheg.me: I think, that if there are 4-5 patches that pass python jobs w/o any problems, we can switch the jobs to voting. They are really simple with a very little room for a failure so should we wait longer? 19 серп. 2015 о 19:50 Sebastian Kalinowski skalinow...@mirantis.com написав(ла): Indeed, great news! I would only suggest to wait a little bit more that a few days with switching to the voting mode since it looks like there will be not so many patches proposed to python-fuelclient as we are heading towards Hard Code Freeze. I hope that the next step will be to enable Python 3 pipepline for our client so we could finally test all the code that uses six library for Python 2 3 compatibility. Best, Sebastian 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in order to accomplish this result. First of all tests were reorganized: now functional and unit tests have their own separate folders inside the fuelclient/tests directory. That allowed us to distinguish them from both the CI and a developer’s point of view, so there will be no mess we used to have. The other change we’ve made is deleting run_tests.sh*. It is possible to run and manage all the tests via tox which is a de-facto standard in OpenStack ecosystem. That also means anyone who is familiar with any of OpenStack projects will be able to orchestrate tests without a need to learn anything. Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup environments. py26 and py27 only run unit tests and cover also involves calculating coverage. functional fires up Nailgun and launches functional tests. cleanup stops Nailgun, deletes its DB and any files left after functional tests and what you will definitely like — cleans up all *.pyc files. By default tox executes environments in the following order: py26-py27-pep8-functional-cleanup. Minimal tox was updated to 2.1 which guarantees no external environment variable is passed to tests. The jobs on OpenStack CI are set to be non-voting for a few days to give it a better try. On the next week we will switch them to voting. At the same time we will remove unit tests from FuelCI to not waste extra time. * Technically it is kept in place to keep compatibility with FuelCI but it only invokes tox from inside. It will be removed later, when it’s time to switch off unit tests on FuelCI. - romcheg __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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://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] [Fuel] Great updates to tests and CI jobs
Indeed, great news! I would only suggest to wait a little bit more that a few days with switching to the voting mode since it looks like there will be not so many patches proposed to python-fuelclient as we are heading towards Hard Code Freeze. I hope that the next step will be to enable Python 3 pipepline for our client so we could finally test all the code that uses six library for Python 2 3 compatibility. Best, Sebastian 2015-08-19 19:00 GMT+02:00 Boris Pavlovic bpavlo...@mirantis.com: Roman, well done! ;) Best regards, Boris Pavlovic On Wed, Aug 19, 2015 at 8:38 AM, Roman Prykhodchenko m...@romcheg.me wrote: Hi folks! Today I’m proud to announce that since this moment python-fuelclient has it’s own python-jobs in OpenStack CI. Thanks to all of you who helped me making Fuel Client compatible with the upstream CI. Besides sharing great news I think it’s necessary to share changes we had to do, in order to accomplish this result. First of all tests were reorganized: now functional and unit tests have their own separate folders inside the fuelclient/tests directory. That allowed us to distinguish them from both the CI and a developer’s point of view, so there will be no mess we used to have. The other change we’ve made is deleting run_tests.sh*. It is possible to run and manage all the tests via tox which is a de-facto standard in OpenStack ecosystem. That also means anyone who is familiar with any of OpenStack projects will be able to orchestrate tests without a need to learn anything. Tox is preconfigured to run py26, py27, pep8, cover, functional, and cleanup environments. py26 and py27 only run unit tests and cover also involves calculating coverage. functional fires up Nailgun and launches functional tests. cleanup stops Nailgun, deletes its DB and any files left after functional tests and what you will definitely like — cleans up all *.pyc files. By default tox executes environments in the following order: py26-py27-pep8-functional-cleanup. Minimal tox was updated to 2.1 which guarantees no external environment variable is passed to tests. The jobs on OpenStack CI are set to be non-voting for a few days to give it a better try. On the next week we will switch them to voting. At the same time we will remove unit tests from FuelCI to not waste extra time. * Technically it is kept in place to keep compatibility with FuelCI but it only invokes tox from inside. It will be removed later, when it’s time to switch off unit tests on FuelCI. - romcheg __ 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] [Fuel] SSL for master node API
+1 for option 2) But I have a question: how do we fit with this into the scope of Feature Freeze and Soft Code Freeze this week? Any ETAs? 2015-08-04 15:06 GMT+02:00 Vitaly Kramskikh vkramsk...@mirantis.com: FYI: There is Strict-Transport-Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security header which can also be useful here (unless we want to make SSL for master node optional) 2015-08-04 15:07 GMT+03:00 Vladimir Sharshov vshars...@mirantis.com: Hi, +1 to 2nd solution too. On Tue, Aug 4, 2015 at 1:45 PM, Evgeniy L e...@mirantis.com wrote: Hi, +1 to 2nd solution, in this case old environments will work without additional actions. Agents for new environments, CLI and UI will use SSL. But probably for UI we will have to perform redirect on JS level. Thanks, On Tue, Aug 4, 2015 at 1:32 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: Hi guys, in overall movement of Fuel to use secure sockets we think about wrapping master node UI and API calls to SSL. But there are next caveat: a) fuel-nailgun-agent cannot work via SSL now and need to be rewritten a little. But if it will be rewritten in 7.0 and HTTPS on master node will be forced by default, it will break upgrade from previous releases to 7.0 due fact that after master node upgrade from 6.1 to 7.0 we will have HTTPS by default and fuel-nailgun-agent on all environments won't upgraded, so it won't be able to connect to master node after upgrade. It breaks seamless upgrade procedure. What options I see there: 1. We can forcedly enable SSL for master node and rewrite clients in 7.0 to be able to work over it. In release notes for 7.0 we will write forewarning that clients which want to upgrade master node from previous releases to 7.0 must also install new fuel-nailgun-agent to all nodes in all deployed environments. 2. We can have both SSL and non-SSL versions enabled by default and rewrite fuel-nailgun-client in 7.0 such way that it will check SSL availability and be able to work in plain HTTP for legacy mode. So, for all new environments SSL will be used by default and for old ones plain HTTP will continue to work too. Master node upgrade will not be broken in this case. 3. We can do some mixed way by gradually rewrite fuel-nailgun-client, save both HTTP and HTTPS for master node in 7.0 and drop plain HTTP in next releases. It is just postponed version of first clause, so it doesn't seems valid for me, actually. I would be really glad to hear what you think about this. Thank you in advance. __ 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 -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ 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
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][python-fuelclient] Implementing new commands
It looks like most people agree on option C (implement features in fuel and fuel2) and in the meantime we should slowly progress with moving fuel to fuel2. 2015-07-27 16:12 GMT+02:00 Sergii Golovatiuk sgolovat...@mirantis.com: Hi, Every functionality should be applied to both clients. Core developers should set -1 if it's not applied to second version of plugin. Though I believe we should completely get rid of first version of CLI in Fuel 8.0 -- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Fri, Jul 24, 2015 at 11:41 AM, Oleg Gelbukh ogelb...@mirantis.com wrote: FWIW, I'm for option B, combined with clear timeline for porting features of fuel-variant to fuel2. For example, we are developing client-side functions for fuel-octane (cluster upgrade) extensions only for fuel2, and don't plan to implement it for 'fuel'. The main reason why we can't just drop 'fuel', or rather switch it to fuel2 syntax, IMO, is the possibility that someone somewhere uses its current syntax for automation. However, if the function is completely new, the automation of this function should be implemented with the new version of syntax. -- Best regards, Oleg Gelbukh On Fri, Jul 24, 2015 at 12:09 PM, Fedor Zhadaev fzhad...@mirantis.com wrote: Hi all, I think that in current situation the best solution will be to add new features for the both versions of client. It may cause a little slowing down of developing each feature, but we won't have to return to them in future. 2015-07-24 11:58 GMT+03:00 Igor Kalnitsky ikalnit...@mirantis.com: Hello, My 2 cents on it. Following plan C requires a huge effort from developer, and it may be unacceptable when FF is close and there're a lot of work to do. So it looks like the plan B is most convenient for us and eventually we will have all features in fuel2. Alternatively we can go with C.. but only if implementing support in either fuel or fuel2 may be postponed to SCF. Thanks, Igor On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L e...@mirantis.com wrote: Hi Sebastian, thanks for clarification, in this case I think we should follow plan C, new features should not slow us down in migration from old to new version of the client. On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com: Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients. Stas, of course moving it all to new fuel2 would be the best way to do it, but this refactoring took place in previous release. There is no one that ported a single command (except new ones) since then and there is no plan for doing so since other activities have higher priority. And features are still coming so it would be nice to have a policy for the time all commands will move to new fuel2. On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote: Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in fuel2? I'm just wondering how much time will it take to implement all required commands in fuel2. So to compare: this is a help message for old fuel [1] and new fuel2 [2]. There are only node, env and task actions covered and even they are not covered in 100%. [1] http://paste.openstack.org/show/404439/ [2] http://paste.openstack.org/show/404440/ Thanks, On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new
Re: [openstack-dev] [fuel] FFE for bug/1475759 ceph generators
Andrew, thanks for this request and for the explanations. +1 for this exception. The new generators are not conflicting with existing ones, code is ready and tested so let's merge it. 2015-07-25 1:24 GMT+02:00 Andrew Woodward xar...@gmail.com: I'm writing to ask for a FFE for landing the ceph generators. It finally received core-reviewers attention late on Wednesday and Thursday and is ready to merge now. I'm only asking for FFE because reviewers are calling this a feature. Possible impact, none. This is not used by anything yet and should be merged. [1] https://bugs.launchpad.net/fuel/+bug/1475759 [2] https://review.openstack.org/#/c/203270/ -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community __ 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] FF Exception request for Templates for Networking feature
Yes, exactly like that. +1 2015-07-27 10:53 GMT+02:00 Evgeniy L e...@mirantis.com: So, to summarise, +1 from me, we accept the changes which are required for the feature as feature freeze exceptions: 1. Fuel client changes [1] 2. Validation [2] 3. Change tokens in template language Sebastian, Igor, correct? [1] https://review.openstack.org/#/c/204321/ [2] https://bugs.launchpad.net/fuel/+bug/1476779 On Sat, Jul 25, 2015 at 1:25 AM, Andrew Woodward xar...@gmail.com wrote: Igor, https://bugs.launchpad.net/fuel/+bug/1476779 must be included in the FFE if you think it's a feature. Networking is the most complicated and frustrating thing the user can work with. If we cant provide usable feedback from bad data in the template then the feature is useless. I could argue that its a critical UX defect. On Fri, Jul 24, 2015 at 7:16 AM Evgeniy L e...@mirantis.com wrote: Aleksey, Yes, my point is those parts should be also included in the scope of FFE. Regarding to template format, it's easy to fix and after release you will not be able to change it, or you can change it, but you will have to support both format, not to brake backward compatibility. So I would prefer to see it fixed in 7.0. Thanks, On Fri, Jul 24, 2015 at 3:14 PM, Aleksey Kasatkin akasat...@mirantis.com wrote: I agree, guys, we need at least some basic validation for template when it is being loaded. Ivan Kliuk started to work on this task. And we agreed to test other types of delimiters (it is regarding ERB style template) but we have some more important issues. Evgeniy, is your meaning to include those to FFE ? Aleksey Kasatkin On Fri, Jul 24, 2015 at 2:12 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: I agree here with Evgeniy. Even if it's not a trivial change, we cannot leave a new API in such shape. 2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Igor, I don't agree with you, some basic validation is essential part of any handler and our API, currently it's easy to get meaningless 500 error (which is unhandled exception) from the backend or get the error that there is something wrong with the template only after you press deploy button. It's a bad UX and contradicts to our attempts to develop good api. Thanks, On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey
Re: [openstack-dev] [fuel] FF Exception request for Templates for Networking feature
I agree here with Evgeniy. Even if it's not a trivial change, we cannot leave a new API in such shape. 2015-07-24 11:41 GMT+02:00 Evgeniy L e...@mirantis.com: Hi Igor, I don't agree with you, some basic validation is essential part of any handler and our API, currently it's easy to get meaningless 500 error (which is unhandled exception) from the backend or get the error that there is something wrong with the template only after you press deploy button. It's a bad UX and contradicts to our attempts to develop good api. Thanks, On Fri, Jul 24, 2015 at 12:02 PM, Igor Kalnitsky ikalnit...@mirantis.com wrote: Greetings, The issue [1] looks like a feature to me. I'd move it to next release. Let's focus on what's important right now - stability. Thanks, Igor [1]: https://bugs.launchpad.net/fuel/+bug/1476779 On Fri, Jul 24, 2015 at 11:53 AM, Evgeniy L e...@mirantis.com wrote: Hi, Since the feature is essential, and changes are small, we can accept it as a, feature freeze exceptions. But as far as I know there is a very important ticket [1] which was created in order to get patches merged faster, also I still have concerns regarding to ERB style template % if3 % which is in fact Jinja. So it's not only about fixes in the client. [1] https://bugs.launchpad.net/fuel/+bug/1476779 On Thu, Jul 23, 2015 at 9:18 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Looks like the only CLI part left: https://review.openstack.org/#/c/204321/, and you guys did a great job finishing the other two. Looks like we'd need to give FF exception, as this is essential feature. It's glad that we merged all other thousands lines of code. This is the most complex feature, and seems like the only small thing is left. I'd like to hear feedback from Nailgun cores fuel client SMEs. For me, it seems it is lower risk, and patch is relatively small. How long would it take to complete it? If it takes a couple of days, then it is fine. If it is going to take week or two, then we will have to have it as a risk for HCF deadline. Spending resources on features now, not on bugs, means less quality or slip of the release. On Wed, Jul 22, 2015 at 2:36 PM Aleksey Kasatkin akasat...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Templates for Networking feature [1]. Exception is required for two CRs to python-fuelclient: [2],[3] and one CR to fuel-web (Nailgun): [4]. These CRs are for adding ability to create/remove networks via API [4] and for supporting new API functionality via CLI. These patchsets are for adding new templates-related functionality and they do not change existing functionality. Patchsets [3],[4] are in deep review and they will hopefully be merged on Thursday. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://blueprints.launchpad.net/fuel/+spec/templates-for-networking [2] https://review.openstack.org/#/c/204321/ [3] https://review.openstack.org/#/c/203602/ [4] https://review.openstack.org/#/c/201217/ -- Best regards, Aleksey Kasatkin __ 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 -- Mike Scherbakov #mihgen __ 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] [fuel] [FFE] FF Exception request for Env Upgrade feature
+1 for this exception - as Evgeniy said it is developed not in the core but in extension and risk is low. 2015-07-24 10:17 GMT+02:00 Evgeniy L e...@mirantis.com: Hi, If we have a rule that feature freeze exceptions should have essential priority, I'm not sure if it matters how risky it's, the risk is low, but it's not zero. Thanks, On Thu, Jul 23, 2015 at 9:09 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Oleg, considering that your feature is essential for the release, sounds like there is no way we can't give an exception. I'm glad that it's perceived by low risk by core reviewer from Nailgun team (Evgeny). If there are no concerns from other, then we are giving FF exception. However, I'd like to understand how much it will take to finish this work and additional resources required. We need to switch to bugfix work, and the more we continue working on features / enhancements, the less confidence I have that we can meet HCF deadline. Thanks, On Thu, Jul 23, 2015 at 11:00 AM Evgeniy L e...@mirantis.com wrote: Hi, The patch into Nailgun requires additional work to do, but as far as I can see it doesn't affect any other parts of the system, also it's implemented as an extension, which means if the feature will introduce bugs which we won't be able to fix in a required time, it can be easily disabled without removing from master with just removing one line from a file [1] (removing it from extensions list). So I think it's ok to accept environment upgrade feature as an exception for feature freeze. Thanks, [1] https://review.openstack.org/#/c/202969/7/nailgun/nailgun/extensions/base.py On Wed, Jul 22, 2015 at 10:18 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for Environment Upgrade extensions added to the Nailgun API [1]. The Nailgun side of the feature is implemented in the following CRs: https://review.openstack.org/#/q/status:open+topic:bp/nailgun-api-env-upgrade-extensions,n,z These changes are implemented as an extension [2] to the Nailgun. It barely touches the core code and doesn't change the existing functionality. Please, respond if you have any questions or concerns related to this request. Thanks in advance. [1] https://review.openstack.org/#/c/192551/ [2] https://review.openstack.org/#/q/topic:bp/volume-manager-refactoring,n,z -- Best regards, Oleg Gelbukh __ 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 -- Mike Scherbakov #mihgen __ 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] [Fuel] Get rid of fuelmenu
I'm against getting rid of fuelmenu. As Alex wrote - we need to remember who are the people that we are targeting. We are adding multiple dialog windows with confirmations, warnings and special way to do dangerous actions (like environment deletion or reset), but in the same time we want to force users to change config file. If the UX of fuelmenu is bad - then we can change it. If the code is hard to maintain and extend - well, I hope that no one need explanations what to do with and how to avoid such issues in future. So I would rather spend time on improving fuelmenu than write a new thing that will not be better. Sebastian 2015-07-23 19:04 GMT+02:00 Alex Schultz aschu...@mirantis.com: For this to be consumable by end-users, a config file and editor (vim seriously?) is terrible UX. We need to remember who we are targeting to consume this functionality as it may not be an expert or even someone absolutely familiar with the linux tool set. While the existing thing may be awkward, it is going to be less error prone to someone accidentally deleteing half of a config file and not being able to recover. If you want to ditch ncurses, then sure why don't we switch to an answer file and question/answer wizard for configuration? This would allow both validation and the ability to override it with a config file. -Alex On Thu, Jul 23, 2015 at 11:49 AM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: The topic is NOT 'get rid of validation' but rather 'get rid of semi-graphical ncurses based interface'. It is not so hard to adopt every piece of validation we currently have in fuelmenu and implement even more including syntax validation using, for example, PLY and logic validation. My idea is to switch from ncurses to plain text file (thoroughly commented), because it so easy to add new parameters or remove those we don't need any more. Vladimir Kozhukalov On Thu, Jul 23, 2015 at 6:17 PM, Nick Chase nch...@mirantis.com wrote: On Thu, Jul 23, 2015 at 4:05 PM, Matthew Mosesohn mmoses...@mirantis.commmoses...@mirantis.com wrote: Here's a relic of what users used to have to configure by hand: https://github.com/stackforge/fuel-library/blob/b015ed975b58dddff3b8da0ce34d9a638c22d032/deployment/puppet/openstack/examples/site_simple.pp Am I alone in thinking it's not the best use of our development resources to throw it away and replace it with a text file that is edited by hand? Please, please, please, I'm having PTSD just remembering that @#$%@#%$ file. I think I was able to successfully deploy without major engineering help about 2% of the time. We absolutely, positively, MUST maintain the validation. Just because the people installing OpenStack are generally not afraid to edit config files doesn't mean that we should be making them do it. Nick __ 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] [Fuel] Nominating Vladimir Kozhukalov to core reviewers of fuel-main
+1 2015-07-23 19:23 GMT+02:00 Dmitry Borodaenko dborodae...@mirantis.com: +1 On Thu, Jul 23, 2015, 09:32 Stanislaw Bogatkin sbogat...@mirantis.com wrote: +1 On Thu, Jul 23, 2015 at 10:43 AM, Roman Vyalov rvya...@mirantis.com wrote: +1 On Thu, Jul 23, 2015 at 6:14 PM, Dmitry Pyzhov dpyz...@mirantis.com wrote: At the moment we have several core reviewers for the fuel-main project. Roman Vyalov is responsible for merging of infrastructure-related variables and for the lists of packages. I am responsible for merges in make system. And I have not so much time for digging into makefiles. Vladimir Kozhukalov is responsible for the makesystem for a long time. And now he works on reducing complexity of the system. I do not merge any single patch without his approval. It's time to give formal transfer of responsibility for the fuel-main to him. I nominate Vladimir to fuel-main core. Please reply with +1/-1. __ 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] [fuel] [FFE] FF Exception request for Custom node attributes feature
+1 for this FFE as it's important to have this functionality covered in CLI 2015-07-23 19:46 GMT+02:00 Igor Kalnitsky ikalnit...@mirantis.com: Hi Julia, I'm ok with FF exception for CLI part. I don't think it can somehow decrease product quality, so as a core I'll help to land it. Thanks, Igor On Thu, Jul 23, 2015 at 7:50 PM, Julia Aranovich jkirnos...@mirantis.com wrote: Team, I would like to request an exception from the Feature Freeze for CLI changes of working with custom node labels added to fuelclient (fuel2) [1]. UI and Nailgun parts of the story are already merged [2]. There CLI request is being actively reviewed, the base flow is accepted. There are minimal risks here since the changes added to fuel2 version. Please, respond if you have any questions or concerns related to this request. Thanks in advance, Julia [1] https://review.openstack.org/#/c/204524/ [2] https://review.openstack.org/#/c/201472/ __ 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] [Fuel][python-fuelclient] Implementing new commands
2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin sbogat...@mirantis.com: Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients. Stas, of course moving it all to new fuel2 would be the best way to do it, but this refactoring took place in previous release. There is no one that ported a single command (except new ones) since then and there is no plan for doing so since other activities have higher priority. And features are still coming so it would be nice to have a policy for the time all commands will move to new fuel2. On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L e...@mirantis.com wrote: Hi, The best option is to add new functionality to fuel2 only, but I don't think that we can do that if there is not enough functionality in fuel2, we should not ask user to switch between fuel and fuel2 to get some specific functionality. Do we have some list of commands which is not covered in fuel2? I'm just wondering how much time will it take to implement all required commands in fuel2. So to compare: this is a help message for old fuel [1] and new fuel2 [2]. There are only node, env and task actions covered and even they are not covered in 100%. [1] http://paste.openstack.org/show/404439/ [2] http://paste.openstack.org/show/404440/ Thanks, On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski skalinow...@mirantis.com wrote: Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new `fuel2` - Issues that forced us to reimplement whole `fuel` as `fuel2` B) Add new features only to new `fuel2` Pros: - Implement feature in one place - No need to cope with issues in old `fuel` (like worse UX, etc.) Cons: - Not all features are covered by `fuel2` so user will need to switch between `fuel` and `fuel2` C) Add new features to both CLIs Pros: - User can choose which tool to use - No need to port feature later... Cons: - ...but it still doubles the work - We keep alive a tool that should be replaced (old `fuel`) Best, Sebastian [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client __ 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] [Fuel][python-fuelclient] Implementing new commands
Hi folks, For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1]. Right now there is a situation where some new features are added just to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch completely to new `fuel2` as it doesn't cover all old commands. As far as I remember there was no agreement how we should proceed with adding new things to python-fuelclient, so to keep all development for new commands I would like us to choose what will be our approach. There are 3 ways to do it (with some pros and cons): A) Add new features only to old `fuel`. Pros: - Implement feature in one place - Almost all features are covered there Cons: - Someone will need to port this features to new `fuel2` - Issues that forced us to reimplement whole `fuel` as `fuel2` B) Add new features only to new `fuel2` Pros: - Implement feature in one place - No need to cope with issues in old `fuel` (like worse UX, etc.) Cons: - Not all features are covered by `fuel2` so user will need to switch between `fuel` and `fuel2` C) Add new features to both CLIs Pros: - User can choose which tool to use - No need to port feature later... Cons: - ...but it still doubles the work - We keep alive a tool that should be replaced (old `fuel`) Best, Sebastian [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client __ 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][Fuel-Library] Nominate Aleksandr Didenko for fuel-library core
+1 2015-06-30 10:38 GMT+02:00 Evgeniy L e...@mirantis.com: +1 On Tue, Jun 30, 2015 at 9:34 AM, Igor Kalnitsky ikalnit...@mirantis.com wrote: +1. Alex's doing a great job! On Mon, Jun 29, 2015 at 5:40 PM, Sergey Vasilenko svasile...@mirantis.com wrote: +1 __ 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] [Fuel] Nominate Julia Aranovich for fuel-web core
+1 2015-04-30 11:33 GMT+02:00 Przemyslaw Kaminski pkamin...@mirantis.com: +1, indeed Julia's reviews are very thorough. P. On 04/30/2015 11:28 AM, Vitaly Kramskikh wrote: Hi, I'd like to nominate Julia Aranovich http://stackalytics.com/report/users/jkirnosova for fuel-web https://github.com/stackforge/fuel-web core team. Julia's reviews are always thorough and have decent quality. She is one of the top contributors and reviewers in fuel-web repo (mostly for JS/UI stuff). Please vote by replying with +1/-1. -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ 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] [Fuel][NetApp plugin] Samuel Bartel added as a maintainer
Hello, Today we added Samuel Bartel as a Core Review for NetApp plugin [1]. He will be now main person leading the plugin development. Congrats! Best, Sebastian [1] https://github.com/stackforge/fuel-plugin-cinder-netapp __ 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] [Fuel][Plugins] Moving old plugins to stackforge-attic
Hello, I propose to move two old, unmaintained plugins to stackforge-attic as there is no interest or plans in continuing development of them: * https://github.com/stackforge/fuel-plugin-group-based-policy - development is now done in another repository as different plugin * https://github.com/stackforge/fuel-plugin-external-nfs - was created just to check how to article Let's use lazy consensus and see if no one have any objections for next week (April 24th). Best, Sebastian __ 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] development tools
As I wrote in the review already: I like the idea of merging those two tools and making a separate repository. After that we could make they more visible in our documentation and wiki so they could benefit from being used by broader audience. Same for vagrant configuration - if it's useful (and it is since newcomers are using them) we could at least move under Mirantis organization on Github. Best, Seabastian 2015-03-19 13:49 GMT+01:00 Przemyslaw Kaminski pkamin...@mirantis.com: Hello, Some time ago I wrote some small tools that make Fuel development easier and it was suggested to add info about them to the documentation -- here's the review link [1]. Evgenyi Li correctly pointed out that we already have something like fuel_development already in fuel-web. I think though that we shouldn't mix such stuff directly into fuel-web, I mean we recently migrated CLI to a separate repo to make fuel-web thinner. So a suggestion -- maybe make these tools more official and create stackforge repos for them? I think dev ecosystem could benefit by having some standard way of dealing with the ISO (for example we get questions from people how to apply new openstack.yaml config to the DB). At the same time we could get rid of fuel_development and merge that into the new repos (it has the useful 'revert' functionality that I didn't think of :)) P. [1] https://review.openstack.org/#/c/140355/9/docs/develop/env.rst __ 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] Let's stick to OpenStack global requirements
I assume that you considered a situation when we have a common repository with RPMs for Fuel master and for nodes. There are some plans (unfortunately I do not know details, so maybe someone from OSCI could tell more) to split those repositories. How this workflow will work with those separated repos? Will we still need it? Thanks! Sebastian 2015-03-18 11:04 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi folks, before you say «romcheg, go away and never come back again!», please read the story that caused me to propose this and the proposed solution. Perhaps it makes you reconsider :) As you know for different reasons, among which are being able to set up everything online and bringing up-to-date packages, we maintain an OSCI repository which is used for building ISOs and deploying OpenStack services. Managing that repo is a pretty hard job. Thus a dedicated group of people is devoted to perform that duty, they are always busy because of a lot of responsibilities they have. At the same time Fuel’s developers are pretty energetic and always want to add new features to Fuel. For that they love to use different libraries, many of which aren’t in the OSCI mirror yet. So they ask OSCI guys to add more and more of those and I guess that’s pretty fine except one little thing — sometimes those libraries conflict with ones, required by OpenStack services. To prevent that from happening someone has to check every patch against the OSCI repo and OpenStack’s global requirements, to detect whether a version bump or adding a new library is required an whether it can be performed. As you can guess, there’s too much of a human factor so statistically no one does that until problems appear. Moreover, theres’ nothing but a «it’s not compatible with OpenStack» yelling from OSCI team that stops developers to change dependencies in Fuel. All the stuff described above causes sometimes tremendous time losses and is very problem-prone. I’d like to propose to make everyone’s life easier by following these steps: - Create a new project called Fuel Requirements, all changes to it should go through a standard review procedure - We strict ourselves to use only packages from both Fuel Requirements and Global Requirements for the version of OpenStack, Fuel is installing in the following manner: - If a requirement is in Global Requirements, the version spec in all Fuel’s components should be exactly like that. - OSCI mirror should contain the maximum version of a requirement that matches its version specification. - If a requirement is not in the global requirements list, then Fuel Requirements list should be used to check whether all Fuel’s components require the same version of a library/package. - OSCI mirror should contain the maximum version of a requirement that matches its version specification. - If a requirement that previously was only in Fuel Requirements is merged to Global Requirements, it should be removed from Global Requirements - Set up CI jobs in both OpenStack CI and FuelCI to check all patches against both Global Requirements and Fuel Requirements and block, if either of checks doesn’t pass - Set up CI jobs to notify OSCI team if either Global Requirements or Fuel Requirements are changed. - Set up requirements proposal jobs that will automatically propose changes to all fuel projects once either of requirements lists was changed, just like it’s done for OpenStack projects. These steps may look terribly hard, but most of the job is already done in OpenStack projects and therefore it can be reused for Fuel. Looking forward for your feedback folks! - romcheg __ 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] Python code in fuel-library
Hi, I've created a patchset that introduces a script to run Python tests in fuel-library [1] and a Jenkins job [2] I also would like to backport those tests to stable branches to assure that any fix backported to stable branches will be also checked. Best, Sebastian [1] https://review.openstack.org/#/c/157319/ [2] https://review.fuel-infra.org/#/c/3810/ 2015-02-18 16:01 GMT+01:00 Aleksandr Didenko adide...@mirantis.com: Hi, I agree that we need a better testing for python tasks/code. There should be no problems adding py.test tests into fuel-library CI, we already have one [1] up and running. So I'm all in and ready to help with such testing implementation. [1] https://fuel-jenkins.mirantis.com/job/fuellib_tasks_graph_check/ Regards, Aleksandr On Wed, Feb 18, 2015 at 4:02 PM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Seb Very fair point, thank you. We need to add this to our jobs for unittests run and syntax check. I am adding Aleksandr Didenko into the loop as he is currently working on the similar task. On Wed, Feb 18, 2015 at 4:53 PM, Jay Pipes jaypi...@gmail.com wrote: On 02/18/2015 04:57 AM, Sebastian Kalinowski wrote: Hello Fuelers, There is more and more Python code appearing in fuel-library [1] that is used in our Puppet manifests. Now, with introduction of Granular Deployment feature it could appear more often as writing some tasks as a Python script is a nice option. First problem that I see is that in some cases this code is getting merged without a positive review from a Python developer from Fuel team. My proposition of the solution is simple: fuel-library core reviewers shouldn't merge such code if there is no a +1 from a Python developer from fuel-core group [2]. Second problem is that there are no automatic tests for this code. Testing it manually and by running deployment when that code is used is not enough since those scripts could be quite large and complicated and some of them are executed in specific situations so it is hard for reviewers to check how they will work. In fuel-library we already have tests for Puppet modules: [3]. I suggest that we should introduce similar checks for Python code: - there will be one global 'test-requirements.txt' file (if there will be a need to, we could introduce more granular split, like per module) - py.test [4] will be used as a test runner - (optional, but advised) flake8+hacking checks [5] (could be limited to just run flake8/pyflakes checks) Looking forward to your opinions on those two issues. Hi Seba, All those suggestions look fine to me. I'd also add to improve the documentation on how to write and run Python tests to help out those developers who are not as familiar with Python as Ruby or other languages. Best, -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 -- Yours Faithfully, Vladimir Kuklin, Fuel Library Tech Lead, Mirantis, Inc. +7 (495) 640-49-04 +7 (926) 702-39-68 Skype kuklinvv 45bk3, Vorontsovskaya Str. Moscow, Russia, www.mirantis.com http://www.mirantis.ru/ www.mirantis.ru vkuk...@mirantis.com __ 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] [Fuel] Python code in fuel-library
Hello Fuelers, There is more and more Python code appearing in fuel-library [1] that is used in our Puppet manifests. Now, with introduction of Granular Deployment feature it could appear more often as writing some tasks as a Python script is a nice option. First problem that I see is that in some cases this code is getting merged without a positive review from a Python developer from Fuel team. My proposition of the solution is simple: fuel-library core reviewers shouldn't merge such code if there is no a +1 from a Python developer from fuel-core group [2]. Second problem is that there are no automatic tests for this code. Testing it manually and by running deployment when that code is used is not enough since those scripts could be quite large and complicated and some of them are executed in specific situations so it is hard for reviewers to check how they will work. In fuel-library we already have tests for Puppet modules: [3]. I suggest that we should introduce similar checks for Python code: - there will be one global 'test-requirements.txt' file (if there will be a need to, we could introduce more granular split, like per module) - py.test [4] will be used as a test runner - (optional, but advised) flake8+hacking checks [5] (could be limited to just run flake8/pyflakes checks) Looking forward to your opinions on those two issues. Best, Sebastian [1] https://github.com/stackforge/fuel-library/search?l=python [2] https://review.openstack.org/#/admin/groups/209,members [3] https://fuel-jenkins.mirantis.com/job/fuellib_unit_tests/ [4] http://pytest.org/latest/ [5] https://github.com/openstack-dev/hacking __ 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] Fuel plugin builder tagging and pypi publishing
+1 for the whole idea, I really waited for it until first release of fuel-plugin-builder. Without tags it's hard to say which commit is included in PyPI release. Also automation of release process is a really nice thing and make it more transparent. 2015-02-13 9:59 GMT+01:00 Evgeniy L e...@mirantis.com: Hi, Since fuel plugins are going to be moved [1] from fuel-plugins repository [2], the only project which will be there is fuel plugin builder and plugins examples which are related to fuel plugin builder testing. Currently fuel plugin builder has its own release cycle, but we don't have tags for these versions, the suggestion is after plugins are removed from the repository, we should push tags for previous fpb releases. Tags can help with another problem, currently I manually publish new version on pypi, we can automatically build and publish new version after tag is pushed. What do you think about that? Thanks, [1] https://review.openstack.org/#/c/151143/ [2] https://github.com/stackforge/fuel-plugins [3] https://github.com/stackforge/fuel-plugins/blob/master/fuel_plugin_builder/CHANGELOG.md __ 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] fuel-client and Nailgun API
Hi, 2015-02-09 13:57 GMT+01:00 Nikolay Markov nmar...@mirantis.com: They say, there is some kind of holywar around the topic on if fuel-client tests should rely on working Nailgun API without mocking it. Could you point us where was such hollywar was, so we could get some background on the topic? Best, Sebastian __ 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] Proposal for nominating people to python-fuelclient-core
+1 2015-01-26 11:33 GMT+01:00 Roman Prykhodchenko m...@romcheg.me: Hi Guys, According to our previous thread [1] and the decision made there I’d like to initiate separation of the original fuel-core group. At the first step propose the following python guys from the original fuel-core group to be nominated to python-fuelclient-core group. Aleksey Kasatkin — akasatkin Dmitry Pyzhov — dpyzhov Evgeniy L — evgeniyl___ Igor Kalnitsky — ikalnitsky The decision will be made basing on lazy consensus. Since I was in python-fuelclient-core group only for technical reasons, I will remove myself from there as soon as it’s populated. All following nominations and de-nominations will be done according to the approved core-dev process [2]. References: 1. http://lists.openstack.org/pipermail/openstack-dev/2015-January/055038.html 2. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess - romcheg __ 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][Agent] Moving Fuel Agent to a separate repo
+1 I'm all for separating it. 2015-01-26 17:52 GMT+01:00 Alexander Gordeev agord...@mirantis.com: Hello Vladimir, totally +1 for separating Fuel Agent out of fuel-web. what will happen with fuel_agent_ci ? On Mon, Jan 26, 2015 at 7:42 PM, Vladimir Kozhukalov vkozhuka...@mirantis.com wrote: Fuelers, As most of you might know we have a bunch of projects inside fuel-web repo which are not directly related to Fuel Web application. Some of them are tested together and it seemed we could end up with a set of incompatibility issues if we separated them and stopped tracking their versions on the git level (instead of release level). Recent activities about separating Fuel Client from Nailgun (api) make me think we are mature enough to move all other not related project out of fuel-web repo and bring them together not earlier than on the stage of system/functional testing. Next step would be moving out Fuel Agent project. The reason is that it is independent and potentially could be used even out of Fuel because its data parsing mechanism is implemented so as to be agnostic to the data format. Some people could be potentially interested in using it independently with their own data format. It is tested together with other Fuel components during system testing only. Vladimir Kozhukalov __ 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] [Fuel][Nailgun] Web framework
Hello all, What is the current situation with choosing web framework? Was there any progress in the topic? I would like to avoid forgetting about it. 2014-12-08 15:47 GMT+01:00 Ryan Petrello ryan.petre...@dreamhost.com: Feel free to ask any questions you have in #pecanpy on IRC; I can answer a lot more quickly than researching docs, and if you have a special need, I can usually accommodate with changes to Pecan (I've done so with several OpenStack projects in the past). On 12/08/14 02:10 PM, Nikolay Markov wrote: Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. We still need some research to do about technical issues and how easy we can move to Pecan. Thanks to Ryan, we now have multiple links to solutions and docs on discussed issues. I guess we'll dedicate some engineer(s) responsible for doing such a research and then make all our decisions on subject. On Mon, Dec 8, 2014 at 11:07 AM, Sebastian Kalinowski skalinow...@mirantis.com wrote: 2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Ryan Petrello Senior Developer, DreamHost ryan.petre...@dreamhost.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
2014-12-04 14:01 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: Ok, guys, It became obvious that most of us either vote for Pecan or abstain from voting. Yes, and it's been 4 days since last message in this thread and no objections, so it seems that Pecan in now our framework-of-choice for Nailgun and future apps/projects. So I propose to stop fighting this battle (Flask vs Pecan) and start thinking about moving to Pecan. You know, there are many questions that need to be discussed (such as 'should we change API version' or 'should be it done iteratively or as one patchset'). IMHO small, iterative changes are rather obvious. For other questions maybe we need (draft of ) a blueprint and a separate mail thread? - Igor ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
2014-12-03 13:47 GMT+01:00 Igor Kalnitsky ikalnit...@mirantis.com: I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask. To be fair, Pecan could also pass request and response explicit to method [1] [1] http://pecan.readthedocs.org/en/latest/contextlocals.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel][Nailgun] Web framework
I never used Flask and Pecan personally so I can only rely from what I saw in this thread and in both projects docs. I don't have strong opinion, just want to share some thoughts. I think that as a part of OpenStack community we should stick with Pecan and because of the same reason we can have a bigger impact how future versions of Pecan will look. If we will choose Flask I see is that we not only need to choose a framework, but also decide which extension will be used to provide REST support (I do not like that we just assume flask-restful will be used). To be honest right now I'm more convinced that we should choose Pecan. 2014-12-03 14:22 GMT+01:00 Nikolay Markov nmar...@mirantis.com: Dear colleagues, We surely may take into account the beauty of the code in both cases (as for me, Pecan loses here, too) and argue about global objects and stuff, but I'm trying to look at amount of men and time we need to move to one of these frameworks. Agree that we should look on the man-hours for implementation, but I think that it is as important as all the small things like global object etc. since they could make future development painful or pleasant. I wouldn't say our API is badly designed, nevertheless Pecan still has a lot of issues needed to be fixed by hand. We don't want to spend much time to this task, because it is mostly the matter of convenience and simplicity for developers, it changes nothing in features or customer-facing behavior. And if we take in account the amount of hours we need to move, based on my experience Flask definitely wins here. Cannot we reuse the PoC ([1]) with Pecan that was created? There was a lot of work put into that piece of code. [1] https://review.openstack.org/#/c/99069/6 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel][Nailgun] Web framework
Hi all, Some time ago we had a discussion about moving Nailgun to new web framework [1]. There was comparison [2] of two possible options: Pecan [3] and Flask [4]. We came to conclusion that we need to move Nailgun on some alive web framework instead of web.py [5] (some of the reasons: [6]) but there was no clear agreement on what framework (there were strong voices for Flask). I would like to bring this topic up again so we could discuss with broader audience and make final decision what will be our next web framework. I think that we should also consider to make that framework our weapon of choice (or so called standard) when creating new web services in Fuel. Best, Sebastian [1] https://lists.launchpad.net/fuel-dev/msg01397.html [2] https://docs.google.com/a/mirantis.com/document/d/1QR7YphyfN64m-e9b5rKC_U8bMtx4zjfW943BfLTqTao/edit?usp=sharing [3] http://www.pecanpy.org/ [4] http://flask.pocoo.org/ [5] http://webpy.org/ [6] https://lists.launchpad.net/fuel-dev/msg01501.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
I have some topics for [1] that I want to discuss: 1) Should we allow users to turn SSL on/off for Fuel master? I think we should since some users may don't care about SSL and enabling it will just make them unhappy (like warnings in browsers, expiring certs). 2) Will we allow users (in first iteration) to use their own certs? If we will (which I think we should and other people aslo seems to share this point of view), we have some options for that: A) Add informations to docs where to upload your own certificate on master node (no UI) - less work, but requires a little more action from users B) Simple form in UI where user will be able to paste his certs - little bit more work, user friendly Are there any reasons we shouldn't do that? 3) How we will manage cert expiration? Stanislaw proposed that we should show user a notification that will tell user about cert expiration. We could check that in cron job. I think that we should also allow user to generate a new cert in Fuel if the old one will expire. I'll also remove part about adding cert validation in fuel agent since it would require a significant amount of work and it's not essential for first iteration. Best, Sebastian [1] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [FUEL] Re: SSL in Fuel.
On Tue, Sep 9, 2014 at 5:53 PM, Stanislaw Bogatkin sbogat...@mirantis.com wrote: So I think that we need to start on [3]. As this is required for OSt public endpoint SSL and also for Fuel SSL it can be quicker to make a first stage where a self-signed certificate is managed from nailgun and a second stage with the docker CA... So, yes, I think that it is good idea, cause it will be good base for [2] and [3] [1] https://blueprints.launchpad.net/fuel/+spec/ca-deployment [2] https://blueprints.launchpad.net/fuel/+spec/fuel-ssl-endpoints [3] https://blueprints.launchpad.net/fuel/+spec/ssl-endpoints +1 I totally agree that we should start with [1] first and later focus on [2] and [3]. I'll also update [2] to adjust it to the plan you proposed. Best, Sebastian ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] SSL in Fuel
Hi all, As next step for improving Fuel security we are introducing SSL for both Fuel [1] and OS API endpoints [2]. Both specs assume usage of self-signed certificates generated by Fuel. It also required to allow users to use their own certs to secure their deployments (two blueprints that touch that part are [3] and [4]) We would like to start a discussion to see what opinions (and maybe ideas) you have for that feature. Best, Sebastian [1] https://review.openstack.org/#/c/119330 [2] https://review.openstack.org/#/c/102273 [3] https://blueprints.launchpad.net/fuel/+spec/ca-deployment [4] https://blueprints.launchpad.net/fuel/+spec/manage-ssl-certificate ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev