-
Notifications
You must be signed in to change notification settings - Fork 306
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
Refactor handling of init systems #355
Conversation
Refer to this link for build results (access rights to CI server needed): |
51ffa8a
to
53c50d2
Compare
Refer to this link for build results (access rights to CI server needed): |
53c50d2
to
7f723a8
Compare
Refer to this link for build results (access rights to CI server needed): |
7f723a8
to
5e80c5d
Compare
Refer to this link for build results (access rights to CI server needed): |
5e80c5d
to
cefdf1e
Compare
Refer to this link for build results (access rights to CI server needed): |
cefdf1e
to
de05b4b
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
I think this in a good state to review now. I've tested on CentOS 7, using both Hammer release, and latest Infernalis dev packages. This covered both sysvinit and systemd. I did the same thing on Trusty, and that successfully gets upstart on each. Using the latest Infernalis packages, I did get an error when trying activate file-based OSDs on both Trusty and CentOS 7::
This seems more to do with running the daemons as the ceph users than anything to do with the init system, though. I should still do a couple tests using RGW and MDS, but it's looking good so far. @alfredodeza @liewegas feel free to take a look. There is additional clean up that could be done, but this is all the obvious stuff. It is nice to not have distro-specific versions of the "mon create" stuff anymore. :) Once this is in, I can work on switching over to |
On Tue, 15 Sep 2015, Travis Rhoden wrote:
if it's dcrypt, that's http://tracker.ceph.com/issues/13000
yeah |
FWIW, the permissions error is because I was using directories for OSDs (which I rarely do) and created them as root. If I did...
things worked just fine. So as part of Infernalis, we'll probably need to update docs to say that if you are using directories for OSD testing, you need to set the right perms. :) Block devices are all taken care of automatically by the tooling. I wonder if ceph-disk should do something similar when pointed at a directory? |
Refer to this link for build results (access rights to CI server needed): |
3b9ffdc
to
dfd598e
Compare
Refer to this link for build results (access rights to CI server needed): |
RGW and MDS services seem correct on Trusty/Upstart. I had to push one more commit to fix RGW on sysvinit. I wasn't properly handling that the 'ceph' and 'ceph-radosgw' init scripts have completely different options (like That's all fixed now. |
@dmick @alfredodeza care to take a look at this one? |
def _get_init_script(self, service): | ||
return 'ceph-radosgw' if service == 'ceph-radosgw' else 'ceph' | ||
|
||
def _build_service_command( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't see any tests for this one. It seems like it is one of the few that has a lot of behavior (maybe there are tests for it already?)
It might get tricky to test it out because the InitSystem
class has eager behavior in __init__
(it connects remotely to find out what the hostname is).
If that results in making it difficult to test maybe hostname
should be a @property
so that is only called/used when needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alfredodeza Thanks for pointing out the eager behavior in __init__
. I've removed that in the two places I had it and used @property
instead. A definite improvement.
Oh man - I never realized this never went in. That's a shame, it was a big improvement! :) I suppose this should just be closed at this point. |
can it be rebased? |
@codenrhoden I think this could be rebased and made to work again and is a very big improvement. |
@liewegas @osynge I'm sure it can be. I just need to go through any fixes/improvements from the last year to see if there is anything that needs to be added. I'll try to get to that over the next week or two. I'm going to be working on some Ceph related stuff over the next few weeks, so I'm happy to help out here! |
@codenrhoden sorry this seems to have become old, the newer centos and ubuntu is only systemd now and the current logic although simple handles it better and is well tested. |
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
There is no longer any need to have a per-distro implementation of mon create. Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
a6c21b1
to
862d407
Compare
well whether it makes sense or not, I'll take a stab at it. I've just pushed an initial rebase, but no testing has been done at this point. |
running against this branch on hammer, jewel http://pulpito.ceph.com/vasu-2016-10-03_16:53:30-ceph-deploy-hammer---basic-vps/ |
@vasukulkarni: thanks for the links. I haven't done much testing yet, so I don't expect things to work. However, the errors in Pulpito are not code related. They are all failing when doing Not sure how Pulpito normally handles that. If the branch can be overriden, I believe |
Make sure we enable ceph/ceph.target appropriately Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Since we have a single place handling "service ceph ..." vs "service ceph-radosgw", we need to handle the fact that their options are different. Refactor code to build the exectuable command all in one place Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Use @Property instead, to only reach out to remote node when the attr in question is needed, rather than setting it on initialization. Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@redhat.com>
Signed-off-by: Travis Rhoden <trhoden@gmail.com>
We'll see what Jenkins thinks of the latest changes. I was able to get all tests passing on py27 and py34 plus flake8 with latest changes (updating pytest and mock version requirements). I wasn't easily able to get a py26 env installed on CentOS 7.2. I guess it's no longer in EPEL? |
So, if Python 3.4 is going to be tested, you should probably add it to the Jenkins nodes. :) I also want to be clear that this was just focusing on the unit tests via Jenkins. Still haven't done "real world" testing yet. |
@codenrhoden that failure as you said is because its in your git repo which i didn't notice , it only looks for branh in ceph repo https://github.com/ceph/ceph-qa-suite/blob/master/tasks/ceph_deploy.py#L66, If you can create the branch in ceph-deploy repo it will be easy to get some runs on hammer/jewel |
ceph is systemd only now |
The idea here is to create and use classes with a common interface to abstract working with the init systems. Should simplify the code immensely.
This will be a pre-req to fixing http://tracker.ceph.com/issues/13087, which has us use the new
ceph-detect-init
tool when it is present.