<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 7, 2018 at 11:24 PM, Tristan Cacqueray <span dir="ltr"><<a href="mailto:tdecacqu@redhat.com" target="_blank">tdecacqu@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello David and Wesley, please find some comments inlined bellow.<span class=""><br>
<br>
On January 5, 2018 6:39 pm, Wesley Hayutin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jan 5, 2018 at 12:36 PM, David Moreau Simard <<a href="mailto:dms@redhat.com" target="_blank">dms@redhat.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are already plans [1] to add the software factory implementation of<br>
Grafana on <a href="http://review.rdoproject.org" rel="noreferrer" target="_blank">review.rdoproject.org</a>, you can see what it looks like on<br>
<a href="http://softwarefactory-project.io" rel="noreferrer" target="_blank">softwarefactory-project.io</a> [2].<br>
<br>
The backend to this grafana implementation is currently influxdb, not<br>
graphite.<br>
However, there are ongoing discussions to either both graphite and<br>
influxdb simultaneously or optionally either.<br>
<br>
We're interested in leveraging this influxdb (or graphite) and grafana<br>
implementation for monitoring data in general (uptime, resources, disk<br>
space, load, etc.) so our goals align here.<br>
We both agree that using graphite would be a plus in order to re-use the<br>
same queries in the grafana dashboard but at the same time, influxdb is<br>
more "modern" and easier to work with -- this is why we might end up<br>
deploying both, we'll see.<br>
<br>
[1]: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1514086" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/sh<wbr>ow_bug.cgi?id=1514086</a><br>
[2]: <a href="https://softwarefactory-project.io/grafana/" rel="noreferrer" target="_blank">https://softwarefactory-projec<wbr>t.io/grafana/</a><br>
<br>
</blockquote></blockquote>
<br></span>
Note that the current influxdb/grafana integration is for instance system<br>
metric (cpu, mem, network and i/o). We are working on getting zuul and<br>
nodepool metric but the upstream query needs to be adapted for influxdb,<br>
hence we may look at integrating graphite/carbon too so that is easier.<br>
There is also this tool that can make influxdb a backend for graphite:<br>
<a href="https://github.com/InfluxGraph/influxgraph" rel="noreferrer" target="_blank">https://github.com/InfluxGraph<wbr>/influxgraph</a><br>
<br>
Also note that we are integrating grafyaml to the config repo so that<br>
grafana dashboards can be proposed and updated by regular user too.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
This is great news David, thank you for sharing.<br>
Given that this is already in plan software factory and we have an<br>
immediate need I'm wondering how to proceed.<br>
Does the RDO Infra team have an estimate when graphite/influxdb/grafana<br>
will be moved to production?<br>
</blockquote>
<br></span>
While we could setup the grafana/influxdb service, and we should<br>
in the near future, it seems like this ci use-case needs some more<br>
tinkering and I think it would be easier to start with another<br>
dedicated setup until the requirements are better defined.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some possibilities come to mind, depending on when it moves to prod<br>
<br>
1.  The TripleO-CI team waits for prod<br>
2.  TripleO CI would stand up a test instance of graphite/influxdb and<br>
grapha and start to work out what we need to send and how to send data<br>
3.  Is it possible to use the stage instance RDO SF as a testbed for<br>
TripleO-CI's work?  Meaning we send metrics and use the stage instance with<br>
a backing up the data in mind?<br>
<br>
What do you think?<br>
Thanks<br>
<br>
<br>
</blockquote>
<br></span>
I think 1. will happen shortly, and this will bring a grafana setup<br>
accessible from the top-menu.<br>
<br>
Though I think 2. is probably easier to begin with, and we could<br>
configure the new graphite/influxdb backend in the existing grafana.<br>
<br>
Not sure what you mean by 3. If there is a graphite/influxdb service in<br>
rdo-prod tenant, then you could use it for tripleo-ci work of course.<br>
The backup of RDO SF is managed by this playbook:<br>
<a href="https://softwarefactory-project.io/r/gitweb?p=software-factory/sf-ops.git;a=blob;f=backup/ansible/backup.yml" rel="noreferrer" target="_blank">https://softwarefactory-projec<wbr>t.io/r/gitweb?p=software-<wbr>factory/sf-ops.git;a=blob;f=<wbr>backup/ansible/backup.yml</a><br>
We could add_host the new backend and backup it's data similarly.<br>
<br>
<br>
Here are some more thoughts:<br>
<br>
Dependending on how the metrics are pushed, we may need some kind of<br>
authorization mechanism and a job secret to allow external clients to<br>
push new metrics.<br>
<br>
It seems like we could setup post run to push job metrics. Perhaps<br>
we could leverage ara sqldump to extract per task duration.<br>
<br>
Software Factory may also automatically setup job duration graph<br>
dashboard per project, here is a new user-story to track this work:<br>
<a href="https://tree.taiga.io/project/morucci-software-factory/us/897" rel="noreferrer" target="_blank">https://tree.taiga.io/project/<wbr>morucci-software-factory/us/89<wbr>7</a><br>
<br>
<br>
Alternatively, we could also use the zuul sql reporter database, which<br>
already record the start/end time of each job. Here is a gnuplot of that<br>
data:<br>
<a href="https://fedorapeople.org/~tdecacqu/tripleo-ci/periodic-tripleo-ci-centos-7-multinode-1ctlr-featureset018-pike.png" rel="noreferrer" target="_blank">https://fedorapeople.org/~tdec<wbr>acqu/tripleo-ci/periodic-tripl<wbr>eo-ci-centos-7-multinode-1ctlr<wbr>-featureset018-pike.png</a><br>
This could probably be integrated in the zuul-web dashboard upstream.<br>
<br>
Alternatively, the elasticsearch data could also be used to constructed a<br>
similar graph in kibana, though it seems like it's missing a duration field.<br>
<br>
<br>
Regards,<br>
-Tristan</blockquote><div><br></div><div>Thanks for the feedback David, Tristan.</div><div>We will be discussing your feedback tomorrow directly after the tripleo meeting on #tripleo.</div><div><br></div><div>You guys are always welcome to join, just ping on #oooq / #tripleo for details about the meeting.</div><div>We're going to spend about 20min in a Q&A session about the tools.</div><div><br></div><div>We'll follow up with our plans to this thread.</div><div><br></div><div>Thanks all!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
David Moreau Simard<br>
Senior Software Engineer | OpenStack RDO<br>
<br>
dmsimard = [irc, github, twitter]<br>
<br>
On Fri, Jan 5, 2018 at 12:13 PM, Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings,<br>
<br>
At the end of 2017, a number of the upstream multinode scenario jobs<br>
started to run over our required deployment times [1].  In an effort to<br>
better understand the performance of the deployment and CI the tripleo<br>
cores requested that a Graphite and Grafana server be stood up such that we<br>
can analyze the core issues more effectively.<br>
<br>
There is a certain amount of urgency with the issue as our upstream<br>
coverage is impacted.  The TripleO-CI team is working on the deployment of<br>
both tools in a dev-ops style in RDO-Cloud this sprint.  Nothing yet has<br>
been deployed.<br>
<br>
The TripleO CI team is also working with upstream infra to send metric<br>
and data to the upstream Graphite and Grafana servers.  It is not clear yet<br>
if we have permission or access to the upstream tools.<br>
<br>
I wanted to publically announce this work to the RDO infra community to<br>
inform and to gather any feedback anyone may have.  There are two scopes of<br>
work here, the initial tooling to stand up the infra and the longer term<br>
maintenance of the tools.  Perhaps there are plans to build these into RDO<br>
SF already.. etc.<br>
<br>
Please reply with your comments and concerns.<br>
Thank you!<br>
<br>
<br>
[1] <a href="https://github.com/openstack-infra/tripleo-ci/commit/7a2" rel="noreferrer" target="_blank">https://github.com/openstack-i<wbr>nfra/tripleo-ci/commit/7a2</a><br>
edf70eccfc7002d26fd1ce1eef803c<wbr>e8d0ba8<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.rdoproject.org" target="_blank">dev@lists.rdoproject.org</a><br>
<a href="http://lists.rdoproject.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.rdoproject.org/ma<wbr>ilman/listinfo/dev</a><br>
<br>
To unsubscribe: <a href="mailto:dev-unsubscribe@lists.rdoproject.org" target="_blank">dev-unsubscribe@lists.rdoproje<wbr>ct.org</a><br>
<br>
<br>
</blockquote>
<br>
</blockquote>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.rdoproject.org" target="_blank">dev@lists.rdoproject.org</a><br>
<a href="http://lists.rdoproject.org/mailman/listinfo/dev" rel="noreferrer" target="_blank">http://lists.rdoproject.org/ma<wbr>ilman/listinfo/dev</a><br>
<br>
To unsubscribe: <a href="mailto:dev-unsubscribe@lists.rdoproject.org" target="_blank">dev-unsubscribe@lists.rdoproje<wbr>ct.org</a><br>
<br>
</blockquote>
</div></div></blockquote></div><br></div></div>