Loving Rockstor and want to do some development. After setting up a VM as described in the “contributing” guide I fire up the webbrowser. When I reach the dashboard, most of the charts and blank and in the inspector I see lots of 404’s on /socket.io.
I spent a couple of hours looking at the logs, configs and running processes but I can’t find what’s the issue here.
Here’s how I’ve setup the VM. After installing from the ISO I ran:
@Richie Welcome to the Rockstor community. Chuffed you fancy doing some development by the way.
What you’ve done looks to be good although I’d get distro via the python-distro package as that’s how I tested it, we need the site install but the build process, from tag 3.9.2-45 onwards, also pip installs for our virtual env as well). It has to exist in both. Not related but just a note. See my notes on this and the change I made to base-buildout.cfg in the following pull request which was merged recently and constitutes git tag 3.9.2-45 (as yet unreleased in rpm form).
Anyway I’m not sure what’s happening with your build but I strongly suspect you still have the original rpm installed. So I would make sure you first delete that. You’ve not build in /opt/rockstor which is good so I say uninstall the rockstor rpm then wipe the /opt/rockstor dir so you are certain there is nothing running from there. I’d also delete all you have as well and build again fresh, just in case. Also note that the rockstor-pre service does a bunch of pre-config (via it’s invoking initrock) so make sure you stop those services (which are probably still from the rpm) then after the build they will be started automatically again and so the config that it sets up will pertain to the new source build dir (your /opt/rockstor-git) not the rpm installed one (/opt/rockstor).
Quick note on work in progress, to avoid us standing on each others toes or duplicating effort: @Flox is in progress making some significant additions / changes to the Rockon system. If it relates to your plans then he would be the best person to speak to on that, ie in this thread or via private message if that works for both parties. @phillxnet (me) is in progress making significant changes to the disk delete mechanism and I’ve also reworked how we refresh our disks and pools (mostly for performance improvements / efficiencies). So you might want to avoid making changes in those areas at least until we have our respective pull request in as it would be a real shame, and disheartening, if our efforts clashed. The above is what I’m currently aware of anyway.
My current issue relating to the above (for me) is:
which I’ve essentially fixed but got carried away with some much needed optimisations / rationalisations re the disk / pool management as whenever a balance is kicked off we really struggle with interactivity: hence the efficiency drive (made some fairly substantial time savings as it goes).
And I’ve also in the process fixed:
by adding (locally only so far) btrfs per disk allocation tracking / surfacing, as well as an embryonic devid tracker. We needed this to make more relevant calculations on that latter issue.
You might also want to take heed of out plans re openSUSE Leap 15.0 / Tumbleweed which a good part of my last 6 months has been prepping the code for; see:
So if you do end up making any changes it would be most appreciated to ensure that those changes work also when building on those distros, just to avoid holding up that move really, but Rockstor on those distros is still very much a work in progress and our main platform is still CentOS. But not worries otherwise as it’s a bit much working across 3 distros concurrently and hopefully what every you do will be OK anyway (really depends on how close to the OS you work at): but just to keep that in mind would be good. Also they run a far newer btrfs-progs and back port a tone of btrfs kernel stuff so if your interests is at that level then also worth bearing in mind.
Hopefully that has been helpful and I haven’t missed the mark. And if all is well you should have a shiny new build running as expected shortly. Let us know how you get on and any ideas on the areas you fancy working on may also help us to pick issues that are less likely to clash. Have fun.
Oh one other thing, You may also need to incorporate the changes in the following pr:
I encountered the same error recently when I tried to rebuild my development VM (I weirdly could see these errors with the Google Chrome developer console, but not Firefox’s). I then decided to test whether I messed something by trying this rebuild and reinstalled a new VM with the Rockstor ISO. After following the steps described in the docs (very similar to yours), I didn’t encounter this error anymore.
I would thus believe it is related to what @phillxnet said with regards to an existing Rockstor rpm:
Let us know how it goes and don’t hesitate to ask (on the forum or PM) if curious, I’ll try to help as best as I can!
Thanks both for the extensive responses! I’ve tried your advises but it didn’t solve the issue. Eventually I started all over from scratch with a new VM but it didn’t help. Here’s exactly what I did so it should be easy to reproduce.
# After I installed fresh VM from ISO:
yum remove rockstor
rm -rf /opt/rockstor
rm -f /etc/systemd/system/rockstor*
reboot
yum install -y git gcc zeromq-devel python-devel postgresql-devel python-distro
git clone https://github.com/rockstor/rockstor-core /opt/rockstor-git
python /opt/rockstor-git/bootstrap.py -c /opt/rockstor-git/buildout.cfg
/opt/rockstor-git/bin/buildout -N -c /opt/rockstor-git/buildout.cfg
Except for the dashboard the rest seems to work fine, but I’m not sure if the /socket.io endpoint is used anywhere else than in the charts.
@Flox, I also saw these errors at first only in Chrome, but then I found out that in Firefox they don’t show up in the console, but they do show in the network tab.
I’m very new to the Rockstor sourcecode and I’ll have to brush up on my Python knowledge, so I’ll try to make a few small improvements. Later on I’ll surely review this thread as it contains a lot of guidance. For now I’m just trying to get the development environment working well.
Give that a go and see how you get on. Pretty sure you will then be sorted. Essentially, at build time, we pull in a variety of libraries and the version of the one freshly pinned in that pr I referenced (and submitted) updated it’s version around 5 hours before I noticed it and submitted the pr. Quoting from that pr:
" As of 25th November 2018 source builds failed to display live Web-UI header info such as time, Rockstor and kernel version etc. This was tracked down to an upstream python-engineio updated to 3.0.0. "
Also note that it is good practice to first install all available updates on our base system.
yum update
Let us know if you are still having problems after first trying all of my prior suggestions and we can take it from there ie:
So deleting the systemd links may not render those services stopped although I appreciated you rebooted which would, so:
The yum-changelog is also included in another pending pr of mine:
again not directly relevant to your issue and affects very few installs as it goes. It was just a missing dependency that I popped in for completeness. It’s usually already installed.
Copy or git pull your code, make the change I originally indicated re the python-engineio.
Visit Web-UI and do initial setup, taking care to remove the system user if you wish to re-use them in this setup, ie ‘userdel admin’ if admin is what you used of course.
Just run through this locally and I have working dashboard. I’m currently mid pr prep so did with my current in house changes in place but they are not in this area anyway.
Lets see how you get on with the above. The project is actually quite active and with that library change we have a number of pr’s awaiting review by project lead @suman and the 2 pending preps by me and @Flox mentioned previously of course. That upstream library update is complicating the normal prep of just building from master which is what you have indicated doing. That upstream library change was a pain but once we have that merged it should no longer be a problem.
Thanks Philip, that worked! Turned out that PR#1996 did the trick here. The rest seems to be optional or unrelated.
No matter how experienced one is, getting involved in a new project can be a bit challenging, it is good to see that friendly knowledgeable people like yourself are available to help out. It certainly motivates to get my hands dirty. Unfortunately it’s not like that with all projects which you surely know.
And clearly you are a man of many talents! For one I highly admire your time-traveling skills:
All joking aside, thanks again @phillxnet and @Flox . Hope I can pick your brains again in the future if I have some more questions.
@Richie Chuffed you are now sorted on your dev environment and look forward to what ever takes your fancy development wise. You can always look to prior pull requests to get a handle on what has been successfully merged prior.
Definitely, plus I see Rockstor as quite a large project really; or at least much larger than one might first imagine. And we utilise quite a range of technologies so definitely at bit of an up hill struggle initially. Although in this case it was really only the complication of that very recent upstream library shift to a major new version that caught us out. Still, when that’s in place (merged) we should be in better shape; at least until the next ‘complication’ anyway.
Re my suspected time-travelling skills: alas not . And it also looks like I have work to do on my communication skills. Oh well bit by bit .
Certainly: speaking for myself; although I can’t always respond as quickly as I would like and given the code side of things takes quite a lot of focus I often have to prioritise a current issue just to get it done and out.
Re the friendly angle: this is a requirement for my involvement at least as I would not choose to be involved otherwise, i.e. it was also a factor for my ‘on boarding’ and I try to perpetuate it as best as I’m able as I go. Speaking of which I am also one of the forum moderators and as such take cues from the community / forum members so do please consider flagging anything you see on the forum as you see fit as this is a major ‘window’ to the project as a whole: a suggestion I encourage all forum members to embrace.
I do. And it’s up to all of us to keep things ‘good’ and I also invite all forum members to call anyone out if they see inappropriate attitudes, after all we can all easily get frustrated with these here confusers/computers.
Well done on persevering and hope you have fun with your development endeavours.
. And it also looks like I have work to do on my communication skills. Oh well bit by bit 
.