Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160311/878ad00c/attachment.html>