3:34 p.m.
Hi Ralph,
I have made quite some changes to statscache[1] and
statscache_plugins[2] to empower a faster prototype of releng dash[3],
currently working with only the AMIs plugin.
I have come up with a layout spec for releng plugin[4] to generate the
UI dynamically with minimum client side code, same code working for
all widgets in the dashboard.
How to test the changes:
1. cd into statscache_plugins/statscahe_plugins, and run 'python -m
unittest tests.releng' to seed initial data for AMIs plugin.
2. cd into statscache/ dir and run the flask server: python statscache/app.py
3. cd into fedora-releng-dash repo dir, and checkout to branch
'statscache', and open index.html in browser.
You should see the AMI widgets in the page.
Also, I think, we need to find a better way to pass the 'frequency'
param to instantiate models and plugins. Also, the data fetching part
could be moved to the plugins to allow plugin level optimizations, if
needed.
Please let me know your thoughts on the above changes.
[1]: https://github.com/fedora-infra/statscache/pull/4
[2]: https://github.com/fedora-infra/statscache_plugins/pull/1
[3]: https://github.com/fedora-infra/fedora-releng-dash/pull/20/
[4]:
https://github.com/rtnpro/statscache_plugins/commit/f1ca6c85bf2a4cb22af93...
Regards,
rtnpro
--
Ratnadeep Debnath,
https://www.waartaa.com
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02 B785 2119 5486 F245 DFD6
3:16 p.m.
Hi Ratnadeep,
On Sun, May 10, 2015 at 02:04:13AM +0530, Ratnadeep Debnath wrote:
Hi Ralph,
I have made quite some changes to statscache[1] and
statscache_plugins[2] to empower a faster prototype of releng dash[3],
currently working with only the AMIs plugin.
I have come up with a layout spec for releng plugin[4] to generate the
UI dynamically with minimum client side code, same code working for
all widgets in the dashboard.
How to test the changes:
1. cd into statscache_plugins/statscahe_plugins, and run 'python -m
unittest tests.releng' to seed initial data for AMIs plugin.
2. cd into statscache/ dir and run the flask server: python statscache/app.py
3. cd into fedora-releng-dash repo dir, and checkout to branch
'statscache', and open index.html in browser.
You should see the AMI widgets in the page.
I got it working locally without much trouble. It is really snappy!
I played a bit more with handlebars.js too, to get a feel for it and
I'm pretty sure I understand your implementation now. It looks good
to me!
You took care of the display of AMIs but you asked me to look at
implementing some specific missing parts the other day. Can you
remind me what those were? I didn't write it down and I don't want to
accidentally duplicate something you're working on at the same time.
Also, I think, we need to find a better way to pass the
'frequency'
param to instantiate models and plugins.
I'm open to changing it, but I don't quite see what's limiting about
it at present (perhaps we could associated the ``make_model()``
callable with the ``BasePlugin`` class for starters?)
Also, the data fetching part could be moved to the plugins to allow
plugin level optimizations, if needed.
I'd be fine with this. As long as we can let a core plugin component
do most of the work of retrieving data, that's fine with me. That
way, most plugins won't have to duplicate the work of querying simple
series of numbers (volume, variance, etc..)
-Ralph
1:30 p.m.
Hi Ralph,
On Tue, May 12, 2015 at 1:46 AM, Ralph Bean <rbean(a)redhat.com> wrote:
You took care of the display of AMIs but you asked me to look at
implementing some specific missing parts the other day. Can you
remind me what those were? I didn't write it down and I don't want to
accidentally duplicate something you're working on at the same time.
I have ported the compose and artifacts plugin crudely, but I'll need
to test it. I will take care of it. Could you help me with porting
images, uploads plugin?
> Also, I think, we need to find a better way to pass the
'frequency'
> param to instantiate models and plugins.
I'm open to changing it, but I don't quite see what's limiting about
it at present (perhaps we could associated the ``make_model()``
callable with the ``BasePlugin`` class for starters?)
+1'd on Github ;)
> Also, the data fetching part could be moved to the plugins to
allow
> plugin level optimizations, if needed.
I'd be fine with this. As long as we can let a core plugin component
do most of the work of retrieving data, that's fine with me. That
way, most plugins won't have to duplicate the work of querying simple
series of numbers (volume, variance, etc..)
+1
Regards,
rtnpro
--
Ratnadeep Debnath,
https://www.waartaa.com
GPG Fingerprint: 033C 8041 A0E9 CDBA 2E02 B785 2119 5486 F245 DFD6
3280
days inactive
3283
days old
infrastructure@lists.fedoraproject.org
2 comments
3 participants
participants (3)
-
Ralph Bean -
Ratnadeep Debnath -
Ratnadeep Debnath