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
