I spent a few days with configuring Jenkins JClouds plugin and Openstack. My original goal was/is to make it possible to create our complex (>3--6 machines) system for the smoke test what I plan to run after each commit. Currently I am extremely far from that, I do not even think it is possible in a clean and maintainable way, but what I wanted to achieve in the first phase of this project is to have the magical on-demand jenkins slave feature in our currently sandbox-only Jenkins. I really really thought it will be easy.....
Plug an play did not happen.... it can be because our openstack configuration, can be because JClouds and its Jenkins plugin seems to be mostly used and tested/created/whatever for Amazon Cloud, but it does not work without some changes. I can not really recall all issues but here are some:
1. userdata is optional.... WRONG it will die with a nullpointer exception
2. create jenkins user did not work, we had to create it in the image, it just died somewhere after the init silently....
3. it needs the instance name but it wont brother itself to use the hostname or name or id fields in the metadata it only expects it in the tags/name.... of course it is not there by default for openstack
4. if you add it to all responses (well its python right? eeeeeeeasy) the RuninstanceResponseHandler will die while the DescribeInstancesResponseHandler (I think that was he class name) will work.... basically they handling the same kind of response.
5. you must like floating ips because it will use that even if you do not want to
6. and debugging a remote jenkins master is just pain.... random ports... guesses... weirdness
But is there an issue? I mean maybe we are just too lazy and forget the fact that we can be proactive. Even if I personally do not have the knowledge to understand and fix a tool (well, actually it is not true, I am fking awesome), our company, our comrades, our friends, our family, our kids.... well mostly the company where we work has to acknowledge and allow and support tweaking/fixing/breaking the tools we use. Support it with time or with people.
There is no such a thing as free tool as we all know, but really often we expect from the reality to give us everything cheap+instant, because these tools are so internal and hidden that there is no way to explain to the chief business guru master marketing demigod, or costumer we need some time (where some is greater than the amount of hours what you can work overtime without notice) to fix/do something with them... We lie too much? We does not complain too much? We are just extremely lucky we could make all those releases? Does not really matter which one, the fact is there, we have to spend visible time on them. We cannot just recoil when we found an issue. At the end we have to forge the Death Star and if the hammer is broken we have to find a way to fix it. We have to be honest, but even if no one cares, we have to keep on at Darth Vader if necessary till the problem is solved or we are dead.
So at the end the first phase was done, Jenkins slave was started, we had to spend some time on debugging, some other on finding solutions, some more on applying solutions, some more on more debugging, some more on drinking more coffee, but at the end it will work (or not), and we learnt something (or not). And we can tell to our boss, and the costumer and the sergeant: software development is not magic... we are just plain old craftsmen
No comments:
Post a Comment