Vagrant/Ansible to auto-build a test server and/or provision a real host. #2205
Conversation
|
I suspect you're comments to Stephen regarding to the IPv6 disablement will apply as I haven't attended to any of the comments in the thread. I am however, happy to do so. |
|
@mikemonkers Hello again. Re:
Yes I'm afraid so. Could just be an additional sed and consequent "grub2-mkconfig -o /boot/grub2/grub.cfg". With ipv6 enabled some of our stuff breaks. See: issue: [OpenSUSE] IPV6 isn’t disabled by Yast and/or sysctl config #2139 So if that and all the other requirements specified in: https://en.opensuse.org/openSUSE:Trademark_guidelines But those are the two we have chosen to use. And we can apparently, from that doc, use these in combination with our own trademark; hence the use you've already seen on the forum etc of "Rockstor built on openSUSE". Haven't looked pull request really but just wanted to drop these notes. I'll re-read what I said in the forum and take a proper look at this pr soon hopefully. Thanks for formalising this and well done on the attribution side re Stephen Brown II for the forum. Oh and for doing docs as well. Nice. I'm not so sure of the various additional software packages listed to be installed. These could be remarked out however so folks could add them if they fancied and it still shows them how such packages might be added in the first place. All in I think it would be good to the like of this folded into the project, but I'm just no keen on it straying from, for example, our rockstor-installer config. Ideally we want to add nothing extra but what is required, almost, hence the rockstor-installer example where we are almost a JeOS config before we add our hard dependencies. Anyway I've not taken a proper look just yet but those are my initial impressions. Thanks again for preparing this pull request. We can now at least work through what we have here and work out between us what might work best. I'd also like for @FroggyFlox to take a look at this at some point. |
|
@mikemonkers I've just thought that it will probably be best to start this pull request over. That is because you have submitted from master. We are less picky with this in the other repos, as you did the same in your soon to be merged hopefully rockstor-installer pull request but we have to be more careful in this repository. We all required, again only strictly in this repo, that an accompanying issue is opened and the pull request linked to it. This issue requirent in order that our Web-UI can do due attribution which is important. The Changelog we embed in the rpms is parsed by the Web-UI and links to the issue pertaining to each pull request. It allows us to surface contributors to the users as they then see what was proposed and given the link on GitHub to the pull request they can also then research the actual code changes associated with that issue. The not committing pull requests from master is important as it eases your ability to rebase locally and to keep your own pull requests separated from one another. The idea being that you create a branch specifically of a pull request. Then once that pull request is done and dusted (can take some time) you would delete the pull request. We have had numerous instances earlier on where folks would start making un-related changes to their 'master' branch and of course GitHub then adds these to the 'in play' pull request and chaos ensues. The easiest way may be a complete re-do. I.e. to return your master to a clone of the upstream you may have to close this pull request, delete your fork of rockstor-core and re-create it. The create the issue branch (ideally after making the issue so their names tie together) and then make your proposed changes to the issue branch and create the pull request from there. Sorry to mess you about but it really is easier in the long run and makes your end easier as well given you have all your changes for a specific issue/pr contained within a specific branch. See our following docs on all this: Community Contributions: http://rockstor.com/docs/contribute_section.html But don't delete you rockstor-installer copy just yet!! As I'm about to have a last look on that. You can move to the more compartmentalised approach on that repo as we go forward as I'm hoping you are game for further pull requests :) as it can often be the case that once you look at one thing another becomes visible and so you can pop suggested changes in another branch accordingly then and do parallel pull requests, both stemming from the master branch. And given you have 2 pending pull requests currently, all-be-it in seperate repos, I thought it best to broach this issue specific branch business sooner rather than later. Thanks again for all your efforts here. Ad do be careful not to loose work in all this re-arrangements. But once you are in the swing of issue specific branches they are a real help all around. |
|
I can do that. It the right way to do things really. It'll give me the chance to look at the IPv6 stuff and aligning the VM as a compatible system. Leave it with me. |
Ansible to deploy/provision Rockstor to a host (refactored from Stephen Brown II work reported here: https://forum.rockstor.com/t/opensuse-ansible-playbook-to-get-rockstor-installed-on-fresh-system/7185 - accredited in the role README.md)
Vagrant to create a test host and use the ansible provisioner part of vagrant to join them together.
One command to build a VM with Rockstor installed ready to go.
Or you can use the ansible directly on you own VM/physical host.