[openstack-dev] [Nova][Glance_store][VMware] Different glance store for Nova snapshot in VMware
dongcan ye
hellochosen at gmail.com
Tue Mar 15 03:32:26 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/a62c71c9/attachment.html>
More information about the OpenStack-dev
mailing list