Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InfluxDB should have static admin assets compiled into the binary #1032

Closed
wants to merge 1 commit into from

Conversation

jvshahid
Copy link
Contributor

So far, I ❤️ statik (https://github.com/rakyll/statik).

We'll probably need to make a couple tweaks to the build process, but it should be pretty straightforward since we're already building the static assets.

@toddboom toddboom self-assigned this Oct 15, 2014
@Dieterbe
Copy link
Contributor

i ❤️ https://github.com/jteeuwen/go-bindata FWIW

@schmurfy
Copy link
Contributor

This may be a wild idea but why not just entirely remove the admin interface from the main demon ?
As far as I can tell the only thing done in the influxdb demon itself is to open an http server to serve static files, a thing that would be better done by nginx or equivalent.
Another idea would be to have the influxdb-admin project build an self supported executable which would do what is currently in the demon: open an http server and serve the files.

I clearly don't share your excitement about embedding a bunch of static files into an executable, I don't use the admin interface (I just don't see any reason to use it right now) and having a bigger executable for nothing is not that great.

At least if you do that please make it optional so I can continue building a "naked" version of the influxdb server.

@Dieterbe
Copy link
Contributor

and having a bigger executable for nothing is not that great.

really, does this matter in 2014? can't imagine the size increase is significant compared to ram sizes.
the most compelling argument i would say is simplicity. no need to manage a bunch of extra files, no need to manage 2 daemons if you can do it with one. the one downside i can think of is if the admin UI crashes it could affect the server. but i have a hard time imagining something that serves some content over http crashing the server.

@toddboom
Copy link
Contributor Author

@schmurfy I think your first proposal is a direction we may take down the road, but for now I think we're choosing to prioritize getting up and running quickly over file size. The usability gains are pretty huge and the only clear downside that I can see is adding an extra megabyte or so to the executable. It also gives contributors an easy way to test out functionality locally without installing an extra package. As it was, having the assets outside of the repo caused enough of a headache, so I'd prefer to step closer to integration than further away.

With that said, I feel that adding an optional build flag to exclude those assets is a good solution for those wishing to slim down a bit. For now, you should be able to do the following:

rm -rf shared/admin/*
make rebuild_static_assets

Then build as normal. Let me know how that strikes you.

@toddboom toddboom force-pushed the fix-1032-admin-interface-static-assets branch from e3b2029 to fdc9235 Compare October 20, 2014 19:11
@jvshahid jvshahid added this to the 0.8.4 milestone Oct 20, 2014
@jvshahid jvshahid added the admin label Oct 20, 2014
@jvshahid jvshahid closed this Oct 20, 2014
@jvshahid jvshahid removed the review label Oct 20, 2014
toddboom added a commit that referenced this pull request Oct 20, 2014
@schmurfy
Copy link
Contributor

@toddboom Thanks, as long as it is optional it is fine for me.

@Dieterbe you are right the size is not really the matter that's more a philosophical concern, I don't like dead weight especially in this case it feels like a mad scientist idea, I understand that for testing and development environment it might make things easier though but I just don't see the point in production.
(and I am pretty sure it could be 2052 my opinion would not change on this ;) )
If I want to serve the admin ui it will be via nginx like I already do with my existing web apps just because nginx is hard solid, does the job very well and use its resources very efficiently.

Don't take me wrong influxdb is awesome, I waited for a long time for such project to be able to drop RRD (and that's why I am following its development) but I think that opposing opinions on matters like this gain to be shared, in this case having it as optional is a good enough solution for me :)

@Dieterbe
Copy link
Contributor

I think pragmatism and simplicity are core values in the influxdb project and this looks like a simple and pragmatic solution, so maybe that helps in understanding the reasoning @schmurfy

@jvshahid jvshahid deleted the fix-1032-admin-interface-static-assets branch October 21, 2014 14:52
@mikhailov
Copy link

by the way, what is benefit to serve static out of backend rather than web-server? From ops point of view this brings a certain level of complexity. To be not able to change static quickly and serve admin/api endpoint with sub-URI makes such great product difficult to deploy and maintain over time. How can we improve that?

@schmurfy
Copy link
Contributor

They are not targeting sysadmin with this but end users wanting to try quickly influxdb who just have to run an executable and it's done, I can understand that.
Since the webadmin is just a bunch of html files I guess you culd simply get them from the sources and put them in another folder to serve them via a real webserver, just remove the http admin port from the influxdb config and it will not be started.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants