On 03/14/2016 09:38 AM, Anastasia Urlapova wrote: > +1 to Vitaliy, it would be nice find somewhere a details for migration. > And one more concern I should highlight - for some users logless UI may > be challenging thing. > The logs removing shouldn't affect the UX.
Logs will still live at the master node's /var/log/remote > > > Nastya. > > > On Sat, Mar 12, 2016 at 3:08 AM, Andrew Woodward <xar...@gmail.com > <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 >> <mailto: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> >>> <mailto:ppe...@mirantis.com>> wrote: >>> >>> >>> On 11 March 2016 at 12:51:40, Igor Kalnitsky >>> (ikalnit...@mirantis.com >>> <mailto:ikalnit...@mirantis.com> >>> <mailto: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> >>>> <mailto:ppe...@mirantis.com>> >>>> wrote: >>>>> >>>>> On 11 March 2016 at 11:34:32, Igor Kalnitsky >>>>> (ikalnit...@mirantis.com >>>>> <mailto:ikalnit...@mirantis.com> >>>>> <mailto: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> >>>>> <mailto: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> >>>>>> <mailto:spasqu...@mirantis.com>) >>>>>> wrote: >>>>>> >>>>>> Hello Roman, >>>>>> >>>>>> On Fri, Mar 11, 2016 at 9:57 AM, Roman >>>>>> Prykhodchenko <m...@romcheg.me >>>>>> <mailto:m...@romcheg.me> <mailto: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 >>>>>>> >>>>>>> <mailto: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 >>>>>> >>>>>> <mailto: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 >>>>>> >>>>>> <mailto: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 >>>>> >>>>> <mailto: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 >>> >>> <mailto: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 >>> >>> <mailto: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 >> >> <mailto: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://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://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://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://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://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 > -- 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
