Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
Hi, I also think, that after release we should run restrospective and actually analyse how much reality differs from the spec. This will help us improve planning in the future. On 03 Feb 2015, at 22:15, Andrey Danin ada...@mirantis.com wrote: I totally agree with Andrew. On Tuesday, February 3, 2015, Andrew Woodward xar...@gmail.com wrote: Either we do specs, or we don't. Either every one has to land their specs before code or no one does. Its that simple. What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? The spec defining what has been committed already needs to be merged, and we can open another review to modify the spec into another direction if necessary. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. The spec doesn't have to be perfect, but it needs to be merged prior to code describing it. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. This isn't the intent of the spec, its to document the extent, general direction, and impact of a feature. As a side effect, well defined specs can also serve as documentation for the feature. While the discussion is common on the spec, this should be done on a merged spec. On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L e...@mirantis.com wrote: Hi, +1 to Dmitriy's comment. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. Also with your suggestion we'll get a lot of patches over 2 thousands lines of code, after spec is merged. Huge patches reduce quality, because it's too hard to review, also such patches much harder to get merged. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. Thanks, On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: Andrew, What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com wrote: Vova, Its great to see so much progress on this, however it appears that we have started merging code prior to the spec landing [0] lets get it sorted ASAP. [0] https://review.openstack.org/#/c/113491/ On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 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 -- Andrew Mirantis Ceph community On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin
Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
The spec doesn't have to be perfect, but it needs to be merged prior to code describing it. Currently the spec has to be perfect and detailed enough, otherwise you will have to merge the spec with -1 from reviewers, also if you postpone the details, you won't be able to track, if these details were fixed. Also with your approach the terminology is going to be changed, because ready spec != merged spec anymore. On Tue, Feb 3, 2015 at 9:46 PM, Andrew Woodward xar...@gmail.com wrote: Either we do specs, or we don't. Either every one has to land their specs before code or no one does. Its that simple. What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? The spec defining what has been committed already needs to be merged, and we can open another review to modify the spec into another direction if necessary. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. The spec doesn't have to be perfect, but it needs to be merged prior to code describing it. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. This isn't the intent of the spec, its to document the extent, general direction, and impact of a feature. As a side effect, well defined specs can also serve as documentation for the feature. While the discussion is common on the spec, this should be done on a merged spec. On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L e...@mirantis.com wrote: Hi, +1 to Dmitriy's comment. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. Also with your suggestion we'll get a lot of patches over 2 thousands lines of code, after spec is merged. Huge patches reduce quality, because it's too hard to review, also such patches much harder to get merged. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. Thanks, On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: Andrew, What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com wrote: Vova, Its great to see so much progress on this, however it appears that we have started merging code prior to the spec landing [0] lets get it sorted ASAP. [0] https://review.openstack.org/#/c/113491/ On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 www.mirantis.ru vkuk...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
Either we do specs, or we don't. Either every one has to land their specs before code or no one does. Its that simple. What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? The spec defining what has been committed already needs to be merged, and we can open another review to modify the spec into another direction if necessary. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. The spec doesn't have to be perfect, but it needs to be merged prior to code describing it. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. This isn't the intent of the spec, its to document the extent, general direction, and impact of a feature. As a side effect, well defined specs can also serve as documentation for the feature. While the discussion is common on the spec, this should be done on a merged spec. On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L e...@mirantis.com wrote: Hi, +1 to Dmitriy's comment. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. Also with your suggestion we'll get a lot of patches over 2 thousands lines of code, after spec is merged. Huge patches reduce quality, because it's too hard to review, also such patches much harder to get merged. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. Thanks, On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: Andrew, What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com wrote: Vova, Its great to see so much progress on this, however it appears that we have started merging code prior to the spec landing [0] lets get it sorted ASAP. [0] https://review.openstack.org/#/c/113491/ On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 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 -- Andrew Mirantis Ceph community On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to
Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
I totally agree with Andrew. On Tuesday, February 3, 2015, Andrew Woodward xar...@gmail.com wrote: Either we do specs, or we don't. Either every one has to land their specs before code or no one does. Its that simple. What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? The spec defining what has been committed already needs to be merged, and we can open another review to modify the spec into another direction if necessary. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. The spec doesn't have to be perfect, but it needs to be merged prior to code describing it. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. This isn't the intent of the spec, its to document the extent, general direction, and impact of a feature. As a side effect, well defined specs can also serve as documentation for the feature. While the discussion is common on the spec, this should be done on a merged spec. On Thu, Jan 29, 2015 at 2:45 AM, Evgeniy L e...@mirantis.com javascript:_e(%7B%7D,'cvml','e...@mirantis.com'); wrote: Hi, +1 to Dmitriy's comment. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. Also with your suggestion we'll get a lot of patches over 2 thousands lines of code, after spec is merged. Huge patches reduce quality, because it's too hard to review, also such patches much harder to get merged. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. Thanks, On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak dshul...@mirantis.com javascript:_e(%7B%7D,'cvml','dshul...@mirantis.com'); wrote: Andrew, What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com javascript:_e(%7B%7D,'cvml','xar...@gmail.com'); wrote: Vova, Its great to see so much progress on this, however it appears that we have started merging code prior to the spec landing [0] lets get it sorted ASAP. [0] https://review.openstack.org/#/c/113491/ On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com javascript:_e(%7B%7D,'cvml','vkuk...@mirantis.com'); wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 www.mirantis.ru vkuk...@mirantis.com javascript:_e(%7B%7D,'cvml','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 -- Andrew Mirantis Ceph community On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin
Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
Hi, +1 to Dmitriy's comment. We can spend several month on polishing the spec, will it help to release feature in time? I don't think so. Also with your suggestion we'll get a lot of patches over 2 thousands lines of code, after spec is merged. Huge patches reduce quality, because it's too hard to review, also such patches much harder to get merged. I think the spec should be a synchronization point, where different teams can discuss details and make sure that everything is correct. The spec should represent the current state of the code which is merged and which is going to be merged. Thanks, On Thu, Jan 29, 2015 at 1:03 AM, Dmitriy Shulyak dshul...@mirantis.com wrote: Andrew, What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com wrote: Vova, Its great to see so much progress on this, however it appears that we have started merging code prior to the spec landing [0] lets get it sorted ASAP. [0] https://review.openstack.org/#/c/113491/ On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 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 -- Andrew Mirantis Ceph community On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 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 -- Andrew
Re: [openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
Andrew, What should be sorted out? It is unavoidable that people will comment and ask questions during development cycle. I am not sure that merging spec as early as possible, and than add comments and different fixes is good strategy. On the other hand we need to eliminate risks.. but how merging spec can help? On Wed, Jan 28, 2015 at 8:49 PM, Andrew Woodward xar...@gmail.com wrote: Vova, Its great to see so much progress on this, however it appears that we have started merging code prior to the spec landing [0] lets get it sorted ASAP. [0] https://review.openstack.org/#/c/113491/ On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 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 -- Andrew Mirantis Ceph community On Mon, Jan 19, 2015 at 8:21 AM, Vladimir Kuklin vkuk...@mirantis.com wrote: Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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 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 -- Andrew 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
[openstack-dev] [Fuel][Fuel-Library] MVP implementation of Granular Deployment merged into Fuel master branch
Hi, Fuelers and Stackers I am glad to announce that we merged initial support for granular deployment feature which is described here: https://blueprints.launchpad.net/fuel/+spec/granular-deployment-based-on-tasks This is an important milestone for our overall deployment and operations architecture as well as it is going to significantly improve our testing and engineering process. Starting from now we can start merging code for: https://blueprints.launchpad.net/fuel/+spec/fuel-library-modularization https://blueprints.launchpad.net/fuel/+spec/fuel-library-modular-testing We are still working on documentation and QA stuff, but it should be pretty simple for you to start trying it out. We would really appreciate your feedback. Existing issues are the following: 1) pre and post deployment hooks are still out of the scope of main deployment graph 2) there is currently only puppet task provider working reliably 3) no developer published documentation 4) acyclic graph testing not injected into CI 5) there is currently no opportunity to execute particular task - only the whole deployment (code is being reviewed right now) -- 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
