[openstack-dev] OpenStack-dev Digest, Vol 37, Issue 45
Ajay Sharma
ajespoo at gmail.com
Wed May 20 11:03:55 UTC 2015
How do I upload the inventory file from the cash register to the web portal
* e-coomerce* , for eg a common grocery owner wish to upload its product
with price on the web portal. any help would be highly appreciated.
Best Regards
Ajay Sharma
On Wed, May 20, 2015 at 8:12 AM, <openstack-dev-request at lists.openstack.org>
wrote:
> 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: [fuel] Enable healthcheck middleware (Swann Croiset)
> 2. Re: [oslo] needed, driver for oslo.db thursday session
> (Roman Podoliaka)
> 3. Re: [Fuel] python-fuelclient 6.1.0 is released (Oleg Gelbukh)
> 4. [glance] missing implementation on glance basic quota (Gareth)
> 5. Re: [oslo] needed, driver for oslo.db thursday session
> (Mike Bayer)
> 6. [nova] libvirt: _do_quality_warnings and the hypervisor
> support matrix (Markus Zoeller)
> 7. Re: [Manila] Question to driver maintainers (Csaba Henk)
> 8. Re: missing implementation on glance basic quota (Nikhil Komawar)
> 9. Re: [nova] libvirt: _do_quality_warnings and the hypervisor
> support matrix (Daniel P. Berrange)
> 10. [Security][Glance] Design session for image
> signing/encryption (Clark, Robert Graham)
> 11. Re: [Security][Glance] Design session for image
> signing/encryption (Louis Taylor)
> 12. Re: [nova] libvirt: _do_quality_warnings and the hypervisor
> support matrix (Markus Zoeller)
> 13. Re: [oslo] needed, driver for oslo.db thursday session
> (Davanum Srinivas)
> 14. Re: [oslo] needed, driver for oslo.db thursday session
> (Davanum Srinivas)
> 15. [nova][glance] Format of 'locations' data in image metadata ?
> (Daniel P. Berrange)
> 16. Re: [oslo] needed, driver for oslo.db thursday session
> (Jeremy Stanley)
> 17. Re: [Glance] glance social event at Vancouver summit
> (Alexander Tivelkov)
> 18. Re: [nova][glance] Format of 'locations' data in image
> metadata ? (Nikhil Komawar)
> 19. Re: [nova-docker] Status update (ADAMS, STEVEN E)
> 20. Re: [nova-docker] Status update (Davanum Srinivas)
> 21. Re: [Manila] Question to driver maintainers (Ben Swartzlander)
> 22. [NFV][Tacker] OpenStack based VNF Manager (Sridhar Ramaswamy)
> 23. Re: [Fuel][Plugin] Contributor license agreement for fuel
> plugin code? (Andrew Woodward)
> 24. Re: [Fuel] Speed Up RabbitMQ Recovering (Andrew Woodward)
> 25. Re: [surge] Introducing Surge - rapid deploy/scale stream
> processing systems on OpenStack (Sergey Lukjanov)
> 26. Re: [new][cognitive] Announcing Cognitive - a project to
> deliver Machine Learning as a Service for OpenStack (Sergey Lukjanov)
> 27. Re: [surge] Introducing Surge - rapid deploy/scale stream
> processing systems on OpenStack (Sergey Lukjanov)
> 28. Re: [glance] missing implementation on glance basic quota
> (Fei Long Wang)
> 29. [nova] Tempest failure help (Sam Morrison)
> 30. [sahara] no meetings May 21 and 28 (Sergey Lukjanov)
> 31. [security] / IDS + openstack meeting in Vancouver 4:10
> Wednesday May 20 (Dan Lambright)
> 32. Re: [all] gate pep8 jobs broken today (Victor Stinner)
> 33. Re: / IDS + openstack meeting in Vancouver 4:10 Wednesday May
> 20 (Alan Kavanagh)
> 34. Re: [nova][glance] Format of 'locations' data in image
> metadata ? (Flavio Percoco)
> 35. Re: [security] / IDS + openstack meeting in Vancouver 4:10
> Wednesday May 20 (Clark, Robert Graham)
> 36. Re: [all] gate pep8 jobs broken today (Robert Collins)
> 37. Re: [nova] Tempest failure help (Matt Riedemann)
> 38. [nova] Friday summit meetup etherpad (Matt Riedemann)
> 39. Re: [all] gate pep8 jobs broken today (Robert Collins)
> 40. [pbr] 1.0.1 released (Robert Collins)
> 41. [barbican] Nominating Kaitlin Farr for barbican-core
> (Douglas Mendiz?bal)
> 42. [security] Nominating Mike McCune as Security-Doc Core
> (Dillon, Nathaniel)
> 43. Re: [Fuel] Speed Up RabbitMQ Recovering (Andrew Beekhof)
> 44. Re: [neutron] How should edge services APIs integrate into
> Neutron? (A, Keshava)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 19 May 2015 14:28:10 +0200
> From: Swann Croiset <scroiset at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [fuel] Enable healthcheck middleware
> Message-ID:
> <CAOmgvhz8BT2ayfCFxsw96Kv749ML2-7uoBYJqY8GRQg=
> a1vAEg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for your feedback.
> I probably start next week and provide links here.
>
> On Wed, May 13, 2015 at 10:40 PM, Andrew Woodward <xarses at gmail.com>
> wrote:
>
> > Sounds good, lets ensure that we create a blue-print in LP and some form
> > of initial spec with the expected design
> >
> >
> > On Wed, May 13, 2015 at 9:38 AM Jay Pipes <jaypipes at gmail.com> wrote:
> >
> >> ++
> >>
> >> On 05/13/2015 11:57 AM, Swann Croiset wrote:
> >> > Hi Fuelers,
> >> >
> >> > It would be valuable to configure the healthcheck middleware [0] for
> all
> >> > services deployed by fuel, available since Kilo.
> >> >
> >> > Several (obvious) benefits:
> >> > - Provide a common API for healthcheck across OpenStack services
> >> > - HAproxy performs more accurate HTTP checks for its backend status
> >> > - Operators can disable a service (maintenance mode, test, ..) by
> >> > creating a simple file w/o stopping the service.
> >> > - monitoring systems can leverage this API to provide insight
> >> > information of service status with a lighten checks w/o authentication
> >> > (in opposition to heavily check for specific resources) <-- here my
> use
> >> > case
> >> >
> >> > Does it sound reasonable to target this for 7.0? any clue? drawback?
> >> > I can handle the writing of the spec to bootstrap this effort and
> maybe
> >> > more.
> >> >
> >> > Implementation details to estimate the workload:
> >> > * Configure WSGI pipelines for each project "api-paste.ini"
> >> > * For security reason as mentioned in the original spec [1], the
> >> > 'healthcheck' URI mustn't be open to the WWW:
> >> > * restricted access to local/management network or by auth
> >> > * or random/configurable URI at deployment time
> >> > * HAproxy "httpchk" option will be "GET /<healthcheck path>" instead
> of
> >> > the default "OPTION /"
> >> >
> >> > Parallel (future) work on oslo or whatever:
> >> > * extend with specific checks (DB unavailable, RabbitMQ stuck, ..) to
> >> > provide a detailed status of subsystem dependencies.
> >> >
> >> > [0]
> >> >
> >>
> http://docs.openstack.org/developer/oslo.middleware/healthcheck_plugins.html
> >> > [1]
> >> >
> >>
> http://git.openstack.org/cgit/openstack/oslo-specs/plain/specs/kilo/oslo-middleware-healthcheck.rst
> >> >
> >> >
> >> >
> >>
> __________________________________________________________________________
> >> > OpenStack Development Mailing List (not for usage questions)
> >> > Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >> >
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/85a20ad4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 19 May 2015 16:08:57 +0300
> From: Roman Podoliaka <rpodolyaka at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
> thursday session
> Message-ID:
> <CAKA_ueAPNx9yTbU73Hq_JaqvBW8kU2VC9Tm68RYozAxY=
> CoYRg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi all,
>
> Just FYI, due to problems with obtaining a Canadian visa, neither
> Victor Sergeyev, nor I made it to Vancouver.
>
> I hope someone else from Oslo team can replace Mike as a session driver.
>
> Thanks,
> Roman
>
> On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <mbayer at redhat.com> wrote:
> > Hello -
> >
> > It is my extreme displeasure and frustration to announce that due to an
> > incredibly unfortunate choice of airline, I had to cancel my entire trip
> to
> > the Openstack summit after spending 26 hours in my home airport waiting
> for
> > my airline to produce a working airplane (which they did not).
> >
> > I will not be able to attend in person the Thursday oslo.db session I
> was to
> > drive, so a replacement will be needed. I am also lamenting not being
> able
> > to meet so many of you who I hoped very much to meet.
> >
> > Hope you all enjoy the summit and I hope our paths can cross at future
> > events.
> >
> > - mike
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 19 May 2015 17:01:49 +0300
> From: Oleg Gelbukh <ogelbukh at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] python-fuelclient 6.1.0 is
> released
> Message-ID:
> <
> CAFkLEwr1U_1V7p7Uu8yUzbGGf0jkzuzMKKK5QNqeEOoqCGYSJw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Roman,
>
> This is awesome news! Thank you for this huge improvement for developers
> who consume Fuel API.
>
> Could you please elaborate on backwards compatibility between the new
> client and older versions of Fuel API? For example, is it possible to use
> the new client to work with Fuel 4.x? 5.x?
>
> --
> Best regards,
> Oleg Gelbukh
>
> On Fri, May 15, 2015 at 5:39 PM, Roman Prykhodchenko <me at romcheg.me>
> wrote:
>
> > Hi folks!
> >
> > I?m glad to announce that the first independent release of Fuel Client
> was
> > published to PyPi: https://pypi.python.org/pypi/python-fuelclient
> > You can either download it from the web page or install with pip install
> > python-fuelclient.
> >
> > What?s new:
> >
> > - Fuel client is now able to run most of it?s features remotely from
> > Fuel?s master node.
> > - Old CLI was deprecated, new fuel2 utility is a preview of the new Fuel
> > client which will be available in the next major release
> > - Versioning scheme of the Fuel Client is not tightly bound to Fuel?s
> > version scheme anymore.
> > - Other improvements and bug-fixes
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/8b7590c7/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 19 May 2015 22:10:53 +0800
> From: Gareth <academicgareth at gmail.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [glance] missing implementation on glance
> basic quota
> Message-ID:
> <
> CAAhuP_9SYvzjzZZoA-Ki9MgmZuW7XSUs0u2i-Ue2_hcXNhANZw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi glance guys
>
> There is a bp[0] said it would implement two basic quota usage:
>
> a, the number of image stored
> b, the amount of storage in occupied by a set of image
>
> However, only b is implemented in the patch[1], and a is still missing in
> current glance.
>
> [0] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas
> [1] https://review.openstack.org/#/c/37993/18
>
> --
> Gareth
>
> *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
> *OpenStack contributor, kun_huang at freenode*
> *My promise: if you find any spelling or grammar mistakes in my email from
> Mar 1 2013, notify me *
> *and I'll donate $1 or ?1 to an open organization you specify.*
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/35eaae6f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 19 May 2015 10:24:56 -0400
> From: Mike Bayer <mbayer at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
> thursday session
> Message-ID: <555B47B8.5070608 at redhat.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> ouch !
>
>
> maybe next summit will be on the "Lost" island. another easy place to
> get to ! :)
>
>
>
>
> On 5/19/15 9:08 AM, Roman Podoliaka wrote:
> > Hi all,
> >
> > Just FYI, due to problems with obtaining a Canadian visa, neither
> > Victor Sergeyev, nor I made it to Vancouver.
> >
> > I hope someone else from Oslo team can replace Mike as a session driver.
> >
> > Thanks,
> > Roman
> >
> > On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <mbayer at redhat.com> wrote:
> >> Hello -
> >>
> >> It is my extreme displeasure and frustration to announce that due to an
> >> incredibly unfortunate choice of airline, I had to cancel my entire
> trip to
> >> the Openstack summit after spending 26 hours in my home airport waiting
> for
> >> my airline to produce a working airplane (which they did not).
> >>
> >> I will not be able to attend in person the Thursday oslo.db session I
> was to
> >> drive, so a replacement will be needed. I am also lamenting not being
> able
> >> to meet so many of you who I hoped very much to meet.
> >>
> >> Hope you all enjoy the summit and I hope our paths can cross at future
> >> events.
> >>
> >> - mike
> >>
> >>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 19 May 2015 16:41:40 +0200
> From: Markus Zoeller <mzoeller at de.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova] libvirt: _do_quality_warnings and the
> hypervisor support matrix
> Message-ID:
> <
> OFB7028464.2C12B897-ONC1257E4A.00506B48-C1257E4A.0050B850 at de.ibm.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> The libvirt driver logs a warning if:
> hostarch not in (arch.I686, arch.X86_64))
> The warning when I start the libvirt driver on system z (arch.S390X)
> will be:
> "The libvirt driver is not tested on kvm/s390x by the OpenStack
> project and thus its quality can not be ensured. For more
> information, see:
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
>
> I'm not quite sure if I understand that correctly. Should this be a
> hint that "arch.I686, arch.X86_64" is the assumed "default"?
> Or am I supposed to add the architecture "S390X" to this method because
> this platform is listed in the hypervisor support matrix?
> I want to avoid that customers will get a bad feeling because of the
> warning after starting the nova libvirt driver on a system z platform.
>
> Note: We are still working on the CI for nova
>
> Regards,
> Markus Zoeller (markus_z)
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Tue, 19 May 2015 10:42:57 -0400 (EDT)
> From: Csaba Henk <chenk at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
> Message-ID:
> <1601921203.2012587.1432046577765.JavaMail.zimbra at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Igor,
>
> > From: "Igor Malinovskiy" <imalinovskiy at mirantis.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Sent: Monday, May 18, 2015 10:15:25 AM
> > Subject: [openstack-dev] [Manila] Question to driver maintainers
> ...
> > So I want to ask driver maintainers here:
> > Will your driver be able to do share extending without loss of
> connectivity?
>
> Currenty:
>
> - glusterfs driver can
> - glusterfs-native won't support share extension (*)
>
> in Liberty timeframe, we are to unify the glusterfs* drivers' backend
> management logic, so both glusterfs driver style and glusterfs-native
> driver style backend management will be available for both drivers
> (actual choice made in configuration). So when this will be in place,
> the answer modifies as follows:
>
> - glusterfs and glusterfs-native will either support non-disruptive
> share extension, or won't support share resize at all (*) (depending
> on configuration)
>
> (*) There are efforts to remove this limitation in GlusterFS, but too
> vague at this point to make a statement on it.
>
> Csaba
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Tue, 19 May 2015 10:50:57 -0400
> From: Nikhil Komawar <nik.komawar at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] missing implementation on glance basic
> quota
> Message-ID: <555B4DD1.1030405 at gmail.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Hi,
>
> The implementer has indicated using a note on the BP that they are going
> with only the initial implementation of quota for storage of bytes and
> not the number of images. It seems like this should be sufficient.
> However, if you feel like we should implement quota for "the number of
> images" (also the use case would be slightly different "for number of
> images stored"), we would be willing to hear more on a Glance spec (
> https://github.com/openstack/glance-specs ). Please file one under the
> liberty folder and I encourage you to attend one of the Glance weekly
> meetings to bring this up and show interest if you (or anyone you know)
> wish(es) to implement it.
>
> Thanks,
> Nikhil
>
> On 5/19/15 3:14 AM, Gareth wrote:
> > Hi glance guys
> >
> > There is a bp[0] said it would implement two basic quota usage:
> >
> > a, the number of image stored
> > b, the amount of storage in occupied by a set of image
> >
> > However, only b is implemented in the patch[1], and a is still missing
> > in current glance.
> >
> > [0] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas
> > [1] https://review.openstack.org/#/c/37993/18
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/268751a8/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Tue, 19 May 2015 15:56:17 +0100
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] libvirt: _do_quality_warnings and
> the hypervisor support matrix
> Message-ID: <20150519145617.GC8535 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> On Tue, May 19, 2015 at 04:41:40PM +0200, Markus Zoeller wrote:
> > The libvirt driver logs a warning if:
> > hostarch not in (arch.I686, arch.X86_64))
> > The warning when I start the libvirt driver on system z (arch.S390X)
> > will be:
> > "The libvirt driver is not tested on kvm/s390x by the OpenStack
> > project and thus its quality can not be ensured. For more
> > information, see:
> > https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
> >
> > I'm not quite sure if I understand that correctly. Should this be a
> > hint that "arch.I686, arch.X86_64" is the assumed "default"?
> > Or am I supposed to add the architecture "S390X" to this method because
> > this platform is listed in the hypervisor support matrix?
> > I want to avoid that customers will get a bad feeling because of the
> > warning after starting the nova libvirt driver on a system z platform.
> >
> > Note: We are still working on the CI for nova
>
> In the wiki page we describe 3 groups of drives, those with CI run
> by the OpenStack project (Group A), those with CI run by 3rd party
> vendors (Group B) and those with no CI at all (Group C)
>
>
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status
>
> The _do_quality_warnings method is intended to print a warning for
> any libvirt driver combination that is in Group C.
>
> After S390(x) has a 3rd party CI system running regularly & reasonably
> reliably, then you can submit a change to add S390X to the architecture
> list in _do_quality_warnings.
>
> Regards,
> Daniel
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org -o- http://virt-manager.org
> :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc
> :|
>
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 19 May 2015 15:01:39 +0000
> From: "Clark, Robert Graham" <robert.clark at hp.com>
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Security][Glance] Design session for image
> signing/encryption
> Message-ID: <D1809E63.1CD42%robert.clark at hp.com>
> Content-Type: text/plain; charset="us-ascii"
>
> All,
>
> Is there a session to discuss the image security proposal?
> https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst
>
> Cheers
> -Rob
>
>
>
> ------------------------------
>
> Message: 11
> Date: Tue, 19 May 2015 16:13:34 +0100
> From: Louis Taylor <louis at kragniz.eu>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Security][Glance] Design session for
> image signing/encryption
> Message-ID: <20150519151333.GA14295 at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On Tue, May 19, 2015 at 03:01:39PM +0000, Clark, Robert Graham wrote:
> > Is there a session to discuss the image security proposal?
> >
> https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst
>
> Yes, it's at 4:30 - 5:10pm on Wednesday.
>
> Cheers,
> Louis
>
>
> https://libertydesignsummit.sched.org/event/fc81bd8fb60d71ba4fe1c0cfa0637b2b
>
> https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 473 bytes
> Desc: Digital signature
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/f734ceb3/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 12
> Date: Tue, 19 May 2015 17:39:39 +0200
> From: Markus Zoeller <mzoeller at de.ibm.com>
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] libvirt: _do_quality_warnings and
> the hypervisor support matrix
> Message-ID:
> <
> OF4A923A23.CE73EC16-ONC1257E4A.0055D550-C1257E4A.0056071C at de.ibm.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> "Daniel P. Berrange" <berrange at redhat.com> wrote on 05/19/2015 04:56:17
> PM:
>
> > From: "Daniel P. Berrange" <berrange at redhat.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org>
> > Date: 05/19/2015 05:09 PM
> > Subject: Re: [openstack-dev] [nova] libvirt: _do_quality_warnings and
> > the hypervisor support matrix
> >
> > On Tue, May 19, 2015 at 04:41:40PM +0200, Markus Zoeller wrote:
> > > The libvirt driver logs a warning if:
> > > hostarch not in (arch.I686, arch.X86_64))
> > > The warning when I start the libvirt driver on system z (arch.S390X)
> > > will be:
> > > "The libvirt driver is not tested on kvm/s390x by the OpenStack
> > > project and thus its quality can not be ensured. For more
> > > information, see:
> > > https://wiki.openstack.org/wiki/HypervisorSupportMatrix"
> > >
> > > I'm not quite sure if I understand that correctly. Should this be a
> > > hint that "arch.I686, arch.X86_64" is the assumed "default"?
> > > Or am I supposed to add the architecture "S390X" to this method
> because
> > > this platform is listed in the hypervisor support matrix?
> > > I want to avoid that customers will get a bad feeling because of the
> > > warning after starting the nova libvirt driver on a system z platform.
> > >
> > > Note: We are still working on the CI for nova
> >
> > In the wiki page we describe 3 groups of drives, those with CI run
> > by the OpenStack project (Group A), those with CI run by 3rd party
> > vendors (Group B) and those with no CI at all (Group C)
> >
> >
>
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix#Driver_Testing_Status
>
> >
> > The _do_quality_warnings method is intended to print a warning for
> > any libvirt driver combination that is in Group C.
> >
> > After S390(x) has a 3rd party CI system running regularly & reasonably
> > reliably, then you can submit a change to add S390X to the architecture
> > list in _do_quality_warnings.
> >
> > Regards,
> > Daniel
>
> Thanks for the clarification Daniel.
>
> Regards,
> Markus Zoeller (markus_z)
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Tue, 19 May 2015 09:06:39 -0700
> From: Davanum Srinivas <davanum at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
> thursday session
> Message-ID:
> <
> CANw6fcHc8JYG_3JRtMvixmweYVJEnpHQY+0zP+TfbzmypG6gKw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Mike,
>
> Thanks for the heads up. Wow 26 hours. crazy! No worries. we'll make
> something out of the session and report back
>
> -- dims
>
> On Tue, May 19, 2015 at 7:24 AM, Mike Bayer <mbayer at redhat.com> wrote:
> > ouch !
> >
> >
> > maybe next summit will be on the "Lost" island. another easy place to
> get
> > to ! :)
> >
> >
> >
> >
> >
> > On 5/19/15 9:08 AM, Roman Podoliaka wrote:
> >>
> >> Hi all,
> >>
> >> Just FYI, due to problems with obtaining a Canadian visa, neither
> >> Victor Sergeyev, nor I made it to Vancouver.
> >>
> >> I hope someone else from Oslo team can replace Mike as a session driver.
> >>
> >> Thanks,
> >> Roman
> >>
> >> On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <mbayer at redhat.com> wrote:
> >>>
> >>> Hello -
> >>>
> >>> It is my extreme displeasure and frustration to announce that due to an
> >>> incredibly unfortunate choice of airline, I had to cancel my entire
> trip
> >>> to
> >>> the Openstack summit after spending 26 hours in my home airport waiting
> >>> for
> >>> my airline to produce a working airplane (which they did not).
> >>>
> >>> I will not be able to attend in person the Thursday oslo.db session I
> was
> >>> to
> >>> drive, so a replacement will be needed. I am also lamenting not being
> >>> able
> >>> to meet so many of you who I hoped very much to meet.
> >>>
> >>> Hope you all enjoy the summit and I hope our paths can cross at future
> >>> events.
> >>>
> >>> - mike
> >>>
> >>>
> >>>
> >>>
> >>>
> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
>
>
> ------------------------------
>
> Message: 14
> Date: Tue, 19 May 2015 09:06:56 -0700
> From: Davanum Srinivas <davanum at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
> thursday session
> Message-ID:
> <CANw6fcGYUYsGaNm=6Rsz=
> zzu8RTHDtoA4ioG1fpV7P0yRtSUPA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Ouch. Thanks for the heads up Roman
>
> -- dims
>
> On Tue, May 19, 2015 at 6:08 AM, Roman Podoliaka
> <rpodolyaka at mirantis.com> wrote:
> > Hi all,
> >
> > Just FYI, due to problems with obtaining a Canadian visa, neither
> > Victor Sergeyev, nor I made it to Vancouver.
> >
> > I hope someone else from Oslo team can replace Mike as a session driver.
> >
> > Thanks,
> > Roman
> >
> > On Tue, May 19, 2015 at 3:53 AM, Mike Bayer <mbayer at redhat.com> wrote:
> >> Hello -
> >>
> >> It is my extreme displeasure and frustration to announce that due to an
> >> incredibly unfortunate choice of airline, I had to cancel my entire
> trip to
> >> the Openstack summit after spending 26 hours in my home airport waiting
> for
> >> my airline to produce a working airplane (which they did not).
> >>
> >> I will not be able to attend in person the Thursday oslo.db session I
> was to
> >> drive, so a replacement will be needed. I am also lamenting not being
> able
> >> to meet so many of you who I hoped very much to meet.
> >>
> >> Hope you all enjoy the summit and I hope our paths can cross at future
> >> events.
> >>
> >> - mike
> >>
> >>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
>
>
> ------------------------------
>
> Message: 15
> Date: Tue, 19 May 2015 17:19:27 +0100
> From: "Daniel P. Berrange" <berrange at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [nova][glance] Format of 'locations' data in
> image metadata ?
> Message-ID: <20150519161927.GH8535 at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> In Nova we are attempting to model[1] the glance image metadata and
> properties using the Nova object model (now oslo.versionedobjects).
>
> The one item I'm stuck on understanding is the 'locations' field
> and more specifically the 'metadata' element in each location
> entry
>
>
> In the file glance/api/v2/images.py I can see this description
> of the data format:
>
> 'locations': {
> 'type': 'array',
> 'items': {
> 'type': 'object',
> 'properties': {
> 'url': {
> 'type': 'string',
> 'maxLength': 255,
> },
> 'metadata': {
> 'type': 'object',
> },
> },
> 'required': ['url', 'metadata'],
> },
> 'description': _('A set of URLs to access the image file kept
> in '
> 'external store'),
>
>
> As you can see here, 'metadata' is just said to be of type 'object'.
>
> Is there somewhere that actually describes what is valid contents
> for this field ? Is it sufficient to assume the metadata will only
> ever be a dict of strings, or can the metadata be a complex type
> with arbitrarily nested data structures ?
>
> Regards,
> Daniel
>
> [1] https://review.openstack.org/#/c/76234/
> --
> |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/
> :|
> |: http://libvirt.org -o- http://virt-manager.org
> :|
> |: http://autobuild.org -o- http://search.cpan.org/~danberr/
> :|
> |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc
> :|
>
>
>
> ------------------------------
>
> Message: 16
> Date: Tue, 19 May 2015 17:17:29 +0000
> From: Jeremy Stanley <fungi at yuggoth.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
> thursday session
> Message-ID: <20150519171729.GN2731 at yuggoth.org>
> Content-Type: text/plain; charset=us-ascii
>
> On 2015-05-19 09:06:56 -0700 (-0700), Davanum Srinivas wrote:
> > Ouch. Thanks for the heads up Roman
>
> We have https://wiki.openstack.org/wiki/Infrastructure/Conferencing
> which we used yesterday to successfully bridge Clark B. into an I18n
> tooling session via Jitsi over the normal conference wireless
> network with the built-in mic/speaker in Jim's laptop. Feel free to
> use it in your sessions, just try to pick a random conference number
> between 6000 and 7999 so nobody steps on the toes of other sessions
> which might be using it (maybe add your conference room number to
> 6000 or something?). Let me or other Infra people know if you have
> any questions about or trouble using it!
> --
> Jeremy Stanley
>
>
>
> ------------------------------
>
> Message: 17
> Date: Tue, 19 May 2015 10:21:04 -0700
> 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] [Glance] glance social event at Vancouver
> summit
> Message-ID: <-2437030608731294219 at unknownmsgid>
> Content-Type: text/plain; charset=UTF-8
>
> Hi Brian,
>
> Seems like it overlaps with the "Core reviewers party" on Wednesday.
>
> Is there any chance to reschedule on Thursday?
>
> > 15 ??? 2015 ?., ? 7:19, Brian Rosmaita <brian.rosmaita at rackspace.com>
> ???????(?):
> >
> > Greetings to all Glance people,
> >
> > kragniz has proposed that we have an informal social event for Glance and
> > Glance-related people attending the summit next week. Please keep your
> > calendars open for about 2 hours or so starting at 7:30 p.m. on
> Wednesday,
> > May 20. Neither kragniz nor I are familiar with Vancouver, so we'll
> > figure out logistics when we get there and announce details during the
> > Glance design sessions on Wednesday.
> >
> > Looking forward to seeing everyone and getting some good design work done
> > next week ... safe travels!
> >
> > rosmaita
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ------------------------------
>
> Message: 18
> Date: Tue, 19 May 2015 13:33:19 -0400
> From: Nikhil Komawar <nik.komawar at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova][glance] Format of 'locations' data
> in image metadata ?
> Message-ID: <555B73DF.9070604 at gmail.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> Hi Daniel,
>
> It's stored as "JSONEncodedDict" as shown below. This is a DB model and
> can accept arbitrarily large and nested data structure.
>
> Hope this helps.
>
> class JSONEncodedDict(TypeDecorator):
> """Represents an immutable structure as a json-encoded string"""
>
> impl = Text
>
> def process_bind_param(self, value, dialect):
> if value is not None:
> value = jsonutils.dumps(value)
> return value
>
> def process_result_value(self, value, dialect):
> if value is not None:
> value = jsonutils.loads(value)
> return value
>
>
> Regards,
> Nikhil
>
> On 5/19/15 12:19 PM, Daniel P. Berrange wrote:
> > In Nova we are attempting to model[1] the glance image metadata and
> > properties using the Nova object model (now oslo.versionedobjects).
> >
> > The one item I'm stuck on understanding is the 'locations' field
> > and more specifically the 'metadata' element in each location
> > entry
> >
> >
> > In the file glance/api/v2/images.py I can see this description
> > of the data format:
> >
> > 'locations': {
> > 'type': 'array',
> > 'items': {
> > 'type': 'object',
> > 'properties': {
> > 'url': {
> > 'type': 'string',
> > 'maxLength': 255,
> > },
> > 'metadata': {
> > 'type': 'object',
> > },
> > },
> > 'required': ['url', 'metadata'],
> > },
> > 'description': _('A set of URLs to access the image file
> kept in '
> > 'external store'),
> >
> >
> > As you can see here, 'metadata' is just said to be of type 'object'.
> >
> > Is there somewhere that actually describes what is valid contents
> > for this field ? Is it sufficient to assume the metadata will only
> > ever be a dict of strings, or can the metadata be a complex type
> > with arbitrarily nested data structures ?
> >
> > Regards,
> > Daniel
> >
> > [1] https://review.openstack.org/#/c/76234/
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/3a64a011/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 19
> Date: Tue, 19 May 2015 17:48:57 +0000
> From: "ADAMS, STEVEN E" <sa240s at att.com>
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova-docker] Status update
> Message-ID:
> <
> F169453C03E0074D99BA6CCA8C42112714507326 at MISOUT7MSGUSRCB.ITServices.sbc.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Has there been any decision made on if and when the nova-docker driver
> will move back to the Nova tree and out of Stackforge?
> -Steve Adams
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/44f3e02e/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 20
> Date: Tue, 19 May 2015 11:15:47 -0700
> From: Davanum Srinivas <davanum at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova-docker] Status update
> Message-ID:
> <CANw6fcEYTLHLknVmoL0Sjn=Y4x=
> 6dtMBjqfye_sRyO2sS++RTA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Adam,
>
> Please follow the discussion on the nova-spec review:
> https://review.openstack.org/#/c/128753/
>
> At the moment, we need folks actively watching the project in terms of
> reviews, gate/check job failures, keeping up with Nova trunk etc.
> Please let me know if you or anyone else is interested.
>
> thanks,
> dims
>
> On Tue, May 19, 2015 at 10:48 AM, ADAMS, STEVEN E <sa240s at att.com> wrote:
> > Has there been any decision made on if and when the nova-docker driver
> will
> > move back to the Nova tree and out of Stackforge?
> >
> > -Steve Adams
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
>
>
> ------------------------------
>
> Message: 21
> Date: Tue, 19 May 2015 15:41:31 -0400
> From: Ben Swartzlander <ben at swartzlander.org>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
> Message-ID: <555B91EB.20203 at swartzlander.org>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> On 05/19/2015 10:42 AM, Csaba Henk wrote:
> > Hi Igor,
> >
> >> From: "Igor Malinovskiy" <imalinovskiy at mirantis.com>
> >> To: "OpenStack Development Mailing List (not for usage questions)"
> >> <openstack-dev at lists.openstack.org>
> >> Sent: Monday, May 18, 2015 10:15:25 AM
> >> Subject: [openstack-dev] [Manila] Question to driver maintainers
> > ...
> >> So I want to ask driver maintainers here:
> >> Will your driver be able to do share extending without loss of
> connectivity?
> > Currenty:
> >
> > - glusterfs driver can
> > - glusterfs-native won't support share extension (*)
> >
> > in Liberty timeframe, we are to unify the glusterfs* drivers' backend
> > management logic, so both glusterfs driver style and glusterfs-native
> > driver style backend management will be available for both drivers
> > (actual choice made in configuration). So when this will be in place,
> > the answer modifies as follows:
> >
> > - glusterfs and glusterfs-native will either support non-disruptive
> > share extension, or won't support share resize at all (*) (depending
> > on configuration)
>
> Csaba, this is a truly interesting set of limitations! I'm trying to
> understand what's going on down in the storage system to prevent the
> extension. Is it a case of not having enough free space? Or can you
> support creating new (larger) shares on the same backend while
> simultaneously not being able to resize an existing share? Is there some
> mapping to physical resources that's immutable once configured? What is
> your recommendation to customers who run out of space in a glusterfs
> share today (independent of Manila)?
>
> If your system can't support this case then I'm worried others may have
> similar problems and we could end up having to choose between making
> extend an optional operation (a choice I don't like) or making the
> glusterfs-native driver and possibly other drivers unsupported (also an
> option I don't like).
>
> -Ben
>
> > (*) There are efforts to remove this limitation in GlusterFS, but too
> > vague at this point to make a statement on it.
> >
> > Csaba
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 22
> Date: Tue, 19 May 2015 12:49:49 -0700
> From: Sridhar Ramaswamy <srics.r at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [NFV][Tacker] OpenStack based VNF Manager
> Message-ID:
> <
> CAK6Sh4DU9z1yG5s9_Q4f_aHr5rF_2Nsvzph0ujHp3TDU6zGXWA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> In some of the sessions there were questions related to VNF Manager efforts
> within OpenStack. There is actually an effort to build an ETSI MANO based
> VNF Manager using the stackforge project called Tacker (yes, it used to be
> for ServiceVMs). Please look at the wiki below for more details,
>
> https://wiki.openstack.org/wiki/Tacker
>
> Also to hear more, and see a demo, there is a speaking session scheduled
> for Thursday 11:50am,
>
> http://sched.co/2qik
>
> - Sridhar
> (for Tacker team)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/167eb325/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 23
> Date: Tue, 19 May 2015 19:53:51 +0000
> From: Andrew Woodward <xarses at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Cc: Joe Marshall <Joe.Marshall at metaswitch.com>
> Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license
> agreement for fuel plugin code?
> Message-ID:
> <CACEfbZhV-KhKpVtQps-61WwRXZT4vsPMyzB0=
> 6nmH40cgSWA7Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, May 6, 2015 at 4:06 AM Emma Gordon (projectcalico.org) <
> emma at projectcalico.org> wrote:
>
> > If fuel plugin code is checked into a stackforge repository (as
> > suggested in the fuel plugin wiki
> > https://wiki.openstack.org/wiki/Fuel/Plugins#Repo), who owns that code?
> >
>
> Disclaimer, I'm not a lawyer this not legal advice.
>
> The "authors" own the work (code) according local assignment rules and the
> Berne convention. This would be treated the same as any other work. The
> Authors can decide what rights they may want people with regards to
> copy-right (and other intellectual property rights), hence the licenses
> that we pass around with opensource projects to clarify the author(s)
> intent. Additional "authors" or contributors to the work can further
> describe their own license on their part of the work (as they hold their
> own copyright) but these are usually not accepted by the maintainers of a
> work.
>
> To that end, you don't have to use the Apache 2.0 License on your plugin if
> you don't desire it. It could however cause the plugin to see limited use.
> The point of plugins is that this in your control.
>
> I would also point out that your plugin could easily contain multiple
> licenses depending on what you are including. I'm working on a way to
> easily identify this with the plugins metadata. This can occur multiple
> ways as there are many parts in a plugin.
>
> a) there is the data describing how the plugin interacts with fuel. All of
> this data is highly structured and has little IP (usually the wording you
> use for the text fields is it)
>
> b) any configuration management code you use to apply the plugin and its
> settings. This could include your pure code, or even multiple works from
> others, for example puppet modules.
>
> c) Packages that you need to include as part of the plugin package to
> ensure they can be found. These could each have their own license and even
> carry GPL licensed parts.
>
> In these cases I'd recommend adding a LICENSES file describing the
> locations where items may change license (similar to any other programs
> Open Source Notice file.) from what ever is written on in the "license"
> string in the plugin metadata.yaml. As I noted above, I'm working to get
> this incorporated into the data we present on the plugins repo page.
> (Likely by pointing to this file in the metadata, but it's not settled yet)
>
>
> > Is there a contributor license agreement to sign? (For example,
> > contributors to OpenStack would sign this
> > https://review.openstack.org/static/cla.html)
> >
> The Openstack CLA is not required for Fuel, and is not obligatory. You
> again have control here and simply configure your gerrit settings for your
> project as you see fit.
>
> > Thanks,
> >
> > Emma
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/c1e4cc58/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 24
> Date: Tue, 19 May 2015 20:05:15 +0000
> From: Andrew Woodward <xarses at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, Zhou Zheng Sheng / ???
> <zhengsheng at awcloud.com>
> Subject: Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering
> Message-ID:
> <
> CACEfbZj7bHJD7ZH9Dv13k3QUN44VNyfTyvztBr6Oj_bq+Hw-kA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof <abeekhof at redhat.com> wrote:
>
> >
> > > On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / ??? <
> > zhengsheng at awcloud.com> wrote:
> > >
> > > Thank you Andrew.
> > >
> > > on 2015/05/05 08:03, Andrew Beekhof wrote:
> > >>> On 28 Apr 2015, at 11:15 pm, Bogdan Dobrelya <bdobrelia at mirantis.com
> >
> > wrote:
> > >>>
> > >>>> Hello,
> > >>> Hello, Zhou
> > >>>
> > >>>> I using Fuel 6.0.1 and find that RabbitMQ recover time is long after
> > >>>> power failure. I have a running HA environment, then I reset power
> of
> > >>>> all the machines at the same time. I observe that after reboot it
> > >>>> usually takes 10 minutes for RabittMQ cluster to appear running
> > >>>> master-slave mode in pacemaker. If I power off all the 3 controllers
> > and
> > >>>> only start 2 of them, the downtime sometimes can be as long as 20
> > minutes.
> > >>> Yes, this is a known issue [0]. Note, there were many bugfixes, like
> > >>> [1],[2],[3], merged for MQ OCF script, so you may want to try to
> > >>> backport them as well by the following guide [4]
> > >>>
> > >>> [0] https://bugs.launchpad.net/fuel/+bug/1432603
> > >>> [1] https://review.openstack.org/#/c/175460/
> > >>> [2] https://review.openstack.org/#/c/175457/
> > >>> [3] https://review.openstack.org/#/c/175371/
> > >>> [4] https://review.openstack.org/#/c/170476/
> > >> Is there a reason you?re using a custom OCF script instead of the
> > upstream[a] one?
> > >> Please have a chat with David (the maintainer, in CC) if there is
> > something you believe is wrong with it.
> > >>
> > >> [a]
> >
> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster
> > >
> > > I'm using the OCF script from the Fuel project, specifically from the
> > > "6.0" stable branch [alpha].
> >
> > Ah, I?m still learning who is who... i thought you were part of that
> > project :-)
> >
> > >
> > > Comparing with upstream OCF code, the main difference is that Fuel
> > > RabbitMQ OCF is a master-slave resource. Fuel RabbitMQ OCF does more
> > > bookkeeping, for example, blocking client access when RabbitMQ cluster
> > > is not ready. I beleive the upstream OCF should be OK to use as well
> > > after I read the code, but it might not fit into the Fuel project. As
> > > far as I test, the Fuel OCF script is good except sometimes the full
> > > reassemble time is long, and as I find out, it is mostly because the
> > > Fuel MySQL Galera OCF script keeps pacemaker from promoting RabbitMQ
> > > resource, as I mentioned in the previous emails.
> > >
> > > Maybe Vladimir and Sergey can give us more insight on why Fuel needs a
> > > master-slave RabbitMQ.
> >
> > That would be good to know.
> > Browsing the agent, promote seems to be a no-op if rabbit is already
> > running.
> >
> >
> To the master / slave reason due to how the ocf script is structured to
> deal with rabbit's poor ability to handle its self in some scenarios.
> Hopefully the state transition diagram [5] is enough to clarify what's
> going on.
>
> [5] http://goo.gl/PPNrw7
>
>
> > > I see Vladimir and Sergey works on the original
> > > Fuel blueprint "RabbitMQ cluster" [beta].
> > >
> > > [alpha]
> > >
> >
> https://github.com/stackforge/fuel-library/blob/stable/6.0/deployment/puppet/nova/files/ocf/rabbitmq
> > > [beta]
> > >
> >
> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-cluster-controlled-by-pacemaker
> > >
> > >>>> I have a little investigation and find out there are some possible
> > causes.
> > >>>>
> > >>>> 1. MySQL Recovery Takes Too Long [1] and Blocking RabbitMQ
> Clustering
> > in
> > >>>> Pacemaker
> > >>>>
> > >>>> The pacemaker resource p_mysql start timeout is set to 475s.
> Sometimes
> > >>>> MySQL-wss fails to start after power failure, and pacemaker would
> wait
> > >>>> 475s before retry starting it. The problem is that pacemaker divides
> > >>>> resource state transitions into batches. Since RabbitMQ is
> > master-slave
> > >>>> resource, I assume that starting all the slaves and promoting master
> > are
> > >>>> put into two different batches. If unfortunately starting all
> RabbitMQ
> > >>>> slaves are put in the same batch as MySQL starting, even if RabbitMQ
> > >>>> slaves and all other resources are ready, pacemaker will not
> continue
> > >>>> but just wait for MySQL timeout.
> > >>> Could you please elaborate the what is the same/different batches for
> > MQ
> > >>> and DB? Note, there is a MQ clustering logic flow charts available
> here
> > >>> [5] and we're planning to release a dedicated technical bulletin for
> > this.
> > >>>
> > >>> [5] http://goo.gl/PPNrw7
> > >>>
> > >>>> I can re-produce this by hard powering off all the controllers and
> > start
> > >>>> them again. It's more likely to trigger MySQL failure in this way.
> > Then
> > >>>> I observe that if there is one cloned mysql instance not starting,
> the
> > >>>> whole pacemaker cluster gets stuck and does not emit any log. On the
> > >>>> host of the failed instance, I can see a mysql resource agent
> process
> > >>>> calling the sleep command. If I kill that process, the pacemaker
> comes
> > >>>> back alive and RabbitMQ master gets promoted. In fact this long
> > timeout
> > >>>> is blocking every resource from state transition in pacemaker.
> > >>>>
> > >>>> This maybe a known problem of pacemaker and there are some
> discussions
> > >>>> in Linux-HA mailing list [2]. It might not be fixed in the near
> > future.
> > >>>> It seems in generally it's bad to have long timeout in state
> > transition
> > >>>> actions (start/stop/promote/demote). There maybe another way to
> > >>>> implement MySQL-wss resource agent to use a short start timeout and
> > >>>> monitor the wss cluster state using monitor action.
> > >>> This is very interesting, thank you! I believe all commands for MySQL
> > RA
> > >>> OCF script should be as well wrapped with timeout -SIGTERM or
> -SIGKILL
> > >>> as we did for MQ RA OCF. And there should no be any sleep calls. I
> > >>> created a bug for this [6].
> > >>>
> > >>> [6] https://bugs.launchpad.net/fuel/+bug/1449542
> > >>>
> > >>>> I also find a fix to improve MySQL start timeout [3]. It shortens
> the
> > >>>> timeout to 300s. At the time I sending this email, I can not find it
> > in
> > >>>> stable/6.0 branch. Maybe the maintainer needs to cherry-pick it to
> > >>>> stable/6.0 ?
> > >>>>
> > >>>> [1] https://bugs.launchpad.net/fuel/+bug/1441885
> > >>>> [2]
> > http://lists.linux-ha.org/pipermail/linux-ha/2014-March/047989.html
> > >>>> [3] https://review.openstack.org/#/c/171333/
> > >>>>
> > >>>>
> > >>>> 2. RabbitMQ Resource Agent Breaks Existing Cluster
> > >>>>
> > >>>> Read the code of the RabbitMQ resource agent, I find it does the
> > >>>> following to start RabbitMQ master-slave cluster.
> > >>>> On all the controllers:
> > >>>> (1) Start Erlang beam process
> > >>>> (2) Start RabbitMQ App (If failed, reset mnesia DB and cluster
> state)
> > >>>> (3) Stop RabbitMQ App but do not stop the beam process
> > >>>>
> > >>>> Then in pacemaker, all the RabbitMQ instances are in slave state.
> > After
> > >>>> pacemaker determines the master, it does the following.
> > >>>> On the to-be-master host:
> > >>>> (4) Start RabbitMQ App (If failed, reset mnesia DB and cluster
> state)
> > >>>> On the slaves hosts:
> > >>>> (5) Start RabbitMQ App (If failed, reset mnesia DB and cluster
> state)
> > >>>> (6) Join RabbitMQ cluster of the master host
> > >>>>
> > >>> Yes, something like that. As I mentioned, there were several bug
> fixes
> > >>> in the 6.1 dev, and you can also check the MQ clustering flow charts.
> > >>>
> > >>>> As far as I can understand, this process is to make sure the master
> > >>>> determined by pacemaker is the same as the master determined in
> > RabbitMQ
> > >>>> cluster. If there is no existing cluster, it's fine. If it is run
> > >>> after
> > >>>
> > >>> Not exactly. There is no master in mirrored MQ cluster. We define the
> > >>> rabbit_hosts configuration option from Oslo.messaging. What ensures
> all
> > >>> queue masters will be spread around all of MQ nodes in a long run.
> And
> > >>> we use a master abstraction only for the Pacemaker RA clustering
> layer.
> > >>> Here, a "master" is the MQ node what joins the rest of the MQ nodes.
> > >>>
> > >>>> power failure and recovery, it introduces the a new problem.
> > >>> We do erase the node master attribute in CIB for such cases. This
> > should
> > >>> not bring problems into the master election logic.
> > >>>
> > >>>> After power recovery, if some of the RabbitMQ instances reach step
> (2)
> > >>>> roughly at the same time (within 30s which is hard coded in
> RabbitMQ)
> > as
> > >>>> the original RabbitMQ master instance, they form the original
> cluster
> > >>>> again and then shutdown. The other instances would have to wait for
> > 30s
> > >>>> before it reports failure waiting for tables, and be reset to a
> > >>>> standalone cluster.
> > >>>>
> > >>>> In RabbitMQ documentation [4], it is also mentioned that if we
> > shutdown
> > >>>> RabbitMQ master, a new master is elected from the rest of slaves. If
> > we
> > >>> (Note, the RabbitMQ documentation mentions *queue* masters and
> slaves,
> > >>> which are not the case for the Pacemaker RA clustering abstraction
> > layer.)
> > >>>
> > >>>> continue to shutdown nodes in step (3), we reach a point that the
> last
> > >>>> node is the RabbitMQ master, and pacemaker is not aware of it. I can
> > see
> > >>>> there is code to bookkeeping a "rabbit-start-time" attribute in
> > >>>> pacemaker to record the most long lived instance to help pacemaker
> > >>>> determine the master, but it does not cover the case mentioned
> above.
> > >>> We made an assumption what the node with the highest MQ uptime should
> > >>> know the most about recent cluster state, so other nodes must join
> it.
> > >>> RA OCF does not work with queue masters directly.
> > >>>
> > >>>> A
> > >>>> recent patch [5] checks existing "rabbit-master" attribute but it
> > >>>> neither cover the above case.
> > >>>>
> > >>>> So in step (4), pacemaker determines a different master which was a
> > >>>> RabbitMQ slave last time. It would wait for its original RabbitMQ
> > master
> > >>>> for 30s and fail, then it gets reset to a standalone cluster. Here
> we
> > >>>> get some different clusters, so in step (5) and (6), it is likely to
> > >>>> report error in log saying timeout waiting for tables or fail to
> merge
> > >>>> mnesia database schema, then the those instances get reset. You can
> > >>>> easily re-produce the case by hard resetting power of all the
> > controllers.
> > >>>>
> > >>>> As you can see, if you are unlucky, there would be several "30s
> > timeout
> > >>>> and reset" before you finally get a healthy RabbitMQ cluster.
> > >>> The full MQ cluster reassemble logic is far from the perfect state,
> > >>> indeed. This might erase all mnesia files, hence any custom entities,
> > >>> like users or vhosts, would be removed as well. Note, we do not
> > >>> configure durable queues for Openstack so there is nothing to care
> > about
> > >>> here - the full cluster downtime assumes there will be no AMQP
> messages
> > >>> stored at all.
> > >>>
> > >>>> I find three possible solutions.
> > >>>> A. Using rabbitmqctl force_boot option [6]
> > >>>> It will skips waiting for 30s and resetting cluster, but just assume
> > the
> > >>>> current node is the master and continue to operate. This is feasible
> > >>>> because the original RabbitMQ master would discards the local state
> > and
> > >>>> sync with the new master after it joins a new cluster [7]. So we can
> > be
> > >>>> sure that after step (4) and (6), the pacemaker determined master
> > >>>> instance is started unconditionally, and it will be the same as
> > RabbitMQ
> > >>>> master, and all operations run without 30s timeout. I find this
> option
> > >>>> is only available in newer RabbitMQ release, and updating RabbitMQ
> > might
> > >>>> introduce other compatibility problems.
> > >>> Yes, this option is only supported for newest RabbitMQ versions. But
> we
> > >>> definitely should look how this could help.
> > >>>
> > >>>> B. Turn RabbitMQ into cloned instance and use pause_minority instead
> > of
> > >>>> autoheal [8]
> > >>> Indeed, there are cases when MQ's autoheal can do nothing with
> existing
> > >>> partitions and remains partitioned for ever, for example:
> > >>>
> > >>> Masters: [ node-1 ]
> > >>> Slaves: [ node-2 node-3 ]
> > >>> root at node-1:~# rabbitmqctl cluster_status
> > >>> Cluster status of node 'rabbit at node-1' ...
> > >>> [{nodes,[{disc,['rabbit at node-1','rabbit at node-2']}]},
> > >>> {running_nodes,['rabbit at node-1']},
> > >>> {cluster_name,<<"rabbit at node-2">>},
> > >>> {partitions,[]}]
> > >>> ...done.
> > >>> root at node-2:~# rabbitmqctl cluster_status
> > >>> Cluster status of node 'rabbit at node-2' ...
> > >>> [{nodes,[{disc,['rabbit at node-2']}]}]
> > >>> ...done.
> > >>> root at node-3:~# rabbitmqctl cluster_status
> > >>> Cluster status of node 'rabbit at node-3' ...
> > >>> [{nodes,[{disc,['rabbit at node-1','rabbit at node-2','rabbit at node-3']}]},
> > >>> {running_nodes,['rabbit at node-3']},
> > >>> {cluster_name,<<"rabbit at node-2">>},
> > >>> {partitions,[]}]
> > >>>
> > >>> So we should test the pause-minority value as well.
> > >>> But I strongly believe we should make MQ multi-state clone to support
> > >>> many masters, related bp [7]
> > >>>
> > >>> [7]
> > >>>
> >
> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-pacemaker-multimaster-clone
> > >>>
> > >>>> This works like MySQL-wss. It let RabbitMQ cluster itself deal with
> > >>>> partition in a manner similar to pacemaker quorum mechanism. When
> > there
> > >>>> is network partition, instances in the minority partition pauses
> > >>>> themselves automatically. Pacemaker does not have to track who is
> the
> > >>>> RabbitMQ master, who lives longest, who to promote... It just starts
> > all
> > >>>> the clones, done. This leads to huge change in RabbitMQ resource
> > agent,
> > >>>> and the stability and other impact is to be tested.
> > >>> Well, we should not mess the queue masters and multi-clone master for
> > MQ
> > >>> resource in the pacemaker.
> > >>> As I said, pacemaker RA has nothing to do with queue masters. And we
> > >>> introduced this "master" mostly in order to support the full cluster
> > >>> reassemble case - there must be a node promoted and other nodes
> should
> > join.
> > >>>
> > >>>> C. Creating a "force_load" file
> > >>>> After reading RabbitMQ source code, I find that the actual thing it
> > does
> > >>>> in solution A is just creating an empty file named "force_load" in
> > >>>> mnesia database dir, then mnesia thinks it is the last node shut
> down
> > in
> > >>>> the last time and boot itself as the master. This implementation
> keeps
> > >>>> the same from v3.1.4 to the latest RabbitMQ master branch. I think
> we
> > >>>> can make use of this little trick. The change is adding just one
> line
> > in
> > >>>> "try_to_start_rmq_app()" function.
> > >>>>
> > >>>> touch "${MNESIA_FILES}/force_load" && \
> > >>>> chown rabbitmq:rabbitmq "${MNESIA_FILES}/force_load"
> > >>> This is a very good point, thank you.
> > >>>
> > >>>> [4] http://www.rabbitmq.com/ha.html
> > >>>> [5] https://review.openstack.org/#/c/169291/
> > >>>> [6] https://www.rabbitmq.com/clustering.html
> > >>>> [7] http://www.rabbitmq.com/partitions.html#recovering
> > >>>> [8] http://www.rabbitmq.com/partitions.html#automatic-handling
> > >>>>
> > >>>> Maybe you have better ideas on this. Please share your thoughts.
> > >>> Thank you for a thorough feedback! This was a really great job.
> > >>>
> > >>>> ----
> > >>>> Best wishes!
> > >>>> Zhou Zheng Sheng / ??? Software Engineer
> > >>>> Beijing AWcloud Software Co., Ltd.
> > >>>>
> > >>>
> > >>> --
> > >>> Best regards,
> > >>> Bogdan Dobrelya,
> > >>> Skype #bogdando_at_yahoo.com
> > >>> Irc #bogdando
> > >>>
> > >>>
> >
> __________________________________________________________________________
> > >>> OpenStack Development Mailing List (not for usage questions)
> > >>> Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >>
> > >>
> >
> __________________________________________________________________________
> > >> OpenStack Development Mailing List (not for usage questions)
> > >> Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/4175e424/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 25
> Date: Tue, 19 May 2015 14:07:59 -0700
> From: Sergey Lukjanov <slukjanov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [surge] Introducing Surge - rapid
> deploy/scale stream processing systems on OpenStack
> Message-ID:
> <
> CA+GZd7_fNwFihgfLCqs-PZnyFRXRBd6hOLd7G7WdZnQVAmdypQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Agreed with notes about the fact that mostly everything is already
> supported by Sahara. The question is there any hidden reason to not
> contribute it into Sahara?
>
> On Mon, May 18, 2015 at 4:38 PM, Andrew Lazarev <alazarev at mirantis.com>
> wrote:
>
> > As I see Surge is pretty much replicating Sahara functionality running in
> > "one process per host" mode. Sahara currently supports much more
> features.
> >
> > Andrew.
> >
> > On Fri, May 15, 2015 at 10:38 AM, Joe Gordon <joe.gordon0 at gmail.com>
> > wrote:
> >
> >>
> >>
> >> On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta <ddutta at gmail.com>
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> It gives me a great pleasure to introduce Surge - a system to rapidly
> >>> deploy and scale a stream processing system on OpenStack. It leverages
> >>> Vagrant and Ansible, and supports both OpenStack as well as the local
> mode
> >>> (with VirtualBox).
> >>>
> >>> https://github.com/CiscoSystems/surge
> >>>
> >>>
> >> I see you support Storm and Kafka,
> >>
> >> How is this different then Sahara's Storm plugin?
> >>
> >>
> >>
> https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47
> >>
> >> And I See Sahara is exploring Kafka support:
> >> https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service
> >>
> >>
> >>> Hope to see a lot of pull requests and comments.
> >>>
> >>> thx
> >>> -Debo~
> >>>
> >>>
> >>>
> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/e3fce5b4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 26
> Date: Tue, 19 May 2015 14:16:09 -0700
> From: Sergey Lukjanov <slukjanov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [new][cognitive] Announcing Cognitive - a
> project to deliver Machine Learning as a Service for OpenStack
> Message-ID:
> <CA+GZd79SK1o=aY-0Uij4THCDakyK-2VWd6jbfBy5DRb23Dy=
> bw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> as there is no any details on the project yet done, if this project will
> deploy ML frameworks it'll be direct duplication of Sahara's functionality
> (we already support HDP and CDH deployments and they are provided tons of
> tools for ML). So, I think that it could be built on top of Sahara or even
> as part of Sahara probably. I'd like to propose you to take a deeper look
> on Sahara and avoid duplicating it.
>
> Thanks.
>
> On Thu, May 14, 2015 at 8:47 PM, Debojyoti Dutta <ddutta at gmail.com> wrote:
>
> > Hi Salvatore
> >
> > Thanks a lot for your comments.
> >
> > Timing: Yes it is time to do this! The nature of applications running on
> > clouds is indeed changing.
> >
> > Initial group: We asked around for folks interested and we got a lot more
> > people than we expected. The idea is to get something out there in a
> stack
> > forge project and build something good. This group already has people who
> > have built things like this already in the past. Hence confident about
> the
> > success.
> >
> > Participation: We want this to be inclusive from scratch independent of
> > who is a PTL or a contributor or merely a curious individual to give us
> > ideas :) The community will get it right. Maybe I should have clarified
> > that these are the members interested in seeing this happen.
> >
> > Wiki page: The wiki page will be ready in 1-2 days. Also we would like to
> > have a discussion during the summit to see what we should build in the
> > community. Would be delighted to get your thoughts.
> >
> > Services: Some of the services this could provide:
> > * create experiments: define data sources, train models, then perform
> > classification, clustering, data cleaning etc.
> > * have experiment templates that can be reused
> > * have an editor (maybe a horizon plugin) to drag and drop the workflow
> > and generate an API that when called from an app would provide results
> > * ML primitives that could be targeted initially: 1) classification 2)
> > clustering 3) Anomaly detection
> >
> > thx
> > debo
> >
> > On Thu, May 14, 2015 at 5:02 PM, Salvatore Orlando <sorlando at nicira.com>
> > wrote:
> >
> >>
> >> On 15 May 2015 at 00:19, Debojyoti Dutta <ddutta at gmail.com> wrote:
> >>
> >>> Hi!
> >>>
> >>> It is a great pleasure to announce the development of a new project
> >>> called Cognitive. Cognitive provides Machine Learning [1] as a Service
> >>> that enables operators to offer next generation data science based
> services
> >>> on top of their OpenStack Clouds.
> >>>
> >>
> >> I was indeed wondering when "Machine Learning as a Service" would come
> >> up...
> >>
> >>
> >>> This project will begin as a StackForge project baed upon an empty
> >>> cookiecutter [2] repo. The repos to work in are:
> >>> Server: https://github.com/stackforge/cognitive
> >>> Client: https://github.com/stackforge/python-cognitiveclient
> >>>
> >>> Please join us via iRC on #openstack-cognitive on freenode.
> >>>
> >>> We will be holding a doodle poll to select times for our first meeting
> >>> the week after summit. This doodle poll will close May 24th and
> meeting
> >>> times will be announced on the mailing list at that time. At our
> first IRC
> >>> meeting, we will draft additional core team members. We would like to
> >>> invite interested individuals to join this exciting new development
> effort!
> >>>
> >>
> >> From my little experience, "drafting" core members before even actually
> >> having a code base has drawbacks. Also, it seems the initial starting
> team
> >> is already large enough for ensuring support for 1 or 2 release cycle.
> >>
> >>
> >>>
> >>>
> >>
> >>> Please commit your schedule in the doodle poll here:
> >>> http://doodle.com/drrka5tgbwpbfbxy
> >>>
> >>> Initial core team: Steven Dake, Aparupa Das Gupa, Debo~ Dutta, Johnu
> >>> George, Kyle Mestery, Sarvesh Ranjan, Ralf Rantzau, Komei Shimamura,
> Marc
> >>> Solanas, Manoj Sharma, Yathi Udupi, Kai Zhang.
> >>>
> >>
> >> Hey! What's the Neutron PTL doing there? Sorry we need his reviews we
> >> can't loan it to you!
> >>
> >>
> >>>
> >>> A little bit about Cognitive:
> >>> Data driven applications on cloud infrastructure increasingly rely on
> >>> Machine Learning. Most data driven applications today use Machine
> Learning
> >>> (ML). This often requires application developers and data scientists to
> >>> write their own machine learning stack or deploy other packages to do
> any
> >>> kind of data science based applications. Data scientists also need to
> have
> >>> an easy way to rapidly experiment with data without having to write
> basic
> >>> infrastructure for data manipulations. Cognitive is a Machine Learning
> >>> service on top of OpenStack and provides machine learning based
> services to
> >>> tenants (API, workbench, compute service).
> >>>
> >>
> >> I wonder what kind of services you would offer; also you could have
> >> shared something about the architecture of this service. Is it
> providing a
> >> full machine learning stack, or just facilitating the use of existing
> one?
> >>
> >> But I see that there's a link to a wiki page below. This might have all
> >> the answers.
> >>
> >>
> >>>
> >>>
> >>> For information about blueprints check out:
> >>> https://blueprints.launchpad.net/cognitive
> >>> https://blueprints.launchpad.net/python-cognitiveclient
> >>>
> >>> For more details, check out our Wiki:
> >>> https://wiki.openstack.org/wiki/Cognitive
> >>>
> >>
> >> ... and unfortunately the wiki is empty ;)
> >>
> >>
> >>>
> >>> Please join the awesome Cognitive team in designing a world class
> >>> Machine Learning as a Service solution.
> >>>
> >>> We look forward to seeing you on IRC on #openstack-cognitive.
> >>>
> >>> Regards,
> >>> Debo~ Dutta (on behalf of the initial team)
> >>>
> >>> [1] http://en.wikipedia.org/wiki/Machine_learning
> >>> [2] https://github.com/openstack-dev/cookiecutter
> >>>
> >>>
> >>>
> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> > --
> > -Debo~
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/7fa6097a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 27
> Date: Tue, 19 May 2015 14:16:55 -0700
> From: Sergey Lukjanov <slukjanov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [surge] Introducing Surge - rapid
> deploy/scale stream processing systems on OpenStack
> Message-ID:
> <
> CA+GZd7_5+Y7Es6YF7fMcOXBJ4fURFM_zJhrVmG28hwS6c-_tPw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Actually the same as for the MLaaS - please, take a deeper look at Sahara
> before starting duplicating already existing things.
>
> On Tue, May 19, 2015 at 2:07 PM, Sergey Lukjanov <slukjanov at mirantis.com>
> wrote:
>
> > Agreed with notes about the fact that mostly everything is already
> > supported by Sahara. The question is there any hidden reason to not
> > contribute it into Sahara?
> >
> > On Mon, May 18, 2015 at 4:38 PM, Andrew Lazarev <alazarev at mirantis.com>
> > wrote:
> >
> >> As I see Surge is pretty much replicating Sahara functionality running
> >> in "one process per host" mode. Sahara currently supports much more
> >> features.
> >>
> >> Andrew.
> >>
> >> On Fri, May 15, 2015 at 10:38 AM, Joe Gordon <joe.gordon0 at gmail.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta <ddutta at gmail.com>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> It gives me a great pleasure to introduce Surge - a system to rapidly
> >>>> deploy and scale a stream processing system on OpenStack. It leverages
> >>>> Vagrant and Ansible, and supports both OpenStack as well as the local
> mode
> >>>> (with VirtualBox).
> >>>>
> >>>> https://github.com/CiscoSystems/surge
> >>>>
> >>>>
> >>> I see you support Storm and Kafka,
> >>>
> >>> How is this different then Sahara's Storm plugin?
> >>>
> >>>
> >>>
> https://github.com/openstack/sahara/blob/45045d918f363fa5763cde700561434345017661/setup.cfg#L47
> >>>
> >>> And I See Sahara is exploring Kafka support:
> >>> https://blueprints.launchpad.net/sahara/+spec/cdh-kafka-service
> >>>
> >>>
> >>>> Hope to see a lot of pull requests and comments.
> >>>>
> >>>> thx
> >>>> -Debo~
> >>>>
> >>>>
> >>>>
> __________________________________________________________________________
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe:
> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>
> >>>
> >>>
> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >>>
> >>
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >
> >
> > --
> > Sincerely yours,
> > Sergey Lukjanov
> > Sahara Technical Lead
> > (OpenStack Data Processing)
> > Principal Software Engineer
> > Mirantis Inc.
> >
>
>
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/d4fba6e7/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 28
> Date: Wed, 20 May 2015 09:04:11 +1200
> From: Fei Long Wang <feilong at catalyst.net.nz>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [glance] missing implementation on glance
> basic quota
> Message-ID: <555BA54B.9060204 at catalyst.net.nz>
> Content-Type: text/plain; charset="utf-8"
>
> We're using user_storage_quota to limit the total number of bytes of
> each user for now based on the discussion, you can see that from the
> blueprint. May I know your user case for number of images? Cheers.
>
> On 20/05/15 02:10, Gareth wrote:
> > Hi glance guys
> >
> > There is a bp[0] said it would implement two basic quota usage:
> >
> > a, the number of image stored
> > b, the amount of storage in occupied by a set of image
> >
> > However, only b is implemented in the patch[1], and a is still missing
> > in current glance.
> >
> > [0] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas
> > [1] https://review.openstack.org/#/c/37993/18
> >
> > --
> > Gareth
> >
> > /Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball/
> > /OpenStack contributor, kun_huang at freenode/
> > /My promise: if you find any spelling or grammar mistakes in my email
> > from Mar 1 2013, notify me /
> > /and I'll donate $1 or ?1 to an open organization you specify./
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Cheers & Best regards,
> Fei Long Wang (???)
> --------------------------------------------------------------------------
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flwang at catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --------------------------------------------------------------------------
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/de494919/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 29
> Date: Tue, 19 May 2015 14:18:36 -0700
> From: Sam Morrison <sorrison at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova] Tempest failure help
> Message-ID: <7712CFBF-68BF-4EC9-A885-626BC283A34F at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi nova devs,
>
> I have a patch https://review.openstack.org/#/c/181776/ <
> https://review.openstack.org/#/c/181776/> where I have a failing tempest
> job which I can?t figure out. Can anyone help me?
>
> Cheers,
> Sam
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/cf7d3303/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 30
> Date: Tue, 19 May 2015 14:20:48 -0700
> From: Sergey Lukjanov <slukjanov at mirantis.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [sahara] no meetings May 21 and 28
> Message-ID:
> <
> CA+GZd7_KzQTvkgrNW-OphqaR9+yQL6xdwHjK0uB52EigG0vmsg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hey,
>
> on the meeting last week we agreed to skip IRC meetings on a summer week
> and on a week after.
>
> Thanks.
>
> --
> Sincerely yours,
> Sergey Lukjanov
> Sahara Technical Lead
> (OpenStack Data Processing)
> Principal Software Engineer
> Mirantis Inc.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150519/51e41a9d/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 31
> Date: Tue, 19 May 2015 17:29:40 -0400 (EDT)
> From: Dan Lambright <dlambrig at redhat.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [security] / IDS + openstack meeting in
> Vancouver 4:10 Wednesday May 20
> Message-ID:
> <155985814.1002516.1432070980605.JavaMail.zimbra at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> Hello,
>
> While at the Vancouver summit, it would be good to have an informal
> meeting on IDS + openstack. My understanding is there has not been a
> community driven effort in this area to date. It would be good to kick
> something off. Likely subjects would be neutron plug-ins and scalability
> (management and monitoring).
>
> The best time would probably be after the TaaS talk Wednesday. TaaS may
> influence what direction to take.
>
> I will be next to the ATM machine on the 1st floor, next to where they
> give away the windbreaker SWAG. I?ll hang out there between 4:10 and 4:30.
> Please feel free to find a drink and walk over. I will also post this
> announcement to the openstack-dev mailing list (
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev). The
> subject will contain: [security] {IDS}
>
> Thanks,
>
> Dan Lambright
> Red Hat
>
>
>
> ------------------------------
>
> Message: 32
> Date: Tue, 19 May 2015 17:30:07 -0400 (EDT)
> From: Victor Stinner <vstinner at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today
> Message-ID:
> <297176382.2081976.1432071007216.JavaMail.zimbra at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi,
>
> I found a related issue in glance.
>
> "issue with pbr 1.0 release"
> https://bugs.launchpad.net/glance/+bug/1456800
>
> "Modify entry point tests to not require deps"
> https://review.openstack.org/#/c/184326/
>
> Victor
>
> ----- Original Message -----
> > From: "Robert Collins" <robertc at robertcollins.net>
> > To: "OpenStack Development Mailing List" <
> openstack-dev at lists.openstack.org>
> > Sent: Monday, May 18, 2015 5:54:43 PM
> > Subject: [openstack-dev] [all] gate pep8 jobs broken today
> >
> > Hi, we had a gate outage today for a few hours.
> >
> > http://pad.lv/1456376
> >
> > The issue was an interaction between the existence of pbr 1.0, project
> > local requirements, hacking 0.10.1 and flake8 <2.4.1.
> >
> > When flake8< 2.4.1 loads plugins (which hacking is) it uses
> > pkg_resources and calls load(), which checks requirements.
> >
> > pbr in the pep8 jobs is installed by the project requirements.txt
> > files, which per global-requirements mostly now say ">=0.11, <2.0", so
> > pbr 1.0.0 was immediately installed once it was released.
> >
> > hacking is installed from release, so hacking 0.10.1 was installed,
> > which has the constraint for pbr of <1.0 that we had prior to bumping
> > the releases in global-requirements. And so boom.
> >
> > We've now released hacking 0.10.2, which contains only the updated pbr
> > constraint, and we don't expect any additional fallout from it.
> >
> > Thanks Clark, Doug, Ian, Sean, and Joe for helping unwind, analyze and
> fix
> > this.
> >
> > -Rob
> >
> > --
> > Robert Collins <rbtcollins at hp.com>
> > Distinguished Technologist
> > HP Converged Cloud
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> ------------------------------
>
> Message: 33
> Date: Tue, 19 May 2015 21:44:55 +0000
> From: Alan Kavanagh <alan.kavanagh at ericsson.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] / IDS + openstack meeting in Vancouver
> 4:10 Wednesday May 20
> Message-ID:
> <C977B257ADF8814C8EB4FB66BB9D0C2EA3BA05 at eusaamb109.ericsson.se>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Dan et.al
>
> Thanks for reaching out, I attended your IDS talk yesterday and we can
> meet up after our TaaS tech talk where we do a walk through from the why,
> what and how and a demo with detail explanations on its built.
> /Alan
>
> -----Original Message-----
> From: Dan Lambright [mailto:dlambrig at redhat.com]
> Sent: May-19-15 2:30 PM
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [security] / IDS + openstack meeting in Vancouver
> 4:10 Wednesday May 20
>
> Hello,
>
> While at the Vancouver summit, it would be good to have an informal
> meeting on IDS + openstack. My understanding is there has not been a
> community driven effort in this area to date. It would be good to kick
> something off. Likely subjects would be neutron plug-ins and scalability
> (management and monitoring).
>
> The best time would probably be after the TaaS talk Wednesday. TaaS may
> influence what direction to take.
>
> I will be next to the ATM machine on the 1st floor, next to where they
> give away the windbreaker SWAG. I?ll hang out there between 4:10 and 4:30.
> Please feel free to find a drink and walk over. I will also post this
> announcement to the openstack-dev mailing list (
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev). The
> subject will contain: [security] {IDS}
>
> Thanks,
>
> Dan Lambright
> Red Hat
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ------------------------------
>
> Message: 34
> Date: Wed, 20 May 2015 00:01:37 +0200
> From: Flavio Percoco <flavio at redhat.com>
> To: "Daniel P. Berrange" <berrange at redhat.com>, "OpenStack Development
> Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova][glance] Format of 'locations' data
> in image metadata ?
> Message-ID: <20150519220137.GC18488 at redhat.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 19/05/15 17:19 +0100, Daniel P. Berrange wrote:
> >In Nova we are attempting to model[1] the glance image metadata and
> >properties using the Nova object model (now oslo.versionedobjects).
> >
> >The one item I'm stuck on understanding is the 'locations' field
> >and more specifically the 'metadata' element in each location
> >entry
> >
> >
> >In the file glance/api/v2/images.py I can see this description
> >of the data format:
> >
> > 'locations': {
> > 'type': 'array',
> > 'items': {
> > 'type': 'object',
> > 'properties': {
> > 'url': {
> > 'type': 'string',
> > 'maxLength': 255,
> > },
> > 'metadata': {
> > 'type': 'object',
> > },
> > },
> > 'required': ['url', 'metadata'],
> > },
> > 'description': _('A set of URLs to access the image file kept
> in '
> > 'external store'),
> >
> >
> >As you can see here, 'metadata' is just said to be of type 'object'.
> >
> >Is there somewhere that actually describes what is valid contents
> >for this field ? Is it sufficient to assume the metadata will only
> >ever be a dict of strings, or can the metadata be a complex type
> >with arbitrarily nested data structures ?
>
> It's just arbitrary metadata for now, we don't have a specific format.
> I'm curious to know if there are folks using this field. We do (did)
> have a use case for it.
>
> Flavio
> >
> >Regards,
> >Daniel
> >
> >[1] https://review.openstack.org/#/c/76234/
> >--
> >|: http://berrange.com -o-
> http://www.flickr.com/photos/dberrange/ :|
> >|: http://libvirt.org -o-
> http://virt-manager.org :|
> >|: http://autobuild.org -o-
> http://search.cpan.org/~danberr/ :|
> >|: http://entangle-photo.org -o-
> http://live.gnome.org/gtk-vnc :|
> >
> >__________________________________________________________________________
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> @flaper87
> Flavio Percoco
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: not available
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/b5373b24/attachment-0001.pgp
> >
>
> ------------------------------
>
> Message: 35
> Date: Tue, 19 May 2015 22:12:16 +0000
> From: "Clark, Robert Graham" <robert.clark at hp.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [security] / IDS + openstack meeting in
> Vancouver 4:10 Wednesday May 20
> Message-ID: <D1810296.1CF6C%robert.clark at hp.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Sounds good, I?m not sure if I?ll be able to make it, or in fact if TaaS
> is the way forward, there?s a few different options in this space and
> personally I like bump in the wire OVS - something to discuss :)
>
> I?ll try to make it but I expect this is will be a long running discussion.
>
> Kind Regard
>
> On 19/05/2015 14:29, "Dan Lambright" <dlambrig at redhat.com> wrote:
>
> >Hello,
> >
> >While at the Vancouver summit, it would be good to have an informal
> >meeting on IDS + openstack. My understanding is there has not been a
> >community driven effort in this area to date. It would be good to kick
> >something off. Likely subjects would be neutron plug-ins and scalability
> >(management and monitoring).
> >
> >The best time would probably be after the TaaS talk Wednesday. TaaS may
> >influence what direction to take.
> >
> >I will be next to the ATM machine on the 1st floor, next to where they
> >give away the windbreaker SWAG. I?ll hang out there between 4:10 and
> >4:30. Please feel free to find a drink and walk over. I will also post
> >this announcement to the openstack-dev mailing list
> >(http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev). The
> >subject will contain: [security] {IDS}
> >
> >Thanks,
> >
> >Dan Lambright
> >Red Hat
> >
> >__________________________________________________________________________
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> ------------------------------
>
> Message: 36
> Date: Wed, 20 May 2015 10:16:32 +1200
> From: Robert Collins <robertc at robertcollins.net>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today
> Message-ID:
> <
> CAJ3HoZ2y+R8c2CN8JCJBNtWAEkMzhNhGJvxOBXHmovLnsMvo+g at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 20 May 2015 at 09:30, Victor Stinner <vstinner at redhat.com> wrote:
> > Hi,
> >
> > I found a related issue in glance.
> >
> > "issue with pbr 1.0 release"
> > https://bugs.launchpad.net/glance/+bug/1456800
> >
> > "Modify entry point tests to not require deps"
> > https://review.openstack.org/#/c/184326/
>
> So its the same pattern: pkg_resources is being asked to validate the
> dependencies, and they are failing because pip doesn't have a resolver
> and we've installed something strictly outside the deps of e.g.
> oslo.db.
>
> I recommended on the bug to use require=False, at least until we've
> worked through our management of dependencies to be less fragile.
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
>
>
> ------------------------------
>
> Message: 37
> Date: Tue, 19 May 2015 15:22:28 -0700
> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [nova] Tempest failure help
> Message-ID: <555BB7A4.80501 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
>
>
> On 5/19/2015 2:18 PM, Sam Morrison wrote:
> > Hi nova devs,
> >
> > I have a patch https://review.openstack.org/#/c/181776/ where I have a
> > failing tempest job which I can?t figure out. Can anyone help me?
> >
> > Cheers,
> > Sam
> >
> >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> I dug a little bit in your change and I think the problem is a random az
> getting set as the device_owner. If you look at a change that's passing
> the neutron job, you'll see the device_owner on the port is
> 'compute:None' so instance.availability_zone is None in these test runs.
>
> In your change, it's a random number for the az which is screwing
> something up somewhere. Could be a problem elsewhere in nova, or
> neutron, or tempest, or devstack, that's something I don't know right
> now. :(
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
>
> ------------------------------
>
> Message: 38
> Date: Tue, 19 May 2015 15:25:14 -0700
> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova] Friday summit meetup etherpad
> Message-ID: <555BB84A.7010703 at linux.vnet.ibm.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> I was looking for this earlier in IRC and bauzas was nice enough to give
> me the link, so here is the Friday summit meetup etherpad for people
> that want to drop some notes:
>
> https://etherpad.openstack.org/p/YVR-nova-contributor-meetup
>
> I had a couple of smaller issues that I didn't want to forget about so I
> added those at the bottom.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
>
> ------------------------------
>
> Message: 39
> Date: Wed, 20 May 2015 10:47:03 +1200
> From: Robert Collins <robertc at robertcollins.net>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today
> Message-ID:
> <
> CAJ3HoZ06W9Xi7W56Aic8+WGctFapuwVCZZ9eZrv3YCC__YVnGg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> There was one more issue - https://bugs.launchpad.net/pbr/+bug/1456663
> - which has now been fixed in pbr 1.0.1.
>
> -Rob
>
>
>
> ------------------------------
>
> Message: 40
> Date: Wed, 20 May 2015 11:07:36 +1200
> From: Robert Collins <robertc at robertcollins.net>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [pbr] 1.0.1 released
> Message-ID:
> <CAJ3HoZ1mHTc=
> ZCqnQVPwjfry-g1mNMJa5PgQvzG+2JCpvHEpVQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> We are super psyched to announce the release of:
>
> pbr 1.0.1: Python Build Reasonableness
>
> With source available at:
>
> http://git.openstack.org/cgit/openstack-dev/pbr
>
> For more details, please see the git log history below and:
>
> http://launchpad.net/pbr/+milestone/1.0.1
>
> Please report issues through launchpad:
>
> http://bugs.launchpad.net/pbr
>
> Changes in pbr 1.0.0..1.0.1
> ---------------------------
>
> b72e446 Remove self.pre_run calls in packaging.py
> 8e87679 Update hacking to 0.10.x series
>
> Diffstat (except docs and test files)
> -------------------------------------
>
> pbr/packaging.py | 2 --
> test-requirements.txt | 2 +-
> 2 files changed, 1 insertion(+), 3 deletions(-)
>
>
> Requirements updates
> --------------------
>
> diff --git a/test-requirements.txt b/test-requirements.txt
> index 2b33504..6e4521c 100644
> --- a/test-requirements.txt
> +++ b/test-requirements.txt
> @@ -4 +4 @@ fixtures>=0.3.14
> -hacking>=0.9.2,<0.10
> +hacking>=0.10.0,<0.11
>
>
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
>
>
> ------------------------------
>
> Message: 41
> Date: Tue, 19 May 2015 17:09:05 -0700
> From: Douglas Mendiz?bal <douglas.mendizabal at rackspace.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [barbican] Nominating Kaitlin Farr for
> barbican-core
> Message-ID: <555BD0A1.5090206 at rackspace.com>
> Content-Type: text/plain; charset="utf-8"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi All,
>
> I would like to nominate Kaitlin Farr for barbican-core.
>
> Kaitlin has been contributing to the project for a long time, both by
> contributing code to Barbican, python-barbicanclient and Castellan,
> and also by providing valuable reviews. [1]
>
> As a reminder to the rest of the core team, we use the process
> outlined in https://wiki.openstack.org/wiki/Barbican/CoreTeam to add
> members to the barbican-core team.
>
> Thanks,
> Douglas Mendiz?bal
>
> [1] http://stackalytics.com/report/contribution/barbican-group/90
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - https://gpgtools.org
>
> iQIcBAEBCgAGBQJVW9CgAAoJEB7Z2EQgmLX7u6kP/22G3NqsnJmKRsnw065btt8z
> /Sb7OqFa2RKuIKk88a9yehwRuunh2YCdfLmXta1+XXpucghG9dbflfFVGU4/VujX
> VG/B3yUXTBYT2kn72mtwpKk4S6mYXBPn+fpKGR7iJrifYSg55XO7a2c2m/xIC8pO
> R9+d5/8ZztxS1UbmhNuqLwBDpo9FIG+5CoWOfYPTAQ1TxB/SIs2ltk4jzLaU05yb
> 5LTG3uq5K3CT+LvM3Rl6SCZ7bIiTmaTuPsXMnqqLiqhya90U63VJGGXUE1yjW11G
> Kgm7yxUV8DkcESHXEe0aW8hpLMuGKda/f83XetGN27+YpM3/G1z8N656zLX9sF3t
> oVU7dWnARn9NsByFP9ASg8BCk8iWr/mCeB/fajwXT95C+OXAicNWn5jXKowXQhQH
> v4XaFrjafROLdJocgH0mfcoEbTXZXlsKyHYtnZdwAO+T06RNd21c/lnNiG1rMYeh
> 2Yl48nzxxx33YprizHDRMEhABIb11HO040+j+EHNCvbsGSJGZIZmzzbxNe2QGXkx
> q++JvMBW60pPd6pi7nEVjbjSEZhb6f6xHs13/y+nZ9NCSNkUPx1UoxKz18JRtrLi
> /XDZLv6D92Trlaxae9mpVlWTM1elYPWSm3QVMxMrSP9wtAYbUIoq0PN+WwKk/1J7
> WaeQpFjA1SdFHj5uPNZk
> =1OIW
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 42
> Date: Wed, 20 May 2015 00:20:47 +0000
> From: "Dillon, Nathaniel" <nathaniel.dillon at hp.com>
> To: OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [security] Nominating Mike McCune as
> Security-Doc Core
> Message-ID: <9970D613-EDC0-4CC3-92DD-275E3D8FA187 at hp.com>
> Content-Type: text/plain; charset="us-ascii"
>
> To the Security and Docs groups as well as other interested parties,
>
> I would like to nominate Mike McCune to the Security Guide core. He has
> been contributing to the Security Guide for about six months now, and he
> has been a consistent participant improving content and helping new
> submittors. In addition, he knows the inner workings of the guide, having
> created and merged for the security guide the chapter on Sahara.
>
> Please chime in with your agreement, or concerns.
>
> Thanks,
>
> Nathaniel
>
>
> ------------------------------
>
> Message: 43
> Date: Wed, 20 May 2015 12:05:01 +1000
> From: Andrew Beekhof <abeekhof at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering
> Message-ID: <D7FDCAA7-59D2-4CA4-9361-30EF3D1390AB at redhat.com>
> Content-Type: text/plain; charset=utf-8
>
>
> > On 20 May 2015, at 6:05 am, Andrew Woodward <xarses at gmail.com> wrote:
> >
> >
> >
> > On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof <abeekhof at redhat.com>
> wrote:
> >
> > > On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / ??? <
> zhengsheng at awcloud.com> wrote:
> > >
> > > Thank you Andrew.
> > >
> > > on 2015/05/05 08:03, Andrew Beekhof wrote:
> > >>> On 28 Apr 2015, at 11:15 pm, Bogdan Dobrelya <bdobrelia at mirantis.com>
> wrote:
> > >>>
> > >>>> Hello,
> > >>> Hello, Zhou
> > >>>
> > >>>> I using Fuel 6.0.1 and find that RabbitMQ recover time is long after
> > >>>> power failure. I have a running HA environment, then I reset power
> of
> > >>>> all the machines at the same time. I observe that after reboot it
> > >>>> usually takes 10 minutes for RabittMQ cluster to appear running
> > >>>> master-slave mode in pacemaker. If I power off all the 3
> controllers and
> > >>>> only start 2 of them, the downtime sometimes can be as long as 20
> minutes.
> > >>> Yes, this is a known issue [0]. Note, there were many bugfixes, like
> > >>> [1],[2],[3], merged for MQ OCF script, so you may want to try to
> > >>> backport them as well by the following guide [4]
> > >>>
> > >>> [0] https://bugs.launchpad.net/fuel/+bug/1432603
> > >>> [1] https://review.openstack.org/#/c/175460/
> > >>> [2] https://review.openstack.org/#/c/175457/
> > >>> [3] https://review.openstack.org/#/c/175371/
> > >>> [4] https://review.openstack.org/#/c/170476/
> > >> Is there a reason you?re using a custom OCF script instead of the
> upstream[a] one?
> > >> Please have a chat with David (the maintainer, in CC) if there is
> something you believe is wrong with it.
> > >>
> > >> [a]
> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/rabbitmq-cluster
> > >
> > > I'm using the OCF script from the Fuel project, specifically from the
> > > "6.0" stable branch [alpha].
> >
> > Ah, I?m still learning who is who... i thought you were part of that
> project :-)
> >
> > >
> > > Comparing with upstream OCF code, the main difference is that Fuel
> > > RabbitMQ OCF is a master-slave resource. Fuel RabbitMQ OCF does more
> > > bookkeeping, for example, blocking client access when RabbitMQ cluster
> > > is not ready. I beleive the upstream OCF should be OK to use as well
> > > after I read the code, but it might not fit into the Fuel project. As
> > > far as I test, the Fuel OCF script is good except sometimes the full
> > > reassemble time is long, and as I find out, it is mostly because the
> > > Fuel MySQL Galera OCF script keeps pacemaker from promoting RabbitMQ
> > > resource, as I mentioned in the previous emails.
> > >
> > > Maybe Vladimir and Sergey can give us more insight on why Fuel needs a
> > > master-slave RabbitMQ.
> >
> > That would be good to know.
> > Browsing the agent, promote seems to be a no-op if rabbit is already
> running.
> >
> >
> > To the master / slave reason due to how the ocf script is structured to
> deal with rabbit's poor ability to handle its self in some scenarios.
> Hopefully the state transition diagram [5] is enough to clarify what's
> going on.
> >
> > [5] http://goo.gl/PPNrw7
>
> Not really.
> It seems to be under the impression you can skip started and go directly
> from stopped to master.
>
>
> ------------------------------
>
> Message: 44
> Date: Wed, 20 May 2015 05:10:46 +0000
> From: "A, Keshava" <keshava.a at hp.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, "pc at michali.net" <
> pc at michali.net>
> Cc: Kalyankumar Asangi <kalyana at huawei.com>
> Subject: Re: [openstack-dev] [neutron] How should edge services APIs
> integrate into Neutron?
> Message-ID:
> <
> 891761EAFA335D44AD1FFDB9B4A8C063F7B0BD at G9W0762.americas.hpqcorp.net>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Vikarm
>
>
>
> 1. What are the use case of ? Dynamic Routing Framework? ?
>
> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing
>
> You are thinking of running both IGP and BGP in the same neutron ?
>
> In which kind of scenario we need this ? It is better have more
> information.
>
> We also need to think do we really need IGP with in the cloud, or we only
> need BGP for external connectivity .
>
> In that scenario, we may not go for Routing Framework, and not to
> complicate things too much.
>
> If some things works well with L2 with in the cloud lets not touch those
> area. We may need to see where there are real problem.
>
>
>
> 2. What is the use case of ?Prefix Clashing? ? You are thinking of
> running multiple routing protocol and they will learn ?same prefix +
> Route? ?
>
>
> https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol
>
> In my opinion, with in the cloud we may not such deployment scenario.
>
>
> Let us not mix underlay network with overlay network .
> Both will go as different solution provider, so different business domain.
>
> This is my thoughts .
>
> keshava
>
> From: Vikram Choudhary [mailto:vikram.choudhary at huawei.com]
> Sent: Wednesday, May 06, 2015 10:45 AM
> To: pc at michali.net; openstack-dev at lists.openstack.org
> Cc: Kalyankumar Asangi
> Subject: Re: [openstack-dev] [neutron] How should edge services APIs
> integrate into Neutron?
>
> Hi Paul,
>
> Thanks for starting this mail thread. We are also eyeing for supporting
> MPBGP in neutron and will like to actively participate in this discussion.
> Please let me know about the IRC channels which we will be following for
> this discussion.
>
> Currently, I am following below BP?s for this work.
> https://blueprints.launchpad.net/neutron/+spec/edge-vpn
> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing
> https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework
>
> https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol
>
> Moreover, a similar kind of work is being headed by Cathy for defining an
> intent framework which can extended for various use case. Currently it will
> be leveraged for SFC but I feel the same can be used for providing intend
> VPN use case.
>
> https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining
>
> Thanks
> Vikram
>
> From: Paul Michali [mailto:pc at michali.net]
> Sent: 06 May 2015 01:38
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron] How should edge services APIs integrate
> into Neutron?
>
> There's been talk in VPN land about new services, like BGP VPN and DM VPN.
> I suspect there are similar things in other Advanced Services. I talked to
> Salvatore today, and he suggested starting a ML thread on this...
>
> Can someone elaborate on how we should integrate these API extensions into
> Neutron, both today, and in the future, assuming the proposal that
> Salvatore has is adopted?
>
> I could see two cases. The first, and simplest, is when a feature has an
> entirely new API that doesn't leverage off of an existing API.
>
> The other case would be when the feature's API would dovetail into the
> existing service API. For example, one may use the existing vpn_service API
> to create the service, but then create BGP VPN or DM VPN connections for
> that service, instead of the IPSec connections we have today.
>
> If there are examples already of how to extend an existing API extension
> that would help in understanding how to do this.
>
> I see that there are RESOURCE_ATTRIBUTE_MAPs with the information on the
> API, and I see that the plugin has a supported_extension_aliases, but
> beyond that, I'm not really sure how it all hooks up, and how to extend an
> existing extension.
>
> I'm assuming that the python-neutronclient would also need to be updated.
>
>
> So... the intent here is to start some discussion on how we do this, such
> that we have some things figured out before the summit and can save some
> time.
>
> Thanks in advance,
>
> Paul Michali (pc_m)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/de4ba3aa/attachment.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 37, Issue 45
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150520/8ac9b3e5/attachment-0001.html>
More information about the OpenStack-dev
mailing list