settingsLogin | Registersettings

Re: [openstack-dev] OpenStack-dev Digest, Vol 37, Issue 45

0 votes

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@lists.openstack.org
wrote:

Send OpenStack-dev mailing list submissions to
openstack-dev@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@lists.openstack.org

You can reach the person managing the list at
openstack-dev-owner@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: doquality_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: doquality_warnings and the hypervisor
    support matrix (Daniel P. Berrange)

    1. [Security][Glance] Design session for image
      signing/encryption (Clark, Robert Graham)
    2. Re: [Security][Glance] Design session for image
      signing/encryption (Louis Taylor)
    3. Re: [nova] libvirt: doquality_warnings and the hypervisor
      support matrix (Markus Zoeller)
    4. Re: [oslo] needed, driver for oslo.db thursday session
      (Davanum Srinivas)
    5. Re: [oslo] needed, driver for oslo.db thursday session
      (Davanum Srinivas)
    6. [nova][glance] Format of 'locations' data in image metadata ?
      (Daniel P. Berrange)
    7. Re: [oslo] needed, driver for oslo.db thursday session
      (Jeremy Stanley)
    8. Re: [Glance] glance social event at Vancouver summit
      (Alexander Tivelkov)
    9. Re: [nova][glance] Format of 'locations' data in image
      metadata ? (Nikhil Komawar)
    10. Re: [nova-docker] Status update (ADAMS, STEVEN E)
    11. Re: [nova-docker] Status update (Davanum Srinivas)
    12. Re: [Manila] Question to driver maintainers (Ben Swartzlander)
    13. [NFV][Tacker] OpenStack based VNF Manager (Sridhar Ramaswamy)
    14. Re: [Fuel][Plugin] Contributor license agreement for fuel
      plugin code? (Andrew Woodward)
    15. Re: [Fuel] Speed Up RabbitMQ Recovering (Andrew Woodward)
    16. Re: [surge] Introducing Surge - rapid deploy/scale stream
      processing systems on OpenStack (Sergey Lukjanov)
    17. Re: [new][cognitive] Announcing Cognitive - a project to
      deliver Machine Learning as a Service for OpenStack (Sergey Lukjanov)
    18. Re: [surge] Introducing Surge - rapid deploy/scale stream
      processing systems on OpenStack (Sergey Lukjanov)
    19. Re: [glance] missing implementation on glance basic quota
      (Fei Long Wang)
    20. [nova] Tempest failure help (Sam Morrison)
    21. [sahara] no meetings May 21 and 28 (Sergey Lukjanov)
    22. [security] / IDS + openstack meeting in Vancouver 4:10
      Wednesday May 20 (Dan Lambright)
    23. Re: [all] gate pep8 jobs broken today (Victor Stinner)
    24. Re: / IDS + openstack meeting in Vancouver 4:10 Wednesday May
      20 (Alan Kavanagh)
    25. Re: [nova][glance] Format of 'locations' data in image
      metadata ? (Flavio Percoco)
    26. Re: [security] / IDS + openstack meeting in Vancouver 4:10
      Wednesday May 20 (Clark, Robert Graham)
    27. Re: [all] gate pep8 jobs broken today (Robert Collins)
    28. Re: [nova] Tempest failure help (Matt Riedemann)
    29. [nova] Friday summit meetup etherpad (Matt Riedemann)
    30. Re: [all] gate pep8 jobs broken today (Robert Collins)
    31. [pbr] 1.0.1 released (Robert Collins)
    32. [barbican] Nominating Kaitlin Farr for barbican-core
      (Douglas Mendiz?bal)
    33. [security] Nominating Mike McCune as Security-Doc Core
      (Dillon, Nathaniel)
    34. Re: [Fuel] Speed Up RabbitMQ Recovering (Andrew Beekhof)
    35. 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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [fuel] Enable healthcheck middleware
Message-ID:
<CAOmgvhz8BT2ayfCFxsw96Kv749ML2-7uoBYJqY8GRQg=
a1vAEg@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@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@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 /" 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@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@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
thursday session
Message-ID:
<CAKAueAPNx9yTbU73HqJaqvBW8kU2VC9Tm68RYozAxY=
CoYRg@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@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel] python-fuelclient 6.1.0 is
released
Message-ID:
<
CAFkLEwr1U_1V7p7Uu8yUzbGGf0jkzuzMKKK5QNqeEOoqCGYSJw@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@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@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@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [glance] missing implementation on glance
basic quota
Message-ID:
<
CAAhuP9SYvzjzZZoA-Ki9MgmZuW7XSUs0u2i-Ue2hcXNhANZw@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@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@redhat.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
thursday session
Message-ID: 555B47B8.5070608@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@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@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@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@de.ibm.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] libvirt: doquality_warnings and the
hypervisor support matrix
Message-ID:
<
OFB7028464.2C12B897-ONC1257E4A.00506B48-C1257E4A.0050B850@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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
Message-ID:
1601921203.2012587.1432046577765.JavaMail.zimbra@redhat.com
Content-Type: text/plain; charset=utf-8

Hi Igor,

From: "Igor Malinovskiy" imalinovskiy@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] missing implementation on glance basic
quota
Message-ID: 555B4DD1.1030405@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@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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] libvirt: doquality_warnings and
the hypervisor support matrix
Message-ID: 20150519145617.GC8535@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 doquality_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 doquality_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@hp.com
To: OpenStack List openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Security][Glance] Design session for image
signing/encryption
Message-ID: D1809E63.1CD42%robert.clark@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@kragniz.eu
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Security][Glance] Design session for
image signing/encryption
Message-ID: 20150519151333.GA14295@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@de.ibm.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] libvirt: doquality_warnings and
the hypervisor support matrix
Message-ID:
<
OF4A923A23.CE73EC16-ONC1257E4A.0055D550-C1257E4A.0056071C@de.ibm.com>
Content-Type: text/plain; charset="US-ASCII"

"Daniel P. Berrange" berrange@redhat.com wrote on 05/19/2015 04:56:17
PM:

From: "Daniel P. Berrange" berrange@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Date: 05/19/2015 05:09 PM
Subject: Re: [openstack-dev] [nova] libvirt: doquality_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 doquality_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 doquality_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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
thursday session
Message-ID:
<
CANw6fcHc8JYG_3JRtMvixmweYVJEnpHQY+0zP+TfbzmypG6gKw@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@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@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@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@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
thursday session
Message-ID:
<CANw6fcGYUYsGaNm=6Rsz=
zzu8RTHDtoA4ioG1fpV7P0yRtSUPA@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@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@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@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@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@redhat.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova][glance] Format of 'locations' data in
image metadata ?
Message-ID: 20150519161927.GH8535@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@yuggoth.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [oslo] needed, driver for oslo.db
thursday session
Message-ID: 20150519171729.GN2731@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Glance] glance social event at Vancouver
summit
Message-ID: <-2437030608731294219@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@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@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@gmail.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][glance] Format of 'locations' data
in image metadata ?
Message-ID: 555B73DF.9070604@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@att.com
To: "openstack-dev@lists.openstack.org"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova-docker] Status update
Message-ID:
<
F169453C03E0074D99BA6CCA8C42112714507326@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova-docker] Status update
Message-ID:
<CANw6fcEYTLHLknVmoL0Sjn=Y4x=
6dtMBjqfye_sRyO2sS++RTA@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@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@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@swartzlander.org
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Manila] Question to driver maintainers
Message-ID: 555B91EB.20203@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [NFV][Tacker] OpenStack based VNF Manager
Message-ID:
<
CAK6Sh4DU9z1yG5s9Q4faHr5rF_2Nsvzph0ujHp3TDU6zGXWA@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


Message: 23
Date: Tue, 19 May 2015 19:53:51 +0000
From: Andrew Woodward xarses@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Cc: Joe Marshall Joe.Marshall@metaswitch.com
Subject: Re: [openstack-dev] [Fuel][Plugin] Contributor license
agreement for fuel plugin code?
Message-ID:
<CACEfbZhV-KhKpVtQps-61WwRXZT4vsPMyzB0=
6nmH40cgSWA7Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Wed, May 6, 2015 at 4:06 AM Emma Gordon (projectcalico.org) <
emma@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, Zhou Zheng Sheng / ???
zhengsheng@awcloud.com
Subject: Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering
Message-ID:
<
CACEfbZj7bHJD7ZH9Dv13k3QUN44VNyfTyvztBr6Oj_bq+Hw-kA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof abeekhof@redhat.com wrote:

On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / ??? <
zhengsheng@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@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/

  1. 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@node-1:~# rabbitmqctl clusterstatus
Cluster status of node 'rabbit@node-1' ...
[{nodes,[{disc,['rabbit@node-1','rabbit@node-2']}]},
{running
nodes,['rabbit@node-1']},
{clustername,<<"rabbit@node-2">>},
{partitions,[]}]
...done.
root@node-2:~# rabbitmqctl cluster
status
Cluster status of node 'rabbit@node-2' ...
[{nodes,[{disc,['rabbit@node-2']}]}]
...done.
root@node-3:~# rabbitmqctl clusterstatus
Cluster status of node 'rabbit@node-3' ...
[{nodes,[{disc,['rabbit@node-1','rabbit@node-2','rabbit@node-3']}]},
{running
nodes,['rabbit@node-3']},
{cluster_name,<<"rabbit@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 "forceload" 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
"trytostartrmqapp()" function.

touch "${MNESIAFILES}/forceload" && \
chown rabbitmq:rabbitmq "${MNESIAFILES}/forceload"
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@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@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [surge] Introducing Surge - rapid
deploy/scale stream processing systems on OpenStack
Message-ID:
<
CA+GZd7_fNwFihgfLCqs-PZnyFRXRBd6hOLd7G7WdZnQVAmdypQ@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@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@gmail.com
wrote:

On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta ddutta@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@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@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@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@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@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@nicira.com
wrote:

On 15 May 2015 at 00:19, Debojyoti Dutta ddutta@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.

... 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@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@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@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@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [surge] Introducing Surge - rapid
deploy/scale stream processing systems on OpenStack
Message-ID:
<
CA+GZd75+Y7Es6YF7fMcOXBJ4fURFMzJhrVmG28hwS6c-_tPw@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@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@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@gmail.com
wrote:

On Fri, May 15, 2015 at 10:13 AM, Debojyoti Dutta ddutta@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@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@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@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@catalyst.net.nz
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] missing implementation on glance
basic quota
Message-ID: 555BA54B.9060204@catalyst.net.nz
Content-Type: text/plain; charset="utf-8"

We're using userstoragequota 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@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@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@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@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Tempest failure help
Message-ID: 7712CFBF-68BF-4EC9-A885-626BC283A34F@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@mirantis.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [sahara] no meetings May 21 and 28
Message-ID:
<
CA+GZd7_KzQTvkgrNW-OphqaR9+yQL6xdwHjK0uB52EigG0vmsg@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@redhat.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [security] / IDS + openstack meeting in
Vancouver 4:10 Wednesday May 20
Message-ID:
155985814.1002516.1432070980605.JavaMail.zimbra@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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today
Message-ID:
297176382.2081976.1432071007216.JavaMail.zimbra@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@robertcollins.net
To: "OpenStack Development Mailing List" <
openstack-dev@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@hp.com
Distinguished Technologist
HP Converged Cloud


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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@ericsson.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] / IDS + openstack meeting in Vancouver
4:10 Wednesday May 20
Message-ID:
C977B257ADF8814C8EB4FB66BB9D0C2EA3BA05@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@redhat.com]
Sent: May-19-15 2:30 PM
To: openstack-dev@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@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@redhat.com
To: "Daniel P. Berrange" berrange@redhat.com, "OpenStack Development
Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][glance] Format of 'locations' data
in image metadata ?
Message-ID: 20150519220137.GC18488@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

--
@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@hp.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [security] / IDS + openstack meeting in
Vancouver 4:10 Wednesday May 20
Message-ID: D1810296.1CF6C%robert.clark@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@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@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@robertcollins.net
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today
Message-ID:
<
CAJ3HoZ2y+R8c2CN8JCJBNtWAEkMzhNhGJvxOBXHmovLnsMvo+g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On 20 May 2015 at 09:30, Victor Stinner vstinner@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@hp.com
Distinguished Technologist
HP Converged Cloud


Message: 37
Date: Tue, 19 May 2015 15:22:28 -0700
From: Matt Riedemann mriedem@linux.vnet.ibm.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Tempest failure help
Message-ID: 555BB7A4.80501@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@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 deviceowner. 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@linux.vnet.ibm.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [nova] Friday summit meetup etherpad
Message-ID: 555BB84A.7010703@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@robertcollins.net
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [all] gate pep8 jobs broken today
Message-ID:
<
CAJ3HoZ06W9Xi7W56Aic8+WGctFapuwVCZZ9eZrv3YCC__YVnGg@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@robertcollins.net
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [pbr] 1.0.1 released
Message-ID:
<CAJ3HoZ1mHTc=
ZCqnQVPwjfry-g1mNMJa5PgQvzG+2JCpvHEpVQ@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@hp.com
Distinguished Technologist
HP Converged Cloud


Message: 41
Date: Tue, 19 May 2015 17:09:05 -0700
From: Douglas Mendiz?bal douglas.mendizabal@rackspace.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [barbican] Nominating Kaitlin Farr for
barbican-core
Message-ID: 555BD0A1.5090206@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@hp.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [security] Nominating Mike McCune as
Security-Doc Core
Message-ID: 9970D613-EDC0-4CC3-92DD-275E3D8FA187@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@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel] Speed Up RabbitMQ Recovering
Message-ID: D7FDCAA7-59D2-4CA4-9361-30EF3D1390AB@redhat.com
Content-Type: text/plain; charset=utf-8

On 20 May 2015, at 6:05 am, Andrew Woodward xarses@gmail.com wrote:

On Thu, May 7, 2015 at 5:01 PM Andrew Beekhof abeekhof@redhat.com
wrote:

On 5 May 2015, at 1:19 pm, Zhou Zheng Sheng / ??? <
zhengsheng@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@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@hp.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, "pc@michali.net" <
pc@michali.net>
Cc: Kalyankumar Asangi kalyana@huawei.com
Subject: Re: [openstack-dev] [neutron] How should edge services APIs
integrate into Neutron?
Message-ID:
<
891761EAFA335D44AD1FFDB9B4A8C063F7B0BD@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.

  1. 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@huawei.com]
Sent: Wednesday, May 06, 2015 10:45 AM
To: pc@michali.net; openstack-dev@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@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 RESOURCEATTRIBUTEMAPs with the information on the
API, and I see that the plugin has a supportedextensionaliases, 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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

End of OpenStack-dev Digest, Vol 37, Issue 45



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked May 20, 2015 in openstack-dev by Ajay_Sharma (120 points)   1
...