<div dir="ltr"><div>Hi, Sabari</div><div><br></div><div>Thanks for your reply.</div><div><br></div><div>Yes, I had tuned FileSystem to vsphere. Then I create an image, image info shows it stores in VMware</div><div>datastore. </div><div><br></div><div>I had followed your suggestion, add show_multiple_locations to glance api conf.</div><div>Then I repeat the operations.</div><div><br></div><div>Results from two snapshotted images:</div><div>locations [{"url": "file:///var/lib/glance/images/0cdd8188-537e-49e2-b173-7de122070574", "metadata": {}}]</div><div><br></div><div>locations [{"url": "vsphere://<a href="http://172.20.2.38/folder/openstack_glance/f462c06a-f202-4b1f-a89a-17f72264b502?dcPath=IDC_Test&dsName=LUN03-00">172.20.2.38/folder/openstack_glance/f462c06a-f202-4b1f-a89a-17f72264b502?dcPath=IDC_Test&dsName=LUN03-00</a>", "metadata": {}}]</div><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-03-14 20:00 GMT+08:00 <span dir="ltr"><<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenStack-dev mailing list submissions to<br>
<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openstack-dev-request@lists.openstack.org" target="_blank">openstack-dev-request@lists.openstack.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openstack-dev-owner@lists.openstack.org" target="_blank">openstack-dev-owner@lists.openstack.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenStack-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: [QA] Not running for PTL (Daniel Mellado)<br>
2. [networking-ovn][devstack] devstack deoloyed with<br>
networking-ovn come accross error 'ovs-ofctl: br-int is not a<br>
bridge or a socket' (Wilence Yao)<br>
3. Re: [Fuel] Removing logs from Fuel Web UI and Nailgun<br>
(Anastasia Urlapova)<br>
4. [Third-Party][CI] Modify&delete&add CI accouts in CI group<br>
(Watanabe, Isao)<br>
5. Re: [Fuel] Removing logs from Fuel Web UI and Nailgun<br>
(Bogdan Dobrelya)<br>
6. [Murano] [FFE] Support for Magnum Plugin (Madhuri)<br>
7. Re: [Murano] [FFE] Support for Magnum Plugin (Kirill Zaitsev)<br>
8. Re: [heat] convergence cancel messages (Anant Patil)<br>
9. Re: [telemetry] stepping down as PTL (Julien Danjou)<br>
10. Re: [gnocchi] strange behavior (Julien Danjou)<br>
11. Re: [neutron][TaaS] Possible points to be considered for TaaS<br>
Spec (Irena Berezovsky)<br>
12. Re: [Nova][Glance_store][VMware] Different glance store for<br>
Nova snapshot in VMware (Sabari Murugesan)<br>
13. Re: [Cinder] PTL Candidacy (Gorka Eguileor)<br>
14. [OpenStack-Ansible] PTL Candidacy (Jesse Pretorius)<br>
15. [swift3][swift] What happens in swift3? (Andrey Pavlov)<br>
16. Re: [heat] issue of ResourceGroup in Heat template<br>
(Duan, Li-Gong (Gary, HPServers-Core-OE-PSC))<br>
17. Re: [QA] Not running for PTL (Andrea Frittoli)<br>
18. Re: [nova] stuck review, mtu incorrectly set on vhost-user<br>
port prevents vm booting. (Markus Zoeller)<br>
19. Re: [telemetry] stepping down as PTL (Nadya Shakhat)<br>
20. Re: [Murano] [FFE] Support for Magnum Plugin<br>
(Nikolay Starodubtsev)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 14 Mar 2016 09:27:11 +0100<br>
From: Daniel Mellado <<a href="mailto:daniel.mellado.es@ieee.org" target="_blank">daniel.mellado.es@ieee.org</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [QA] Not running for PTL<br>
Message-ID: <<a href="mailto:56E675DF.4020809@ieee.org" target="_blank">56E675DF.4020809@ieee.org</a>><br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Thanks Matt for all your help and support, and glad that you'll be still<br>
around!<br>
<br>
El 11/03/16 a las 20:34, Matthew Treinish escribi?:<br>
> Hi everyone,<br>
><br>
> I'm writing this to announce that I am not running for QA PTL this cycle. I've<br>
> been the QA PTL for the past 4 cycles and I think it's time for another person<br>
> to take over the role. I think during the past 4 cycles the QA community has<br>
> grown greatly and become a much larger and stronger community compared to when<br>
> I first took on the position in the Juno cycle.<br>
><br>
> I strongly believe in the diversity of leadership and ideas, and I don't want<br>
> the community to grow stagnant because it becomes synonymous with just my voice.<br>
> Being a PTL is not the same as being an autocrat and I think it's time for<br>
> another person to step up and take over the QA PTL spot.<br>
><br>
> That being said, I'm not planning on going anywhere or leaving the project. I<br>
> fully intend to continue working and being heavily involved with the QA program,<br>
> as I have for been the past 2 years. (although maybe with a bit more free time<br>
> now)<br>
><br>
> -Matt Treinish<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/f33565e4/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/f33565e4/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 14 Mar 2016 16:36:07 +0800<br>
From: Wilence Yao <<a href="mailto:wilence.yao@gmail.com" target="_blank">wilence.yao@gmail.com</a>><br>
To: openstack-dev <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [networking-ovn][devstack] devstack deoloyed<br>
with networking-ovn come accross error 'ovs-ofctl: br-int is not a<br>
bridge or a socket'<br>
Message-ID:<br>
<CANAfaUEYjEBq9-XVCp=6e84FNGgBxo5NvLh9k0LJtF7foo=U=<a href="mailto:A@mail.gmail.com" target="_blank">A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hello all,<br>
<br>
I am going to deploye devstakv with networking-ovn, and I am following with<br>
the doc <a href="http://docs.openstack.org/developer/networking-ovn/testing.html" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/networking-ovn/testing.html</a><br>
<br>
However, error occured in running stack.sh.<br>
<br>
Traceback below here:<br>
<br>
2016-03-14 08:14:44.729 | cd datapath/linux && make modules_install<br>
2016-03-14 08:14:44.735 | make[1]: Entering directory<br>
`/opt/stack/ovs/datapath/linux'<br>
2016-03-14 08:14:44.735 | make -C<br>
/lib/modules/3.10.0-327.10.1.el7.x86_64/build<br>
M=/opt/stack/ovs/datapath/linux modules_install<br>
2016-03-14 08:14:45.079 | make[2]: Entering directory<br>
`/usr/src/kernels/3.10.0-327.10.1.el7.x86_64'<br>
2016-03-14 08:14:45.098 | INSTALL<br>
/opt/stack/ovs/datapath/linux/openvswitch.ko<br>
2016-03-14 08:14:45.148 | Can't read private key<br>
2016-03-14 08:14:45.151 | INSTALL<br>
/opt/stack/ovs/datapath/linux/vport-geneve.ko<br>
2016-03-14 08:14:45.183 | Can't read private key<br>
2016-03-14 08:14:45.186 | INSTALL<br>
/opt/stack/ovs/datapath/linux/vport-gre.ko<br>
2016-03-14 08:14:45.218 | Can't read private key<br>
2016-03-14 08:14:45.220 | INSTALL<br>
/opt/stack/ovs/datapath/linux/vport-lisp.ko<br>
2016-03-14 08:14:45.248 | Can't read private key<br>
2016-03-14 08:14:45.250 | INSTALL<br>
/opt/stack/ovs/datapath/linux/vport-stt.ko<br>
2016-03-14 08:14:45.278 | Can't read private key<br>
2016-03-14 08:14:45.281 | INSTALL<br>
/opt/stack/ovs/datapath/linux/vport-vxlan.ko<br>
2016-03-14 08:14:45.309 | Can't read private key<br>
2016-03-14 08:14:45.322 | DEPMOD 3.10.0-327.10.1.el7.x86_64<br>
2016-03-14 08:14:45.668 | make[2]: Leaving directory<br>
`/usr/src/kernels/3.10.0-327.10.1.el7.x86_64'<br>
2016-03-14 08:14:45.669 | depmod `sed -n 's/#define UTS_RELEASE<br>
"\([^"]*\)"/\1/p'<br>
/lib/modules/3.10.0-327.10.1.el7.x86_64/build/include/generated/utsrelease.h`<br>
2016-03-14 08:14:45.986 | make[1]: Leaving directory<br>
`/opt/stack/ovs/datapath/linux'<br>
2016-03-14 08:14:46.007 | modprobe: FATAL: Module openvswitch is in use.<br>
2016-03-14 08:14:46.009 | Error on exit<br>
2016-03-14 08:14:46.487 | ovs-vsctl:<br>
unix:/usr/local/var/run/openvswitch/db.sock: database connection failed (No<br>
such file or directory)<br>
2016-03-14 08:14:46.498 | ovs-ofctl: br-int is not a bridge or a socket<br>
2016-03-14 08:14:46.508 | ovs-ofctl: br-tun is not a bridge or a socket<br>
2016-03-14 08:14:46.518 | ovs-ofctl: br-ex is not a bridge or a socket<br>
2016-03-14 08:14:46.529 | ovs-ofctl: br-int is not a bridge or a socket<br>
2016-03-14 08:14:46.540 | ovs-ofctl: br-tun is not a bridge or a socket<br>
2016-03-14 08:14:46.551 | ovs-ofctl: br-ex is not a bridge or a socket<br>
<br>
I know that in this process , stack.sh will install openvswitch when<br>
processing neutron, then it will uninstall openvswitch and make && make<br>
install openvswitch from ovs code source again.<br>
<br>
Because of uninstalling of openvswitch, br-int and other brigeds loss from<br>
ovs, so the new ovn process come accross the error that no bridges<br>
br-int/br-ex/br-tun.<br>
<br>
Is this a networking-ovn bug or a devstack bug?<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/4daf867f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/4daf867f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 14 Mar 2016 11:38:45 +0300<br>
From: Anastasia Urlapova <<a href="mailto:aurlapova@mirantis.com" target="_blank">aurlapova@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and<br>
Nailgun<br>
Message-ID:<br>
<<a href="mailto:CAC%2BXjbZMXMLdhgezYocxuD49fx1Uw3WqBjAtxe2G-mwxboKZ_Q@mail.gmail.com" target="_blank">CAC+XjbZMXMLdhgezYocxuD49fx1Uw3WqBjAtxe2G-mwxboKZ_Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
+1 to Vitaliy, it would be nice find somewhere a details for migration.<br>
And one more concern I should highlight - for some users logless UI may be<br>
challenging thing.<br>
The logs removing shouldn't affect the UX.<br>
<br>
<br>
Nastya.<br>
<br>
<br>
On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>> wrote:<br>
<br>
> I think we can address it by retaining deployment logs in nailgun/ui, this<br>
> also removes the chicken and egg problem. after LMA is deployed it can be<br>
> allowed to re-own 'logs' button on UI once it's deployed, including<br>
> redirecting fuel logs there.<br>
><br>
> On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>><br>
> wrote:<br>
><br>
>> We can sort out details later. In a worst case, the warning will be there<br>
>> in Newton too, and feature will go away only in O* release. So let's<br>
>> proceed with the bug..<br>
>><br>
>> On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh <<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>><br>
>> wrote:<br>
>><br>
>>> We can add the warning, but I think before we do this we should have<br>
>>> clear migration plan. According to this thread, some parts are still not<br>
>>> clear.<br>
>>><br>
>>> 2016-03-11 22:00 GMT+03:00 Mike Scherbakov <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>>:<br>
>>><br>
>>>> Deprecation warning for Fuel Mitaka:<br>
>>>> <a href="https://bugs.launchpad.net/fuel/+bug/1556244" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1556244</a>.<br>
>>>><br>
>>>><br>
>>>> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko <<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>><br>
>>>> wrote:<br>
>>>><br>
>>>>> Since there are a lot of supporters for this idea, what do you folks<br>
>>>>> think about creating a BP spec where we can describe what we should do in<br>
>>>>> order to remove logs from UI and Nailgun? I also propose to file a bug<br>
>>>>> about adding a deprecation warning to Mitaka release of Fuel.<br>
>>>>><br>
>>>>><br>
>>>>> 11 ???. 2016 ?. ? 16:55 Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>><br>
>>>>> ???????(??):<br>
>>>>><br>
>>>>><br>
>>>>> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:<br>
>>>>><br>
>>>>> +1 to remove logs from Fuel UI in Fuel Newton.<br>
>>>>> In Fuel Mitaka we'd need to put a deprecation warning somewhere.<br>
>>>>><br>
>>>>><br>
>>>>> I agree, there is not much sense having non flexible (no content<br>
>>>>> filters) logs view in UI. LMA plugins shall cover this area as well.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Fri, Mar 11, 2016, 04:57 Patrick Petit <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a><br>
>>>>> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a> <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>>>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>> On 11 March 2016 at 12:51:40, Igor Kalnitsky<br>
>>>>> (<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a> <mailto:<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a><br>
>>>>> <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>>>) wrote:<br>
>>>>><br>
>>>>> Patrick,<br>
>>>>><br>
>>>>> Sorry, but I meant another question. I thought that LMA plugin<br>
>>>>> should<br>
>>>>> be installed in some environment before we can start use it. Is<br>
>>>>> this a<br>
>>>>> case? If so, it means we can't use for master node until some<br>
>>>>> environment is deployed.<br>
>>>>><br>
>>>>><br>
>>>>> Right. This is the chicken and egg problem I mentioned earlier...<br>
>>>>><br>
>>>>> But this is not a ?problem? specific to Fuel. My take on this is is<br>
>>>>> that ops management tooling (logging, monitoring) should be<br>
>>>>> installed off-band before any OpenStack deployment. In fact, in<br>
>>>>> real-world usage, we frequently get asks to have the monitoring and<br>
>>>>> logging services of StackLight installed permanently for<br>
>>>>> multi-enviroments. And so, one approach would be to make Stacklight<br>
>>>>> backend services the first bits of software installed by Fuel (if<br>
>>>>> not already there), then reconfigure Fuel to hook into those<br>
>>>>> services and only then, enter into the regular OpenStack<br>
>>>>> provisioning mode.<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit<br>
>>>>> <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a><br>
>>>>> <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>>>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a><br>
>>>>> <mailto:<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a> <<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>>>)<br>
>>>>> wrote:<br>
>>>>><br>
>>>>> Hey Roman,<br>
>>>>><br>
>>>>> Thank you for bringing this up. +1 from my side, especially taking<br>
>>>>> into account the patch where we tried to solve logrotated logs problem<br>
>>>>><br>
>>>>> [1]. It's complex and unsupportable, as well as already existed<br>
>>>>> logview code in Nailgun.<br>
>>>>><br>
>>>>> Patrick, Simon,<br>
>>>>><br>
>>>>> Does LMA plugin support logs from master node? Or it's designed to<br>
>>>>> watch environment's logs?<br>
>>>>><br>
>>>>> No it?s not designed specifically for environment logs. Can be adapted<br>
>>>>> to<br>
>>>>> any log format.<br>
>>>>><br>
>>>>> Would just need to write a parser like you would with logstach when<br>
>>>>> logs are<br>
>>>>> not standard.<br>
>>>>><br>
>>>>> Patrick<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> Igor<br>
>>>>><br>
>>>>><br>
>>>>> [1]: <a href="https://review.openstack.org/#/c/243240/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/243240/</a><br>
>>>>><br>
>>>>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a> <<br>
>>>>> mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a> <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>>>> wrote:<br>
>>>>><br>
>>>>> Fuelers,<br>
>>>>><br>
>>>>> As Simon said, we already have a log centralisation solution for MOS<br>
>>>>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so<br>
>>>>> objectively, there is no need to have log management in Nailgun<br>
>>>>> anymore.<br>
>>>>> To<br>
>>>>> go one step further we suggested several times to have a StackLight<br>
>>>>> agent<br>
>>>>> installed on the Fuel master node to also collect and centralise those<br>
>>>>><br>
>>>>> logs.<br>
>>>>> There is a little bit of a chicken and egg problem to resolve but I<br>
>>>>> think<br>
>>>>> it<br>
>>>>> is worth a try to have that nailed down in the roadmap for Fuel 10.<br>
>>>>> Cheers<br>
>>>>> - Patrick<br>
>>>>><br>
>>>>><br>
>>>>> On 11 March 2016 at 10:07:28, Simon Pasquier (<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a> <<br>
>>>>> mailto:<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a> <<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a>>>)<br>
>>>>> wrote:<br>
>>>>><br>
>>>>> Hello Roman,<br>
>>>>><br>
>>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a> <<br>
>>>>> mailto:<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a> <<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>>>><br>
>>>>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>> Fuelers,<br>
>>>>><br>
>>>>> I remember we?ve discussing this topic in our couloirs before but I?d<br>
>>>>> like<br>
>>>>> to bring that discussion to a more official format.<br>
>>>>><br>
>>>>> Let me state a few reasons to do this:<br>
>>>>><br>
>>>>> - Log management code in Nailgun is overcomplicated<br>
>>>>> - Working with logs on big scale deployments is barely possible given<br>
>>>>> the<br>
>>>>> current representation<br>
>>>>> - Due to overcomplexity and ineffectiveness of the code we always get<br>
>>>>> recurring bugs like [1]. That eats tons of time to resolve.<br>
>>>>> - There are much better specialized tools, say Logstash [2], that can<br>
>>>>> deal<br>
>>>>> with logs much more effectively.<br>
>>>>><br>
>>>>><br>
>>>>> There may be more reasons bus I think even the already mentioned ones<br>
>>>>> are<br>
>>>>> enough to think about the following proposal:<br>
>>>>><br>
>>>>> - Remove Logs tab from Fuel Web UI<br>
>>>>> - Remove logs support from Nailgun<br>
>>>>> - Create mechanism that allows to configure different log management<br>
>>>>> software, say Logstash, Loggly, etc<br>
>>>>><br>
>>>>> - Choose a default software to install and provide a plugin for it from<br>
>>>>><br>
>>>>> the box<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> This is what the LMA/StackLight plugins [1][2] are meant for. No need<br>
>>>>> to<br>
>>>>> develop anything new.<br>
>>>>><br>
>>>>> And I'm +1 with the removal of log management from Fuel. As you said,<br>
>>>>> it<br>
>>>>> can't scale...<br>
>>>>><br>
>>>>> [1] <a href="http://fuel-plugin-lma-collector.readthedocs.org/en/latest/" rel="noreferrer" target="_blank">http://fuel-plugin-lma-collector.readthedocs.org/en/latest/</a><br>
>>>>> [2] <a href="http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/" rel="noreferrer" target="_blank">http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> References<br>
>>>>> 1. <a href="https://bugs.launchpad.net/fuel/+bug/1553170" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1553170</a><br>
>>>>> 2. <a href="https://www.elastic.co/products/logstash" rel="noreferrer" target="_blank">https://www.elastic.co/products/logstash</a><br>
>>>>><br>
>>>>><br>
>>>>> - romcheg<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>><br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>><br>
>>>>> <<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>><br>
>>>>> ><br>
>>>>><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>><br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>> ?subject:unsubscribe<br>
>>>>><br>
>>>>> <<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>><br>
>>>>> ><br>
>>>>><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>><br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>> ?subject:unsubscribe<br>
>>>>><br>
>>>>> <<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>><br>
>>>>> ><br>
>>>>><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>><br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>> ?subject:unsubscribe<br>
>>>>><br>
>>>>> <<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>><br>
>>>>> ><br>
>>>>><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>><br>
>>>>> ><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>> --<br>
>>>>> Mike Scherbakov<br>
>>>>> #mihgen<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>> ?subject:unsubscribe<br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> --<br>
>>>>> Best regards,<br>
>>>>> Bogdan Dobrelya,<br>
>>>>> Irc #bogdando<br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>> ?subject:unsubscribe<br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>> --<br>
>>>> Mike Scherbakov<br>
>>>> #mihgen<br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Vitaly Kramskikh,<br>
>>> Fuel UI Tech Lead,<br>
>>> Mirantis, Inc.<br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>> --<br>
>> Mike Scherbakov<br>
>> #mihgen<br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
> --<br>
><br>
> --<br>
><br>
> Andrew Woodward<br>
><br>
> Mirantis<br>
><br>
> Fuel Community Ambassador<br>
><br>
> Ceph Community<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/f575548d/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/f575548d/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Mon, 14 Mar 2016 08:39:53 +0000<br>
From: "Watanabe, Isao" <<a href="mailto:watanabe_isao@jp.fujitsu.com" target="_blank">watanabe_isao@jp.fujitsu.com</a>><br>
To: "<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Third-Party][CI] Modify&delete&add CI<br>
accouts in CI group<br>
Message-ID: <AC0F94DB49C0C2439892181E6CDA6E6C172D509A@G01JPEXMBYT05><br>
Content-Type: text/plain; charset="iso-2022-jp"<br>
<br>
Hello, Third-Party Coordinators<br>
Cc?Ramy<br>
<br>
Could you please help me about the following CI accounts changes in CI group?<br>
<br>
[1]Add account<br>
Name: Fujitsu ISM CI<br>
Mail: <a href="mailto:fj-lsoft-ismci@dl.jp.fujitsu.com" target="_blank">fj-lsoft-ismci@dl.jp.fujitsu.com</a><br>
<br>
[2]Modify<br>
Name: Fujitsu ETERNUS CI<br>
OLD-Email: <a href="mailto:lsoft-eternusci@ml.css.fujitsu.com" target="_blank">lsoft-eternusci@ml.css.fujitsu.com</a><br>
NEW-Email: <a href="mailto:fj-lsoft-eternusci@dl.jp.fujitsu.com" target="_blank">fj-lsoft-eternusci@dl.jp.fujitsu.com</a><br>
<br>
[3] Modify<br>
OLD-Name: Fujitsu IRMC CI<br>
NEW-Name: Fujitsu iRMC CI<br>
OLD-Email: <a href="mailto:lsoft-irmcci@ml.css.fujitsu.com" target="_blank">lsoft-irmcci@ml.css.fujitsu.com</a><br>
NEW-Email: <a href="mailto:fj-lsoft-irmcci@dl.jp.fujitsu.com" target="_blank">fj-lsoft-irmcci@dl.jp.fujitsu.com</a><br>
<br>
[4] Modify<br>
Name: Fujitsu C-Fabric CI<br>
OLD-Email: <a href="mailto:lsoft-cfabricci@ml.css.fujitsu.com" target="_blank">lsoft-cfabricci@ml.css.fujitsu.com</a><br>
NEW-Email: <a href="mailto:fj-lsoft-cfabricci@dl.jp.fujitsu.com" target="_blank">fj-lsoft-cfabricci@dl.jp.fujitsu.com</a><br>
<br>
[5] Delete<br>
Name: Fujitsu ETERNUS FC CI<br>
Email: <a href="mailto:lsoft-openstackci@ml.css.fujitsu.com" target="_blank">lsoft-openstackci@ml.css.fujitsu.com</a><br>
<br>
<br>
Best regards,<br>
Watanabe.isao<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Mon, 14 Mar 2016 09:53:49 +0100<br>
From: Bogdan Dobrelya <<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Fuel] Removing logs from Fuel Web UI and<br>
Nailgun<br>
Message-ID: <<a href="mailto:56E67C1D.1030904@mirantis.com" target="_blank">56E67C1D.1030904@mirantis.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 03/14/2016 09:38 AM, Anastasia Urlapova wrote:<br>
> +1 to Vitaliy, it would be nice find somewhere a details for migration.<br>
> And one more concern I should highlight - for some users logless UI may<br>
> be challenging thing.<br>
> The logs removing shouldn't affect the UX.<br>
<br>
Logs will still live at the master node's /var/log/remote<br>
<br>
><br>
><br>
> Nastya.<br>
><br>
><br>
> On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a><br>
> <mailto:<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>>> wrote:<br>
><br>
> I think we can address it by retaining deployment logs in<br>
> nailgun/ui, this also removes the chicken and egg problem. after LMA<br>
> is deployed it can be allowed to re-own 'logs' button on UI once<br>
> it's deployed, including redirecting fuel logs there.<br>
><br>
> On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov<br>
> <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a> <mailto:<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>>> wrote:<br>
><br>
> We can sort out details later. In a worst case, the warning will<br>
> be there in Newton too, and feature will go away only in O*<br>
> release. So let's proceed with the bug..<br>
><br>
> On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh<br>
> <<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a> <mailto:<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>>> wrote:<br>
><br>
> We can add the warning, but I think before we do this we<br>
> should have clear migration plan. According to this thread,<br>
> some parts are still not clear.<br>
><br>
> 2016-03-11 22:00 GMT+03:00 Mike Scherbakov<br>
> <<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a> <mailto:<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>>>:<br>
><br>
> Deprecation warning for Fuel<br>
> Mitaka: <a href="https://bugs.launchpad.net/fuel/+bug/1556244" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1556244</a>.<br>
><br>
><br>
> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko<br>
> <<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a> <mailto:<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>>> wrote:<br>
><br>
> Since there are a lot of supporters for this idea,<br>
> what do you folks think about creating a BP spec<br>
> where we can describe what we should do in order to<br>
> remove logs from UI and Nailgun? I also propose to<br>
> file a bug about adding a deprecation warning to<br>
> Mitaka release of Fuel.<br>
><br>
><br>
>> 11 ???. 2016 ?. ? 16:55 Bogdan Dobrelya<br>
>> <<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a><br>
>> <mailto:<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>>> ???????(??):<br>
>><br>
>> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:<br>
>>> +1 to remove logs from Fuel UI in Fuel Newton.<br>
>>> In Fuel Mitaka we'd need to put a deprecation<br>
>>> warning somewhere.<br>
>><br>
>> I agree, there is not much sense having non<br>
>> flexible (no content<br>
>> filters) logs view in UI. LMA plugins shall cover<br>
>> this area as well.<br>
>><br>
>>><br>
>>><br>
>>> On Fri, Mar 11, 2016, 04:57 Patrick Petit<br>
>>> <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>><br>
>>> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>>> wrote:<br>
>>><br>
>>><br>
>>> On 11 March 2016 at 12:51:40, Igor Kalnitsky<br>
>>> (<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a><br>
>>> <mailto:<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>> <mailto:<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>>)<br>
>>> wrote:<br>
>>><br>
>>>> Patrick,<br>
>>>><br>
>>>> Sorry, but I meant another question. I<br>
>>>> thought that LMA plugin should<br>
>>>> be installed in some environment before we<br>
>>>> can start use it. Is<br>
>>>> this a<br>
>>>> case? If so, it means we can't use for master<br>
>>>> node until some<br>
>>>> environment is deployed.<br>
>>><br>
>>> Right. This is the chicken and egg problem I<br>
>>> mentioned earlier...<br>
>>><br>
>>> But this is not a ?problem? specific to Fuel.<br>
>>> My take on this is is<br>
>>> that ops management tooling (logging,<br>
>>> monitoring) should be<br>
>>> installed off-band before any OpenStack<br>
>>> deployment. In fact, in<br>
>>> real-world usage, we frequently get asks to<br>
>>> have the monitoring and<br>
>>> logging services of StackLight installed<br>
>>> permanently for<br>
>>> multi-enviroments. And so, one approach would<br>
>>> be to make Stacklight<br>
>>> backend services the first bits of software<br>
>>> installed by Fuel (if<br>
>>> not already there), then reconfigure Fuel to<br>
>>> hook into those<br>
>>> services and only then, enter into the regular<br>
>>> OpenStack<br>
>>> provisioning mode.<br>
>>><br>
>>>><br>
>>>><br>
>>>> On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit<br>
>>>> <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a><br>
>>>> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky<br>
>>>>> (<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a><br>
>>>>> <mailto:<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>> <mailto:<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>>)<br>
>>>>> wrote:<br>
>>>>><br>
>>>>> Hey Roman,<br>
>>>>><br>
>>>>> Thank you for bringing this up. +1 from my<br>
>>>>> side, especially taking<br>
>>>>> into account the patch where we tried to solve<br>
>>>>> logrotated logs problem<br>
>>>>> [1]. It's complex and unsupportable, as well as<br>
>>>>> already existed<br>
>>>>> logview code in Nailgun.<br>
>>>>><br>
>>>>> Patrick, Simon,<br>
>>>>><br>
>>>>> Does LMA plugin support logs from master node?<br>
>>>>> Or it's designed to<br>
>>>>> watch environment's logs?<br>
>>>>><br>
>>>>> No it?s not designed specifically for<br>
>>>>> environment logs. Can be adapted to<br>
>>>>> any log format.<br>
>>>>><br>
>>>>> Would just need to write a parser like you<br>
>>>>> would with logstach when logs are<br>
>>>>> not standard.<br>
>>>>><br>
>>>>> Patrick<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> Thanks,<br>
>>>>> Igor<br>
>>>>><br>
>>>>><br>
>>>>> [1]: <a href="https://review.openstack.org/#/c/243240/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/243240/</a><br>
>>>>><br>
>>>>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit<br>
>>>>> <<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a><br>
>>>>> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>> <mailto:<a href="mailto:ppetit@mirantis.com" target="_blank">ppetit@mirantis.com</a>>><br>
>>>>> wrote:<br>
>>>>>> Fuelers,<br>
>>>>>><br>
>>>>>> As Simon said, we already have a log<br>
>>>>>> centralisation solution for MOS<br>
>>>>>> delivered as a Fuel plugins known as<br>
>>>>>> StackLight / LMA toolset. And so<br>
>>>>>> objectively, there is no need to have log<br>
>>>>>> management in Nailgun anymore.<br>
>>>>>> To<br>
>>>>>> go one step further we suggested several times<br>
>>>>>> to have a StackLight agent<br>
>>>>>> installed on the Fuel master node to also<br>
>>>>>> collect and centralise those<br>
>>>>>> logs.<br>
>>>>>> There is a little bit of a chicken and egg<br>
>>>>>> problem to resolve but I think<br>
>>>>>> it<br>
>>>>>> is worth a try to have that nailed down in the<br>
>>>>>> roadmap for Fuel 10.<br>
>>>>>> Cheers<br>
>>>>>> - Patrick<br>
>>>>>><br>
>>>>>><br>
>>>>>> On 11 March 2016 at 10:07:28, Simon Pasquier<br>
>>>>>> (<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a><br>
>>>>>> <mailto:<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a>> <mailto:<a href="mailto:spasquier@mirantis.com" target="_blank">spasquier@mirantis.com</a>>)<br>
>>>>>> wrote:<br>
>>>>>><br>
>>>>>> Hello Roman,<br>
>>>>>><br>
>>>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman<br>
>>>>>> Prykhodchenko <<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a><br>
>>>>>> <mailto:<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>> <mailto:<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>>><br>
>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> Fuelers,<br>
>>>>>>><br>
>>>>>>> I remember we?ve discussing this topic in our<br>
>>>>>>> couloirs before but I?d<br>
>>>>>>> like<br>
>>>>>>> to bring that discussion to a more official<br>
>>>>>>> format.<br>
>>>>>>><br>
>>>>>>> Let me state a few reasons to do this:<br>
>>>>>>><br>
>>>>>>> - Log management code in Nailgun is<br>
>>>>>>> overcomplicated<br>
>>>>>>> - Working with logs on big scale deployments<br>
>>>>>>> is barely possible given the<br>
>>>>>>> current representation<br>
>>>>>>> - Due to overcomplexity and ineffectiveness<br>
>>>>>>> of the code we always get<br>
>>>>>>> recurring bugs like [1]. That eats tons of<br>
>>>>>>> time to resolve.<br>
>>>>>>> - There are much better specialized tools,<br>
>>>>>>> say Logstash [2], that can<br>
>>>>>>> deal<br>
>>>>>>> with logs much more effectively.<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> There may be more reasons bus I think even<br>
>>>>>>> the already mentioned ones are<br>
>>>>>>> enough to think about the following proposal:<br>
>>>>>>><br>
>>>>>>> - Remove Logs tab from Fuel Web UI<br>
>>>>>>> - Remove logs support from Nailgun<br>
>>>>>>> - Create mechanism that allows to configure<br>
>>>>>>> different log management<br>
>>>>>>> software, say Logstash, Loggly, etc<br>
>>>>>>><br>
>>>>>>> - Choose a default software to install and<br>
>>>>>>> provide a plugin for it from<br>
>>>>>>> the box<br>
>>>>>><br>
>>>>>><br>
>>>>>> This is what the LMA/StackLight plugins [1][2]<br>
>>>>>> are meant for. No need to<br>
>>>>>> develop anything new.<br>
>>>>>><br>
>>>>>> And I'm +1 with the removal of log management<br>
>>>>>> from Fuel. As you said, it<br>
>>>>>> can't scale...<br>
>>>>>><br>
>>>>>> [1]<br>
>>>>>> <a href="http://fuel-plugin-lma-collector.readthedocs.org/en/latest/" rel="noreferrer" target="_blank">http://fuel-plugin-lma-collector.readthedocs.org/en/latest/</a><br>
>>>>>> [2]<br>
>>>>>> <a href="http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/" rel="noreferrer" target="_blank">http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/</a><br>
>>>>>><br>
>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> References<br>
>>>>>>> 1. <a href="https://bugs.launchpad.net/fuel/+bug/1553170" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1553170</a><br>
>>>>>>> 2. <a href="https://www.elastic.co/products/logstash" rel="noreferrer" target="_blank">https://www.elastic.co/products/logstash</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> - romcheg<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> __________________________________________________________________________<br>
>>>>>>> OpenStack Development Mailing List (not for<br>
>>>>>>> usage questions)<br>
>>>>>>> Unsubscribe:<br>
>>>>>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
>>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>>><br>
>>>>>><br>
>>>>>> __________________________________________________________________________<br>
>>>>>> OpenStack Development Mailing List (not for<br>
>>>>>> usage questions)<br>
>>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> __________________________________________________________________________<br>
>>>>>> OpenStack Development Mailing List (not for<br>
>>>>>> usage questions)<br>
>>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
>>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>>><br>
>>>>><br>
>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for<br>
>>>>> usage questions)<br>
>>>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for<br>
>>> usage questions)<br>
>>> Unsubscribe:<br>
>>> <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <<a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe</a>>><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>>> --<br>
>>> Mike Scherbakov<br>
>>> #mihgen<br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage<br>
>>> questions)<br>
>>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> --<br>
>> Best regards,<br>
>> Bogdan Dobrelya,<br>
>> Irc #bogdando<br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage<br>
>> questions)<br>
>> Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a><br>
>> <mailto:<a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>>?subject:unsubscribe<br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Vitaly Kramskikh,<br>
> Fuel UI Tech Lead,<br>
> Mirantis, Inc.<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> --<br>
> Mike Scherbakov<br>
> #mihgen<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> --<br>
><br>
> --<br>
><br>
> Andrew Woodward<br>
><br>
> Mirantis<br>
><br>
> Fuel Community Ambassador<br>
><br>
> Ceph Community<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Mon, 14 Mar 2016 14:24:49 +0530<br>
From: Madhuri <<a href="mailto:madhuri.rai07@gmail.com" target="_blank">madhuri.rai07@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin<br>
Message-ID:<br>
<CAHKoAgpxs+6MSYnYe5O39=yd=jSrpxsadAWWzG=<a href="mailto:bcY3E8yE-4g@mail.gmail.com" target="_blank">bcY3E8yE-4g@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi All,<br>
<br>
I would like to request a feature freeze exception for "Magnum/Murano<br>
rationalization" [1], Magnum app to deploy Kubernetes/Mesos/Swarm cluster.<br>
The patch is on review[2].<br>
I am looking for your decision about considering this change for a FFE.<br>
<br>
[1]<br>
<a href="https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization</a><br>
[2] <a href="https://review.openstack.org/#/c/269250/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/269250/</a><br>
<br>
Regards,<br>
Madhuri<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/845864a9/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/845864a9/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Mon, 14 Mar 2016 11:58:22 +0300<br>
From: Kirill Zaitsev <<a href="mailto:kzaitsev@mirantis.com" target="_blank">kzaitsev@mirantis.com</a>><br>
To: Madhuri <<a href="mailto:madhuri.rai07@gmail.com" target="_blank">madhuri.rai07@gmail.com</a>>, "OpenStack Development Mailing<br>
List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin<br>
Message-ID: <etPan.56e67d2e.3dc3eba9.173@TefMBPr.local><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
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.<br>
<br>
Serg, do you have any objections?<br>
<br>
--?<br>
Kirill Zaitsev<br>
Software Engineer<br>
Mirantis, Inc<br>
<br>
On 14 March 2016 at 11:55:46, Madhuri (<a href="mailto:madhuri.rai07@gmail.com" target="_blank">madhuri.rai07@gmail.com</a>) wrote:<br>
<br>
Hi All,<br>
<br>
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].<br>
I am looking for your decision about considering this change for a FFE.<br>
<br>
[1]?<a href="https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization</a><br>
[2]?<a href="https://review.openstack.org/#/c/269250/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/269250/</a><br>
<br>
Regards,<br>
Madhuri<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/92dcf8e1/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/92dcf8e1/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Mon, 14 Mar 2016 14:40:39 +0530<br>
From: Anant Patil <<a href="mailto:anant.patil@hpe.com" target="_blank">anant.patil@hpe.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [heat] convergence cancel messages<br>
Message-ID: <<a href="mailto:56E6800F.7080102@hpe.com" target="_blank">56E6800F.7080102@hpe.com</a>><br>
Content-Type: text/plain; charset=windows-1252<br>
<br>
On 24-Feb-16 22:48, Clint Byrum wrote:<br>
> Excerpts from Anant Patil's message of 2016-02-23 23:08:31 -0800:<br>
>> Hi,<br>
>><br>
>> I would like the discuss various approaches towards fixing bug<br>
>> <a href="https://launchpad.net/bugs/1533176" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1533176</a><br>
>><br>
>> When convergence is on, and if the stack is stuck, there is no way to<br>
>> cancel the existing request. This feature was not implemented in<br>
>> convergence, as the user can again issue an update on an in-progress<br>
>> stack. But if a resource worker is stuck, the new update will wait<br>
>> for-ever on it and the update will not be effective.<br>
>><br>
>> The solution is to implement cancel request. Since the work for a stack<br>
>> is distributed among heat engines, the cancel request will not work as<br>
>> it does in legacy way. Many or all of the heat engines might be running<br>
>> worker threads to provision a stack.<br>
>><br>
>> I could think of two options which I would like to discuss:<br>
>><br>
>> (a) When a user triggered cancel request is received, set the stack<br>
>> current traversal to None or something else other than current<br>
>> traversal. With this the new check-resources/workers will never be<br>
>> triggered. This is okay as long as the worker(s) is not stuck. The<br>
>> existing workers will finish running, and no new check-resource<br>
>> (workers) will be triggered, and it will be a graceful cancel. But the<br>
>> workers that are stuck will be stuck for-ever till stack times-out. To<br>
>> take care of such cases, we will have to implement logic of "polling"<br>
>> the DB at regular intervals (may be at each step() of scheduler task)<br>
>> and bail out if the current traversal is updated. Basically, each worker<br>
>> will "poll" the DB to see if the current traversal is still valid and if<br>
>> not, stop itself. The drawback of this approach is that all the workers<br>
>> will be hitting the DB and incur a significant overhead. Besides, all<br>
>> the stack workers irrespective of whether they will be cancelled or not,<br>
>> will keep on hitting DB. The advantage is that it probably is easier to<br>
>> implement. Also, if the worker is stuck in particular "step", then this<br>
>> approach will not work.<br>
>><br>
>> (b) Another approach is to send cancel message to all the heat engines<br>
>> when one receives a stack cancel request. The idea is to use the thread<br>
>> group manager in each engine to keep track of threads running for a<br>
>> stack, and stop the thread group when a cancel message is received. The<br>
>> advantage is that the messages to cancel stack workers is sent only when<br>
>> required and there is no other over-head. The draw-back is that the<br>
>> cancel message is 'broadcasted' to all heat engines, even if they are<br>
>> not running any workers for the given stack, though, in such cases, it<br>
>> will be a just no-op for the heat-engine (the message will be gracefully<br>
>> discarded).<br>
> Oh hah, I just sent (b) as an option to avoid (a) without really<br>
> thinking about (b) again.<br>
><br>
> I don't think the cancel broadcasts are all that much of a drawback. I<br>
> do think you need to rate limit cancels though, or you give users the<br>
> chance to DDoS the system.<br>
There is no easier way to restrict the cancels, so I am choosing the<br>
option of having a "monitoring task" which runs in separate thread. This<br>
task periodically polls DB to check if the current traversal is updated.<br>
When a cancel message is received, the current traversal is updated to<br>
new id and monitoring task will stop the thread group running worker<br>
threads for previous traversal (traversal uniquely identifies a stack<br>
operation).<br>
<br>
Also, this will help with checking timeout. Currently each worker checks<br>
for timeout. I can move this to the monitoring thread which will stop<br>
the thread group when stack times out.<br>
<br>
It is better to restrict the actions within the heat engine than to load<br>
the AMQP; that can lead to potentially complicated issues.<br>
<br>
-- Anant<br>
<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Mon, 14 Mar 2016 10:34:39 +0100<br>
From: Julien Danjou <<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>><br>
To: gordon chung <<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>><br>
Cc: "<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [telemetry] stepping down as PTL<br>
Message-ID: <<a href="mailto:m0egbd768g.fsf@danjou.info" target="_blank">m0egbd768g.fsf@danjou.info</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
On Fri, Mar 11 2016, gordon chung wrote:<br>
<br>
> as the PTL nominations are open, i just want to note that i won't be<br>
> running again as the Telemetry PTL for Newton cycle.<br>
><br>
> i've thoroughly enjoyed my time as PTL which afforded me the opportunity<br>
> to work with and learn from some great individuals who share the same<br>
> passion to collaborate openly. i have the utmost confidence that the<br>
> projects will continue to grow and become more refined under the next<br>
> leadership.<br>
><br>
> personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities<br>
> as well as the projects that provided valuable feedback by collaborating<br>
> with us. i thank you for sharing in the decision making so i could<br>
> spread the blame around. i also thank you for reading through terribly<br>
> written messages that make you question whether the shift keys on all my<br>
> keyboards are broken.<br>
<br>
I'd like to join others and thank you for your amazing work as a PTL.<br>
<br>
You've led the community in an open way that allowed it to share the<br>
leadership and be one of the most thrilling group that I've been able to<br>
contribute to in OpenStack.<br>
<br>
Cheers,<br>
--<br>
Julien Danjou<br>
// Free Software hacker<br>
// <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 800 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/10bdac2e/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/10bdac2e/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Mon, 14 Mar 2016 10:36:18 +0100<br>
From: Julien Danjou <<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>><br>
To: Mike Lowe <<a href="mailto:j.michael.lowe@gmail.com" target="_blank">j.michael.lowe@gmail.com</a>><br>
Cc: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [gnocchi] strange behavior<br>
Message-ID: <<a href="mailto:m07fh5765p.fsf@danjou.info" target="_blank">m07fh5765p.fsf@danjou.info</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
On Fri, Mar 11 2016, Mike Lowe wrote:<br>
<br>
> I?m having a little trouble with my gnocchi install, the only output from the<br>
> status command is ?storage? and even with verbose and debugging true the api<br>
> log doesn?t show anything after startup. Any hints?<br>
<br>
Can you share your configuration file and the log of the metricd daemon<br>
and the WSGI server?<br>
<br>
--<br>
Julien Danjou<br>
# Free Software hacker<br>
# <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: signature.asc<br>
Type: application/pgp-signature<br>
Size: 800 bytes<br>
Desc: not available<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/b8d496cf/attachment-0001.pgp" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/b8d496cf/attachment-0001.pgp</a>><br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Mon, 14 Mar 2016 11:41:21 +0200<br>
From: Irena Berezovsky <<a href="mailto:irenab.dev@gmail.com" target="_blank">irenab.dev@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, <a href="mailto:reedip14@gmail.com" target="_blank">reedip14@gmail.com</a><br>
Subject: Re: [openstack-dev] [neutron][TaaS] Possible points to be<br>
considered for TaaS Spec<br>
Message-ID:<br>
<CALqgCCqRQDwQsrPCMoUk5tCU9VJPy=<a href="mailto:0MXzDuZii0ik0sb-rkXQ@mail.gmail.com" target="_blank">0MXzDuZii0ik0sb-rkXQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Reedip,<br>
Please see my comments inline<br>
<br>
On Tue, Mar 8, 2016 at 9:19 AM, reedip banerjee <<a href="mailto:reedip14@gmail.com" target="_blank">reedip14@gmail.com</a>> wrote:<br>
<br>
> While reading up the specs in [1] and [2], there are certain things which<br>
> we may need to discuss before proceeding forward<br>
><br>
> a) Reference point for Ingress/Egress traffic:<br>
> There may be some confusion related to how we are labelling<br>
> Ingress and Egress ( is it with respect to a VM, with a switch ,<br>
> or any other entity).<br>
> As we are looking from "Inside the VM" and not from "Inside the Network",<br>
> that needs to be made clear.<br>
><br>
I think it worth to be consistent with other neutron features, for example<br>
with Security Groups<br>
<br>
><br>
> b) How to perceive TaaS:<br>
> In the section "Proposed Changes" Taas has been compared with a Core<br>
> Neutron<br>
> Plugin ( L3-Router) and a plugin which has emerged out of Neutron (<br>
> Neutron LBaaS).<br>
> This might cause confusion to the reviewers. It would be better that we<br>
> decide<br>
> how we would like to demonstrate TaaS:<br>
> - Is it a plugin which can be integrated with the Neutron Core<br>
> - Or is it an extension of the Core Neutron Services which can be used by<br>
> selected users<br>
><br>
> Based on the decision, we can modify the explanation to make the spec a<br>
> bit more streamed.<br>
><br>
I think it's advanced service adding value to the core neutron.<br>
<br>
><br>
> c) Device Owner for TaaS:<br>
> - If Tap Service creates a "destination" port, the port would have a<br>
> device owner<br>
> of the format of "network:tap"<br>
> - If the "destination" port is now connected to a VM and the VM is booted<br>
> up, nova<br>
> changes the owner to "compute:nova"<br>
><br>
Probably the difference will be if TaaS is allowed to remove this port or<br>
not.<br>
<br>
><br>
> # Is there any impact of the change of the device_owner<br>
> # If there is an impact, should there be a change in nova so that the<br>
> device_owner is not modified<br>
> # When in the future, TaaS supports user providing an "already created<br>
> port" should the device owner<br>
> be checked and modified?<br>
><br>
> d) Outcome of Deleting the VM where TaaS operates<br>
> Following might be added to the Spec:<br>
><br>
> 1. Deletion of the VM (and port attched to it) from which we were<br>
> mirroring (source of the mirror):<br>
> In this case we would do a cascade delete of the 'Tap_Flow' instances that<br>
> were associated with the port that was deleted.<br>
><br>
Are you sure you want to delete the Flow? Maybe it should reflect the<br>
status of being not operational any more. I personally do not think user<br>
created resource should be deleted without explicit user operation.<br>
<br>
><br>
> 2. Deletion of the VM (and port attched to it) to which we were mirroring<br>
> (Destination of the mirror):<br>
> In this case we would do a cascade delete of the 'Tap_Service' instance<br>
> that was associated with the port that was deleted.<br>
><br>
Same as previous comment.<br>
<br>
><br>
> e) Making the API independent of OpenVSwitch<br>
> As per our last discussion [3], it is better that w esplit our<br>
> implementation for TaaS,<br>
> so that<br>
> # the focus is not limited to OpenVSwitch, which may be a point of<br>
> concern during review<br>
> # allow other vendors to create thier own pluggable implementation<br>
><br>
+1<br>
<br>
><br>
> f) Choice of Tapping before/after Sec Groups<br>
><br>
> Security Groups can filter a lot , and implementing TaaS before or after<br>
> the SG<br>
> can impact the overall monitoring.<br>
> As referenced in [1], we can provide this option as a future course of<br>
> work, and<br>
> in the meanwhile specify the option which we are working upon ( Before or<br>
> After)<br>
> in the spec, to make it clear.<br>
><br>
> I think it can be the TapFlow attribute, lets say 'position' that can be<br>
either 'port' or 'vNIC'.<br>
*'vnic' *to capture ingress traffic after it passed inbound SG filters and<br>
egress traffic before it passes outbound SG filters<br>
<br>
'port' to capture ingress traffic before it passed inbound SG filters and<br>
egress traffic after it passes outbound SG filters<br>
<br>
<br>
><br>
> [1]:<br>
> <a href="https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst</a><br>
> [2]:<br>
> <a href="https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst</a><br>
> [3]:<br>
> <a href="http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt" rel="noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt</a><br>
><br>
> --<br>
> Thanks and Regards,<br>
> Reedip Banerjee<br>
> IRC: reedip<br>
><br>
><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/c8beee31/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/c8beee31/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Mon, 14 Mar 2016 02:41:58 -0700<br>
From: Sabari Murugesan <<a href="mailto:sabari.bits@gmail.com" target="_blank">sabari.bits@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Nova][Glance_store][VMware] Different<br>
glance store for Nova snapshot in VMware<br>
Message-ID:<br>
<<a href="mailto:CAJJL21MpwO6Jta8eOHvTJaw1%2BFhf_8frqW9xOhgaQEMUuy1pzw@mail.gmail.com" target="_blank">CAJJL21MpwO6Jta8eOHvTJaw1+Fhf_8frqW9xOhgaQEMUuy1pzw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Dongcan<br>
<br>
Regardless of when you snapshot, the image should be uploaded to<br>
the default glance store. Is it possible that you had enabled the FileSystem<br>
store earlier and recently changed to the vsphere store ?<br>
<br>
To further debug, can<br>
you add the following to the default section of glance-api.conf and provide<br>
us the value for 'locations' attribute of the snapshotted image. You can do<br>
"glance image-show --os-image-api-version 2 image-show <image_id>" to<br>
know the location.<br>
<br>
[DEFAULT]<br>
show_multiple_locations = True<br>
<br>
Thanks<br>
Sabari<br>
<br>
<br>
<br>
<br>
<br>
On Sun, Mar 13, 2016 at 7:54 PM, dongcan ye <<a href="mailto:hellochosen@gmail.com" target="_blank">hellochosen@gmail.com</a>> wrote:<br>
<br>
> Hi all,<br>
><br>
> In our production environment, we enables glance_store for VMware<br>
> datastore.<br>
> Configuration in glance-api.conf:<br>
><br>
> [DEFAULT]<br>
> show_image_direct_url = True<br>
> [glance_store]<br>
> stores= glance.store.vmware_datastore.Store<br>
> default_store = vsphere<br>
> vmware_server_host= 172.18.6.22<br>
> vmware_server_username = administrator@vsphere.local<br>
> vmware_server_password = 1qaz!QAZ<br>
> vmware_datastores = ICT Test:F7-HPP9500-SAS-ICTHPCLUSTER03-LUN06<br>
><br>
><br>
> Firstly we boot an instance, make online snapshot for the VM, we see the<br>
> image stores on local file system:<br>
> direct_url<br>
> file:///var/lib/glance/images/8cf7ba51-31d8-4282-89db-06957d609691<br>
><br>
> Then we poweroff the VM, make offline snapshot, the image stores on VMware<br>
> datastore:<br>
> direct_url vsphere://<br>
> <a href="http://172.20.2.38/folder/openstack_glance/52825a70-f645-46b5-80ec-7a430dcd13cf?dcPath=IDC_Test&dsName=LUN03-00" rel="noreferrer" target="_blank">172.20.2.38/folder/openstack_glance/52825a70-f645-46b5-80ec-7a430dcd13cf?dcPath=IDC_Test&dsName=LUN03-00</a><br>
><br>
> In Nova VCDriver, make snapshot will upload VM disk file to Glance image<br>
> server. But why different behaviour for the VM poweron and poweroff?<br>
><br>
> Hopes for your reply.<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/43624923/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/43624923/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Mon, 14 Mar 2016 10:50:31 +0100<br>
From: Gorka Eguileor <<a href="mailto:geguileo@redhat.com" target="_blank">geguileo@redhat.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Cinder] PTL Candidacy<br>
Message-ID: <20160314095031.GB668@localhost><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
<br>
Thanks for your leadership Sean, I think you've done a terrific job.<br>
<br>
Gorka.<br>
<br>
On 11/03, Sean McGinnis wrote:<br>
> Hey everyone,<br>
><br>
> Wow, how six months flies! I'd like to announce my candidacy to continue on as<br>
> Cinder PTL for the Newton release cycle.<br>
><br>
> A lot has been accomplished in the Mitaka cycle. After a lot of work by many<br>
> folks, over a couple development cycles, we now have what we consider a "tech<br>
> preview" of rolling upgrades. It just hasn't had enough runtime and testing for<br>
> us to say it's "official". We will likely need to fix a few minor things in the<br>
> Newton timeframe before it's fully baked and reliable. But it has come a long<br>
> way and I'm really happy with the progress that has been made.<br>
><br>
> Another priority we had identified for Mitaka was active/active high<br>
> availability of the c-vol service. We were not able to complete that work, but<br>
> many pieces have been put in place to support that in Newton. We fixed several<br>
> API races and added the ability to use something like tooz for locking. These<br>
> are foundation pieces for us to be able to start breaking out things and<br>
> running in a reliable active/active configuration.<br>
><br>
> Microversion support has been added and there is now a new v3 API endpoint.<br>
> This was a bit of a controversy as we really had just started to get folks to<br>
> move off of v1 to v2. To be safe though I decided it would protect end users<br>
> better to have a clearly separate new API endpoint for the microversion<br>
> compatibility. And now hopefully it is our last.<br>
><br>
> Replication was another slightly controversial feature implemented. Late in<br>
> Liberty we finally agreed on a spec for a v2 version of replication. The v2<br>
> spec was approved so late that no one actually had time to implement it for<br>
> that release. As we started to implement it for Mitaka we found that a lot of<br>
> compromises had crept in during the spec review that it had the risk of being<br>
> too complex and having some of the issues we were trying to get rid of by<br>
> moving away from replication v1. At our midcycle we had a lot of discussion on<br>
> replication and finally decided to change course before it was too late.<br>
> Whether that ends up being the best choice when we look back a year from now or<br>
> not, I'm proud of the team that we were willing to put on the brakes and make<br>
> changes - even though it was more work for us - before we released something<br>
> out to end users that would have caused problems or a poor experience.<br>
><br>
> Other than that, there's mostly been a lot of good bug fixes. Eight new drivers<br>
> have been added from (I think) five different vendors. The os-brick library is<br>
> now 1.0 (actually 1.1.0) and is in use by both Cinder and Nova for common<br>
> storage management operations so there is not a duplication and disconnect of<br>
> code between the two projects. We were also able to add a Brick cinder client<br>
> extension to be able to perform storage management on nodes without Nova (bare<br>
> metal, etc.).<br>
><br>
> None of this goodness was from me.<br>
><br>
> We have a bunch of smart and active members of the Cinder community. They are<br>
> the ones that are making a difference, working across the community, and<br>
> making sure Cinder is a solid component in an OpenStack cloud.<br>
><br>
> Being part of the Cinder community has been one of the best and most engaging<br>
> parts of my career. I am lucky enough to have support from my company to be<br>
> able to devote time to being a part of this. I would love the opportunity to<br>
> continue as PTL to not just contribute where I can, but to make sure the folks<br>
> doing the heavy lifting have the support and project organization they need to<br>
> avoid distractions and be able to focus on getting the important stuff done.<br>
><br>
> I think in Newton we need to continue the momentum and get Active/Active Cinder<br>
> volume service support implemented. We need to continue to work closely with<br>
> the Nova team to make sure our interaction is correct and solid. But also work<br>
> to make Cinder a useful storage management interface in environments without<br>
> Nova. I will continue to encourage developer involvement and vendor support.<br>
> We need to improve the user experience with better error reporting when things<br>
> go wrong. And last, but definitely not least, we need to continue to expand our<br>
> testing - unit, functional, and tempest - to make sure we can avoid those<br>
> errors and deliver a high quality and solid solution.<br>
><br>
> I really feel I'm just getting into the swing of things. I would love the<br>
> opportunity to serve as PTL for the Newton release.<br>
><br>
> Thank you for your consideration.<br>
><br>
> Sean McGinnis (smcginnis)<br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Mon, 14 Mar 2016 09:57:33 +0000<br>
From: Jesse Pretorius <<a href="mailto:jesse.pretorius@gmail.com" target="_blank">jesse.pretorius@gmail.com</a>><br>
To: <a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a><br>
Subject: [openstack-dev] [OpenStack-Ansible] PTL Candidacy<br>
Message-ID:<br>
<CAGSrQvz=<a href="mailto:JsKisOqHTdru0VrEKHN5zeaoNS9-eLNi70WiuWGmpg@mail.gmail.com" target="_blank">JsKisOqHTdru0VrEKHN5zeaoNS9-eLNi70WiuWGmpg@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi everyone,<br>
<br>
The Mitaka cycle for OpenStack-Ansible (OSA) has had the following<br>
successes:<br>
<br>
1. Our community has grown. The activity in the IRC channel has shown that<br>
we now have more people making use of OSA to deploy both private and public<br>
OpenStack clouds. Our development team now includes two non-Rackspace core<br>
team members who are committed to ensuring that OSA's development process<br>
has more diversity in its inputs and outputs. We have also increased the<br>
breadth of roles available to our deployers. Most importantly they were<br>
developed by non-core development team members.<br>
<br>
2. The roles are more modular. We've split out the Ansible roles into<br>
composable units which are usable without the dynamic inventory, LXC and<br>
without the general playbook tooling which has been implemented in the<br>
integrated build OSA repository.<br>
<br>
3. Multi-OS platform support enablement has progressed. Several of the<br>
roles in our stable are already passing the CentOS-based gate check, even<br>
though this work was very low priority in the cycle.<br>
<br>
4. Usability has improved. We've done an amazing job of improving install<br>
guide documentation, improving developer documentation, and adding release<br>
notes for the Mitaka release and retrospectively for the Liberty release.<br>
<br>
It would be my honour to serve as PTL for the Newton cycle to continue the<br>
journey along the following themes:<br>
<br>
1. Grow the community<br>
I would like to continue to increase our community participation through<br>
the engagement with other OpenStack Projects and the Operator community. I<br>
believe that it's crucial to the success of the project to increase the<br>
diversity of contributors. Our work in the Mitaka cycle has laid a good<br>
foundation on which I'd like to build through active engagement with the<br>
respective communities to share how OSA can meet the needs of both the<br>
Developer and Operator communities.<br>
<br>
2. Improve testing<br>
In the Mitaka cycle we laid the foundation for broader and deeper testing<br>
for each role and for the integrated tests. In the Newton cycle we need to<br>
complete that work in order to ensure that we have greater confidence that<br>
every patch submitted produces a functional build and does not introduce<br>
regressions in existing deployments. We need to ensure that each role is<br>
tested both in terms convergence and in terms of function.<br>
We also need to ensure that we have integrated testing for a broader<br>
variety of scenario's to ensure that each scenario that is considered a<br>
supported deployment design is tested.<br>
<br>
3. Improve usability<br>
While OSA is reasonably simple to use to deploy OpenStack, a barrier to<br>
most new users is understanding how to customise the inventory and how to<br>
prepare the host networking.<br>
I'd like us to reduce this barrier to entry in the Newton cycle in order to<br>
further simplify an OpenStack deployment for a new user.<br>
<br>
4. Improve platform support enablement<br>
In the Newton cycle we have agreed to ensure that we take advantage of<br>
Ansible 2.x and that we also implement support for Ubuntu 16.04 LTS. This<br>
work will implement the patterns which make it much easier to add more<br>
Linux distributions to our supported platform list.<br>
<br>
I look forward to working with you all in the Newton cycle and hope that we<br>
can meet our lofty goals!<br>
<br>
Jesse<br>
IRC: odyssey4me<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/2091cde2/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/2091cde2/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Mon, 14 Mar 2016 13:01:42 +0300<br>
From: Andrey Pavlov <<a href="mailto:andrey.mp@gmail.com" target="_blank">andrey.mp@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: [openstack-dev] [swift3][swift] What happens in swift3?<br>
Message-ID:<br>
<<a href="mailto:CAKdBrScVhawgvTtdCjj6PpNUEqYNdLegO2yKQ%2BOgB%2BafKeZNTA@mail.gmail.com" target="_blank">CAKdBrScVhawgvTtdCjj6PpNUEqYNdLegO2yKQ+OgB+afKeZNTA@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
Hello,<br>
<br>
I found that new Amazon tool for S3 started to use another way to sign requests.<br>
I made changes and submitted my review [1] seven months ago.<br>
<br>
This functionality is needed for ec2api project [2].<br>
It is needed for using new aws cli tool.<br>
<br>
I asked to review my changes directly to Kota via email.<br>
My colleague asked him on previous summit about it.<br>
All dependent reviews (in keystone) already merged four months ago.<br>
On all comments were answered in the review.<br>
I tried to raise this question at swift3 meeting.<br>
<br>
But still there is no answer.<br>
<br>
Can anyone answer - Can it really be reviewed and merged?<br>
<br>
[1] <a href="https://review.openstack.org/#/c/211933/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/211933/</a><br>
[2] <a href="https://review.openstack.org/#/c/198571/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/198571/</a><br>
<br>
--<br>
Kind regards,<br>
Andrey Pavlov.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Mon, 14 Mar 2016 10:04:37 +0000<br>
From: "Duan, Li-Gong (Gary, HPServers-Core-OE-PSC)"<br>
<<a href="mailto:li-gong.duan@hpe.com" target="_blank">li-gong.duan@hpe.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat<br>
template<br>
Message-ID:<br>
<<a href="mailto:632AC00166CA654683E6FE74AD16B12776CC70C1@G9W0758.americas.hpqcorp.net" target="_blank">632AC00166CA654683E6FE74AD16B12776CC70C1@G9W0758.americas.hpqcorp.net</a>><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Sergey,<br>
<br>
Thanks a lot.<br>
What I am using is Liberty release of Heat in a devstack environment.<br>
<br>
I'll provide my trace log later.<br>
<br>
Regards,<br>
Gary<br>
<br>
-----Original Message-----<br>
From: Sergey Kraynev [mailto:<a href="mailto:skraynev@mirantis.com" target="_blank">skraynev@mirantis.com</a>]<br>
Sent: Friday, March 11, 2016 10:23 PM<br>
To: OpenStack Development Mailing List (not for usage questions) <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat template<br>
<br>
Hi Gary,<br>
<br>
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).<br>
<br>
So your issue looks like a strange bug, because I can not reproduce it.<br>
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.<br>
<br>
On 11 March 2016 at 08:25, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) <<a href="mailto:li-gong.duan@hpe.com" target="_blank">li-gong.duan@hpe.com</a>> wrote:<br>
> Hi Sergey,<br>
><br>
> Thanks for your reply.<br>
><br>
> Thanks for your pointing out that "depends_on" is not needed when we have already used "get_attr".<br>
<br>
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.<br>
<br>
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).<br>
<br>
><br>
>>you create in rg_a some Server and probably it goes to active state<br>
>>before ip address becomes available for get_attr. It is necessary to<br>
>>check, but if it's try to add wait condition for this resource, then<br>
>>you will get created rg_a with fully available resources and I suppose<br>
>>IP will be available<br>
><br>
> 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?<br>
> 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:<br>
> ------------------<br>
> rg_a_wc_notify:<br>
> type: OS::Heat::SoftwareConfig<br>
> properties:<br>
> group: ungrouped<br>
> config:<br>
> str_replace:<br>
> template: |<br>
> #!/bin/bash -v<br>
> wc_notify --data-binary '{"status": "SUCCESS"}'<br>
> params:<br>
> wc_notify: {get_attr: [master_wait_handle, curl_cli]}<br>
> ------------------<br>
> 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)?<br>
><br>
> 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).<br>
><br>
> 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?<br>
<br>
<br>
<br>
><br>
> Regards,<br>
> Gary<br>
><br>
> -----Original Message-----<br>
> From: Sergey Kraynev [mailto:<a href="mailto:skraynev@mirantis.com" target="_blank">skraynev@mirantis.com</a>]<br>
> Sent: Wednesday, March 09, 2016 6:42 PM<br>
> To: OpenStack Development Mailing List (not for usage questions)<br>
> Subject: Re: [openstack-dev] [heat] issue of ResourceGroup in Heat<br>
> template<br>
><br>
> Hi Gary,<br>
><br>
><br>
> First of all you don't need to use "depends_on", because using "get_attr" already create implicit dependency from rg_a.<br>
> About getting Null instead of real Ip address:<br>
> It sounds like a bug, but IMO, it's expected behavior, because I suppose it happens due to:<br>
> - 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.<br>
><br>
> On 9 March 2016 at 13:14, Duan, Li-Gong (Gary, HPServers-Core-OE-PSC) <<a href="mailto:li-gong.duan@hpe.com" target="_blank">li-gong.duan@hpe.com</a>> wrote:<br>
>> Hi,<br>
>><br>
>><br>
>><br>
>> I have 3 Heat templates using ResourceGroup. There are 2 resource<br>
>> groups(rg_a and rg_b) and rg_b depends on rg_a. and rg_b requires<br>
>> the IP address of rg_a as the paremeter of rg_b. I use ?rg_a_public_ip: {get_attr:<br>
>> [rg_a, rg_a_public_ip]}? to get the IP address of rg_a both in the<br>
>> section of rg_b parameters (rg_b/properties/resource_def/properties)<br>
>> and the section of outputs.<br>
>><br>
>> As per my observation, rg_a_public_ip shows ?null? in the parameter<br>
>> section of rg_b. while rg_a_public_ip shows the correct IP address in<br>
>> the outputs section of the yaml file.<br>
>><br>
>><br>
>><br>
>> My questions are:<br>
>><br>
>> 1) Does this behavior is expected as designed or this is a bug?<br>
>><br>
>> 2) What is the alternative solution for the above case(user want to get<br>
>> the run-time information of the instance when creating the second<br>
>> resource<br>
>> group) if this behavior is expected?<br>
>><br>
>><br>
>><br>
>> ------- a.yaml -------------------<br>
>><br>
>> resources:<br>
>><br>
>> rg_a:<br>
>><br>
>> type: OS::Heat::ResourceGroup<br>
>><br>
>> properties:<br>
>><br>
>> count: 1<br>
>><br>
>> resource_def:<br>
>><br>
>> type: b.yaml<br>
>><br>
>> properties:<br>
>><br>
>> ?<br>
>><br>
>><br>
>><br>
>> rg_b:<br>
>><br>
>> type: OS::Heat::ResourceGroup<br>
>><br>
>> depends_on:<br>
>><br>
>> -rg_a<br>
>><br>
>> properties:<br>
>><br>
>> count: 2<br>
>><br>
>> resource_def:<br>
>><br>
>> type: c.yaml<br>
>><br>
>> properties:<br>
>><br>
>> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}<br>
>> -------------------- the value is ?null?<br>
>><br>
>> ?<br>
>><br>
>><br>
>><br>
>> outputs:<br>
>><br>
>> rg_a_public_ip: {get_attr: [rg_a, rg_a_public_ip]}<br>
>> --------------------- the value is correct.<br>
>><br>
>> --------------------------<br>
>><br>
>><br>
>><br>
>> ------b.yaml --------------------<br>
>><br>
>> ?<br>
>><br>
>> resources:<br>
>><br>
>> rg_a:<br>
>><br>
>> type: OS::Nova::Server<br>
>><br>
>> properties:<br>
>><br>
>> ?<br>
>><br>
>> outputs:<br>
>><br>
>> rg_a_public_ip:<br>
>><br>
>> value: {get_attr: [rg_a, networks, public, 0]}<br>
>><br>
>> --------------------------<br>
>><br>
>><br>
>><br>
>> ---------- c.yaml --------------------<br>
>><br>
>> parameters:<br>
>><br>
>> rg_a_public_ip:<br>
>><br>
>> type: string<br>
>><br>
>> description: IP of rg_a<br>
>><br>
>> ?<br>
>><br>
>> resources:<br>
>><br>
>> rg_b:<br>
>><br>
>> type: OS::Nova::Server<br>
>><br>
>> properties:<br>
>><br>
>> ?<br>
>><br>
>> outputs:<br>
>><br>
>> ?<br>
>><br>
>> ---------------------------------------<br>
>><br>
>><br>
>><br>
>> Regards,<br>
>><br>
>> Gary<br>
>><br>
>><br>
>><br>
>><br>
>> _____________________________________________________________________<br>
>> _ ____ OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
> Sergey.<br>
><br>
> ______________________________________________________________________<br>
> ____ OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ______________________________________________________________________<br>
> ____ OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
--<br>
Regards,<br>
Sergey.<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Mon, 14 Mar 2016 10:21:27 +0000<br>
From: Andrea Frittoli <<a href="mailto:andrea.frittoli@gmail.com" target="_blank">andrea.frittoli@gmail.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [QA] Not running for PTL<br>
Message-ID:<br>
<CAB7WYGUn1nBYBWA1hjCY2wsPvGqd=<a href="mailto:PWT5NCF2gkqH_CZCaRf6w@mail.gmail.com" target="_blank">PWT5NCF2gkqH_CZCaRf6w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Thanks Matt for the great work as PTL in the past 4 cycles!<br>
<br>
You had the fun of serving through the change in governance model, which is<br>
especially though on horizontal teams like QA - and I think you set strong<br>
foundations for QA to be successful in the big tent.<br>
<br>
andreaf<br>
<br>
<br>
On Mon, Mar 14, 2016 at 8:27 AM Daniel Mellado <<a href="mailto:daniel.mellado.es@ieee.org" target="_blank">daniel.mellado.es@ieee.org</a>><br>
wrote:<br>
<br>
> Thanks Matt for all your help and support, and glad that you'll be still<br>
> around!<br>
><br>
> El 11/03/16 a las 20:34, Matthew Treinish escribi?:<br>
><br>
> Hi everyone,<br>
><br>
> I'm writing this to announce that I am not running for QA PTL this cycle. I've<br>
> been the QA PTL for the past 4 cycles and I think it's time for another person<br>
> to take over the role. I think during the past 4 cycles the QA community has<br>
> grown greatly and become a much larger and stronger community compared to when<br>
> I first took on the position in the Juno cycle.<br>
><br>
> I strongly believe in the diversity of leadership and ideas, and I don't want<br>
> the community to grow stagnant because it becomes synonymous with just my voice.<br>
> Being a PTL is not the same as being an autocrat and I think it's time for<br>
> another person to step up and take over the QA PTL spot.<br>
><br>
> That being said, I'm not planning on going anywhere or leaving the project. I<br>
> fully intend to continue working and being heavily involved with the QA program,<br>
> as I have for been the past 2 years. (although maybe with a bit more free time<br>
> now)<br>
><br>
> -Matt Treinish<br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/2ac6aafa/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/2ac6aafa/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 18<br>
Date: Mon, 14 Mar 2016 11:34:28 +0100<br>
From: "Markus Zoeller" <<a href="mailto:mzoeller@de.ibm.com" target="_blank">mzoeller@de.ibm.com</a>><br>
To: "OpenStack Development Mailing List \(not for usage questions\)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [nova] stuck review, mtu incorrectly set<br>
on vhost-user port prevents vm booting.<br>
Message-ID:<br>
<<a href="mailto:201603141034.u2EAYYe7005382@d06av12.portsmouth.uk.ibm.com" target="_blank">201603141034.u2EAYYe7005382@d06av12.portsmouth.uk.ibm.com</a>><br>
Content-Type: text/plain; charset="ISO-8859-1"<br>
<br>
"Mooney, Sean K" <<a href="mailto:sean.k.mooney@intel.com" target="_blank">sean.k.mooney@intel.com</a>> wrote on 03/11/2016 07:20:46<br>
PM:<br>
<br>
> From: "Mooney, Sean K" <<a href="mailto:sean.k.mooney@intel.com" target="_blank">sean.k.mooney@intel.com</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
> Date: 03/11/2016 07:21 PM<br>
> Subject: [openstack-dev] [nova] stuck review, mtu incorrectly set on<br>
> vhost-user port prevents vm booting.<br>
><br>
> Hi everyone<br>
> I opened a bug back in January to correct an issue with vhost-user<br>
> Related to setting the mtu on the interface.<br>
><br>
> The recent changes in nova and neutron to change the default mtu value<br>
> from 0 to 1500<br>
> Are a direct trigger for this bug resulting in an inability to boot<br>
> vms that use vhost-user.<br>
><br>
> If anyone on the nova core/stable teams has time to look at this bug<br>
> and the fix I would appreciated it.<br>
><br>
> I would really like get this merged before rc1 is tagged if possible.<br>
> We have been running it in our ci for two weeks to make our cis work but<br>
I want<br>
> To get them back to running against the head of master nova as soon<br>
aspossible.<br>
><br>
> Bug : <a href="https://bugs.launchpad.net/nova/+bug/1533876" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1533876</a><br>
> Review: <a href="https://review.openstack.org/#/c/271444/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/271444/</a><br>
><br>
> Liberty backport: <a href="https://review.openstack.org/#/c/289370/1" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/289370/1</a><br>
> Kilo backport: <a href="https://review.openstack.org/#/c/289374/1" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/289374/1</a><br>
><br>
> Regards<br>
> Se?n<br>
><br>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
Matt Riedemann tagged the bug report as "mitaka-rc-potential" last<br>
Friday. The report is also on the priorities etherpad [1] and I informed<br>
our PTL John Garbutt to consider this before creating the stable branch.<br>
Hopefully some of the core reviewers will check your patch(es) today.<br>
<br>
References:<br>
[1] <a href="https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking</a><br>
<br>
Regards, Markus Zoeller (markus_z)<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 19<br>
Date: Mon, 14 Mar 2016 13:36:32 +0300<br>
From: Nadya Shakhat <<a href="mailto:nprivalova@mirantis.com" target="_blank">nprivalova@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, gordon chung <<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>><br>
Subject: Re: [openstack-dev] [telemetry] stepping down as PTL<br>
Message-ID:<br>
<CAKWrcJeadCCb_Y1gJkNMSsTNo053y-tsB=tThgnJX=<a href="mailto:E5oKoo_w@mail.gmail.com" target="_blank">E5oKoo_w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Gordon,<br>
Thank you very much for your work! I was always amazed by your patience and<br>
proficiency. It seems to me that you answered billion questions during<br>
working on Telemetry. I wish you all the best in the future, you are<br>
awesome :)!<br>
<br>
Thanks,<br>
Nadya<br>
<br>
On Mon, Mar 14, 2016 at 12:34 PM, Julien Danjou <<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>> wrote:<br>
<br>
> On Fri, Mar 11 2016, gordon chung wrote:<br>
><br>
> > as the PTL nominations are open, i just want to note that i won't be<br>
> > running again as the Telemetry PTL for Newton cycle.<br>
> ><br>
> > i've thoroughly enjoyed my time as PTL which afforded me the opportunity<br>
> > to work with and learn from some great individuals who share the same<br>
> > passion to collaborate openly. i have the utmost confidence that the<br>
> > projects will continue to grow and become more refined under the next<br>
> > leadership.<br>
> ><br>
> > personal thanks to everyone in Aodh, Ceilometer and Gnocchi communities<br>
> > as well as the projects that provided valuable feedback by collaborating<br>
> > with us. i thank you for sharing in the decision making so i could<br>
> > spread the blame around. i also thank you for reading through terribly<br>
> > written messages that make you question whether the shift keys on all my<br>
> > keyboards are broken.<br>
><br>
> I'd like to join others and thank you for your amazing work as a PTL.<br>
><br>
> You've led the community in an open way that allowed it to share the<br>
> leadership and be one of the most thrilling group that I've been able to<br>
> contribute to in OpenStack.<br>
><br>
> Cheers,<br>
> --<br>
> Julien Danjou<br>
> // Free Software hacker<br>
> // <a href="https://julien.danjou.info" rel="noreferrer" target="_blank">https://julien.danjou.info</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/cfd50f3f/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/cfd50f3f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 20<br>
Date: Mon, 14 Mar 2016 14:09:00 +0300<br>
From: Nikolay Starodubtsev <<a href="mailto:nstarodubtsev@mirantis.com" target="_blank">nstarodubtsev@mirantis.com</a>><br>
To: "OpenStack Development Mailing List (not for usage questions)"<br>
<<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
Subject: Re: [openstack-dev] [Murano] [FFE] Support for Magnum Plugin<br>
Message-ID:<br>
<CAAa8YgBa7t1S6dJSK6ScP=<a href="mailto:jKEgyH9bjrCCekogcWgFNmwFpSAw@mail.gmail.com" target="_blank">jKEgyH9bjrCCekogcWgFNmwFpSAw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
I don't like when we need to break rules, but in this case I agree with<br>
Kirill. As far as the plugin is not something which can broke general<br>
murano functionality, I'm for FFE.<br>
<br>
<br>
<br>
Nikolay Starodubtsev<br>
<br>
Software Engineer<br>
<br>
Mirantis Inc.<br>
<br>
<br>
Skype: dark_harlequine1<br>
<br>
2016-03-14 11:58 GMT+03:00 Kirill Zaitsev <<a href="mailto:kzaitsev@mirantis.com" target="_blank">kzaitsev@mirantis.com</a>>:<br>
<br>
> I?m going to advocate for this FFE. Even though it?s very late to ask for<br>
> FFE, I believe, that this commit is very low-risk/high reward (the plugin<br>
> is not enabled by default). I believe that code is in good shape (I<br>
> remember +2 it at some point) and would very much like to see this in.<br>
><br>
> Serg, do you have any objections?<br>
><br>
> --<br>
> Kirill Zaitsev<br>
> Software Engineer<br>
> Mirantis, Inc<br>
><br>
> On 14 March 2016 at 11:55:46, Madhuri (<a href="mailto:madhuri.rai07@gmail.com" target="_blank">madhuri.rai07@gmail.com</a>) wrote:<br>
><br>
> Hi All,<br>
><br>
> I would like to request a feature freeze exception for "Magnum/Murano<br>
> rationalization" [1], Magnum app to deploy Kubernetes/Mesos/Swarm cluster.<br>
> The patch is on review[2].<br>
> I am looking for your decision about considering this change for a FFE.<br>
><br>
> [1]<br>
> <a href="https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/murano/+spec/magnum-murano-rationalization</a><br>
> [2] <a href="https://review.openstack.org/#/c/269250/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/269250/</a><br>
><br>
> Regards,<br>
> Madhuri<br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/1aba7a73/attachment-0001.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/1aba7a73/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
End of OpenStack-dev Digest, Vol 47, Issue 56<br>
*********************************************<br>
</blockquote></div><br></div>
</blockquote></div><br></div></div>