[openstack-dev] OpenStack-dev Digest, Vol 47, Issue 56
dongcan ye
hellochosen at gmail.com
Tue Mar 15 03:24:16 UTC 2016
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 show_multiple_locations 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/openstack_glance/f462c06a-f202-4b1f-a89a-17f72264b502?dcPath=IDC_Test&dsName=LUN03-00",
"metadata": {}}]
2016-03-14 20:00 GMT+08:00 <openstack-dev-request at lists.openstack.org>:
> Send OpenStack-dev mailing list submissions to
> openstack-dev at lists.openstack.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> or, via email, send a message with subject or body 'help' to
> openstack-dev-request at lists.openstack.org
>
> You can reach the person managing the list at
> openstack-dev-owner at lists.openstack.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OpenStack-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [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)
> 10. Re: [gnocchi] strange behavior (Julien Danjou)
> 11. Re: [neutron][TaaS] Possible points to be considered for TaaS
> Spec (Irena Berezovsky)
> 12. Re: [Nova][Glance_store][VMware] Different glance store for
> Nova snapshot in VMware (Sabari Murugesan)
> 13. Re: [Cinder] PTL Candidacy (Gorka Eguileor)
> 14. [OpenStack-Ansible] PTL Candidacy (Jesse Pretorius)
> 15. [swift3][swift] What happens in swift3? (Andrey Pavlov)
> 16. Re: [heat] issue of ResourceGroup in Heat template
> (Duan, Li-Gong (Gary, HPServers-Core-OE-PSC))
> 17. Re: [QA] Not running for PTL (Andrea Frittoli)
> 18. Re: [nova] stuck review, mtu incorrectly set on vhost-user
> port prevents vm booting. (Markus Zoeller)
> 19. Re: [telemetry] stepping down as PTL (Nadya Shakhat)
> 20. 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 at ieee.org>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [QA] Not running for PTL
> Message-ID: <56E675DF.4020809 at 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 at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/f33565e4/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 14 Mar 2016 16:36:07 +0800
> From: Wilence Yao <wilence.yao at gmail.com>
> To: openstack-dev <openstack-dev at 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 at 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 modules_install
> 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.x86_64
> 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 | depmod `sed -n 's/#define UTS_RELEASE
> "\([^"]*\)"/\1/p'
>
> /lib/modules/3.10.0-327.10.1.el7.x86_64/build/include/generated/utsrelease.h`
> 2016-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 at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and
> Nailgun
> Message-ID:
> <
> CAC+XjbZMXMLdhgezYocxuD49fx1Uw3WqBjAtxe2G-mwxboKZ_Q at 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 at 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 at 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 at 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 at 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 at 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 at 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 at mirantis.com
> >>>>> <mailto:ppetit at mirantis.com <ppetit at mirantis.com>>> wrote:
> >>>>>
> >>>>>
> >>>>> On 11 March 2016 at 12:51:40, Igor Kalnitsky
> >>>>> (ikalnitsky at mirantis.com <mailto:ikalnitsky at mirantis.com
> >>>>> <ikalnitsky at 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 at mirantis.com <mailto:ppetit at mirantis.com
> >>>>> <ppetit at mirantis.com>>> wrote:
> >>>>>
> >>>>>
> >>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (
> ikalnitsky at mirantis.com
> >>>>> <mailto:ikalnitsky at mirantis.com <ikalnitsky at 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 at mirantis.com
> <
> >>>>> mailto:ppetit at mirantis.com <ppetit at 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 at mirantis.com
> <
> >>>>> mailto:spasquier at mirantis.com <spasquier at mirantis.com>>)
> >>>>> wrote:
> >>>>>
> >>>>> Hello Roman,
> >>>>>
> >>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <me at romcheg.me
> <
> >>>>> mailto:me at romcheg.me <me at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.openstack.org
> >>>>> ?subject:unsubscribe
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>>>
> >>>>>
> __________________________________________________________________________
> >>>>> OpenStack Development Mailing List (not for usage questions)
> >>>>> Unsubscribe:
> >>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>>
> >>>> --
> >>>> Mike Scherbakov
> >>>> #mihgen
> >>>>
> >>>>
> >>>>
> __________________________________________________________________________
> >>>> OpenStack Development Mailing List (not for usage questions)
> >>>> Unsubscribe:
> >>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Vitaly Kramskikh,
> >>> Fuel UI Tech Lead,
> >>> Mirantis, Inc.
> >>>
> >>>
> __________________________________________________________________________
> >>> OpenStack Development Mailing List (not for usage questions)
> >>> Unsubscribe:
> >>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>>
> >> --
> >> Mike Scherbakov
> >> #mihgen
> >>
> __________________________________________________________________________
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe:
> >> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> > --
> >
> > --
> >
> > Andrew Woodward
> >
> > Mirantis
> >
> > Fuel Community Ambassador
> >
> > Ceph Community
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- 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 at jp.fujitsu.com>
> To: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Third-Party][CI] Modify&delete&add CI
> accouts in CI group
> Message-ID: <AC0F94DB49C0C2439892181E6CDA6E6C172D509A at 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 at dl.jp.fujitsu.com
>
> [2]Modify
> Name: Fujitsu ETERNUS CI
> OLD-Email: lsoft-eternusci at ml.css.fujitsu.com
> NEW-Email: fj-lsoft-eternusci at dl.jp.fujitsu.com
>
> [3] Modify
> OLD-Name: Fujitsu IRMC CI
> NEW-Name: Fujitsu iRMC CI
> OLD-Email: lsoft-irmcci at ml.css.fujitsu.com
> NEW-Email: fj-lsoft-irmcci at dl.jp.fujitsu.com
>
> [4] Modify
> Name: Fujitsu C-Fabric CI
> OLD-Email: lsoft-cfabricci at ml.css.fujitsu.com
> NEW-Email: fj-lsoft-cfabricci at dl.jp.fujitsu.com
>
> [5] Delete
> Name: Fujitsu ETERNUS FC CI
> Email: lsoft-openstackci at ml.css.fujitsu.com
>
>
> Best regards,
> Watanabe.isao
>
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 14 Mar 2016 09:53:49 +0100
> From: Bogdan Dobrelya <bdobrelia at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and
> Nailgun
> Message-ID: <56E67C1D.1030904 at 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 at gmail.com
> > <mailto:xarses at 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 at mirantis.com <mailto:mscherbakov at 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 at mirantis.com <mailto:vkramskikh at 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 at mirantis.com <mailto:mscherbakov at 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 at romcheg.me <mailto:me at 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 at mirantis.com
> >> <mailto:bdobrelia at 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 at mirantis.com <mailto:ppetit at mirantis.com>
> >>> <mailto:ppetit at mirantis.com>> wrote:
> >>>
> >>>
> >>> On 11 March 2016 at 12:51:40, Igor Kalnitsky
> >>> (ikalnitsky at mirantis.com
> >>> <mailto:ikalnitsky at mirantis.com> <mailto:
> ikalnitsky at 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 at mirantis.com
> >>>> <mailto:ppetit at mirantis.com> <mailto:
> ppetit at mirantis.com>>
> >>>> wrote:
> >>>>>
> >>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky
> >>>>> (ikalnitsky at mirantis.com
> >>>>> <mailto:ikalnitsky at mirantis.com> <mailto:
> ikalnitsky at 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 at mirantis.com
> >>>>> <mailto:ppetit at mirantis.com> <mailto:
> ppetit at 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 at mirantis.com
> >>>>>> <mailto:spasquier at mirantis.com> <mailto:
> spasquier at mirantis.com>)
> >>>>>> wrote:
> >>>>>>
> >>>>>> Hello Roman,
> >>>>>>
> >>>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman
> >>>>>> Prykhodchenko <me at romcheg.me
> >>>>>> <mailto:me at romcheg.me> <mailto:me at 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 at lists.openstack.org
> >>>>>>> <mailto:
> OpenStack-dev-request at 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 at lists.openstack.org
> >>>>>> <mailto:
> OpenStack-dev-request at 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 at lists.openstack.org
> >>>>>> <mailto:
> OpenStack-dev-request at 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 at lists.openstack.org
> >>>>> <mailto:
> OpenStack-dev-request at 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 at lists.openstack.org
> >>> <mailto:OpenStack-dev-request at 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 at lists.openstack.org
> >>> <mailto:OpenStack-dev-request at 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 at lists.openstack.org
> >> <mailto:OpenStack-dev-request at lists.openstack.org
> >?subject:unsubscribe
> >>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage
> > questions)
> > Unsubscribe:
> >
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > <
> http://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 at lists.openstack.org?subject:unsubscribe
> > <
> http://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 at 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 at 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 at 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 at 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 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin
> Message-ID:
> <CAHKoAgpxs+6MSYnYe5O39=yd=jSrpxsadAWWzG=
> bcY3E8yE-4g at 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 at mirantis.com>
> To: Madhuri <madhuri.rai07 at gmail.com>, "OpenStack Development Mailing
> List (not for usage questions)" <openstack-dev at lists.openstack.org
> >
> Subject: Re: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin
> Message-ID: <etPan.56e67d2e.3dc3eba9.173 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/92dcf8e1/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Mon, 14 Mar 2016 14:40:39 +0530
> From: Anant Patil <anant.patil at hpe.com>
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [heat] convergence cancel messages
> Message-ID: <56E6800F.7080102 at 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 at 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 at danjou.info>
> To: gordon chung <gord at live.ca>
> Cc: "openstack-dev at lists.openstack.org"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [telemetry] stepping down as PTL
> Message-ID: <m0egbd768g.fsf at 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 at danjou.info>
> To: Mike Lowe <j.michael.lowe at gmail.com>
> Cc: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [gnocchi] strange behavior
> Message-ID: <m07fh5765p.fsf at 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 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, reedip14 at gmail.com
> Subject: Re: [openstack-dev] [neutron][TaaS] Possible points to be
> considered for TaaS Spec
> Message-ID:
> <CALqgCCqRQDwQsrPCMoUk5tCU9VJPy=
> 0MXzDuZii0ik0sb-rkXQ at 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 at 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.
>
> >
> > 2. 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
>
>
> >
> > [1]:
> > https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst
> > [2]:
> >
> 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 at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/c8beee31/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 12
> Date: Mon, 14 Mar 2016 02:41:58 -0700
> From: Sabari Murugesan <sabari.bits at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova][Glance_store][VMware] Different
> glance store for Nova snapshot in VMware
> Message-ID:
> <
> CAJJL21MpwO6Jta8eOHvTJaw1+Fhf_8frqW9xOhgaQEMUuy1pzw at 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 <image_id>" to
> know the location.
>
> [DEFAULT]
> show_multiple_locations = True
>
> Thanks
> Sabari
>
>
>
>
>
> On Sun, Mar 13, 2016 at 7:54 PM, dongcan ye <hellochosen at gmail.com> wrote:
>
> > Hi all,
> >
> > In our production environment, we enables glance_store for VMware
> > datastore.
> > Configuration in glance-api.conf:
> >
> > [DEFAULT]
> > show_image_direct_url = True
> > [glance_store]
> > stores= glance.store.vmware_datastore.Store
> > default_store = vsphere
> > vmware_server_host= 172.18.6.22
> > vmware_server_username = administrator at vsphere.local
> > vmware_server_password = 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/openstack_glance/52825a70-f645-46b5-80ec-7a430dcd13cf?dcPath=IDC_Test&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 at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/43624923/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Mon, 14 Mar 2016 10:50:31 +0100
> From: Gorka Eguileor <geguileo at redhat.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Cinder] PTL Candidacy
> Message-ID: <20160314095031.GB668 at 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 at 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 at gmail.com>
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [OpenStack-Ansible] PTL Candidacy
> Message-ID:
> <CAGSrQvz=
> JsKisOqHTdru0VrEKHN5zeaoNS9-eLNi70WiuWGmpg at 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 at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [swift3][swift] What happens in swift3?
> Message-ID:
> <
> CAKdBrScVhawgvTtdCjj6PpNUEqYNdLegO2yKQ+OgB+afKeZNTA at 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 at hpe.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat
> template
> Message-ID:
> <
> 632AC00166CA654683E6FE74AD16B12776CC70C1 at 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 at mirantis.com]
> Sent: Friday, March 11, 2016 10:23 PM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev at 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 at hpe.com> wrote:
> > Hi Sergey,
> >
> > Thanks for your reply.
> >
> > Thanks for your pointing out that "depends_on" is not needed when we
> have already used "get_attr".
>
> So as Zane pointed, when we use get_attr it's expected, that we start
> create rg_b, when rg_a 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 rg_a 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 "depends_on" functionalities, Heat will launch
> another resource group(in my case, "rg_b") as soon as the server in "rg_a"
> 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_a_wc_notify:
> > type: OS::Heat::SoftwareConfig
> > properties:
> > group: ungrouped
> > config:
> > str_replace:
> > template: |
> > #!/bin/bash -v
> > wc_notify --data-binary '{"status": "SUCCESS"}'
> > params:
> > wc_notify: {get_attr: [master_wait_handle, 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(rg_a and rg_b) is completed?
>
>
>
> >
> > Regards,
> > Gary
> >
> > -----Original Message-----
> > From: Sergey Kraynev [mailto:skraynev at 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 "depends_on", because using
> "get_attr" already create implicit dependency from rg_a.
> > 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 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.
> >
> > On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) <
> li-gong.duan at hpe.com> wrote:
> >> Hi,
> >>
> >>
> >>
> >> I have 3 Heat templates using ResourceGroup. There are 2 resource
> >> groups(rg_a and rg_b) and rg_b depends on rg_a. and rg_b requires
> >> the IP address of rg_a as the paremeter of rg_b. I use ?rg_a_public_ip:
> {get_attr:
> >> [rg_a, rg_a_public_ip]}? to get the IP address of rg_a both in the
> >> section of rg_b parameters (rg_b/properties/resource_def/properties)
> >> and the section of outputs.
> >>
> >> As per my observation, rg_a_public_ip shows ?null? in the parameter
> >> section of rg_b. while rg_a_public_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:
> >>
> >> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}
> >> --------------------- 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:
> >>
> >> rg_a_public_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 at 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 at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > ______________________________________________________________________
> > ____ OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> --
> Regards,
> Sergey.
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ------------------------------
>
> Message: 17
> Date: Mon, 14 Mar 2016 10:21:27 +0000
> From: Andrea Frittoli <andrea.frittoli at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [QA] Not running for PTL
> Message-ID:
> <CAB7WYGUn1nBYBWA1hjCY2wsPvGqd=
> PWT5NCF2gkqH_CZCaRf6w at 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 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/2ac6aafa/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 18
> Date: Mon, 14 Mar 2016 11:34:28 +0100
> From: "Markus Zoeller" <mzoeller at de.ibm.com>
> To: "OpenStack Development Mailing List \(not for usage questions\)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [nova] stuck review, mtu incorrectly set
> on vhost-user port prevents vm booting.
> Message-ID:
> <201603141034.u2EAYYe7005382 at d06av12.portsmouth.uk.ibm.com>
> Content-Type: text/plain; charset="ISO-8859-1"
>
> "Mooney, Sean K" <sean.k.mooney at intel.com> wrote on 03/11/2016 07:20:46
> PM:
>
> > From: "Mooney, Sean K" <sean.k.mooney at intel.com>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at 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 at 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 at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>, gordon chung <gord at live.ca>
> Subject: Re: [openstack-dev] [telemetry] stepping down as PTL
> Message-ID:
> <CAKWrcJeadCCb_Y1gJkNMSsTNo053y-tsB=tThgnJX=
> E5oKoo_w at 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 at 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 at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/cfd50f3f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 20
> Date: Mon, 14 Mar 2016 14:09:00 +0300
> From: Nikolay Starodubtsev <nstarodubtsev at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin
> Message-ID:
> <CAAa8YgBa7t1S6dJSK6ScP=
> jKEgyH9bjrCCekogcWgFNmwFpSAw at 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 at 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 at 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 at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/1aba7a73/attachment-0001.html
> >
>
> ------------------------------
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 47, Issue 56
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160315/a017610f/attachment-0001.html>
More information about the OpenStack-dev
mailing list