[openstack-dev] [OpenStack-Dev] [Cinder FFE] Request for HDS FFE

Steven Sonnenberg steven.sonnenberg at hds.com
Tue Mar 25 14:42:20 UTC 2014


I just want to point out, there were no changes required to pass the tests. We were running those tests in Brazil and tunneling NFS and iSCSI across the Internet which explain timeout issues. Those are the same tests that passed a month earlier before we went into the cycle of review/fix/format etc.

-----Original Message-----
From: openstack-dev-request at lists.openstack.org [mailto:openstack-dev-request at lists.openstack.org] 
Sent: Tuesday, March 25, 2014 8:00 AM
To: openstack-dev at lists.openstack.org
Subject: OpenStack-dev Digest, Vol 23, Issue 88

Send OpenStack-dev mailing list submissions to
	openstack-dev at lists.openstack.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
or, via email, send a message with subject or body 'help' to
	openstack-dev-request at lists.openstack.org

You can reach the person managing the list at
	openstack-dev-owner at lists.openstack.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenStack-dev digest..."


Today's Topics:

   1. Re: [OpenStack-Dev] [Cinder FFE] Request for HDS FFE (Mike Perez)
   2.  [Murano] Code review (Timur Nurlygayanov)
   3. Re: Separating our Murano PL core in own package (Serg Melikyan)
   4. Re: Separating our Murano PL core in own package (Dmitry Teselkin)
   5. Re: [Neutron][LBaaS] (Oleg Bondarev)
   6. Re: Separating our Murano PL core in own package
      (Timur Nurlygayanov)
   7. Re: [qa] [neutron] Neutron Full Parallel job - Last 4 days
      failures (Salvatore Orlando)
   8. Re: [Nova] Updates to Juno blueprint review process
      (Russell Bryant)
   9. Re: [openstack-qa] Graduation Requirements + Scope	of Tempest
      (Maru Newby)
  10. [Trove] Meeting Wednesday, 26 March @ 1800 UTC (Nikhil Manchanda)
  11. Re: [depfreeze] Dependency freeze coming up (EOD Tuesday
      March 25) (Thierry Carrez)
  12. Re: [neutron][rootwrap] Performance considerations, sudo?
      (Miguel Angel Ajo)
  13. Re: Separating our Murano PL core in own package
      (Alexander Tivelkov)
  14. Re: [Murano][Heat] MuranoPL questions? (Georgy Okrokvertskhov)
  15. Re: [Nova] Updates to Juno blueprint review process
      (Thierry Carrez)
  16. Re: [Murano][Heat] MuranoPL questions? (Thomas Herve)
  17. Re: Multiple patches in one review (Mark McLoughlin)
  18. Re: [Murano][Heat] MuranoPL questions? (Thomas Herve)
  19. Re: OpenStack vs. SQLA 0.9 (Mark McLoughlin)
  20. Re: OpenStack vs. SQLA 0.9 (Sean Dague)
  21. Re: Spec repos for blueprint development and review (Mark McClain)
  22. Re: [Murano][Heat] MuranoPL questions? (Georgy Okrokvertskhov)
  23. Re: [Murano][Heat] MuranoPL questions? (Stan Lagun)
  24. Re: [openstack-qa] Graduation Requirements + Scope of Tempest
      (Malini Kamalambal)
  25. Re: [Neutron][LBaaS] Neutron LBaaS, Libra and "managed
      services" (Susanne Balle)


----------------------------------------------------------------------

Message: 1
Date: Mon, 24 Mar 2014 23:46:08 -0700
From: Mike Perez <thingee at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [OpenStack-Dev] [Cinder FFE] Request for
	HDS FFE
Message-ID: <20140325064608.GA13533 at gmail.com>
Content-Type: text/plain; charset=us-ascii

On 21:29 Mon 24 Mar     , Tom Goulding wrote:
> I'd like to request an FFE for Cinder drivers for Hitachi HNAS storage. We showed this driver running in the demo theater at the Hong Kong summit and we've had end-users using it since January.
> 
> The driver was initially submitted on Feb 18, 2014 some 45 days ago with regular work since then to address all review comments (a total of 8 revisions).  The only real functional change that has occurred since Hong Kong was making CHAP protocol support optional. (The blueprint for this driver was submitted back on Aug. 29, 2013.) We've been working through the new Cinder requirements for certification testing which slowed things down as has obtaining a stable devstack environment.  Early documentation on the new certification tests was not clear and has since been improved.
> 
> We are convinced that the driver poses no risk to the stability and quality of the Icehouse release, so given that it's in the community's best interest to encourage a broad ecosystem of device support, and that we've been working in good faith to get this driver through the process, please help us get this into Icehouse.

Hi Tom,

Thanks for submitting your driver. Unfortunately I would have to give a -1 for
an exception to be made for a new driver this late in the release.

I'm sorry that there were problems with getting the cert tests working.
However, on March 13th [1], your cert test did reveal that it was not passing
for ISCSI and NFS [2][3], which would've gone out with the release. I think you
would agree it's far more important to make sure things actually work than
making a release.

There were other issues with the unit tests not using mock and other standards
that Cinder reviewers hold to every review, that this late in the release just
didn't make the time frame doable.

Regardless of risk to Cinder core, this is a time that contributors should be
spending on getting targeted core issues stable and focusing review time on
those issues. I would encourage you to propose a review for the Juno
release.

[1] - https://review.openstack.org/#/c/74371/
[2] - https://gist.github.com/sombrafam/9493308
[3] - https://gist.github.com/sombrafam/9416255

-- 
Mike Perez



------------------------------

Message: 2
Date: Tue, 25 Mar 2014 10:59:49 +0400
From: Timur Nurlygayanov <tnurlygayanov at mirantis.com>
To: OpenStack Development Mailing List
	<openstack-dev at lists.openstack.org>
Subject: [openstack-dev]  [Murano] Code review
Message-ID:
	<CAHCYybMGUDVQW5mvR7fn6Fj5PMZ74nN-xyAriCJdv80A9CdFnA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Murano team,

can we review this commit asap:
https://bugs.launchpad.net/murano/+bug/1291968?
This is fix for the critical issue in release 0.5:
#1291968<https://bugs.launchpad.net/murano/+bug/1291968>
.

Thanks!

-- 

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/62ff4687/attachment-0001.html>

------------------------------

Message: 3
Date: Tue, 25 Mar 2014 11:21:09 +0400
From: Serg Melikyan <smelikyan at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Separating our Murano PL core in own
	package
Message-ID:
	<CAOnDsYOxYU_mTEuahAw-6+6TEsDJ=T-Ufcr6E4WCDm=ki1eL4Q at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Joshua, I was talking about simple python sub-package inside existing
repository, in existing package. I am suggesting to add
muranoapi.engine.<name> sub-package, and nothing more.


On Mon, Mar 24, 2014 at 10:29 PM, Ruslan Kamaldinov <
rkamaldinov at mirantis.com> wrote:

> On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow <harlowja at yahoo-inc.com>
> wrote:
> > Seeing that the following repos already exist, maybe there is some need
> for
> > cleanup?
> >
> > - https://github.com/stackforge/murano-agent
> > - https://github.com/stackforge/murano-api
> > - https://github.com/stackforge/murano-common
> > - https://github.com/stackforge/murano-conductor
> > - https://github.com/stackforge/murano-dashboard
> > - https://github.com/stackforge/murano-deployment
> > - https://github.com/stackforge/murano-docs
> > - https://github.com/stackforge/murano-metadataclient
> > - https://github.com/stackforge/murano-repository
> > - https://github.com/stackforge/murano-tests
> > ...(did I miss others?)
> >
> > Can we maybe not have more git repositories and instead figure out a way
> to
> > have 1 repository (perhaps with submodules?) ;-)
> >
> > It appears like murano is already exploding all over stackforge which
> makes
> > it hard to understand why yet another repo is needed. I understand why
> from
> > a code point of view, but it doesn't seem right from a code organization
> > point of view to continue adding repos. It seems like murano
> > (https://github.com/stackforge/murano) should just have 1 repo, with
> > sub-repos (tests, docs, api, agent...) for its own organizational usage
> > instead of X repos that expose others to murano's internal organizational
> > details.
> >
> > -Josh
>
>
> Joshua,
>
> I agree that this huge number of repositories is confusing for newcomers.
> I've
> spent some time to understand mission of each of these repos. That's why we
> already did the cleanup :) [0]
>
> And I personally will do everything to prevent creation of new repo for
> Murano.
>
> Here is the list of repositories targeted for the next Murano release (Apr
> 17):
> * murano-api
> * murano-agent
> * python-muranoclient
> * murano-dashboard
> * murano-docs
>
> The rest of these repos will be deprecated right after the release.  Also
> we
> will rename murano-api to just "murano". murano-api will include all the
> Murano services, functionaltests for Tempest, Devstack scripts, developer
> docs.
> I guess we already can update README files in deprecated repos to avoid
> further
> confusion.
>
> I wouldn't agree that there should be just one repo. Almost every OpenStack
> project has it's own repo for python client. All the user docs are kept in
> a
> separate repo. Guest agent code should live in it's own repository to keep
> number of dependencies as low as possible. I'd say there should be
> required/comfortable minimum of repositories per project.
>
>
> And one more nit correction:
> OpenStack has it's own git repository [1]. We shoul avoid referring to
> github
> since it's just a convinient mirror, while [1] is an official
> OpenStack repository.
>
> [0]
> https://blueprints.launchpad.net/murano/+spec/repository-reorganization
> [1] http://git.openstack.org/cgit/
>
>
>
> Thanks,
> Ruslan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Serg Melikyan, Senior Software Engineer at Mirantis, Inc.
http://mirantis.com | smelikyan at mirantis.com

+7 (495) 640-4904, 0261
+7 (903) 156-0836
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/07236a8e/attachment-0001.html>

------------------------------

Message: 4
Date: Tue, 25 Mar 2014 11:38:55 +0400
From: Dmitry Teselkin <dteselkin at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Separating our Murano PL core in own
	package
Message-ID:
	<CAGY=Eixp=5VFBR64icABOE9KS7M4y=9k2119JFEt4TM8hoag5Q at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Ruslan,

What about murano-deployment repo? The most important part of it are
PowerSheel scripts, Windows Image Builder, package manifests, and some
other scripts that better to keep somewhere. Where do we plan to move them?


On Mon, Mar 24, 2014 at 10:29 PM, Ruslan Kamaldinov <
rkamaldinov at mirantis.com> wrote:

> On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow <harlowja at yahoo-inc.com>
> wrote:
> > Seeing that the following repos already exist, maybe there is some need
> for
> > cleanup?
> >
> > - https://github.com/stackforge/murano-agent
> > - https://github.com/stackforge/murano-api
> > - https://github.com/stackforge/murano-common
> > - https://github.com/stackforge/murano-conductor
> > - https://github.com/stackforge/murano-dashboard
> > - https://github.com/stackforge/murano-deployment
> > - https://github.com/stackforge/murano-docs
> > - https://github.com/stackforge/murano-metadataclient
> > - https://github.com/stackforge/murano-repository
> > - https://github.com/stackforge/murano-tests
> > ...(did I miss others?)
> >
> > Can we maybe not have more git repositories and instead figure out a way
> to
> > have 1 repository (perhaps with submodules?) ;-)
> >
> > It appears like murano is already exploding all over stackforge which
> makes
> > it hard to understand why yet another repo is needed. I understand why
> from
> > a code point of view, but it doesn't seem right from a code organization
> > point of view to continue adding repos. It seems like murano
> > (https://github.com/stackforge/murano) should just have 1 repo, with
> > sub-repos (tests, docs, api, agent...) for its own organizational usage
> > instead of X repos that expose others to murano's internal organizational
> > details.
> >
> > -Josh
>
>
> Joshua,
>
> I agree that this huge number of repositories is confusing for newcomers.
> I've
> spent some time to understand mission of each of these repos. That's why we
> already did the cleanup :) [0]
>
> And I personally will do everything to prevent creation of new repo for
> Murano.
>
> Here is the list of repositories targeted for the next Murano release (Apr
> 17):
> * murano-api
> * murano-agent
> * python-muranoclient
> * murano-dashboard
> * murano-docs
>
> The rest of these repos will be deprecated right after the release.  Also
> we
> will rename murano-api to just "murano". murano-api will include all the
> Murano services, functionaltests for Tempest, Devstack scripts, developer
> docs.
> I guess we already can update README files in deprecated repos to avoid
> further
> confusion.
>
> I wouldn't agree that there should be just one repo. Almost every OpenStack
> project has it's own repo for python client. All the user docs are kept in
> a
> separate repo. Guest agent code should live in it's own repository to keep
> number of dependencies as low as possible. I'd say there should be
> required/comfortable minimum of repositories per project.
>
>
> And one more nit correction:
> OpenStack has it's own git repository [1]. We shoul avoid referring to
> github
> since it's just a convinient mirror, while [1] is an official
> OpenStack repository.
>
> [0]
> https://blueprints.launchpad.net/murano/+spec/repository-reorganization
> [1] http://git.openstack.org/cgit/
>
>
>
> Thanks,
> Ruslan
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Dmitry Teselkin
Deployment Engineer
Mirantis
http://www.mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/593e7baf/attachment-0001.html>

------------------------------

Message: 5
Date: Tue, 25 Mar 2014 12:02:09 +0400
From: Oleg Bondarev <obondarev at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS]
Message-ID:
	<CAO_ZGNGdf4F6ZqTtaTUZSDXqTnJPA=z68DZ3kvBxXdFCvLgv0A at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Vijay,
Currently Neutron LBaaS supports only namespace based implementation for
HAProxy.
You can however run LBaaS agent on the host other than network controller
node - in that
case HAProxy processes will be running on that host but still in namespaces.

Also there is an effort in Neutron regarding adding support of advanced
services in VMs [1].
After it is completed I hope it will be possible to adopt it in LBaaS and
run HAProxy in such a service VM.

[1] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms

Thanks,
Oleg


On Tue, Mar 25, 2014 at 1:39 AM, Vijay B <os.vbvs at gmail.com> wrote:

> Hi Eugene,
>
> Thanks for the reply! How/where is the agent configuration done for
> HAProxy? If I don't want to go with a network namespace based HAProxy
> process, but want to deploy my own HAProxy instance on a host outside of
> the network controller node, and make neutron deploy pools/VIPs on that
> HAProxy instance, does neutron currently support this scenario? If so, what
> are the configuration steps I will need to carry out to deploy HAProxy on a
> separate host (for example, where do I specify the ip address of the
> haproxy host, etc)?
>
> Regards,
> Vijay
>
>
> On Mon, Mar 24, 2014 at 2:04 PM, Eugene Nikanorov <enikanorov at mirantis.com
> > wrote:
>
>> Hi,
>>
>> HAProxy driver has not removed from the trunk, instead it became a base
>> for agent-based driver, so the only haproxy-specific thing in the plugin
>> driver is device driver name. Namespace driver is a device driver on the
>> agent side and it was there from the beginning.
>> The reason for the change is mere refactoring: it seems that solutions
>> that employ agents could share the same code with only device driver being
>> specific.
>>
>> So, everything is in place, HAProxy continues to be the default
>> implementation of Neutron LBaaS service. It supports spawning haproxy
>> processes on any host that runs lbaas agent.
>>
>> Thanks,
>> Eugene.
>>
>>
>>
>> On Tue, Mar 25, 2014 at 12:33 AM, Vijay B <os.vbvs at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'm looking at HAProxy support in Neutron, and I observe that the
>>> drivers/haproxy/plugin_driver.py file in the stable/havana release has been
>>> effectively removed from trunk (master), in that the plugin driver in the
>>> master simply points to the namespace driver. What was the reason to do
>>> this? Was the plugin driver in havana tested and documented? I can't seem
>>> to get hold of any relevant documentation that describes how to configure
>>> HAProxy LBs installed on separate boxes (and not brought up in network
>>> namespaces) - can anyone please point me to the same?
>>>
>>> Also, are there any plans to bring back the HAProxy plugin driver to
>>> talk to remote HAProxy instances?
>>>
>>> Thanks,
>>> Regards,
>>> Vijay
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/ec4a2be2/attachment-0001.html>

------------------------------

Message: 6
Date: Tue, 25 Mar 2014 12:09:23 +0400
From: Timur Nurlygayanov <tnurlygayanov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Separating our Murano PL core in own
	package
Message-ID:
	<CAHCYybMw=EL+mqL95NpxhshRJjgQtp3GPS-EkFTthorX=nyr2A at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Dmitry,

I suggest to move all needed Powershell scripts and etc. to the main
repository 'murano' in the separate folder.


On Tue, Mar 25, 2014 at 11:38 AM, Dmitry Teselkin <dteselkin at mirantis.com>wrote:

> Ruslan,
>
> What about murano-deployment repo? The most important part of it are
> PowerSheel scripts, Windows Image Builder, package manifests, and some
> other scripts that better to keep somewhere. Where do we plan to move them?
>
>
> On Mon, Mar 24, 2014 at 10:29 PM, Ruslan Kamaldinov <
> rkamaldinov at mirantis.com> wrote:
>
>> On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow <harlowja at yahoo-inc.com>
>> wrote:
>> > Seeing that the following repos already exist, maybe there is some need
>> for
>> > cleanup?
>> >
>> > - https://github.com/stackforge/murano-agent
>> > - https://github.com/stackforge/murano-api
>> > - https://github.com/stackforge/murano-common
>> > - https://github.com/stackforge/murano-conductor
>> > - https://github.com/stackforge/murano-dashboard
>> > - https://github.com/stackforge/murano-deployment
>> > - https://github.com/stackforge/murano-docs
>> > - https://github.com/stackforge/murano-metadataclient
>> > - https://github.com/stackforge/murano-repository
>> > - https://github.com/stackforge/murano-tests
>> > ...(did I miss others?)
>> >
>> > Can we maybe not have more git repositories and instead figure out a
>> way to
>> > have 1 repository (perhaps with submodules?) ;-)
>> >
>> > It appears like murano is already exploding all over stackforge which
>> makes
>> > it hard to understand why yet another repo is needed. I understand why
>> from
>> > a code point of view, but it doesn't seem right from a code organization
>> > point of view to continue adding repos. It seems like murano
>> > (https://github.com/stackforge/murano) should just have 1 repo, with
>> > sub-repos (tests, docs, api, agent...) for its own organizational usage
>> > instead of X repos that expose others to murano's internal
>> organizational
>> > details.
>> >
>> > -Josh
>>
>>
>> Joshua,
>>
>> I agree that this huge number of repositories is confusing for newcomers.
>> I've
>> spent some time to understand mission of each of these repos. That's why
>> we
>> already did the cleanup :) [0]
>>
>> And I personally will do everything to prevent creation of new repo for
>> Murano.
>>
>> Here is the list of repositories targeted for the next Murano release
>> (Apr 17):
>> * murano-api
>> * murano-agent
>> * python-muranoclient
>> * murano-dashboard
>> * murano-docs
>>
>> The rest of these repos will be deprecated right after the release.  Also
>> we
>> will rename murano-api to just "murano". murano-api will include all the
>> Murano services, functionaltests for Tempest, Devstack scripts, developer
>> docs.
>> I guess we already can update README files in deprecated repos to avoid
>> further
>> confusion.
>>
>> I wouldn't agree that there should be just one repo. Almost every
>> OpenStack
>> project has it's own repo for python client. All the user docs are kept
>> in a
>> separate repo. Guest agent code should live in it's own repository to keep
>> number of dependencies as low as possible. I'd say there should be
>> required/comfortable minimum of repositories per project.
>>
>>
>> And one more nit correction:
>> OpenStack has it's own git repository [1]. We shoul avoid referring to
>> github
>> since it's just a convinient mirror, while [1] is an official
>> OpenStack repository.
>>
>> [0]
>> https://blueprints.launchpad.net/murano/+spec/repository-reorganization
>> [1] http://git.openstack.org/cgit/
>>
>>
>>
>> Thanks,
>> Ruslan
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Thanks,
> Dmitry Teselkin
> Deployment Engineer
> Mirantis
> http://www.mirantis.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

Timur,
QA Engineer
OpenStack Projects
Mirantis Inc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/87f71d8f/attachment-0001.html>

------------------------------

Message: 7
Date: Tue, 25 Mar 2014 09:17:13 +0100
From: Salvatore Orlando <sorlando at nicira.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [qa] [neutron] Neutron Full Parallel job
	- Last 4 days failures
Message-ID:
	<CAGR=i3isEP7HYpkVxvMw9EbSvs1ZceN546_vsuLtEQBiwLE54g at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Inline

Salvatore


On 24 March 2014 23:01, Matthew Treinish <mtreinish at kortar.org> wrote:

> On Mon, Mar 24, 2014 at 09:56:09PM +0100, Salvatore Orlando wrote:
> > Thanks a lot!
> >
> > We now need to get on these bugs, and define with QA an acceptable
> failure
> > rate criterion for switching the full job to voting.
> > It would be good to have a chance to only run the tests against code
> which
> > is already in master.
> > To this aim we might push a dummy patch, and keep it spinning in the
> check
> > queue.
>
> Honestly, there isn't really a number. I had a thread trying to get
> consensus on
> that back when I first made tempest run in parallel. What I ended up doing
> back
> then and what we've done since for this kind of change is to just pick a
> slower
> week for the gate and just green light it, of course after checking to
> make sure
> if it blows up we're not blocking anything critical.


Then I guess the ideal period would be after RC2s are cut.
Also, we'd need to run also a postgres flavour of the job at least.
Meaning that when calculating the probability of a patch passing in the
gate is actually the combined probability of two jobs completing
successfully.
On another note, we noticed that the duplicated jobs currently executed for
redundancy in neutron actually seem to point all to the same build id.
I'm not sure then if we're actually executing each job twice or just
duplicating lines in the jenkins report.


> If it looks like it's
> passing at roughly the same rate as everything else and you guys think it's
> ready. 25% is definitely too high, for comparison when I looked at a
> couple of
> min. ago at the numbers for the past 4 days on the equivalent job with
> nova-network it only failed 4% of the time. (12 out of 300) But that
> number does
> fluctuate quite a bit for example looking at the past week the number
> grows to
> 11.6%. (171 out of 1480)


Even with 11.6% I would not enable it.
Running mysql and pg jobs this will give us a combined success rate of
 78.1%, which pretty much means the chances of clearing successfully a
5-deep queue in the gate will be a mere 29%. My "gut" metric is that we
should achieve a degree of pass rate which allows us to clear a 10-deep
gate queue with a 50% success rate. This translates to a 3.5% failure rate
per job, which is indeed inline with what's currently observed for
nova-network.

Doing it this way doesn't seem like the best, but until it's gating things
> really don't get the attention they deserve and more bugs will just slip in
> while you wait. There will most likely be initial pain after it merges,
> but it's
> the only real way to lock it down and make forward progress.
>

> -Matt Treinish
>
> >
> >
> > On 24 March 2014 21:45, Rossella Sblendido <rsblendido at suse.com> wrote:
> >
> > > Hello all,
> > >
> > > here is an update regarding the Neutron full parallel job.
> > > I used the following Logstash query [1]  that checks the failures of
> the
> > > last
> > > 4 days (the last bug fix related with the full job was merged 4 days
> ago).
> > > These are the results:
> > >
> > > 123 failure (25% of the total)
> > >
> > > I took a sample of 50 failures and I obtained the following:
> > >
> > > 22% legitimate failures (they are due to the code change introduced by
> the
> > > patch)
> > > 22% infra issues
> > > 12% https://bugs.launchpad.net/openstack-ci/+bug/1291611
> > > 12% https://bugs.launchpad.net/tempest/+bug/1281969
> > > 8% https://bugs.launchpad.net/tempest/+bug/1294603
> > > 3% https://bugs.launchpad.net/neutron/+bug/1283522
> > > 3% https://bugs.launchpad.net/neutron/+bug/1291920
> > > 3% https://bugs.launchpad.net/nova/+bug/1290642
> > > 3% https://bugs.launchpad.net/tempest/+bug/1252971
> > > 3% https://bugs.launchpad.net/horizon/+bug/1257885
> > > 3% https://bugs.launchpad.net/tempest/+bug/1292242
> > > 3% https://bugs.launchpad.net/neutron/+bug/1277439
> > > 3% https://bugs.launchpad.net/neutron/+bug/1283599
> > >
> > > cheers,
> > >
> > > Rossella
> > >
> > > [1] http://logstash.openstack.org/#eyJzZWFyY2giOiJidWlsZF9uYW1lOi
> > > BcImNoZWNrLXRlbXBlc3QtZHN2bS1uZXV0cm9uLWZ1bGxcIiBBTkQgbWVzc2
> > > FnZTpcIkZpbmlzaGVkOiBGQUlMVVJFXCIgQU5EIHRhZ3M6Y29uc29sZSIsIm
> > > ZpZWxkcyI6W10sIm9mZnNldCI6MCwidGltZWZyYW1lIjoiY3VzdG9tIiwiZ3
> > > JhcGhtb2RlIjoiY291bnQiLCJ0aW1lIjp7ImZyb20iOiIyMDE0LTAzLTIwVD
> > > EzOjU0OjI1KzAwOjAwIiwidG8iOiIyMDE0LTAzLTI0VDEzOjU0OjI1KzAwOj
> > > AwIiwidXNlcl9pbnRlcnZhbCI6IjAifSwibW9kZSI6IiIsImFuYWx5emVfZm
> > > llbGQiOiIiLCJzdGFtcCI6MTM5NTY3MDY2ODc0OX0=
> > >
> > > _______________________________________________
> > > OpenStack-dev mailing list
> > > OpenStack-dev at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/06634df9/attachment-0001.html>

------------------------------

Message: 8
Date: Tue, 25 Mar 2014 04:30:55 -0400
From: Russell Bryant <rbryant at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Updates to Juno blueprint review
	process
Message-ID: <53313EBF.3070102 at redhat.com>
Content-Type: text/plain; charset=ISO-8859-1

On 03/25/2014 12:01 AM, Stefano Maffulli wrote:
> On 03/24/2014 09:20 AM, Russell Bryant wrote:
>> Another critical point of clarification ... we are *not* moving out of
>> blueprints at all.  We're still using them for tracking, just as before.
>>  We are *adding* the use of gerrit for reviewing the design.
> 
> That changes things, thank you for the clarification. If I understand
> correctly, pages like
> https://wiki.openstack.org/wiki/HowToContribute#Feature_development will
> still be valid at pointing at Launchpad Blueprints as the tool we use
> for the design, roadmap, tracking of progress. What changes is that for
> Nova all blueprints will have to have a URL added to the specifications,
> filed in a gerrit repository.

Correct.

> I can live with that, even though I personally think this is a horrible
> hack and a major tech debt we need to solve properly in the shortest
> amount of time.

I really don't see why this is so bad.  We're using a tool specifically
designed for reviewing things that is already working *really* well, not
just for code, but also for TC governance documents.

Unless Storyboard plans to re-implement what gerrit does (I sure hope it
doesn't), I expect we would keep working like this.  Do you expect
storyboard to have an interface for iterating on text documents, where
you can provide inline comments, review differences between revisions,
etc?  What am I missing?

-- 
Russell Bryant



------------------------------

Message: 9
Date: Tue, 25 Mar 2014 01:49:06 -0700
From: Maru Newby <marun at redhat.com>
To: David Kranz <dkranz at redhat.com>
Cc: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [openstack-qa] Graduation Requirements +
	Scope	of Tempest
Message-ID: <1AB56669-9304-4B97-B3CF-77567C58866B at redhat.com>
Content-Type: text/plain; charset=iso-8859-1


On Mar 21, 2014, at 9:01 AM, David Kranz <dkranz at redhat.com> wrote:

> On 03/20/2014 04:19 PM, Rochelle.RochelleGrober wrote:
>> 
>>> -----Original Message-----
>>> From: Malini Kamalambal [mailto:malini.kamalambal at RACKSPACE.COM]
>>> Sent: Thursday, March 20, 2014 12:13 PM
>>> 
>>> 'project specific functional testing' in the Marconi context is
>>> treating
>>> Marconi as a complete system, making Marconi API calls & verifying the
>>> response - just like an end user would, but without keystone. If one of
>>> these tests fail, it is because there is a bug in the Marconi code ,
>>> and
>>> not because its interaction with Keystone caused it to fail.
>>> 
>>> "That being said there are certain cases where having a project
>>> specific
>>> functional test makes sense. For example swift has a functional test
>>> job
>>> that
>>> starts swift in devstack. But, those things are normally handled on a
>>> per
>>> case
>>> basis. In general if the project is meant to be part of the larger
>>> OpenStack
>>> ecosystem then Tempest is the place to put functional testing. That way
>>> you know
>>> it works with all of the other components. The thing is in openstack
>>> what
>>> seems
>>> like a project isolated functional test almost always involves another
>>> project
>>> in real use cases. (for example keystone auth with api requests)
>>> 
>>> "



>>> 
>>> One of the concerns we heard in the review was 'having the functional
>>> tests elsewhere (I.e within the project itself) does not count and they
>>> have to be in Tempest'.
>>> This has made us as a team wonder if we should migrate all our
>>> functional
>>> tests to Tempest.
>>> But from Matt's response, I think it is reasonable to continue in our
>>> current path & have the functional tests in Marconi coexist  along with
>>> the tests in Tempest.
>>> 
>> I think that what is being asked, really is that the functional tests could be a single set of tests that would become a part of the tempest repository and that these tests would have an ENV variable as part of the configuration that would allow either "no Keystone" or "Keystone" or some such, if that is the only configuration issue that separates running the tests isolated vs. integrated.  The functional tests need to be as much as possible a single set of tests to reduce duplication and remove the likelihood of two sets getting out of sync with each other/development.  If they only run in the integrated environment, that's ok, but if you want to run them isolated to make debugging easier, then it should be a configuration option and a separate test job.
>> 
>> So, if my assumptions are correct, QA only requires functional tests for integrated runs, but if the project QAs/Devs want to run isolated for dev and devtest purposes, more power to them.  Just keep it a single set of functional tests and put them in the Tempest repository so that if a failure happens, anyone can find the test and do the debug work without digging into a separate project repository.
>> 
>> Hopefully, the tests as designed could easily take a new configuration directive and a short bit of work with OS QA will get the integrated FTs working as well as the isolated ones.
>> 
>> --Rocky
> This issue has been much debated. There are some active members of our community who believe that all the functional tests should live outside of tempest in the projects, albeit with the same idea that such tests could be run either as part of today's "real" tempest runs or mocked in various ways to allow component isolation or better performance. Maru Newby posted a patch with an example of one way to do this but I think it expired and I don't have a pointer.

I think the best place for functional api tests to be maintained is in the projects themselves.  The domain expertise required to write api tests is likely to be greater among project resources, and they should be tasked with writing api tests pre-merge.  The current 'merge-first, test-later' procedure of maintaining api tests in the Tempest repo makes that impossible.  Worse, the cost of developing functional api tests is higher in the integration environment that is the Tempest default.

The patch in question [1] proposes allowing pre-merge functional api test maintenance and test reuse in an integration environment.


m.

1: https://review.openstack.org/#/c/72585/

> IMO there are valid arguments on both sides, but I hope every one could agree that functional tests should not be arbitrarily split between projects and tempest as they are now. The Tempest README states a desire for "complete coverage of the OpenStack API" but Tempest is not close to that. We have been discussing and then ignoring this issue for some time but I think the recent action to say that Tempest will be used to determine if something can use the OpenStack trademark will force more completeness on tempest (more tests, that is). I think we need to resolve this issue but it won't be easy and modifying existing api tests to be more flexible will be a lot of work. But at least new projects could get on the right path sooner.



 - to say nothing of the increased effort required to develop functional tests in an integration envirequired to maintain tests in Tempest splinters their efforts unnecessarily.  I'm not suggesting that    


> 
> -David
> 




------------------------------

Message: 10
Date: Tue, 25 Mar 2014 02:05:22 -0700
From: Nikhil Manchanda <nikhil at manchanda.me>
To: "openstack-dev\@lists.openstack.org"
	<openstack-dev at lists.openstack.org>
Subject: [openstack-dev] [Trove] Meeting Wednesday, 26 March @ 1800
	UTC
Message-ID: <m138i6d4x9.fsf at gmail.com>
Content-Type: text/plain


Just a quick reminder for the weekly Trove meeting.
https://wiki.openstack.org/wiki/Meetings#Trove_.28DBaaS.29_meeting

Date/Time: Wednesday 26 March - 1800 UTC / 1100 PDT / 1300 CDT
IRC channel: #openstack-meeting-alt

Meeting Agenda (https://wiki.openstack.org/wiki/Meetings/TroveMeeting):

1. Data Store abstraction start/stop/status/control
https://blueprints.launchpad.net/trove/+spec/trove-guest-agent-datastore-control

2. Point in time recovery
https://wiki.openstack.org/wiki/Trove/PointInTimeRecovery

3. Data volume snapshot
https://wiki.openstack.org/wiki/Trove/volume-data-snapshot-design

Cheers,
Nikhil



------------------------------

Message: 11
Date: Tue, 25 Mar 2014 10:47:05 +0100
From: Thierry Carrez <thierry at openstack.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [depfreeze] Dependency freeze coming up
	(EOD Tuesday March 25)
Message-ID: <53315099.4090604 at openstack.org>
Content-Type: text/plain; charset=ISO-8859-1

Sergey Lukjanov wrote:
> RE Sahara, we'll need one more version bump to remove all backward
> compat code added for smooth transition. What's the deadline for doing
> it? Personally, I'd like to do it next week. Is it ok?

If you are only *removing* dependencies I think next week is fine :)

-- 
Thierry Carrez (ttx)



------------------------------

Message: 12
Date: Tue, 25 Mar 2014 10:00:15 +0100
From: Miguel Angel Ajo <majopela at redhat.com>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [neutron][rootwrap] Performance
	considerations, sudo?
Message-ID: <5331459F.5020003 at redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed



On 03/24/2014 07:23 PM, Yuriy Taraday wrote:
> On Mon, Mar 24, 2014 at 9:51 PM, Carl Baldwin <carl at ecbaldwin.net
> <mailto:carl at ecbaldwin.net>> wrote:
>
>     Don't discard the first number so quickly.
>
>     For example, say we use a timeout mechanism for the daemon running
>     inside namespaces to avoid using too much memory with a daemon in
>     every namespace.  That means we'll pay the startup cost repeatedly but
>     in a way that amortizes it down.
>
>     Even if it is really a one time cost, then if you collect enough
>     samples then the outlier won't have much affect on the mean anyway.
>
>
> It actually affects all numbers but mean (e.g. deviation is gross).


Carl is right, I thought of it later in the evening, when the timeout
mechanism is in place we must consider the number.

>
>     I'd say keep it in there.

+1 I agree.

>
>     Carl
>
>     On Mon, Mar 24, 2014 at 2:04 AM, Miguel Angel Ajo
>     <majopela at redhat.com <mailto:majopela at redhat.com>> wrote:
>      >
>      >
>      > It's the first call starting the daemon / loading config files, etc?,
>      >
>      > May be that first sample should be discarded from the mean for
>     all processes
>      > (it's an outlier value).
>
>
> I thought about cutting max from counting deviation and/or showing
> second-max value. But I don't think it matters much and there's not much
> people here who're analyzing deviation. It's pretty clear what happens
> with the longest run with this case and I think we can let it be as is.
> It's mean value that matters most here.

Yes, I agree, but as Carl said, having timeouts in place, in a practical
environment, the mean will be shifted too.

Timeouts are needed within namespaces, to avoid excessive memory
consumption. But it could be OK as we'd be cutting out the ip netns
delay.  Or , if we find a simpler "setns" mechanism enough for our
needs, may be we don't need to care about short-timeouts in ip netns
at all...


Best,
Miguel ?ngel.


>
> --
>
> Kind regards, Yuriy.
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



------------------------------

Message: 13
Date: Tue, 25 Mar 2014 13:55:11 +0400
From: Alexander Tivelkov <ativelkov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Separating our Murano PL core in own
	package
Message-ID:
	<CAM6FM9Q+nsHkPmOg9C4wmwwbQP-Waqm+pWBe7oPkDO37foLKzw at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

> I suggest to move all needed Powershell scripts and etc. to the main
repository 'murano' in the separate folder.

+1 on this. The scripts will not go inside the PyPi package, they will be
just grouped in a subfolder.

Completely agree on the repo-reorganization topic in general. However
> And I personally will do everything to prevent creation of new repo for
Murano.

Well, this may be unavoidable :)
We may face a need to create a "murano-contrib" repository where Murano
users will be able to contribute sources of their own murano packages,
improve the core library etc.
Given that we get rid of murano-conductor, murano-repository,
murano-metadataclient, murano-common, murano-tests and, probably,
murano-deployment, we are probably ok with having one more. Technically, we
may reuse murano-repository for this. But this can be discussed right
after there 0.5 release.


--
Regards,
Alexander Tivelkov


On Tue, Mar 25, 2014 at 12:09 PM, Timur Nurlygayanov <
tnurlygayanov at mirantis.com> wrote:

> Dmitry,
>
> I suggest to move all needed Powershell scripts and etc. to the main
> repository 'murano' in the separate folder.
>
>
> On Tue, Mar 25, 2014 at 11:38 AM, Dmitry Teselkin <dteselkin at mirantis.com>wrote:
>
>> Ruslan,
>>
>> What about murano-deployment repo? The most important part of it are
>> PowerSheel scripts, Windows Image Builder, package manifests, and some
>> other scripts that better to keep somewhere. Where do we plan to move them?
>>
>>
>> On Mon, Mar 24, 2014 at 10:29 PM, Ruslan Kamaldinov <
>> rkamaldinov at mirantis.com> wrote:
>>
>>> On Mon, Mar 24, 2014 at 10:08 PM, Joshua Harlow <harlowja at yahoo-inc.com>
>>> wrote:
>>> > Seeing that the following repos already exist, maybe there is some
>>> need for
>>> > cleanup?
>>> >
>>> > - https://github.com/stackforge/murano-agent
>>> > - https://github.com/stackforge/murano-api
>>> > - https://github.com/stackforge/murano-common
>>> > - https://github.com/stackforge/murano-conductor
>>> > - https://github.com/stackforge/murano-dashboard
>>> > - https://github.com/stackforge/murano-deployment
>>> > - https://github.com/stackforge/murano-docs
>>> > - https://github.com/stackforge/murano-metadataclient
>>> > - https://github.com/stackforge/murano-repository
>>> > - https://github.com/stackforge/murano-tests
>>> > ...(did I miss others?)
>>> >
>>> > Can we maybe not have more git repositories and instead figure out a
>>> way to
>>> > have 1 repository (perhaps with submodules?) ;-)
>>> >
>>> > It appears like murano is already exploding all over stackforge which
>>> makes
>>> > it hard to understand why yet another repo is needed. I understand why
>>> from
>>> > a code point of view, but it doesn't seem right from a code
>>> organization
>>> > point of view to continue adding repos. It seems like murano
>>> > (https://github.com/stackforge/murano) should just have 1 repo, with
>>> > sub-repos (tests, docs, api, agent...) for its own organizational usage
>>> > instead of X repos that expose others to murano's internal
>>> organizational
>>> > details.
>>> >
>>> > -Josh
>>>
>>>
>>> Joshua,
>>>
>>> I agree that this huge number of repositories is confusing for
>>> newcomers. I've
>>> spent some time to understand mission of each of these repos. That's why
>>> we
>>> already did the cleanup :) [0]
>>>
>>> And I personally will do everything to prevent creation of new repo for
>>> Murano.
>>>
>>> Here is the list of repositories targeted for the next Murano release
>>> (Apr 17):
>>> * murano-api
>>> * murano-agent
>>> * python-muranoclient
>>> * murano-dashboard
>>> * murano-docs
>>>
>>> The rest of these repos will be deprecated right after the release.
>>>  Also we
>>> will rename murano-api to just "murano". murano-api will include all the
>>> Murano services, functionaltests for Tempest, Devstack scripts,
>>> developer docs.
>>> I guess we already can update README files in deprecated repos to avoid
>>> further
>>> confusion.
>>>
>>> I wouldn't agree that there should be just one repo. Almost every
>>> OpenStack
>>> project has it's own repo for python client. All the user docs are kept
>>> in a
>>> separate repo. Guest agent code should live in it's own repository to
>>> keep
>>> number of dependencies as low as possible. I'd say there should be
>>> required/comfortable minimum of repositories per project.
>>>
>>>
>>> And one more nit correction:
>>> OpenStack has it's own git repository [1]. We shoul avoid referring to
>>> github
>>> since it's just a convinient mirror, while [1] is an official
>>> OpenStack repository.
>>>
>>> [0]
>>> https://blueprints.launchpad.net/murano/+spec/repository-reorganization
>>> [1] http://git.openstack.org/cgit/
>>>
>>>
>>>
>>> Thanks,
>>> Ruslan
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Thanks,
>> Dmitry Teselkin
>> Deployment Engineer
>> Mirantis
>> http://www.mirantis.com
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
>
> Timur,
> QA Engineer
> OpenStack Projects
> Mirantis Inc
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/e64a4843/attachment-0001.html>

------------------------------

Message: 14
Date: Tue, 25 Mar 2014 02:58:12 -0700
From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
Message-ID:
	<CAG_6_okJ=FeZEC7GSjkZvjaa2M=VTXibbpd1HiiYGzrUONrroA at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi Thomas,

I think we went to the second loop of the discussion about generic language
concepts.  Murano does not use a new language for the sole purpose of
having parameters, constraints and polymorphism. These are generic concepts
which are common for different languages, so keeping arguing about these
generic concepts is just like a holy war  like Python vs. C. Keeping these
arguments is just like to say that we don't need Python as functions and
parameters already exists in C which is used under the hood in Python.

Yes Murano DSL have some generic concepts similar to HOT. I think this is a
benefit as user will see the familiar syntax constructions and it will be a
lower threshold for him to start using Murano DSL.

In a simplified view Murano uses DSL for application definition to solve
several particular problems:
a) control UI rendering of Application Catalog
b) control HOT template generation

These aspects are not covered in HOT and probably should not be covered. I
don't like an idea of expressing HOT template generation in HOT as it
sounds like a creation another Lisp like language :-)

I don't think that your statement that most of the people in the community
are against new DSL is a right summary. There are some disagreements how it
should look like and what are the goals. You will be probably surprised but
we are not the first who use DSL for HOT templates generation. Here is an
e-mail thread right about Ruby based DSL used in IBM for the same purpose:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html

The term "Orchestration" is quite generic. Saying that orchestration should
be Heat job sounds like a well know Henry Ford's phrase "You can have any
colour as long as it's black.".
I think this is again a lack of understanding of the difference between
Orchestration program and Heat project. There are many aspects of
Orchestration and OpenStack has the Orchestration program for the projects
which are focused on some aspects of orchestration. Heat is one of the
project inside Orchestration program but it does not mean that Heat should
cover everything. That is why we discussed in this thread how workflows
aspects should be aligned and how they should be placed into this
Orchestration program.

Thanks
Georgy


On Mon, Mar 24, 2014 at 8:28 AM, Dmitry <meytin at gmail.com> wrote:

> MuranoPL supposed to provide a solution for the real needs to manage
> services in the centralized manner and to allow cloud provider customers to
> create their own services.
> The application catalog similar to AppDirect (www.appdirect.com) natively
> supported by OpenStack is a huge step forward.
> Think about Amazon which provides different services for the different
> needs: Amazon Cloud Formation, Amazon OpsWorks and Amazon Beanstalk.
> Following the similar logic (which is fully makes sense for me), OpenStack
> should provide resource reservation and orchestration (Heat and Climate),
> Application Catalog (Murano) and PaaS (Solum).
> Every project can live in harmony with other and contribute for the cloud
> service provider service completeness.
> This is my opinion and i would happy to use Murano in our internal
> solution.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284


On Mon, Mar 24, 2014 at 5:13 AM, Thomas Herve <thomas.herve at enovance.com>wrote:

> Hi Stan,
>
> Comments inline.
>
> > Zane,
> >
> > I appreciate your explanations on Heat/HOT. This really makes sense.
> > I didn't mean to say that MuranoPL is better for Heat. Actually HOT is
> good
> > for Heat's mission. I completely acknowledge it.
> > I've tried to avoid comparison between languages and I'm sorry if it felt
> > that way. This is not productive as I don't offer you to replace HOT with
> > MuranoPL (although I believe that certain elements of MuranoPL syntax
> can be
> > contributed to HOT and be valuable addition there). Also people tend to
> > protect what they have developed and invested into and to be fair this is
> > what we did in this thread to great extent.
> >
> > What I'm trying to achieve is that you and the rest of Heat team
> understand
> > why it was designed the way it is. I don't feel that Murano can become
> > full-fledged member of OpenStack ecosystem without a bless from Heat
> team.
> > And it would be even better if we agree on certain design, join our
> efforts
> > and contribute to each other for sake of Orchestration program.
>
> Note that I feel that most people outside of the Murano project are
> against the idea of using a DSL. You should feel that it could block the
> integration in OpenStack.
>
> > I'm sorry for long mail texts written in not-so-good English and
> appreciate
> > you patience reading and answering them.
> >
> > Having said that let me step backward and explain our design decisions.
> >
> > Cloud administrators are usually technical guys that are capable of
> learning
> > HOT and writing YAML templates. They know exact configuration of their
> cloud
> > (what services are available, what is the version of OpenStack cloud is
> > running) and generally understands how OpenStack works. They also know
> about
> > software they intent to install. If such guy wants to install Drupal he
> > knows exactly that he needs HOT template describing Fedora VM with
> Apache +
> > PHP + MySQL + Drupal itself. It is not a problem for him to write such
> HOT
> > template.
> >
> > Note that such template would be designed for very particular
> configuration.
> > There are hundreds of combinations that may be used to install that
> Drupal -
> > use RHEL/Windows/etc instead of Fedora, use ngnix/IIS/etc instead of
> Apache,
> > use FastCGI instead of mod_php, PostgreSQL instead of MySQL. You may
> choose
> > to have all software on single VM or have one VM for database and another
> > for Drupal. There are also constraints to those combinations. For example
> > you cannot have Fedora + IIS on the same VM. You cannot have Apache and
> > Drupal on different VMs.
> >
> > So the HOT template represent fixed combination of those software
> components.
> > HOT may have input parameters like "username" or "dbImageName" but the
> > overall structure of template is fixed. You cannot have template that
> choses
> > whether to use Windows or Linux based on parameter value. You cannot
> write
> > HOT that accepts number of instances it allowed to create and then decide
> > what would be installed on each of them. This is just not needed for Heat
> > users.
> >
> > With Murano the picture looks the opposite. Typical Murano user is a guy
> who
> > bought account from cloud hosting vendor (cloud operator) and want to run
> > some software in the cloud. He may not even be aware that it is
> OpenStack.
> > He knows nothing about programming in general and Heat in particular. He
> > doesn't want to write YAMLs. He may not know how exactly Drupal is
> installed
> > and what components it consists of.
>
> So that's where I want to make a first stop. If your primary user is not a
> developer, there is no reason to introduce a DSL for security reasons. The
> provider can trust the code he writes, and there is no need to create a
> dedicated language.
>
> > So what he does is he goes to his cloud (Murano) dashboard, browses
> through
> > application catalog, finds Drupal and drags it onto his environment board
> > (think like Visio-style designer). He can stop at this point, click
> "deploy"
> > button and the system will deploy Drupal. In another words the system (or
> > maybe better to say cloud operator or application developer) decides what
> > set of components is going to be installed (like 1 Fedora VM for MySQL
> and 1
> > CentOS VM for Apache-PHP-Drupal). But user may decide he wants to
> customize
> > his environment. He digs down and sees that Drupal requires database
> > instance and the default is MySQL. He clicks on a button to see what are
> > other options available for that role.
> >
> > In Heat HOT developer is the user. But in Murano those are completely
> > different roles. There are developers that write application definitions
> > (that is DSL code) and there are end users who compose environments from
> > those applications (components). Application developers may have nothing
> to
> > do with particular cloud their application deployed on. As for Drupal
> > application the developer knows that Drupal can be run with MySQL or
> > PostgreSQL. But there may be many compatible implementations of those
> DBMSes
> > - Galera MySQL, TroveMySQL, MMM MySQL etc. So to get a list of what
> > components can be placed in a database role Murano needs to look at all
> > applications in Application Catalog and find which of them are compatible
> > with MySQL and PostgreSQL so that user could choose what implementation
> is
> > better suits his needs (trade performance for high-availability etc.).
> >
> > User can go deeper and to decide that he wants that MySQL instance (this
> can
> > be 1 or more VMs depending on implementation) to be shared between Drupal
> > and another application in that environment (say WordPress). He can go
> even
> > deeper to VM level and decide that he wants to have WordPress, Drupal,
> > Apcache and slave MySQL node on one VM and MySQL master node on another.
> >
> > The ultimate goal is to create sort of construction kit for applications.
> > Cloud LEGO. And let users build environments of any complexity from small
> > components while providing reasonable default so that one-click
> deployment
> > would also be possible. And such system to be useful the design process
> need
> > to be guided and driven by UI. System must know what combination of
> > components are possible and what are not and not let user create
> Microsoft
> > IIS hosted on Fedora.
>
> Those goals are really nice and I'd like to have something like that in
> OpenStack.
>
> > This leads us to following design decisions:
> >
> > a. We need a DSL that would allow describing those small components
> > independently in such a way that the environment could be composed from
> > components written by different people that are not aware of each other
>
> You somewhat start by the end here. You haven't convinced us that you need
> a DSL.
>
> > b. Components need to have properties (parameters in Heat terms).
> Properties
> > may be of different types (strings, numbers, booleans etc.). There can be
> > constraints on property values ("not null", "length > 5").
>
> We have those constraints in Heat, they don't require imperative
> constructs.
>
> > c. Components may reference (require, make use of) other components
> (Drupal
> > uses MySQL, hosted on Apache etc). There can be constraints for those
> > references.
>
> Present in HOTs.
>
> > d. Constraints for both properties and references can be *very* complex
> and
> > indirect. Like "IIS can be deployed on any VM who's image is known to be
> > Windows with version >= WinServer2003". Or "my app requires 10 to 20
> Windows
> > instances that are all member of the same ActiveDirectory domain". Or "I
> > have 2 properties: minInstanceCount and maxInstanceCount and constraint
> > maxInstaceCount >= minInstanceCount". So we need a language to express
> > conditions of any complexity.
>
> We support pluggable constraints in Heat, that you can write in Python.
>
> > e. Both properties and references must be declared in a way that would
> make
> > possible for UI dashboard to discover their existence, ask user
> appropriate
> > input and validate the constraints on the fly.
>
> Possible as well.
>
> > f. Properties and especially references can have complex structure
> (lists,
> > maps, combination of them) rather than plain scalars. For example
> > ActiveDirectory consists of (e.g. references) *list* of domain
> controllers.
> > Constraints must respect that and be capable of validating things like
> > len(list) >= 2, all elements in list have some predicate true, there is
> at
> > least one element with desired set of properties etc.
>
> If not possible, HOT should be extended to support this.
>
> > g. Language need to have some sort mechanism to express polymorphism.
> E,g,
> > GaleraMySQL *is* MySQL (and thus can be used anywhere where "just MySQL"
> can
> > be). This also implies ability to have declare interfaces (class
> contracts)
> > and ability to implement those interface to that it would be possible
> that
> > two components are conform to the same interface.
>
> You don't need to have polymorphism for this. I'm mostly familiar with the
> mechanism used by Juju, where you *declare* an interface. It's basically
> metadata, and it's much simpler.
>
> > h. If we want components to be reusable and easy to write we need to have
> > ability to one component to inherit/extend another. Inheritance implies
> > ability to override and customize some methods
> >
> > i. We don't want to do deployment ourself. We don't intend to replace
> Heat,
> > Puppet etc. So we need a way to construct Heat templates that will do the
> > job. We need to map component's properties to
> > HOT parameters. This requires a language to express those bindings
> >
> > j. Because there can be lists of references (or properties) it should be
> > possible to express something like
> > for(domain_controller in self.controllers):
> > hot_template.insert(resources_for_particular_controller)
> >
> > or
> >
> > if self.deploy_on_windows:
> > generate_windows_hot_template()
> > else:
> > generate_linux_hot_template()
> >
> > or
> >
> > for i in range(self.instance_count):
> > hot_template.insert(generate_instance())
>
> CloudFormation recently added support for conditionals in templates. I'm
> not a super fan of it, but we could presumably have those in HOT as well.
>
> > k. Need to provide most simple method to compose stack from pre-made HOT
> > snippets and avoid dynamic generation when its not really needed
> >
> > l. Need to have some standard format to represent view of the world that
> is
> > what was designed in dashboard. In Murano it is JSON that describes
> object
> > graph with object property values and references to another objects.
> This is
> > somewhat similar to simple HOT template but with hierarchical structure
> >
> > I think at this point it becomes obvious that above describes
> object-oriented
> > Turing-complete language. And the most important property of that
> language
> > is that *everything* is declared in a way useful to be accessed from
> > dashboard/app catalog. You not often see
> properties/references/constraints
> > declared in dynamic language. I've answered several times already why
> this
> > language cannot be JavaScript or Lua. And this is just on the surface.
> There
> > are many things under the hood that makes MuranoPL stand out from all
> > embeddable languages I know and thats for a good reason.
> >
> > And I didn't even mentioned ALM aspects, orchestration, and many many
> other
> > things that go far beyond what can be expressed by HOT-style DSL
>
> Well orchestration should be Heat's job.
>
> What I can say is that I'm not convinced. The only use-case for a DSL
> would be if you have to upload user-written code, but what you mentioned is
> a Web interface, where the user doesn't use the DSL, and the cloud provider
> is the developer. There is no reason in this case to have a secure
> environment for the code.
>
> Cheers,
>
> --
> Thomas
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/7acf18eb/attachment-0001.html>

------------------------------

Message: 15
Date: Tue, 25 Mar 2014 11:25:07 +0100
From: Thierry Carrez <thierry at openstack.org>
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Nova] Updates to Juno blueprint review
	process
Message-ID: <53315983.5050702 at openstack.org>
Content-Type: text/plain; charset=ISO-8859-1

Russell Bryant wrote:
> On 03/24/2014 11:42 AM, Stefano Maffulli wrote:
>> At this point I'd like to get a fair assessment of storyboard's status
>> and timeline: it's clear that Launchpad blueprints need to be abandoned
>> lightspeed fast and I (and others) have been sold the idea that
>> Storyboard is a *thing* that will happen *soon*. I also was told that
>> spec reviews are an integral part of Storyboard use case scenarios, not
>> just defects.
> 
> Another critical point of clarification ... we are *not* moving out of
> blueprints at all.  We're still using them for tracking, just as before.
>  We are *adding* the use of gerrit for reviewing the design.

Yes, there is a clear misunderstanding here. There never was any kind of
spec review system in Launchpad. Launchpad tracks feature completion,
not design specs. It supported a link and behind that link was a set of
tools (wiki pages, etherpads, google docs) where the spec review would
hopefully happen.

This proposal is *just* about replacing all those "design documents"
with a clear change and using Gerrit to iterate and track approvals on it.

This is not "moving off Launchpad blueprints" nor is it "bypassing
StoryBoard". It's adding a bit of formal process around something that
randomly lived out of our tooling up to now.


About StoryBoard progress now:

People got very excited with the Django proof-of-concept because it
looked like it was almost ready to replace Launchpad. But I always made
clear this was just a proof-of-concept and it would take a *lot* of time
and effort to make it real. And my usual amount of free time would
probably not allow me to help that much.

It also took us more time than we expected to set up a basic team to
work on it (many thanks to HP and Mirantis for jumping on it with
significant resources), to align that team on clear goals, to rewrite
the main data server as an OpenStack-style API server, to write from
scratch a JavaScript webclient and get it properly tested at the gate, etc.

We now have the base infrastructure in place, we continuously deploy,
and the minimal viable product is almost completed. We expect the
infrastructure team to start dogfooding it in Juno and hopefully we'll
iterate faster next cycle... to make it a viable Launchpad alternative
for adventurous projects in the K cycle.

So it's not vaporware, it exists for real. But there is still a lot of
work needed on it to be generally usable, so it shouldn't be used as an
argument to stall everything else.

-- 
Thierry Carrez (ttx)



------------------------------

Message: 16
Date: Tue, 25 Mar 2014 11:27:11 +0100 (CET)
From: Thomas Herve <thomas.herve at enovance.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
Message-ID:
	<7628669.12365358.1395743231639.JavaMail.zimbra at enovance.com>
Content-Type: text/plain; charset=utf-8

 
>> What I can say is that I'm not convinced. The only use-case for a DSL would
>> be if you have to upload user-written code, but what you mentioned is a Web
>> interface, where the user doesn't use the DSL, and the cloud provider is the
>> developer. There is no reason in this case to have a secure environment for
>> the code.
> 
> I didn't say that. There are at least 2 different roles application
> developers/publishers and application users. Application developer is not
> necessary cloud provider. The whole point of AppCatalog is to support
> scenario when anyone can create and package some application and that
> package can be uploaded by user alone. Think Apple AppStore or Google Play.
> Some cloud providers may configure ACLs so that user be allowed to consume
> applications they decided while others may permit to upload applications to
> some configurable scope (e.g. apps that would be visible to all cloud users,
> to particular tenant or be private to the user). We also think to have some
> of peer relations so that it would be possible to have application upload in
> one catalog to become automatically available in all connected catalogs.
> 
> This is similar to how Linux software repos work - AppCatalog is repo, Murano
> package is what DEB/RPMs are to repo and DSL is what DEB/RPMs manifests are
> to packages. Just that is run on cloud and designed to handle complex
> multi-node apps as well as trivial ones in which case this may be narrowed
> to actual installation of DEB/RPM

I'm glad that you bring packages up. This is a really good example of why you don't need a new programming language. Packages uses whatever technology they prefer to handle their scripting needs. They then have an declarative interface which hides the imperative parts behind.

You trust OpenStack developers with their code, you trust package developers with their code, why not trust catalog developers?

-- 
Thomas



------------------------------

Message: 17
Date: Tue, 25 Mar 2014 06:28:35 -0400
From: Mark McLoughlin <markmc at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Multiple patches in one review
Message-ID: <1395743315.2374.6.camel at sorcha>
Content-Type: text/plain; charset="UTF-8"

On Mon, 2014-03-24 at 10:49 -0400, Russell Bryant wrote:
> Gerrit support for a patch series could certainly be better.

There has long been talking about gerrit getting "topic review"
functionality, whereby you could e.g. approve a whole series of patches
from a "topic view".

See:

  https://code.google.com/p/gerrit/issues/detail?id=51
  https://groups.google.com/d/msg/repo-discuss/5oRra_tLKMA/rxwU7pPAQE8J

My understanding is there's a fork of gerrit out there with this
functionality that some projects are using successfully.

Mark.





------------------------------

Message: 18
Date: Tue, 25 Mar 2014 11:32:04 +0100 (CET)
From: Thomas Herve <thomas.herve at enovance.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
Message-ID:
	<1394415352.12365864.1395743524381.JavaMail.zimbra at enovance.com>
Content-Type: text/plain; charset=utf-8


> Hi Thomas,
> 
> I think we went to the second loop of the discussion about generic language
> concepts. Murano does not use a new language for the sole purpose of having
> parameters, constraints and polymorphism. These are generic concepts which
> are common for different languages, so keeping arguing about these generic
> concepts is just like a holy war like Python vs. C. Keeping these arguments
> is just like to say that we don't need Python as functions and parameters
> already exists in C which is used under the hood in Python.
> 
> Yes Murano DSL have some generic concepts similar to HOT. I think this is a
> benefit as user will see the familiar syntax constructions and it will be a
> lower threshold for him to start using Murano DSL.
> 
> In a simplified view Murano uses DSL for application definition to solve
> several particular problems:
> a) control UI rendering of Application Catalog
> b) control HOT template generation
> 
> These aspects are not covered in HOT and probably should not be covered. I
> don't like an idea of expressing HOT template generation in HOT as it sounds
> like a creation another Lisp like language :-)

I'm not saying that HOT will cover all your needs. I think it will cover a really good portion. And I'm saying that for the remaining part, you can use an existing language and not create a new one.

> I don't think that your statement that most of the people in the community
> are against new DSL is a right summary. There are some disagreements how it
> should look like and what are the goals. You will be probably surprised but
> we are not the first who use DSL for HOT templates generation. Here is an
> e-mail thread right about Ruby based DSL used in IBM for the same purpose:
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html
> 
> The term "Orchestration" is quite generic. Saying that orchestration should
> be Heat job sounds like a well know Henry Ford's phrase "You can have any
> colour as long as it's black.".

That worked okay for him :).

> I think this is again a lack of understanding of the difference between
> Orchestration program and Heat project. There are many aspects of
> Orchestration and OpenStack has the Orchestration program for the projects
> which are focused on some aspects of orchestration. Heat is one of the
> project inside Orchestration program but it does not mean that Heat should
> cover everything. That is why we discussed in this thread how workflows
> aspects should be aligned and how they should be placed into this
> Orchestration program.

Well, today Heat is the one and only program in the Orchestration program. If and when you have orchestration needs not covered, we are there to make sure Heat is not the best place to handle them. The answer will probably not Heat forever, but we need good use cases to delegate those needs to another project.


-- 
Thomas



------------------------------

Message: 19
Date: Tue, 25 Mar 2014 06:36:19 -0400
From: Mark McLoughlin <markmc at redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] OpenStack vs. SQLA 0.9
Message-ID: <1395743779.2374.10.camel at sorcha>
Content-Type: text/plain; charset="UTF-8"

FYI, allowing 0.9 recently merged into openstack/requirements:

  https://review.openstack.org/79817

This is a good example of how we should be linking gerrit and mailing
list discussions together more. I don't think the gerrit review was
linked in this thread nor was the mailing list discussion linked in the
gerrit review.

Mark.

On Thu, 2014-03-13 at 22:45 -0700, Roman Podoliaka wrote:
> Hi all,
> 
> I think it's actually not that hard to fix the errors we have when
> using SQLAlchemy 0.9.x releases.
> 
> I uploaded two changes two Nova to fix unit tests:
> - https://review.openstack.org/#/c/80431/ (this one should also fix
> the Tempest test run error)
> - https://review.openstack.org/#/c/80432/
> 
> Thanks,
> Roman
> 
> On Thu, Mar 13, 2014 at 7:41 PM, Thomas Goirand <zigo at debian.org> wrote:
> > On 03/14/2014 02:06 AM, Sean Dague wrote:
> >> On 03/13/2014 12:31 PM, Thomas Goirand wrote:
> >>> On 03/12/2014 07:07 PM, Sean Dague wrote:
> >>>> Because of where we are in the freeze, I think this should wait until
> >>>> Juno opens to fix. Icehouse will only be compatible with SQLA 0.8, which
> >>>> I think is fine. I expect the rest of the issues can be addressed during
> >>>> Juno 1.
> >>>>
> >>>>     -Sean
> >>>
> >>> Sean,
> >>>
> >>> No, it's not fine for me. I'd like things to be fixed so we can move
> >>> forward. Debian Sid has SQLA 0.9, and Jessie (the next Debian stable)
> >>> will be released SQLA 0.9 and with Icehouse, not Juno.
> >>
> >> We're past freeze, and this requires deep changes in Nova DB to work. So
> >> it's not going to happen. Nova provably does not work with SQLA 0.9, as
> >> seen in Tempest tests.
> >>
> >>       -Sean
> >
> > I'd be nice if we considered more the fact that OpenStack, at some
> > point, gets deployed on top of distributions... :/
> >
> > Anyway, if we can't do it because of the freeze, then I will have to
> > carry the patch in the Debian package. Never the less, someone will have
> > to work and fix it. If you know how to help, it'd be very nice if you
> > proposed a patch, even if we don't accept it before Juno opens.
> >
> > Thomas Goirand (zigo)
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





------------------------------

Message: 20
Date: Tue, 25 Mar 2014 06:56:39 -0400
From: Sean Dague <sean at dague.net>
To: Mark McLoughlin <markmc at redhat.com>,  "OpenStack Development
	Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] OpenStack vs. SQLA 0.9
Message-ID: <533160E7.7020707 at dague.net>
Content-Type: text/plain; charset="utf-8"

In fairness, there were also copious IRC conversations on the topic as
well. I think because there were so few people in this thread, and all
those people were participating in the review and irc conversations,
updating the thread just fell off the list.

My bad. When conversations jump media it's some times hard to remember
that each one might have had different people watching passively.

On 03/25/2014 06:36 AM, Mark McLoughlin wrote:
> FYI, allowing 0.9 recently merged into openstack/requirements:
> 
>   https://review.openstack.org/79817
> 
> This is a good example of how we should be linking gerrit and mailing
> list discussions together more. I don't think the gerrit review was
> linked in this thread nor was the mailing list discussion linked in the
> gerrit review.
> 
> Mark.
> 
> On Thu, 2014-03-13 at 22:45 -0700, Roman Podoliaka wrote:
>> Hi all,
>>
>> I think it's actually not that hard to fix the errors we have when
>> using SQLAlchemy 0.9.x releases.
>>
>> I uploaded two changes two Nova to fix unit tests:
>> - https://review.openstack.org/#/c/80431/ (this one should also fix
>> the Tempest test run error)
>> - https://review.openstack.org/#/c/80432/
>>
>> Thanks,
>> Roman
>>
>> On Thu, Mar 13, 2014 at 7:41 PM, Thomas Goirand <zigo at debian.org> wrote:
>>> On 03/14/2014 02:06 AM, Sean Dague wrote:
>>>> On 03/13/2014 12:31 PM, Thomas Goirand wrote:
>>>>> On 03/12/2014 07:07 PM, Sean Dague wrote:
>>>>>> Because of where we are in the freeze, I think this should wait until
>>>>>> Juno opens to fix. Icehouse will only be compatible with SQLA 0.8, which
>>>>>> I think is fine. I expect the rest of the issues can be addressed during
>>>>>> Juno 1.
>>>>>>
>>>>>>     -Sean
>>>>>
>>>>> Sean,
>>>>>
>>>>> No, it's not fine for me. I'd like things to be fixed so we can move
>>>>> forward. Debian Sid has SQLA 0.9, and Jessie (the next Debian stable)
>>>>> will be released SQLA 0.9 and with Icehouse, not Juno.
>>>>
>>>> We're past freeze, and this requires deep changes in Nova DB to work. So
>>>> it's not going to happen. Nova provably does not work with SQLA 0.9, as
>>>> seen in Tempest tests.
>>>>
>>>>       -Sean
>>>
>>> I'd be nice if we considered more the fact that OpenStack, at some
>>> point, gets deployed on top of distributions... :/
>>>
>>> Anyway, if we can't do it because of the freeze, then I will have to
>>> carry the patch in the Debian package. Never the less, someone will have
>>> to work and fix it. If you know how to help, it'd be very nice if you
>>> proposed a patch, even if we don't accept it before Juno opens.
>>>
>>> Thomas Goirand (zigo)
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/b95c5148/attachment-0001.pgp>

------------------------------

Message: 21
Date: Tue, 25 Mar 2014 10:58:33 +0000
From: Mark McClain <mmcclain at yahoo-inc.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] Spec repos for blueprint development and
	review
Message-ID: <209FC3FE-152D-4331-BB90-885263D5D91F at yahoo-inc.com>
Content-Type: text/plain; charset="windows-1252"


On Mar 24, 2014, at 2:23 PM, Sean Dague <sean at dague.net<mailto:sean at dague.net>> wrote:

On 03/24/2014 02:05 PM, James E. Blair wrote:
Russell Bryant <rbryant at redhat.com<mailto:rbryant at redhat.com>> writes:

On 03/24/2014 12:34 PM, James E. Blair wrote:
Hi,

So recently we started this experiment with the compute and qa programs
to try using Gerrit to review blueprints.  Launchpad is deficient in
this area, and while we hope Storyboard will deal with it much better,
but it's not ready yet.

This seems to be a point of confusion.  My view is that Storyboard isn't
intended to implement what gerrit provides.  Given that, it seems like
we'd still be using this whether the tracker is launchpad or storyboard.

I don't think it's intended to implement what Gerrit provides, however,
I'm not sure what Gerrit provides is _exactly_ what's needed here.  I do
agree that Gerrit is a much better tool than launchpad for collaborating
on some kinds of blueprints.


Agreed, but the current blueprint system is broken in a way that a half step with an imperfect tool is better than keeping the status quo.

However, one of the reasons we're creating StoryBoard is so that we have
a tool that is compatible with our workflow and meets our requirements.
It's not just about tracking work items, it should be a tool for
creating, evaluating, and progressing changes to projects (stories),
across all stages.

I don't envision the end-state for storyboard to be that we end up
copying data back and forth between it and Gerrit.  Since we're
designing a system from scratch, we might as well design it to do what
we want.

One of our early decisions was to say that UX and code stories have
equally important use cases in StoryBoard.  Collaboration around UX
style blueprints (especially those with graphical mock-ups) sets a
fairly high bar for the kind of interaction we will support.

Gerrit is a great tool for reviewing code and other text media.  But
somehow it is even worse than launchpad for collaborating when visual
media are involved.  Quite a number of blueprints could benefit from
better support for that (not just UI mockups but network diagrams, etc).
We can learn a lot from the experiment of using Gerrit for blueprint
review, and I think it's going to help make StoryBoard a lot better for
all of our use cases.

Diagram handling was one of the first questions I asked Russell when I saw the repo creation proposal.  Diagrams are very helpful and while gerrit is not ideal for handling diagrams, Sphinx should allow us to incorporate them in basic way for now.  I view this as an improvement over the 5 different formats blueprints are submitted in now.


I think that's fine if long term this whole thing is optimized. I just
do very much worry that StoryBoard keeps going under progressive scope
creep before we've managed to ship the base case. That's a dangerous
situation to be in, as it means it's evolving without a feedback loop.

I'd much rather see Storyboard get us off launchpad ASAP across all the
projects, and then work on solving the things launchpad doesn't do.


+1000 I don?t want to see Storyboard changing scope to the point where it doesn?t adequately deliver because it is trying to solve too many problems in the first iteration.

mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/383e435b/attachment-0001.html>

------------------------------

Message: 22
Date: Tue, 25 Mar 2014 04:22:22 -0700
From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
Message-ID:
	<CAG_6_onbpuu0Rhu32DsGT=b3cuq885k_wDx16HkFOSn2Leiyww at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Mar 25, 2014 at 3:32 AM, Thomas Herve <thomas.herve at enovance.com>wrote:

>
> > Hi Thomas,
> >
> > I think we went to the second loop of the discussion about generic
> language
> > concepts. Murano does not use a new language for the sole purpose of
> having
> > parameters, constraints and polymorphism. These are generic concepts
> which
> > are common for different languages, so keeping arguing about these
> generic
> > concepts is just like a holy war like Python vs. C. Keeping these
> arguments
> > is just like to say that we don't need Python as functions and parameters
> > already exists in C which is used under the hood in Python.
> >
> > Yes Murano DSL have some generic concepts similar to HOT. I think this
> is a
> > benefit as user will see the familiar syntax constructions and it will
> be a
> > lower threshold for him to start using Murano DSL.
> >
> > In a simplified view Murano uses DSL for application definition to solve
> > several particular problems:
> > a) control UI rendering of Application Catalog
> > b) control HOT template generation
> >
> > These aspects are not covered in HOT and probably should not be covered.
> I
> > don't like an idea of expressing HOT template generation in HOT as it
> sounds
> > like a creation another Lisp like language :-)
>
> I'm not saying that HOT will cover all your needs. I think it will cover a
> really good portion. And I'm saying that for the remaining part, you can
> use an existing language and not create a new one.
>

As a user can't run arbitrary python code in openstack we used Python
language to create a new API for the remaining parts. This API service
accepts a yaml based description of what should be done. There is no
intention to create a new generic programming language. We used OpenStack
approach and created a service for specific functions around Application
Catalog features. Due to dynamic nature of applications we had to add a bit
of dynamics to the service input just because of the same reason why Heat
uses templates.



> > I don't think that your statement that most of the people in the
> community
> > are against new DSL is a right summary. There are some disagreements how
> it
> > should look like and what are the goals. You will be probably surprised
> but
> > we are not the first who use DSL for HOT templates generation. Here is an
> > e-mail thread right about Ruby based DSL used in IBM for the same
> purpose:
> >
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026606.html
> >
> > The term "Orchestration" is quite generic. Saying that orchestration
> should
> > be Heat job sounds like a well know Henry Ford's phrase "You can have any
> > colour as long as it's black.".
>
> That worked okay for him :).
>

Not really. The world acknowledged his inventions and new approaches. Other
manufacturers adopted his ideas and moved forward, providing more variety,
while Ford stuck with his model-T, which was very successful though. The
history shows that variety won the battle over single approach and now we
have different colors, shapes, engines :-)

>
> > I think this is again a lack of understanding of the difference between
> > Orchestration program and Heat project. There are many aspects of
> > Orchestration and OpenStack has the Orchestration program for the
> projects
> > which are focused on some aspects of orchestration. Heat is one of the
> > project inside Orchestration program but it does not mean that Heat
> should
> > cover everything. That is why we discussed in this thread how workflows
> > aspects should be aligned and how they should be placed into this
> > Orchestration program.
>
> Well, today Heat is the one and only program in the Orchestration program.
> If and when you have orchestration needs not covered, we are there to make
> sure Heat is not the best place to handle them. The answer will probably
> not Heat forever, but we need good use cases to delegate those needs to
> another project.
>
>
That is exactly the reason why we have these discussions :-) We have the
use cases for new functionality and we are trying to find a place for it.


>
> --
> Thomas
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/c0a55aa9/attachment-0001.html>

------------------------------

Message: 23
Date: Tue, 25 Mar 2014 15:31:45 +0400
From: Stan Lagun <slagun at mirantis.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Murano][Heat] MuranoPL questions?
Message-ID:
	<CAOCoZia2hw_EY9a0yag4WsMvCnxFP9qW5epLVH+jo4ta_wqFkg at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Tue, Mar 25, 2014 at 2:27 PM, Thomas Herve <thomas.herve at enovance.com>wrote:

>
> >> What I can say is that I'm not convinced. The only use-case for a DSL
> would
> >> be if you have to upload user-written code, but what you mentioned is a
> Web
> >> interface, where the user doesn't use the DSL, and the cloud provider
> is the
> >> developer. There is no reason in this case to have a secure environment
> for
> >> the code.
> >
> > I didn't say that. There are at least 2 different roles application
> > developers/publishers and application users. Application developer is not
> > necessary cloud provider. The whole point of AppCatalog is to support
> > scenario when anyone can create and package some application and that
> > package can be uploaded by user alone. Think Apple AppStore or Google
> Play.
> > Some cloud providers may configure ACLs so that user be allowed to
> consume
> > applications they decided while others may permit to upload applications
> to
> > some configurable scope (e.g. apps that would be visible to all cloud
> users,
> > to particular tenant or be private to the user). We also think to have
> some
> > of peer relations so that it would be possible to have application
> upload in
> > one catalog to become automatically available in all connected catalogs.
> >
> > This is similar to how Linux software repos work - AppCatalog is repo,
> Murano
> > package is what DEB/RPMs are to repo and DSL is what DEB/RPMs manifests
> are
> > to packages. Just that is run on cloud and designed to handle complex
> > multi-node apps as well as trivial ones in which case this may be
> narrowed
> > to actual installation of DEB/RPM
>
> I'm glad that you bring packages up. This is a really good example of why
> you don't need a new programming language. Packages uses whatever
> technology they prefer to handle their scripting needs. They then have an
> declarative interface which hides the imperative parts behind.
>
>
The same is true for Murano. MuranoPL is not used to express what should be
deployed. In Murano there is object model that describes view of the word.
It serves for the same purpose as HOT in Heat but it is simpler because it
says just what need to be deployed but not how it should be accomplished as
this information is already contained in application definitions. There is
REST API to edit/submit Object Model which is again has nothing to do with
MuranoPL. UI dashboard talks to AppCatalog to see what applications/classes
are available and AppCatalog also knows what are the properties of those
classes. This is needed for UI so that it can ask user for appropriate
input. This is similar to how Horizon asks user to input parameters that
are declared in HOT template. But all the imperative stuff is hidden inside
Murano packages and is not used for anything outside Murano engine.
MuranoPL is not a replacement for scripting languages. You still use
bash/puppet/PowerShell/whatever you like for actual deployment. No MuranoPL
code is executed on VM side. So the analogy with RPMs manifests is valid.




> You trust OpenStack developers with their code, you trust package
> developers with their code, why not trust catalog developers?
>

They do trust catalog developers (hopefully). But catalog developers have
nothing to do with catalog contents. Anyone can create and upload
application to App Catalog the same way how anyone can upload his
application to Google Play. The fact that I trust Google doesn't mean that
I trust all applications in Google Play. The fact that I trust catalog
developers doesn't mean that I (as a cloud operator) is going to allow
execution of untrusted code in that catalog. Unless that code is sandboxed
by design. Similar to that I can navigate to any web site google points me
out and let it execute any JavaScript it wants unless it it JavaScript and
not browser plugin or desktop application.



>
> --
> Thomas
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
slagun at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/2c78b503/attachment-0001.html>

------------------------------

Message: 24
Date: Tue, 25 Mar 2014 11:55:58 +0000
From: Malini Kamalambal <malini.kamalambal at RACKSPACE.COM>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [openstack-qa] Graduation Requirements +
	Scope of Tempest
Message-ID: <CF56E319.21AA6%malini.kamalambal at rackspace.com>
Content-Type: text/plain; charset="windows-1252"




We are talking about different levels of testing,

1. Unit tests - which everybody agrees should be in the individual project
itself
2. System Tests - 'System' referring to (& limited to), all the components
that make up the project. These are also the functional tests for the
project.
3. Integration Tests - This is to verify that the OS components interact
well and don't break other components -Keystone being the most obvious
example. This is where I see getting the maximum mileage out of Tempest.

"Its not easy to detect what the integration points with other projects are, any project can use any stable API from any other project. Because of this all OpenStack APIs should fit into this category. "

Any project can use any stable API ?but that does not make all API tests , Integration Tests.
A test becomes Integration test when it has two or more projects interacting in the test.

Individual projects should be held accountable to make sure that their API's work ? no matter who consumes them.
We should be able to treat the project as a complete system, make API calls and validate that the response matches the API definitions.
Identifying issues earlier in the pipeline reduces the Total Cost of Quality.

I agree that Integration Testing is hard. It is complicated because it requires knowledge of how systems interact with each other ? and knowledge comes from a lot of time spent on analysis.
It requires people with project expertise to talk to each other & identify possible test cases.
openstack-qa is the ideal forum to do this.
Holding projects responsible for their functionality will help the QA team focus on complicated integration tests.

"Having a second group writing tests to Nova's public APIs has been really helpful in keeping us honest as well."

Sounds like a testimonial for more project level testing :)


I see value in projects taking ownership of the System Tests - because if
the project is not 'functionally ready', it is not ready to integrate with
other components of Openstack.

"What do you mean by not ready?"

'Functionally Ready' - The units that make up a project can work together as a system,  all API's have been exercised with positive & negative test cases by treating the project as a complete system.
There are no known critical bugs. The point here being identify as many issues as possible, earlier in the game.

But for this approach to be successful, projects should have diversity in
the team composition - we need more testers who focus on creating these
tests.
This will keep the teams honest in their quality standards.

As long as individual projects cannot guarantee functional test coverage,
we will need more tests in Tempest.
But that will shift focus away from Integration Testing, which can be done
ONLY in Tempest.

Regardless of whatever we end up deciding, it will be good to have these
discussions sooner than later.
This will help at least the new projects to move in the right direction.

-Malini








_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/e5f8eee5/attachment-0001.html>

------------------------------

Message: 25
Date: Tue, 25 Mar 2014 07:59:26 -0400
From: Susanne Balle <sleipnir012 at gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
	<openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and
	"managed services"
Message-ID:
	<CADBYD+yrTeQWNboPsSxMBm1Yvh_2a7s8kfWG-my4hKvnPpo51Q at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

John, Brandon,

I agree that we cannot have a multitude of drivers doing the same thing or
close to because then we end-up in the same situation as we are today where
we have duplicate effort and technical debt.

The goal would be here to be able to built a framework around the drivers
that would allow for resiliency, failover, etc...

If the differentiators are in higher level APIs then we can have one a
single driver (in the best case) for each software LB e.g. HA proxy, nginx,
etc.

Thoughts?

Susanne


On Mon, Mar 24, 2014 at 11:26 PM, John Dewey <john at dewey.ws> wrote:

>  I have a similar concern.  The underlying driver may support different
> functionality, but the differentiators need exposed through the top level
> API.
>
> I see the SSL work is well underway, and I am in the process of defining
> L7 scripting requirements.  However, I will definitely need L7 scripting
> prior to the API being defined.
> Is this where vendor extensions come into play?  I kinda like the route
> the Ironic guy safe taking with a "vendor passthru" API.
>
> John
>
> On Monday, March 24, 2014 at 3:17 PM, Brandon Logan wrote:
>
>  Creating a separate driver for every new need brings up a concern I have
> had.  If we are to implement a separate driver for every need then the
> permutations are endless and may cause a lot drivers and technical debt.
>  If someone wants an ha-haproxy driver then great.  What if they want it to
> be scalable and/or HA, is there supposed to be scalable-ha-haproxy,
> scalable-haproxy, and ha-haproxy drivers?  Then what if instead of doing
> spinning up processes on the host machine we want a nova VM or a container
> to house it?  As you can see the permutations will begin to grow
> exponentially.  I'm not sure there is an easy answer for this.  Maybe I'm
> worrying too much about it because hopefully most cloud operators will use
> the same driver that addresses those basic needs, but worst case scenarios
> we have a ton of drivers that do a lot of similar things but are just
> different enough to warrant a separate driver.
>  ------------------------------
> *From:* Susanne Balle [sleipnir012 at gmail.com]
> *Sent:* Monday, March 24, 2014 4:59 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] Neutron LBaaS, Libra and
> "managed services"
>
>   Eugene,
>
>  Thanks for your comments,
>
>  See inline:
>
>  Susanne
>
>
>  On Mon, Mar 24, 2014 at 4:01 PM, Eugene Nikanorov <
> enikanorov at mirantis.com> wrote:
>
> Hi Susanne,
>
>  a couple of comments inline:
>
>
>
>
> We would like to discuss adding the concept of "managed services" to the
> Neutron LBaaS either directly or via a Neutron LBaaS plug-in to Libra/HA
> proxy. The latter could be a second approach for some of the software
> load-balancers e.g. HA proxy since I am not sure that it makes sense to
> deploy Libra within Devstack on a single VM.
>
>
>
> Currently users would have to deal with HA, resiliency, monitoring and
> managing their load-balancers themselves.  As a service provider we are
> taking a more managed service approach allowing our customers to consider
> the LB as a black box and the service manages the resiliency, HA,
> monitoring, etc. for them.
>
>
>
>   As far as I understand these two abstracts, you're talking about making
> LBaaS API more high-level than it is right now.
> I think that was not on our roadmap because another project (Heat) is
> taking care of more abstracted service.
> The LBaaS goal is to provide vendor-agnostic management of load balancing
> capabilities and quite fine-grained level.
> Any higher level APIs/tools can be built on top of that, but are out of
> LBaaS scope.
>
>
>  [Susanne] Yes. Libra currently has some internal APIs that get triggered
> when an action needs to happen. We would like similar functionality in
> Neutron LBaaS so the user doesn't have to manage the load-balancers but can
> consider them as black-boxes. Would it make sense to maybe consider
> integrating Neutron LBaaS with heat to support some of these use cases?
>
>
>
>
> We like where Neutron LBaaS is going with regards to L7 policies and SSL
> termination support which Libra is not currently supporting and want to
> take advantage of the best in each project.
>
> We have a draft on how we could make Neutron LBaaS take advantage of Libra
> in the back-end.
>
> The details are available at:
> https://wiki.openstack.org/wiki/Neutron/LBaaS/LBaaS%2Band%2BLibra%2Bintegration%2BDraft
>
>
>  I looked at the proposal briefly, it makes sense to me. Also it seems to
> be the simplest way of integrating LBaaS and Libra - create a Libra driver
> for LBaaS.
>
>
>  [Susanne] Yes that would be the short team solution to get us where we
> need to be. But We do not want to continue to enhance Libra. We would like
> move to Neutron LBaaS and not have duplicate efforts.
>
>
>
>
>  While this would allow us to fill a gap short term we would like to
> discuss the longer term strategy since we believe that everybody would
> benefit from having such "managed services" artifacts built directly into
> Neutron LBaaS.
>
> I'm not sure about building it directly into LBaaS, although we can
> discuss it.
>
>
>  [Susanne] The idea behind the "managed services" aspect/extensions would
> be reusable for other software LB.
>
>
>   For instance, HA is definitely on roadmap and everybody seems to agree
> that HA should not require user/tenant to do any specific configuration
> other than choosing HA capability of LBaaS service. So as far as I see it,
> requirements for HA in LBaaS look very similar to requirements for HA in
> Libra.
>
>
>  [Susanne] Yes. Libra works well for us in the public cloud but we would
> like to move to Neutron LBaaS and not have duplicate efforts: Libra and
> Neutron LBaaS. We were hoping to be able to take the best of Libra and add
> it to Neutron LBaaS and help shape Neutron LBaaS to fit a wider spectrum of
> customers/users.
>
>
>
> There are blueprints on high-availability for the HA proxy software
> load-balancer and we would like to suggest implementations that fit our
> needs as services providers.
>
>
>
> One example where the managed service approach for the HA proxy load
> balancer is different from the current Neutron LBaaS roadmap is around HA
> and resiliency. The 2 LB HA setup proposed (
> https://blueprints.launchpad.net/neutron/+spec/lbaas-ha-haproxy) isn't
> appropriate for service providers in that users would have to pay for the
> extra load-balancer even though it is not being actively used.
>
> One important idea of the HA is that its implementation is
> vendor-specific, so each vendor or cloud provider can implement it in the
> way that suits their needs. So I don't see why particular HA solution for
> haproxy should be considered as a common among other vendors/providers.
>
>
>  [Susanne] Are you saying that we should create a driver that would be a
> peer to the current loadbalancer/ ha-proxy driver? So for example
>  loadbalancer/managed-ha-proxy (please don't get hung-up on the name I
> picked) would be a driver we would implement to get our interaction with a
> pool of stand-by load-and preconfigured load balancers instead of the 2 LB
> HA servers? And it would be part of the Neutron LBaaS branch?
>
>
>
> I am assuming that blueprints need to be approved before the feature is
> accepted into a release. Then the feature is implemented and accepted by
> the core members into the main repo. What the process would we have to
> follow if we wanted to get such a driver into Neutron LBaaS? It is hard to
> imagine that even thought it would be a "vendor-specific ha-proxy" driver
> that people in the Neutron LBaaS team wouldn't want to have a say around
> how it is architected.
>
>
>  An alternative approach is to implement resiliency using a pool of
> stand-by load-and preconfigured load balancers own by e.g. LBaaS tenant and
> assign load-balancers from the pool to tenants environments. We currently
> are using this approach in the public cloud with Libra and it takes
> approximately 80 seconds for the service to decide that a load-balancer has
> failed, swap the floating ip and update the db, etc. and have a new LB
> running.
>
>
>
>   That for sure can be implemented. I only would recommend to implement
> such kind of management system out of Neutron/LBaaS tree, e.g. to only have
> client within Libra driver that will communicate with the management
> backend.
>
>
>  [Susanne] Again this would only be a short term solution since as we
> move forward and want to contribute new features it would result in
> duplication of efforts because the features might need to be done in Libra
> and not Neutron LBaaS.
>
>  In the longer term I would like to discuss how we make Neutron LBaaS
> have features that are a little friendlier towards service providers' use
> cases. It is very important to us that services like the LBaaS service is
> viewed as a managed service e.g. black-box to our customers.
>
>
>
>  Thanks,
> Eugene.
>
>
>
> Regards Susanne
>
> -------------------------------------------
>
> Susanne M. Balle
> Hewlett-Packard
> HP Cloud Services
>
> Please consider the environment before printing this email.
>
>
>
>  _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>    _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140325/276aeacd/attachment-0001.html>

------------------------------

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


End of OpenStack-dev Digest, Vol 23, Issue 88
*********************************************



More information about the OpenStack-dev mailing list