Open Stack

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


Nastya.


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

> I think we can address it by retaining deployment logs in nailgun/ui, this
> also removes the chicken and egg problem. after LMA is deployed it can be
> allowed to re-own 'logs' button on UI once it's deployed, including
> redirecting fuel logs there.
>
> On Fri, Mar 11, 2016 at 2:07 PM Mike Scherbakov <mscherbakov at mirantis.com>
> wrote:
>
>> We can sort out details later. In a worst case, the warning will be there
>> in Newton too, and feature will go away only in O* release. So let's
>> proceed with the bug..
>>
>> On Fri, Mar 11, 2016 at 1:02 PM Vitaly Kramskikh <vkramskikh at mirantis.com>
>> wrote:
>>
>>> We can add the warning, but I think before we do this we should have
>>> clear migration plan. According to this thread, some parts are still not
>>> clear.
>>>
>>> 2016-03-11 22:00 GMT+03:00 Mike Scherbakov <mscherbakov at mirantis.com>:
>>>
>>>> Deprecation warning for Fuel Mitaka:
>>>> https://bugs.launchpad.net/fuel/+bug/1556244.
>>>>
>>>>
>>>> On Fri, Mar 11, 2016 at 8:59 AM Roman Prykhodchenko <me at romcheg.me>
>>>> wrote:
>>>>
>>>>> Since there are a lot of supporters for this idea, what do you folks
>>>>> think about creating a BP spec where we can describe what we should do in
>>>>> order to remove logs from UI and Nailgun? I also propose to file a bug
>>>>> about adding a deprecation warning to Mitaka release of Fuel.
>>>>>
>>>>>
>>>>> 11 бер. 2016 р. о 16:55 Bogdan Dobrelya <bdobrelia at mirantis.com>
>>>>> написав(ла):
>>>>>
>>>>>
>>>>> On 03/11/2016 04:46 PM, Mike Scherbakov wrote:
>>>>>
>>>>> +1 to remove logs from Fuel UI in Fuel Newton.
>>>>> In Fuel Mitaka we'd need to put a deprecation warning somewhere.
>>>>>
>>>>>
>>>>> I agree, there is not much sense having non flexible (no content
>>>>> filters) logs view in UI. LMA plugins shall cover this area as well.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Mar 11, 2016, 04:57 Patrick Petit <ppetit at mirantis.com
>>>>> <mailto:ppetit at mirantis.com <ppetit at mirantis.com>>> wrote:
>>>>>
>>>>>
>>>>>    On 11 March 2016 at 12:51:40, Igor Kalnitsky
>>>>>    (ikalnitsky at mirantis.com <mailto:ikalnitsky at mirantis.com
>>>>> <ikalnitsky at mirantis.com>>) wrote:
>>>>>
>>>>>    Patrick,
>>>>>
>>>>>    Sorry, but I meant another question. I thought that LMA plugin
>>>>> should
>>>>>    be installed in some environment before we can start use it. Is
>>>>>    this a
>>>>>    case? If so, it means we can't use for master node until some
>>>>>    environment is deployed.
>>>>>
>>>>>
>>>>>    Right. This is the chicken and egg problem I mentioned earlier...
>>>>>
>>>>>    But this is not a “problem” specific to Fuel. My take on this is is
>>>>>    that ops management tooling (logging, monitoring) should be
>>>>>    installed off-band before any OpenStack deployment. In fact, in
>>>>>    real-world usage, we frequently get asks to have the monitoring and
>>>>>    logging services of StackLight installed permanently for
>>>>>    multi-enviroments. And so, one approach would be to make Stacklight
>>>>>    backend services the first bits of software installed by Fuel (if
>>>>>    not already there), then reconfigure Fuel to hook into those
>>>>>    services and only then, enter into the regular OpenStack
>>>>>    provisioning mode.
>>>>>
>>>>>
>>>>>
>>>>>    On Fri, Mar 11, 2016 at 12:52 PM, Patrick Petit
>>>>>    <ppetit at mirantis.com <mailto:ppetit at mirantis.com
>>>>> <ppetit at mirantis.com>>> wrote:
>>>>>
>>>>>
>>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnitsky at mirantis.com
>>>>> <mailto:ikalnitsky at mirantis.com <ikalnitsky at mirantis.com>>)
>>>>> wrote:
>>>>>
>>>>> Hey Roman,
>>>>>
>>>>> Thank you for bringing this up. +1 from my side, especially taking
>>>>> into account the patch where we tried to solve logrotated logs problem
>>>>>
>>>>> [1]. It's complex and unsupportable, as well as already existed
>>>>> logview code in Nailgun.
>>>>>
>>>>> Patrick, Simon,
>>>>>
>>>>> Does LMA plugin support logs from master node? Or it's designed to
>>>>> watch environment's logs?
>>>>>
>>>>> No it’s not designed specifically for environment logs. Can be adapted
>>>>> to
>>>>> any log format.
>>>>>
>>>>> Would just need to write a parser like you would with logstach when
>>>>> logs are
>>>>> not standard.
>>>>>
>>>>> Patrick
>>>>>
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Igor
>>>>>
>>>>>
>>>>> [1]: https://review.openstack.org/#/c/243240/
>>>>>
>>>>> On Fri, Mar 11, 2016 at 11:53 AM, Patrick Petit <ppetit at mirantis.com <
>>>>> mailto:ppetit at mirantis.com <ppetit at mirantis.com>>> wrote:
>>>>>
>>>>> Fuelers,
>>>>>
>>>>> As Simon said, we already have a log centralisation solution for MOS
>>>>> delivered as a Fuel plugins known as StackLight / LMA toolset. And so
>>>>> objectively, there is no need to have log management in Nailgun
>>>>> anymore.
>>>>> To
>>>>> go one step further we suggested several times to have a StackLight
>>>>> agent
>>>>> installed on the Fuel master node to also collect and centralise those
>>>>>
>>>>> logs.
>>>>> There is a little bit of a chicken and egg problem to resolve but I
>>>>> think
>>>>> it
>>>>> is worth a try to have that nailed down in the roadmap for Fuel 10.
>>>>> Cheers
>>>>> - Patrick
>>>>>
>>>>>
>>>>> On 11 March 2016 at 10:07:28, Simon Pasquier (spasquier at mirantis.com <
>>>>> mailto:spasquier at mirantis.com <spasquier at mirantis.com>>)
>>>>> wrote:
>>>>>
>>>>> Hello Roman,
>>>>>
>>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <me at romcheg.me <
>>>>> mailto:me at romcheg.me <me at romcheg.me>>>
>>>>> wrote:
>>>>>
>>>>>
>>>>> Fuelers,
>>>>>
>>>>> I remember we’ve discussing this topic in our couloirs before but I’d
>>>>> like
>>>>> to bring that discussion to a more official format.
>>>>>
>>>>> Let me state a few reasons to do this:
>>>>>
>>>>> - Log management code in Nailgun is overcomplicated
>>>>> - Working with logs on big scale deployments is barely possible given
>>>>> the
>>>>> current representation
>>>>> - Due to overcomplexity and ineffectiveness of the code we always get
>>>>> recurring bugs like [1]. That eats tons of time to resolve.
>>>>> - There are much better specialized tools, say Logstash [2], that can
>>>>> deal
>>>>> with logs much more effectively.
>>>>>
>>>>>
>>>>> There may be more reasons bus I think even the already mentioned ones
>>>>> are
>>>>> enough to think about the following proposal:
>>>>>
>>>>> - Remove Logs tab from Fuel Web UI
>>>>> - Remove logs support from Nailgun
>>>>> - Create mechanism that allows to configure different log management
>>>>> software, say Logstash, Loggly, etc
>>>>>
>>>>> - Choose a default software to install and provide a plugin for it from
>>>>>
>>>>> the box
>>>>>
>>>>>
>>>>>
>>>>> This is what the LMA/StackLight plugins [1][2] are meant for. No need
>>>>> to
>>>>> develop anything new.
>>>>>
>>>>> And I'm +1 with the removal of log management from Fuel. As you said,
>>>>> it
>>>>> can't scale...
>>>>>
>>>>> [1] http://fuel-plugin-lma-collector.readthedocs.org/en/latest/
>>>>> [2] http://fuel-plugin-elasticsearch-kibana.readthedocs.org/en/latest/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> References
>>>>> 1. https://bugs.launchpad.net/fuel/+bug/1553170
>>>>> 2. https://www.elastic.co/products/logstash
>>>>>
>>>>>
>>>>> - romcheg
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>
>>>>>    <
>>>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>>>> >
>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>>>>> ?subject:unsubscribe
>>>>>
>>>>>    <
>>>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>>>> >
>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>>>>> ?subject:unsubscribe
>>>>>
>>>>>    <
>>>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>>>> >
>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>>>>> ?subject:unsubscribe
>>>>>
>>>>>    <
>>>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>>>> >
>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>    __________________________________________________________________________
>>>>>    OpenStack Development Mailing List (not for usage questions)
>>>>>    Unsubscribe:
>>>>>    OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>    <
>>>>> http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>>>>> <http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe>
>>>>> >
>>>>>    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>> --
>>>>> Mike Scherbakov
>>>>> #mihgen
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>>>>> ?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Bogdan Dobrelya,
>>>>> Irc #bogdando
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org
>>>>> ?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>> --
>>>> Mike Scherbakov
>>>> #mihgen
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Vitaly Kramskikh,
>>> Fuel UI Tech Lead,
>>> Mirantis, Inc.
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> --
>> Mike Scherbakov
>> #mihgen
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> --
>
> --
>
> Andrew Woodward
>
> Mirantis
>
> Fuel Community Ambassador
>
> Ceph Community
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160314/f575548d/attachment.html>