settingsLogin | Registersettings

Re: [openstack-dev] OpenStack-dev Digest, Vol 47, Issue 56

0 votes

Hi, Sabari

Thanks for your reply.

Yes, I had tuned FileSystem to vsphere. Then I create an image, image info
shows it stores in VMware
datastore.

I had followed your suggestion, add showmultiplelocations to glance api
conf.
Then I repeat the operations.

Results from two snapshotted images:
locations [{"url":
"file:///var/lib/glance/images/0cdd8188-537e-49e2-b173-7de122070574",
"metadata": {}}]

locations [{"url": "vsphere://
172.20.2.38/folder/openstackglance/f462c06a-f202-4b1f-a89a-17f72264b502?dcPath=IDCTest&dsName=LUN03-00",
"metadata": {}}]

2016-03-14 20:00 GMT+08:00 openstack-dev-request@lists.openstack.org:

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: [QA] Not running for PTL (Daniel Mellado)
  2. [networking-ovn][devstack] devstack deoloyed with
    networking-ovn come accross error 'ovs-ofctl: br-int is not a
    bridge or a socket' (Wilence Yao)
  3. Re: [Fuel] Removing logs from Fuel Web UI and Nailgun
    (Anastasia Urlapova)
  4. [Third-Party][CI] Modify&delete&add CI accouts in CI group
    (Watanabe, Isao)
  5. Re: [Fuel] Removing logs from Fuel Web UI and Nailgun
    (Bogdan Dobrelya)
  6. [Murano] [FFE] Support for Magnum Plugin (Madhuri)
  7. Re: [Murano] [FFE] Support for Magnum Plugin (Kirill Zaitsev)
  8. Re: [heat] convergence cancel messages (Anant Patil)
  9. Re: [telemetry] stepping down as PTL (Julien Danjou)

    1. Re: [gnocchi] strange behavior (Julien Danjou)
    2. Re: [neutron][TaaS] Possible points to be considered for TaaS
      Spec (Irena Berezovsky)
    3. Re: [Nova][Glance_store][VMware] Different glance store for
      Nova snapshot in VMware (Sabari Murugesan)
    4. Re: [Cinder] PTL Candidacy (Gorka Eguileor)
    5. [OpenStack-Ansible] PTL Candidacy (Jesse Pretorius)
    6. [swift3][swift] What happens in swift3? (Andrey Pavlov)
    7. Re: [heat] issue of ResourceGroup in Heat template
      (Duan, Li-Gong (Gary, HPServers-Core-OE-PSC))
    8. Re: [QA] Not running for PTL (Andrea Frittoli)
    9. Re: [nova] stuck review, mtu incorrectly set on vhost-user
      port prevents vm booting. (Markus Zoeller)
    10. Re: [telemetry] stepping down as PTL (Nadya Shakhat)
    11. Re: [Murano] [FFE] Support for Magnum Plugin
      (Nikolay Starodubtsev)

Message: 1
Date: Mon, 14 Mar 2016 09:27:11 +0100
From: Daniel Mellado daniel.mellado.es@ieee.org
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [QA] Not running for PTL
Message-ID: 56E675DF.4020809@ieee.org
Content-Type: text/plain; charset="windows-1252"

Thanks Matt for all your help and support, and glad that you'll be still
around!

El 11/03/16 a las 20:34, Matthew Treinish escribi?:

Hi everyone,

I'm writing this to announce that I am not running for QA PTL this
cycle. I've
been the QA PTL for the past 4 cycles and I think it's time for another
person
to take over the role. I think during the past 4 cycles the QA community
has
grown greatly and become a much larger and stronger community compared
to when
I first took on the position in the Juno cycle.

I strongly believe in the diversity of leadership and ideas, and I don't
want
the community to grow stagnant because it becomes synonymous with just
my voice.
Being a PTL is not the same as being an autocrat and I think it's time
for
another person to step up and take over the QA PTL spot.

That being said, I'm not planning on going anywhere or leaving the
project. I
fully intend to continue working and being heavily involved with the QA
program,
as I have for been the past 2 years. (although maybe with a bit more
free time
now)

-Matt Treinish


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/20160314/f33565e4/attachment-0001.html
>


Message: 2
Date: Mon, 14 Mar 2016 16:36:07 +0800
From: Wilence Yao wilence.yao@gmail.com
To: openstack-dev openstack-dev@lists.openstack.org
Subject: [openstack-dev] [networking-ovn][devstack] devstack deoloyed
with networking-ovn come accross error 'ovs-ofctl: br-int is not a
bridge or a socket'
Message-ID:
<CANAfaUEYjEBq9-XVCp=6e84FNGgBxo5NvLh9k0LJtF7foo=U=
A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello all,

I am going to deploye devstakv with networking-ovn, and I am following with
the doc http://docs.openstack.org/developer/networking-ovn/testing.html

However, error occured in running stack.sh.

Traceback below here:

2016-03-14 08:14:44.729 | cd datapath/linux && make modulesinstall
2016-03-14 08:14:44.735 | make[1]: Entering directory
/opt/stack/ovs/datapath/linux' 2016-03-14 08:14:44.735 | make -C /lib/modules/3.10.0-327.10.1.el7.x86_64/build M=/opt/stack/ovs/datapath/linux modules_install 2016-03-14 08:14:45.079 | make[2]: Entering directory/usr/src/kernels/3.10.0-327.10.1.el7.x86
64'
2016-03-14 08:14:45.098 | INSTALL
/opt/stack/ovs/datapath/linux/openvswitch.ko
2016-03-14 08:14:45.148 | Can't read private key
2016-03-14 08:14:45.151 | INSTALL
/opt/stack/ovs/datapath/linux/vport-geneve.ko
2016-03-14 08:14:45.183 | Can't read private key
2016-03-14 08:14:45.186 | INSTALL
/opt/stack/ovs/datapath/linux/vport-gre.ko
2016-03-14 08:14:45.218 | Can't read private key
2016-03-14 08:14:45.220 | INSTALL
/opt/stack/ovs/datapath/linux/vport-lisp.ko
2016-03-14 08:14:45.248 | Can't read private key
2016-03-14 08:14:45.250 | INSTALL
/opt/stack/ovs/datapath/linux/vport-stt.ko
2016-03-14 08:14:45.278 | Can't read private key
2016-03-14 08:14:45.281 | INSTALL
/opt/stack/ovs/datapath/linux/vport-vxlan.ko
2016-03-14 08:14:45.309 | Can't read private key
2016-03-14 08:14:45.322 | DEPMOD 3.10.0-327.10.1.el7.x8664
2016-03-14 08:14:45.668 | make[2]: Leaving directory
/usr/src/kernels/3.10.0-327.10.1.el7.x86_64' 2016-03-14 08:14:45.669 | depmodsed -n 's/#define UTS
RELEASE
"([^"]*)"/\1/p'

/lib/modules/3.10.0-327.10.1.el7.x86_64/build/include/generated/utsrelease.h2016-03-14 08:14:45.986 | make[1]: Leaving directory/opt/stack/ovs/datapath/linux'
2016-03-14 08:14:46.007 | modprobe: FATAL: Module openvswitch is in use.
2016-03-14 08:14:46.009 | Error on exit
2016-03-14 08:14:46.487 | ovs-vsctl:
unix:/usr/local/var/run/openvswitch/db.sock: database connection failed (No
such file or directory)
2016-03-14 08:14:46.498 | ovs-ofctl: br-int is not a bridge or a socket
2016-03-14 08:14:46.508 | ovs-ofctl: br-tun is not a bridge or a socket
2016-03-14 08:14:46.518 | ovs-ofctl: br-ex is not a bridge or a socket
2016-03-14 08:14:46.529 | ovs-ofctl: br-int is not a bridge or a socket
2016-03-14 08:14:46.540 | ovs-ofctl: br-tun is not a bridge or a socket
2016-03-14 08:14:46.551 | ovs-ofctl: br-ex is not a bridge or a socket

I know that in this process , stack.sh will install openvswitch when
processing neutron, then it will uninstall openvswitch and make && make
install openvswitch from ovs code source again.

Because of uninstalling of openvswitch, br-int and other brigeds loss from
ovs, so the new ovn process come accross the error that no bridges
br-int/br-ex/br-tun.

Is this a networking-ovn bug or a devstack bug?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/4daf867f/attachment-0001.html
>


Message: 3
Date: Mon, 14 Mar 2016 11:38:45 +0300
From: Anastasia Urlapova aurlapova@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and
Nailgun
Message-ID:
<
CAC+XjbZMXMLdhgezYocxuD49fx1Uw3WqBjAtxe2G-mwxboKZ_Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

+1 to Vitaliy, it would be nice find somewhere a details for migration.
And one more concern I should highlight - for some users logless UI may be
challenging thing.
The logs removing shouldn't affect the UX.

Nastya.

On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward xarses@gmail.com wrote:

I think we can address it by retaining deployment logs in nailgun/ui,
this
also removes the chicken and egg problem. after LMA is deployed it can be
allowed to re-own 'logs' button on UI once it's deployed, including
redirecting fuel logs there.

On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov <
mscherbakov@mirantis.com>
wrote:

We can sort out details later. In a worst case, the warning will be
there
in Newton too, and feature will go away only in O* release. So let's
proceed with the bug..

On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh <
vkramskikh@mirantis.com>
wrote:

We can add the warning, but I think before we do this we should have
clear migration plan. According to this thread, some parts are still
not
clear.

2016-03-11 22:00 GMT+03:00 Mike Scherbakov mscherbakov@mirantis.com:

Deprecation warning for Fuel Mitaka:
https://bugs.launchpad.net/fuel/+bug/1556244.

On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko me@romcheg.me
wrote:

Since there are a lot of supporters for this idea, what do you folks
think about creating a BP spec where we can describe what we should
do in
order to remove logs from UI and Nailgun? I also propose to file a
bug
about adding a deprecation warning to Mitaka release of Fuel.

11 ???. 2016 ?. ? 16:55 Bogdan Dobrelya bdobrelia@mirantis.com
???????(??):

On 03/11/2016 04:46 PM, Mike Scherbakov wrote:

+1 to remove logs from Fuel UI in Fuel Newton.
In Fuel Mitaka we'd need to put a deprecation warning somewhere.

I agree, there is not much sense having non flexible (no content
filters) logs view in UI. LMA plugins shall cover this area as well.

On Fri, Mar 11, 2016, 04:57 Patrick Petit <ppetit@mirantis.com
<mailto:ppetit@mirantis.com ppetit@mirantis.com>> wrote:

On 11 March 2016 at 12:51:40, Igor Kalnitsky
(ikalnitsky@mirantis.com <mailto:ikalnitsky@mirantis.com
ikalnitsky@mirantis.com>) wrote:

Patrick,

Sorry, but I meant another question. I thought that LMA plugin
should
be installed in some environment before we can start use it. Is
this a
case? If so, it means we can't use for master node until some
environment is deployed.

Right. This is the chicken and egg problem I mentioned earlier...

But this is not a ?problem? specific to Fuel. My take on this is
is
that ops management tooling (logging, monitoring) should be
installed off-band before any OpenStack deployment. In fact, in
real-world usage, we frequently get asks to have the monitoring
and
logging services of StackLight installed permanently for
multi-enviroments. And so, one approach would be to make
Stacklight
backend services the first bits of software installed by Fuel (if
not already there), then reconfigure Fuel to hook into those
services and only then, enter into the regular OpenStack
provisioning mode.

On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
<ppetit@mirantis.com <mailto:ppetit@mirantis.com
ppetit@mirantis.com>> wrote:

On 11 March 2016 at 11:34:32, Igor Kalnitsky (
ikalnitsky@mirantis.com
<mailto:ikalnitsky@mirantis.com ikalnitsky@mirantis.com>)
wrote:

Hey Roman,

Thank you for bringing this up. +1 from my side, especially taking
into account the patch where we tried to solve logrotated logs
problem

[1]. It's complex and unsupportable, as well as already existed
logview code in Nailgun.

Patrick, Simon,

Does LMA plugin support logs from master node? Or it's designed to
watch environment's logs?

No it?s not designed specifically for environment logs. Can be
adapted
to
any log format.

Would just need to write a parser like you would with logstach when
logs are
not standard.

Patrick

Thanks,
Igor

[1]: https://review.openstack.org/#/c/243240/

On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppetit@mirantis.com
<
mailto:ppetit@mirantis.com ppetit@mirantis.com>> wrote:

Fuelers,

As Simon said, we already have a log centralisation solution for MOS
delivered as a Fuel plugins known as StackLight / LMA toolset. And so
objectively, there is no need to have log management in Nailgun
anymore.
To
go one step further we suggested several times to have a StackLight
agent
installed on the Fuel master node to also collect and centralise
those

logs.
There is a little bit of a chicken and egg problem to resolve but I
think
it
is worth a try to have that nailed down in the roadmap for Fuel 10.
Cheers
- Patrick

On 11 March 2016 at 10:07:28, Simon Pasquier (spasquier@mirantis.com
<
mailto:spasquier@mirantis.com spasquier@mirantis.com>)
wrote:

Hello Roman,

On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <me@romcheg.me
<
mailto:me@romcheg.me me@romcheg.me>>
wrote:

Fuelers,

I remember we?ve discussing this topic in our couloirs before but I?d
like
to bring that discussion to a more official format.

Let me state a few reasons to do this:

  • Log management code in Nailgun is overcomplicated
  • Working with logs on big scale deployments is barely possible given
    the
    current representation
  • Due to overcomplexity and ineffectiveness of the code we always get
    recurring bugs like [1]. That eats tons of time to resolve.
  • There are much better specialized tools, say Logstash [2], that can
    deal
    with logs much more effectively.

There may be more reasons bus I think even the already mentioned ones
are
enough to think about the following proposal:

  • Remove Logs tab from Fuel Web UI
  • Remove logs support from Nailgun
  • Create mechanism that allows to configure different log management
    software, say Logstash, Loggly, etc

  • Choose a default software to install and provide a plugin for it
    from

the box

This is what the LMA/StackLight plugins [1][2] are meant for. No need
to
develop anything new.

And I'm +1 with the removal of log management from Fuel. As you said,
it
can't scale...

[1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
[2]
http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/

References
1. https://bugs.launchpad.net/fuel/+bug/1553170
2. https://www.elastic.co/products/logstash

  • romcheg

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

<
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Mike Scherbakov

mihgen


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

--
Best regards,
Bogdan Dobrelya,
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

--
Mike Scherbakov

mihgen


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

--
Vitaly Kramskikh,
Fuel UI Tech Lead,
Mirantis, Inc.


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

--
Mike Scherbakov

mihgen


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

--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community


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/20160314/f575548d/attachment-0001.html
>


Message: 4
Date: Mon, 14 Mar 2016 08:39:53 +0000
From: "Watanabe, Isao" watanabe_isao@jp.fujitsu.com
To: "openstack-dev@lists.openstack.org"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Third-Party][CI] Modify&delete&add CI
accouts in CI group
Message-ID: <AC0F94DB49C0C2439892181E6CDA6E6C172D509A@G01JPEXMBYT05>
Content-Type: text/plain; charset="iso-2022-jp"

Hello, Third-Party Coordinators
Cc?Ramy

Could you please help me about the following CI accounts changes in CI
group?

[1]Add account
Name: Fujitsu ISM CI
Mail: fj-lsoft-ismci@dl.jp.fujitsu.com

[2]Modify
Name: Fujitsu ETERNUS CI
OLD-Email: lsoft-eternusci@ml.css.fujitsu.com
NEW-Email: fj-lsoft-eternusci@dl.jp.fujitsu.com

[3] Modify
OLD-Name: Fujitsu IRMC CI
NEW-Name: Fujitsu iRMC CI
OLD-Email: lsoft-irmcci@ml.css.fujitsu.com
NEW-Email: fj-lsoft-irmcci@dl.jp.fujitsu.com

[4] Modify
Name: Fujitsu C-Fabric CI
OLD-Email: lsoft-cfabricci@ml.css.fujitsu.com
NEW-Email: fj-lsoft-cfabricci@dl.jp.fujitsu.com

[5] Delete
Name: Fujitsu ETERNUS FC CI
Email: lsoft-openstackci@ml.css.fujitsu.com

Best regards,
Watanabe.isao


Message: 5
Date: Mon, 14 Mar 2016 09:53:49 +0100
From: Bogdan Dobrelya bdobrelia@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and
Nailgun
Message-ID: 56E67C1D.1030904@mirantis.com
Content-Type: text/plain; charset=UTF-8

On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:

+1 to Vitaliy, it would be nice find somewhere a details for migration.
And one more concern I should highlight - for some users logless UI may
be challenging thing.
The logs removing shouldn't affect the UX.

Logs will still live at the master node's /var/log/remote

Nastya.

On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <xarses@gmail.com
xarses@gmail.com> wrote:

I think we can address it by retaining deployment logs in
nailgun/ui, this also removes the chicken and egg problem. after LMA
is deployed it can be allowed to re-own 'logs' button on UI once
it's deployed, including redirecting fuel logs there.

On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov
<mscherbakov@mirantis.com <mailto:mscherbakov@mirantis.com>> wrote:

    We can sort out details later. In a worst case, the warning will
    be there in Newton too, and feature will go away only in O*
    release. So let's proceed with the bug..

    On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh
    <vkramskikh@mirantis.com <mailto:vkramskikh@mirantis.com>>

wrote:

        We can add the warning, but I think before we do this we
        should have clear migration plan. According to this thread,
        some parts are still not clear.

        2016-03-11 22:00 GMT+03:00 Mike Scherbakov
        <mscherbakov@mirantis.com <mailto:mscherbakov@mirantis.com

:

            Deprecation warning for Fuel
            Mitaka: https://bugs.launchpad.net/fuel/+bug/1556244.


            On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko
            <me@romcheg.me <mailto:me@romcheg.me>> wrote:

                Since there are a lot of supporters for this idea,
                what do you folks think about creating a BP spec
                where we can describe what we should do in order to
                remove logs from UI and Nailgun? I also propose to
                file a bug about adding a deprecation warning to
                Mitaka release of Fuel.
                11 ???. 2016 ?. ? 16:55 Bogdan Dobrelya
                <bdobrelia@mirantis.com
                <mailto:bdobrelia@mirantis.com>> ???????(??):

                On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
                +1 to remove logs from Fuel UI in Fuel Newton.
                In Fuel Mitaka we'd need to put a deprecation
                warning somewhere.
                I agree, there is not much sense having non
                flexible (no content
                filters) logs view in UI. LMA plugins shall cover
                this area as well.
                On Fri, Mar 11, 2016, 04:57 Patrick Petit
                <ppetit@mirantis.com <mailto:ppetit@mirantis.com>
                <mailto:ppetit@mirantis.com>> wrote:


                   On 11 March 2016 at 12:51:40, Igor Kalnitsky
                   (ikalnitsky@mirantis.com
                <mailto:ikalnitsky@mirantis.com> <mailto:

ikalnitsky@mirantis.com>)
wrote:

                   Patrick,

                   Sorry, but I meant another question. I
                thought that LMA plugin should
                   be installed in some environment before we
                can start use it. Is
                   this a
                   case? If so, it means we can't use for master
                node until some
                   environment is deployed.
                   Right. This is the chicken and egg problem I
                mentioned earlier...

                   But this is not a ?problem? specific to Fuel.
                My take on this is is
                   that ops management tooling (logging,
                monitoring) should be
                   installed off-band before any OpenStack
                deployment. In fact, in
                   real-world usage, we frequently get asks to
                have the monitoring and
                   logging services of StackLight installed
                permanently for
                   multi-enviroments. And so, one approach would
                be to make Stacklight
                   backend services the first bits of software
                installed by Fuel (if
                   not already there), then reconfigure Fuel to
                hook into those
                   services and only then, enter into the regular
                OpenStack
                   provisioning mode.
                   On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
                   <ppetit@mirantis.com
                <mailto:ppetit@mirantis.com> <mailto:

ppetit@mirantis.com>>
wrote:

                On 11 March 2016 at 11:34:32, Igor Kalnitsky
                (ikalnitsky@mirantis.com
                <mailto:ikalnitsky@mirantis.com> <mailto:

ikalnitsky@mirantis.com>)
wrote:

                Hey Roman,

                Thank you for bringing this up. +1 from my
                side, especially taking
                into account the patch where we tried to solve
                logrotated logs problem
                [1]. It's complex and unsupportable, as well as
                already existed
                logview code in Nailgun.

                Patrick, Simon,

                Does LMA plugin support logs from master node?
                Or it's designed to
                watch environment's logs?

                No it?s not designed specifically for
                environment logs. Can be adapted to
                any log format.

                Would just need to write a parser like you
                would with logstach when logs are
                not standard.

                Patrick



                Thanks,
                Igor


                [1]: https://review.openstack.org/#/c/243240/

                On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit
                <ppetit@mirantis.com
                <mailto:ppetit@mirantis.com> <mailto:

ppetit@mirantis.com>>
wrote:

                Fuelers,

                As Simon said, we already have a log
                centralisation solution for MOS
                delivered as a Fuel plugins known as
                StackLight / LMA toolset. And so
                objectively, there is no need to have log
                management in Nailgun anymore.
                To
                go one step further we suggested several times
                to have a StackLight agent
                installed on the Fuel master node to also
                collect and centralise those
                logs.
                There is a little bit of a chicken and egg
                problem to resolve but I think
                it
                is worth a try to have that nailed down in the
                roadmap for Fuel 10.
                Cheers
                - Patrick


                On 11 March 2016 at 10:07:28, Simon Pasquier
                (spasquier@mirantis.com
                <mailto:spasquier@mirantis.com> <mailto:

spasquier@mirantis.com>)
wrote:

                Hello Roman,

                On Fri, Mar 11, 2016 at 9:57 AM, Roman
                Prykhodchenko <me@romcheg.me
                <mailto:me@romcheg.me> <mailto:me@romcheg.me>>
                wrote:
                Fuelers,

                I remember we?ve discussing this topic in our
                couloirs before but I?d
                like
                to bring that discussion to a more official
                format.

                Let me state a few reasons to do this:

                - Log management code in Nailgun is
                overcomplicated
                - Working with logs on big scale deployments
                is barely possible given the
                current representation
                - Due to overcomplexity and ineffectiveness
                of the code we always get
                recurring bugs like [1]. That eats tons of
                time to resolve.
                - There are much better specialized tools,
                say Logstash [2], that can
                deal
                with logs much more effectively.


                There may be more reasons bus I think even
                the already mentioned ones are
                enough to think about the following proposal:

                - Remove Logs tab from Fuel Web UI
                - Remove logs support from Nailgun
                - Create mechanism that allows to configure
                different log management
                software, say Logstash, Loggly, etc

                - Choose a default software to install and
                provide a plugin for it from
                the box
                This is what the LMA/StackLight plugins [1][2]
                are meant for. No need to
                develop anything new.

                And I'm +1 with the removal of log management
                from Fuel. As you said, it
                can't scale...

                [1]

http://fuel-plugin-lma-collector.readthedocs.org/en/latest/

                [2]

http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/


                OpenStack Development Mailing List (not for
                usage questions)
                Unsubscribe:
                OpenStack-dev-request@lists.openstack.org
                <mailto:

OpenStack-dev-request@lists.openstack.org>?subject:unsubscribe
<
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://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
                <mailto:OpenStack-dev-request@lists.openstack.org

?subject:unsubscribe
<
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<
http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

                --
                Mike Scherbakov
                #mihgen

                OpenStack Development Mailing List (not for usage
                questions)
                Unsubscribe:

OpenStack-dev-request@lists.openstack.org
<mailto:OpenStack-dev-request@lists.openstack.org
?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

                --
                Best regards,
                Bogdan Dobrelya,
                Irc #bogdando

                OpenStack Development Mailing List (not for usage
                questions)
                Unsubscribe:

OpenStack-dev-request@lists.openstack.org
<mailto: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

            --
            Mike Scherbakov
            #mihgen

            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

        --
        Vitaly Kramskikh,
        Fuel UI Tech Lead,
        Mirantis, Inc.

        OpenStack Development Mailing List (not for usage questions)
        Unsubscribe:

OpenStack-dev-request@lists.openstack.org?subject:unsubscribe <
http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

    --
    Mike Scherbakov
    #mihgen

    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
    <

http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community

OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
<

http://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

--
Best regards,
Bogdan Dobrelya,
Irc #bogdando


Message: 6
Date: Mon, 14 Mar 2016 14:24:49 +0530
From: Madhuri madhuri.rai07@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin
Message-ID:
<CAHKoAgpxs+6MSYnYe5O39=yd=jSrpxsadAWWzG=
bcY3E8yE-4g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi All,

I would like to request a feature freeze exception for "Magnum/Murano
rationalization" [1], Magnum app to deploy Kubernetes/Mesos/Swarm cluster.
The patch is on review[2].
I am looking for your decision about considering this change for a FFE.

[1]
https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization
[2] https://review.openstack.org/#/c/269250/

Regards,
Madhuri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/845864a9/attachment-0001.html
>


Message: 7
Date: Mon, 14 Mar 2016 11:58:22 +0300
From: Kirill Zaitsev kzaitsev@mirantis.com
To: Madhuri madhuri.rai07@gmail.com, "OpenStack Development Mailing
List (not for usage questions)" <openstack-dev@lists.openstack.org
>
Subject: Re: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin
Message-ID: etPan.56e67d2e.3dc3eba9.173@TefMBPr.local
Content-Type: text/plain; charset="utf-8"

I?m going to advocate for this FFE. Even though it?s very late to ask for
FFE, I believe, that this commit is very low-risk/high reward (the plugin
is not enabled by default). I believe that code is in good shape (I
remember +2 it at some point) and would very much like to see this in.

Serg, do you have any objections?

--?
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 14 March 2016 at 11:55:46, Madhuri (madhuri.rai07@gmail.com) wrote:

Hi All,

I would like to request a feature freeze exception for "Magnum/Murano
rationalization" [1], Magnum app to deploy Kubernetes/Mesos/Swarm cluster.
The patch is on review[2].
I am looking for your decision about considering this change for a FFE.

[1]?
https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization
[2]?https://review.openstack.org/#/c/269250/

Regards,
Madhuri


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/20160314/92dcf8e1/attachment-0001.html
>

Message: 8
Date: Mon, 14 Mar 2016 14:40:39 +0530
From: Anant Patil anant.patil@hpe.com
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] convergence cancel messages
Message-ID: 56E6800F.7080102@hpe.com
Content-Type: text/plain; charset=windows-1252

On 24-Feb-16 22:48, Clint Byrum wrote:

Excerpts from Anant Patil's message of 2016-02-23 23:08:31 -0800:

Hi,

I would like the discuss various approaches towards fixing bug
https://launchpad.net/bugs/1533176

When convergence is on, and if the stack is stuck, there is no way to
cancel the existing request. This feature was not implemented in
convergence, as the user can again issue an update on an in-progress
stack. But if a resource worker is stuck, the new update will wait
for-ever on it and the update will not be effective.

The solution is to implement cancel request. Since the work for a stack
is distributed among heat engines, the cancel request will not work as
it does in legacy way. Many or all of the heat engines might be running
worker threads to provision a stack.

I could think of two options which I would like to discuss:

(a) When a user triggered cancel request is received, set the stack
current traversal to None or something else other than current
traversal. With this the new check-resources/workers will never be
triggered. This is okay as long as the worker(s) is not stuck. The
existing workers will finish running, and no new check-resource
(workers) will be triggered, and it will be a graceful cancel. But the
workers that are stuck will be stuck for-ever till stack times-out. To
take care of such cases, we will have to implement logic of "polling"
the DB at regular intervals (may be at each step() of scheduler task)
and bail out if the current traversal is updated. Basically, each worker
will "poll" the DB to see if the current traversal is still valid and if
not, stop itself. The drawback of this approach is that all the workers
will be hitting the DB and incur a significant overhead. Besides, all
the stack workers irrespective of whether they will be cancelled or not,
will keep on hitting DB. The advantage is that it probably is easier to
implement. Also, if the worker is stuck in particular "step", then this
approach will not work.

(b) Another approach is to send cancel message to all the heat engines
when one receives a stack cancel request. The idea is to use the thread
group manager in each engine to keep track of threads running for a
stack, and stop the thread group when a cancel message is received. The
advantage is that the messages to cancel stack workers is sent only when
required and there is no other over-head. The draw-back is that the
cancel message is 'broadcasted' to all heat engines, even if they are
not running any workers for the given stack, though, in such cases, it
will be a just no-op for the heat-engine (the message will be gracefully
discarded).
Oh hah, I just sent (b) as an option to avoid (a) without really
thinking about (b) again.

I don't think the cancel broadcasts are all that much of a drawback. I
do think you need to rate limit cancels though, or you give users the
chance to DDoS the system.
There is no easier way to restrict the cancels, so I am choosing the
option of having a "monitoring task" which runs in separate thread. This
task periodically polls DB to check if the current traversal is updated.
When a cancel message is received, the current traversal is updated to
new id and monitoring task will stop the thread group running worker
threads for previous traversal (traversal uniquely identifies a stack
operation).

Also, this will help with checking timeout. Currently each worker checks
for timeout. I can move this to the monitoring thread which will stop
the thread group when stack times out.

It is better to restrict the actions within the heat engine than to load
the AMQP; that can lead to potentially complicated issues.

-- Anant

>


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: 9
Date: Mon, 14 Mar 2016 10:34:39 +0100
From: Julien Danjou julien@danjou.info
To: gordon chung gord@live.ca
Cc: "openstack-dev@lists.openstack.org"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [telemetry] stepping down as PTL
Message-ID: m0egbd768g.fsf@danjou.info
Content-Type: text/plain; charset="us-ascii"

On Fri, Mar 11 2016, gordon chung wrote:

as the PTL nominations are open, i just want to note that i won't be
running again as the Telemetry PTL for Newton cycle.

i've thoroughly enjoyed my time as PTL which afforded me the opportunity
to work with and learn from some great individuals who share the same
passion to collaborate openly. i have the utmost confidence that the
projects will continue to grow and become more refined under the next
leadership.

personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities
as well as the projects that provided valuable feedback by collaborating
with us. i thank you for sharing in the decision making so i could
spread the blame around. i also thank you for reading through terribly
written messages that make you question whether the shift keys on all my
keyboards are broken.

I'd like to join others and thank you for your amazing work as a PTL.

You've led the community in an open way that allowed it to share the
leadership and be one of the most thrilling group that I've been able to
contribute to in OpenStack.

Cheers,
--
Julien Danjou
// Free Software hacker
// https://julien.danjou.info
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/10bdac2e/attachment-0001.pgp
>


Message: 10
Date: Mon, 14 Mar 2016 10:36:18 +0100
From: Julien Danjou julien@danjou.info
To: Mike Lowe j.michael.lowe@gmail.com
Cc: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [gnocchi] strange behavior
Message-ID: m07fh5765p.fsf@danjou.info
Content-Type: text/plain; charset="utf-8"

On Fri, Mar 11 2016, Mike Lowe wrote:

I?m having a little trouble with my gnocchi install, the only output
from the
status command is ?storage? and even with verbose and debugging true the
api
log doesn?t show anything after startup. Any hints?

Can you share your configuration file and the log of the metricd daemon
and the WSGI server?

--
Julien Danjou

Free Software hacker

https://julien.danjou.info

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/b8d496cf/attachment-0001.pgp
>


Message: 11
Date: Mon, 14 Mar 2016 11:41:21 +0200
From: Irena Berezovsky irenab.dev@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, reedip14@gmail.com
Subject: Re: [openstack-dev] [neutron][TaaS] Possible points to be
considered for TaaS Spec
Message-ID:
<CALqgCCqRQDwQsrPCMoUk5tCU9VJPy=
0MXzDuZii0ik0sb-rkXQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Reedip,
Please see my comments inline

On Tue, Mar 8, 2016 at 9:19 AM, reedip banerjee reedip14@gmail.com
wrote:

While reading up the specs in [1] and [2], there are certain things which
we may need to discuss before proceeding forward

a) Reference point for Ingress/Egress traffic:
There may be some confusion related to how we are labelling
Ingress and Egress ( is it with respect to a VM, with a switch ,
or any other entity).
As we are looking from "Inside the VM" and not from "Inside the Network",
that needs to be made clear.

I think it worth to be consistent with other neutron features, for example
with Security Groups

b) How to perceive TaaS:
In the section "Proposed Changes" Taas has been compared with a Core
Neutron
Plugin ( L3-Router) and a plugin which has emerged out of Neutron (
Neutron LBaaS).
This might cause confusion to the reviewers. It would be better that we
decide
how we would like to demonstrate TaaS:
- Is it a plugin which can be integrated with the Neutron Core
- Or is it an extension of the Core Neutron Services which can be used by
selected users

Based on the decision, we can modify the explanation to make the spec a
bit more streamed.

I think it's advanced service adding value to the core neutron.

c) Device Owner for TaaS:
- If Tap Service creates a "destination" port, the port would have a
device owner
of the format of "network:tap"
- If the "destination" port is now connected to a VM and the VM is booted
up, nova
changes the owner to "compute:nova"

Probably the difference will be if TaaS is allowed to remove this port or
not.

Is there any impact of the change of the device_owner

If there is an impact, should there be a change in nova so that the

device_owner is not modified

When in the future, TaaS supports user providing an "already created

port" should the device owner
be checked and modified?

d) Outcome of Deleting the VM where TaaS operates
Following might be added to the Spec:

  1. Deletion of the VM (and port attched to it) from which we were
    mirroring (source of the mirror):
    In this case we would do a cascade delete of the 'Tap_Flow' instances
    that
    were associated with the port that was deleted.

Are you sure you want to delete the Flow? Maybe it should reflect the
status of being not operational any more. I personally do not think user
created resource should be deleted without explicit user operation.

  1. Deletion of the VM (and port attched to it) to which we were mirroring
    (Destination of the mirror):
    In this case we would do a cascade delete of the 'Tap_Service' instance
    that was associated with the port that was deleted.

Same as previous comment.

e) Making the API independent of OpenVSwitch
As per our last discussion [3], it is better that w esplit our
implementation for TaaS,
so that
# the focus is not limited to OpenVSwitch, which may be a point of
concern during review
# allow other vendors to create thier own pluggable implementation

+1

f) Choice of Tapping before/after Sec Groups

Security Groups can filter a lot , and implementing TaaS before or after
the SG
can impact the overall monitoring.
As referenced in [1], we can provide this option as a future course of
work, and
in the meanwhile specify the option which we are working upon ( Before
or
After)
in the spec, to make it clear.

I think it can be the TapFlow attribute, lets say 'position' that can be
either 'port' or 'vNIC'.
*'vnic' *to capture ingress traffic after it passed inbound SG filters and
egress traffic before it passes outbound SG filters

'port' to capture ingress traffic before it passed inbound SG filters and
egress traffic after it passes outbound SG filters

https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst

[3]:

http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt

--
Thanks and Regards,
Reedip Banerjee
IRC: reedip


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/20160314/c8beee31/attachment-0001.html
>


Message: 12
Date: Mon, 14 Mar 2016 02:41:58 -0700
From: Sabari Murugesan sabari.bits@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova][Glancestore][VMware] Different
glance store for Nova snapshot in VMware
Message-ID:
<
CAJJL21MpwO6Jta8eOHvTJaw1+Fhf
8frqW9xOhgaQEMUuy1pzw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi Dongcan

Regardless of when you snapshot, the image should be uploaded to
the default glance store. Is it possible that you had enabled the
FileSystem
store earlier and recently changed to the vsphere store ?

To further debug, can
you add the following to the default section of glance-api.conf and provide
us the value for 'locations' attribute of the snapshotted image. You can do
"glance image-show --os-image-api-version 2 image-show " to
know the location.

[DEFAULT]
showmultiplelocations = True

Thanks
Sabari

On Sun, Mar 13, 2016 at 7:54 PM, dongcan ye hellochosen@gmail.com wrote:

Hi all,

In our production environment, we enables glance_store for VMware
datastore.
Configuration in glance-api.conf:

[DEFAULT]
showimagedirecturl = True
[glance
store]
stores= glance.store.vmwaredatastore.Store
default
store = vsphere
vmwareserverhost= 172.18.6.22
vmwareserverusername = administrator@vsphere.local
vmwareserverpassword = 1qaz!QAZ
vmware_datastores = ICT Test:F7-HPP9500-SAS-ICTHPCLUSTER03-LUN06

Firstly we boot an instance, make online snapshot for the VM, we see the
image stores on local file system:
direct_url
file:///var/lib/glance/images/8cf7ba51-31d8-4282-89db-06957d609691

Then we poweroff the VM, make offline snapshot, the image stores on
VMware
datastore:
direct_url vsphere://

172.20.2.38/folder/openstackglance/52825a70-f645-46b5-80ec-7a430dcd13cf?dcPath=IDCTest&dsName=LUN03-00

In Nova VCDriver, make snapshot will upload VM disk file to Glance image
server. But why different behaviour for the VM poweron and poweroff?

Hopes for your reply.


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/20160314/43624923/attachment-0001.html
>


Message: 13
Date: Mon, 14 Mar 2016 10:50:31 +0100
From: Gorka Eguileor geguileo@redhat.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Cinder] PTL Candidacy
Message-ID: <20160314095031.GB668@localhost>
Content-Type: text/plain; charset=us-ascii

Thanks for your leadership Sean, I think you've done a terrific job.

Gorka.

On 11/03, Sean McGinnis wrote:

Hey everyone,

Wow, how six months flies! I'd like to announce my candidacy to continue
on as
Cinder PTL for the Newton release cycle.

A lot has been accomplished in the Mitaka cycle. After a lot of work by
many
folks, over a couple development cycles, we now have what we consider a
"tech
preview" of rolling upgrades. It just hasn't had enough runtime and
testing for
us to say it's "official". We will likely need to fix a few minor things
in the
Newton timeframe before it's fully baked and reliable. But it has come a
long
way and I'm really happy with the progress that has been made.

Another priority we had identified for Mitaka was active/active high
availability of the c-vol service. We were not able to complete that
work, but
many pieces have been put in place to support that in Newton. We fixed
several
API races and added the ability to use something like tooz for locking.
These
are foundation pieces for us to be able to start breaking out things and
running in a reliable active/active configuration.

Microversion support has been added and there is now a new v3 API
endpoint.
This was a bit of a controversy as we really had just started to get
folks to
move off of v1 to v2. To be safe though I decided it would protect end
users
better to have a clearly separate new API endpoint for the microversion
compatibility. And now hopefully it is our last.

Replication was another slightly controversial feature implemented. Late
in
Liberty we finally agreed on a spec for a v2 version of replication. The
v2
spec was approved so late that no one actually had time to implement it
for
that release. As we started to implement it for Mitaka we found that a
lot of
compromises had crept in during the spec review that it had the risk of
being
too complex and having some of the issues we were trying to get rid of by
moving away from replication v1. At our midcycle we had a lot of
discussion on
replication and finally decided to change course before it was too late.
Whether that ends up being the best choice when we look back a year from
now or
not, I'm proud of the team that we were willing to put on the brakes and
make
changes - even though it was more work for us - before we released
something
out to end users that would have caused problems or a poor experience.

Other than that, there's mostly been a lot of good bug fixes. Eight new
drivers
have been added from (I think) five different vendors. The os-brick
library is
now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common
storage management operations so there is not a duplication and
disconnect of
code between the two projects. We were also able to add a Brick cinder
client
extension to be able to perform storage management on nodes without Nova
(bare
metal, etc.).

None of this goodness was from me.

We have a bunch of smart and active members of the Cinder community.
They are
the ones that are making a difference, working across the community, and
making sure Cinder is a solid component in an OpenStack cloud.

Being part of the Cinder community has been one of the best and most
engaging
parts of my career. I am lucky enough to have support from my company to
be
able to devote time to being a part of this. I would love the
opportunity to
continue as PTL to not just contribute where I can, but to make sure the
folks
doing the heavy lifting have the support and project organization they
need to
avoid distractions and be able to focus on getting the important stuff
done.

I think in Newton we need to continue the momentum and get Active/Active
Cinder
volume service support implemented. We need to continue to work closely
with
the Nova team to make sure our interaction is correct and solid. But
also work
to make Cinder a useful storage management interface in environments
without
Nova. I will continue to encourage developer involvement and vendor
support.
We need to improve the user experience with better error reporting when
things
go wrong. And last, but definitely not least, we need to continue to
expand our
testing - unit, functional, and tempest - to make sure we can avoid those
errors and deliver a high quality and solid solution.

I really feel I'm just getting into the swing of things. I would love the
opportunity to serve as PTL for the Newton release.

Thank you for your consideration.

Sean McGinnis (smcginnis)


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: 14
Date: Mon, 14 Mar 2016 09:57:33 +0000
From: Jesse Pretorius jesse.pretorius@gmail.com
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [OpenStack-Ansible] PTL Candidacy
Message-ID:
<CAGSrQvz=
JsKisOqHTdru0VrEKHN5zeaoNS9-eLNi70WiuWGmpg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi everyone,

The Mitaka cycle for OpenStack-Ansible (OSA) has had the following
successes:

  1. Our community has grown. The activity in the IRC channel has shown that
    we now have more people making use of OSA to deploy both private and public
    OpenStack clouds. Our development team now includes two non-Rackspace core
    team members who are committed to ensuring that OSA's development process
    has more diversity in its inputs and outputs. We have also increased the
    breadth of roles available to our deployers. Most importantly they were
    developed by non-core development team members.

  2. The roles are more modular. We've split out the Ansible roles into
    composable units which are usable without the dynamic inventory, LXC and
    without the general playbook tooling which has been implemented in the
    integrated build OSA repository.

  3. Multi-OS platform support enablement has progressed. Several of the
    roles in our stable are already passing the CentOS-based gate check, even
    though this work was very low priority in the cycle.

  4. Usability has improved. We've done an amazing job of improving install
    guide documentation, improving developer documentation, and adding release
    notes for the Mitaka release and retrospectively for the Liberty release.

It would be my honour to serve as PTL for the Newton cycle to continue the
journey along the following themes:

  1. Grow the community
    I would like to continue to increase our community participation through
    the engagement with other OpenStack Projects and the Operator community. I
    believe that it's crucial to the success of the project to increase the
    diversity of contributors. Our work in the Mitaka cycle has laid a good
    foundation on which I'd like to build through active engagement with the
    respective communities to share how OSA can meet the needs of both the
    Developer and Operator communities.

  2. Improve testing
    In the Mitaka cycle we laid the foundation for broader and deeper testing
    for each role and for the integrated tests. In the Newton cycle we need to
    complete that work in order to ensure that we have greater confidence that
    every patch submitted produces a functional build and does not introduce
    regressions in existing deployments. We need to ensure that each role is
    tested both in terms convergence and in terms of function.
    We also need to ensure that we have integrated testing for a broader
    variety of scenario's to ensure that each scenario that is considered a
    supported deployment design is tested.

  3. Improve usability
    While OSA is reasonably simple to use to deploy OpenStack, a barrier to
    most new users is understanding how to customise the inventory and how to
    prepare the host networking.
    I'd like us to reduce this barrier to entry in the Newton cycle in order to
    further simplify an OpenStack deployment for a new user.

  4. Improve platform support enablement
    In the Newton cycle we have agreed to ensure that we take advantage of
    Ansible 2.x and that we also implement support for Ubuntu 16.04 LTS. This
    work will implement the patterns which make it much easier to add more
    Linux distributions to our supported platform list.

I look forward to working with you all in the Newton cycle and hope that we
can meet our lofty goals!

Jesse
IRC: odyssey4me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/2091cde2/attachment-0001.html
>


Message: 15
Date: Mon, 14 Mar 2016 13:01:42 +0300
From: Andrey Pavlov andrey.mp@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: [openstack-dev] [swift3][swift] What happens in swift3?
Message-ID:
<
CAKdBrScVhawgvTtdCjj6PpNUEqYNdLegO2yKQ+OgB+afKeZNTA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Hello,

I found that new Amazon tool for S3 started to use another way to sign
requests.
I made changes and submitted my review [1] seven months ago.

This functionality is needed for ec2api project [2].
It is needed for using new aws cli tool.

I asked to review my changes directly to Kota via email.
My colleague asked him on previous summit about it.
All dependent reviews (in keystone) already merged four months ago.
On all comments were answered in the review.
I tried to raise this question at swift3 meeting.

But still there is no answer.

Can anyone answer - Can it really be reviewed and merged?

[1] https://review.openstack.org/#/c/211933/
[2] https://review.openstack.org/#/c/198571/

--
Kind regards,
Andrey Pavlov.


Message: 16
Date: Mon, 14 Mar 2016 10:04:37 +0000
From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)"
li-gong.duan@hpe.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat
template
Message-ID:
<
632AC00166CA654683E6FE74AD16B12776CC70C1@G9W0758.americas.hpqcorp.net>

Content-Type: text/plain; charset="utf-8"

Hi Sergey,

Thanks a lot.
What I am using is Liberty release of Heat in a devstack environment.

I'll provide my trace log later.

Regards,
Gary

-----Original Message-----
From: Sergey Kraynev [mailto:skraynev@mirantis.com]
Sent: Friday, March 11, 2016 10:23 PM
To: OpenStack Development Mailing List (not for usage questions) <
openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template

Hi Gary,

I have tried your template and it works for me correctly. Note, that I
used private network (because my servers have not any public IP in
template).

So your issue looks like a strange bug, because I can not reproduce it.
Could you share traceback if your error and also provide information about
Heat version. Please create new bug with all this data and ping us to
review it.

On 11 March 2016 at 08:25, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) <
li-gong.duan@hpe.com> wrote:

Hi Sergey,

Thanks for your reply.

Thanks for your pointing out that "dependson" is not needed when we
have already used "get
attr".

So as Zane pointed, when we use getattr it's expected, that we start
create rg
b, when rga will be finally completed/created , because all
information (in your case it's attributes) will be available after creation
of rg
a.

In heat we have two types of dependencies explicit and implicit. So
implicit dependencies will be created with using some Heat intrinsic
functions. Depends_on add explicit dependency. All these dependencies work
in the same way, depended resource will be created, when all his
dependencies be resolved (created).

you create in rga some Server and probably it goes to active state
before ip address becomes available for get
attr. It is necessary to
check, but if it's try to add wait condition for this resource, then
you will get created rg_a with fully available resources and I suppose
IP will be available

Do you mean that with "dependson" functionalities, Heat will launch
another resource group(in my case, "rg
b") as soon as the server in "rga"
becomes "active" state?
Actually, in my real program code, there is a wait condition, but it is
located in the server template, not Resource group(in my case, it is
"b.yaml), which is like:
rg
awcnotify:
type: OS::Heat::SoftwareConfig
properties:
group: ungrouped
config:
strreplace:
template: |
#!/bin/bash -v
wc
notify --data-binary '{"status": "SUCCESS"}'
params:
wcnotify: {getattr: [masterwaithandle, curl_cli]}


Is it the wait condition which you mentioned in " but if it's try to add
wait condition for this resource"? or you want this wait condition to be
added to "a.yaml"(the template declaring resource group)?

And as per my observation, only after Heat receives the signal of
"SUCCESS", then it try to begin launch "rg_b"(my another server in another
resource group).

I am wondering whether there is a chance that, the "IP" information is
available but Heat doesn't try to get it until the creation of the 2
resource groups(rga and rgb) is completed?

Regards,
Gary

-----Original Message-----
From: Sergey Kraynev [mailto:skraynev@mirantis.com]
Sent: Wednesday, March 09, 2016 6:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat
template

Hi Gary,

First of all you don't need to use "dependson", because using
"get
attr" already create implicit dependency from rga.
About getting Null instead of real Ip address:
It sounds like a bug, but IMO, it's expected behavior, because I suppose
it happens due to:
- you create in rg
a some Server and probably it goes to active state
before ip address becomes available for getattr. It is necessary to check,
but if it's try to add wait condition for this resource, then you will get
created rg
a with fully available resources and I suppose IP will be
available.

On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) <
li-gong.duan@hpe.com> wrote:

Hi,

I have 3 Heat templates using ResourceGroup. There are 2 resource
groups(rga and rgb) and rgb depends on rga. and rgb requires
the IP address of rg
a as the paremeter of rgb. I use ?rgapublicip:
{getattr:
[rg
a, rgapublicip]}? to get the IP address of rga both in the
section of rgb parameters (rgb/properties/resource_def/properties)
and the section of outputs.

As per my observation, rgapublicip shows ?null? in the parameter
section of rg
b. while rgapublic_ip shows the correct IP address in
the outputs section of the yaml file.

My questions are:

1) Does this behavior is expected as designed or this is a bug?

2) What is the alternative solution for the above case(user want
to get
the run-time information of the instance when creating the second
resource
group) if this behavior is expected?

------- a.yaml -------------------

resources:

rg_a:

type: OS::Heat::ResourceGroup

properties:

  count: 1

  resource_def:

      type: b.yaml

      properties:

           ?

rg_b:

type: OS::Heat::ResourceGroup

depends_on:

    -rg_a

properties:

count: 2

resource_def:

    type: c.yaml

    properties:

        rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}

-------------------- the value is ?null?

        ?

outputs:

rgapublicip: {getattr: [rga, rgapublicip]}
--------------------- the value is correct.


------b.yaml --------------------

?

resources:

rg_a:

type: OS::Nova::Server

properties:

 ?

outputs:

 rg_a_public_ip:

     value: {get_attr: [rg_a, networks, public, 0]}

---------- c.yaml --------------------

parameters:

rgapublic_ip:

 type: string

 description: IP of rg_a

?

resources:

rg_b:

type: OS::Nova::Server

properties:

     ?

outputs:

     ?

Regards,

Gary


_ ____ 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

--
Regards,
Sergey.


____ 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

--
Regards,
Sergey.


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: 17
Date: Mon, 14 Mar 2016 10:21:27 +0000
From: Andrea Frittoli andrea.frittoli@gmail.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [QA] Not running for PTL
Message-ID:
<CAB7WYGUn1nBYBWA1hjCY2wsPvGqd=
PWT5NCF2gkqH_CZCaRf6w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks Matt for the great work as PTL in the past 4 cycles!

You had the fun of serving through the change in governance model, which is
especially though on horizontal teams like QA - and I think you set strong
foundations for QA to be successful in the big tent.

andreaf

On Mon, Mar 14, 2016 at 8:27 AM Daniel Mellado <daniel.mellado.es@ieee.org
>
wrote:

Thanks Matt for all your help and support, and glad that you'll be still
around!

El 11/03/16 a las 20:34, Matthew Treinish escribi?:

Hi everyone,

I'm writing this to announce that I am not running for QA PTL this
cycle. I've
been the QA PTL for the past 4 cycles and I think it's time for another
person
to take over the role. I think during the past 4 cycles the QA community
has
grown greatly and become a much larger and stronger community compared
to when
I first took on the position in the Juno cycle.

I strongly believe in the diversity of leadership and ideas, and I don't
want
the community to grow stagnant because it becomes synonymous with just
my voice.
Being a PTL is not the same as being an autocrat and I think it's time
for
another person to step up and take over the QA PTL spot.

That being said, I'm not planning on going anywhere or leaving the
project. I
fully intend to continue working and being heavily involved with the QA
program,
as I have for been the past 2 years. (although maybe with a bit more
free time
now)

-Matt Treinish


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://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/20160314/2ac6aafa/attachment-0001.html
>


Message: 18
Date: Mon, 14 Mar 2016 11:34:28 +0100
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] stuck review, mtu incorrectly set
on vhost-user port prevents vm booting.
Message-ID:
201603141034.u2EAYYe7005382@d06av12.portsmouth.uk.ibm.com
Content-Type: text/plain; charset="ISO-8859-1"

"Mooney, Sean K" sean.k.mooney@intel.com wrote on 03/11/2016 07:20:46
PM:

From: "Mooney, Sean K" sean.k.mooney@intel.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Date: 03/11/2016 07:21 PM
Subject: [openstack-dev] [nova] stuck review, mtu incorrectly set on
vhost-user port prevents vm booting.

Hi everyone
I opened a bug back in January to correct an issue with vhost-user
Related to setting the mtu on the interface.

The recent changes in nova and neutron to change the default mtu value
from 0 to 1500
Are a direct trigger for this bug resulting in an inability to boot
vms that use vhost-user.

If anyone on the nova core/stable teams has time to look at this bug
and the fix I would appreciated it.

I would really like get this merged before rc1 is tagged if possible.
We have been running it in our ci for two weeks to make our cis work but
I want
To get them back to running against the head of master nova as soon
aspossible.

Bug : https://bugs.launchpad.net/nova/+bug/1533876
Review: https://review.openstack.org/#/c/271444/

Liberty backport: https://review.openstack.org/#/c/289370/1
Kilo backport: https://review.openstack.org/#/c/289374/1

Regards
Se?n


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

Matt Riedemann tagged the bug report as "mitaka-rc-potential" last
Friday. The report is also on the priorities etherpad [1] and I informed
our PTL John Garbutt to consider this before creating the stable branch.
Hopefully some of the core reviewers will check your patch(es) today.

References:
[1] https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking

Regards, Markus Zoeller (markus_z)


Message: 19
Date: Mon, 14 Mar 2016 13:36:32 +0300
From: Nadya Shakhat nprivalova@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org, gordon chung gord@live.ca
Subject: Re: [openstack-dev] [telemetry] stepping down as PTL
Message-ID:
<CAKWrcJeadCCbY1gJkNMSsTNo053y-tsB=tThgnJX=
E5oKoo
w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Gordon,
Thank you very much for your work! I was always amazed by your patience and
proficiency. It seems to me that you answered billion questions during
working on Telemetry. I wish you all the best in the future, you are
awesome :)!

Thanks,
Nadya

On Mon, Mar 14, 2016 at 12:34 PM, Julien Danjou julien@danjou.info
wrote:

On Fri, Mar 11 2016, gordon chung wrote:

as the PTL nominations are open, i just want to note that i won't be
running again as the Telemetry PTL for Newton cycle.

i've thoroughly enjoyed my time as PTL which afforded me the
opportunity
to work with and learn from some great individuals who share the same
passion to collaborate openly. i have the utmost confidence that the
projects will continue to grow and become more refined under the next
leadership.

personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities
as well as the projects that provided valuable feedback by
collaborating
with us. i thank you for sharing in the decision making so i could
spread the blame around. i also thank you for reading through terribly
written messages that make you question whether the shift keys on all
my
keyboards are broken.

I'd like to join others and thank you for your amazing work as a PTL.

You've led the community in an open way that allowed it to share the
leadership and be one of the most thrilling group that I've been able to
contribute to in OpenStack.

Cheers,
--
Julien Danjou
// Free Software hacker
// https://julien.danjou.info


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/20160314/cfd50f3f/attachment-0001.html
>


Message: 20
Date: Mon, 14 Mar 2016 14:09:00 +0300
From: Nikolay Starodubtsev nstarodubtsev@mirantis.com
To: "OpenStack Development Mailing List (not for usage questions)"
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin
Message-ID:
<CAAa8YgBa7t1S6dJSK6ScP=
jKEgyH9bjrCCekogcWgFNmwFpSAw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,
I don't like when we need to break rules, but in this case I agree with
Kirill. As far as the plugin is not something which can broke general
murano functionality, I'm for FFE.

Nikolay Starodubtsev

Software Engineer

Mirantis Inc.

Skype: dark_harlequine1

2016-03-14 11:58 GMT+03:00 Kirill Zaitsev kzaitsev@mirantis.com:

I?m going to advocate for this FFE. Even though it?s very late to ask for
FFE, I believe, that this commit is very low-risk/high reward (the plugin
is not enabled by default). I believe that code is in good shape (I
remember +2 it at some point) and would very much like to see this in.

Serg, do you have any objections?

--
Kirill Zaitsev
Software Engineer
Mirantis, Inc

On 14 March 2016 at 11:55:46, Madhuri (madhuri.rai07@gmail.com) wrote:

Hi All,

I would like to request a feature freeze exception for "Magnum/Murano
rationalization" [1], Magnum app to deploy Kubernetes/Mesos/Swarm
cluster.
The patch is on review[2].
I am looking for your decision about considering this change for a FFE.

[1]

https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization


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/20160314/1aba7a73/attachment-0001.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 47, Issue 56



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 Mar 15, 2016 in openstack-dev by dongcan_ye (220 points)   1 1
...