Open Stack

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 <adanin at mirantis.com> wrote:
> 
> I totally agree with Andrew. 
> 
> On Tuesday, February 3, 2015, Andrew Woodward <xarses at 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 <eli at 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 <dshulyak at 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 <xarses at 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 <vkuklin at 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
> > vkuklin at mirantis.com
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at 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 <vkuklin at 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
> > vkuklin at mirantis.com
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> -- 
> Andrew
> Mirantis
> Fuel community ambassador 
> Ceph community
> 
> 
> -- 
> Andrey Danin
> adanin at mirantis.com
> skype: gcon.monolake
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Tomasz 'Zen' Napierala
Sr. OpenStack Engineer
tnapierala at mirantis.com