+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 <xar...@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 <mscherba...@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 <vkramsk...@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 <mscherba...@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 <m...@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 <bdobre...@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 <ppe...@mirantis.com >>>>> <mailto:ppe...@mirantis.com <ppe...@mirantis.com>>> wrote: >>>>> >>>>> >>>>> On 11 March 2016 at 12:51:40, Igor Kalnitsky >>>>> (ikalnit...@mirantis.com <mailto:ikalnit...@mirantis.com >>>>> <ikalnit...@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 >>>>> <ppe...@mirantis.com <mailto:ppe...@mirantis.com >>>>> <ppe...@mirantis.com>>> wrote: >>>>> >>>>> >>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky (ikalnit...@mirantis.com >>>>> <mailto:ikalnit...@mirantis.com <ikalnit...@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 <ppe...@mirantis.com < >>>>> mailto:ppe...@mirantis.com <ppe...@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 (spasqu...@mirantis.com < >>>>> mailto:spasqu...@mirantis.com <spasqu...@mirantis.com>>) >>>>> wrote: >>>>> >>>>> Hello Roman, >>>>> >>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman Prykhodchenko <m...@romcheg.me < >>>>> mailto:m...@romcheg.me <m...@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-requ...@lists.openstack.org?subject:unsubscribe >>>>> >>>>> < >>>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org >>>>> ?subject:unsubscribe >>>>> >>>>> < >>>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org >>>>> ?subject:unsubscribe >>>>> >>>>> < >>>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org >>>>> ?subject:unsubscribe >>>>> >>>>> < >>>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >>>>> < >>>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>>>> <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
