Aside from the "Cloud API sucks" discussion (I totally agree with it), I'm definitely interested to get as much metrics from the provisioning process. So +1 for all your efforts, Oliver.
As we discussed yesterday at Linuxwochen, it would be great to get this stuff integrated with https://wiki.jenkins-ci.org/display/JENKINS/Metrics+Plugin for Jenkins. It automatically makes the metrics pluggable and allows to access them from APIs. I wish to get Metrics and Monitoring plugins integrated as well... BR, Oleg среда, 27 апреля 2016 г., 16:40:56 UTC+2 пользователь Kanstantsin Shautsou написал: > > @ogondza you can try to look at > https://github.com/KostyaSha/yet-another-docker-plugin where i clean-uped > most of the code that i started working on in docker-plugin. Not ideal of > course but i un-hardcoded and clean-uped as much as i can. All other > plugins copy-pasting code without understanding how it works (my impression > after reading a lot of cloud plugins). > PS feel free to contact about stats if you need some experiments. > > On Wednesday, April 27, 2016 at 4:59:35 PM UTC+3, Stephen Connolly wrote: >> >> So you should not be checking that the slave is launched by running >> through computer.connect(false) as that requires that you return early. >> Instead you should be checking for e.g. the ssh service to be open and >> responding to connection requests (you can do that easily with your >> launcher... but a custom check would be better as you only want to check >> that the port is open) then you return and let Jenkins add the node and >> connect. The critical bug is >> https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-plugin/src/main/java/jenkins/plugins/jclouds/compute/JCloudsCloud.java#L297 >> >> i.e. you should *never* add the node to jenkins yourself, when you do >> that you cause the second issue that you are then trying to correct. >> >> In short the future should return the Node instance to be added *when* the >> actual Node instance is ready to connect. If you return the Node too soon, >> then you get over-provisioning... which then leads to people trying to >> "fix" that by copying the hacks in the EC2 plugin. >> >> The cloud API is a mess. I want to replace it with something that a sane >> individual has a hope of implementing correctly. >> >> Do not fear, after dealing with the cloud API for many years now I have >> come to the conclusion that it is IMPOSSIBLE to write a correct >> implementation. The closest thing to a correct implementation is the >> oc-cloud implementation used by CJOC (and that only avoids the bugs that >> you cannot avoid because we can linearize operations in CJOC). >> >> Our nectar-vmware plugin is "ok" (largely due to a shake-down we did when >> we were using it for the predecessor to CJOC) >> >> The next closest to a correct implementation is Docker. >> >> After that... well it's all mostly sh1t... I loose the will to live when >> I start looking at other implementations. >> >> If you pick EC2 as your template you will be following every wrong >> example in the book. >> >> On 27 April 2016 at 13:54, Oliver Gondža <[email protected]> wrote: >> >>> On 04/27/2016 02:08 PM, Stephen Connolly wrote: >>> >>>> >>>> On 8 April 2016 at 14:44, Oliver Gondža <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Some plugins even wait for launch to complete before leaving >>>> PlannedNode#future >>>> >>>> >>>> Those are broken plugins >>>> >>> >>> As a maintainer of one such plugin I would like to hear your input on >>> [1] is it seems to be quite common. With regards to the cloud-stats plugin, >>> it would not change much even if they all get fixed since launch can be >>> started by Jenkins before it collects completed futures, it just makes it >>> happen all the time instead of rarely. >>> >>> [1] >>> https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-plugin/src/main/java/jenkins/plugins/jclouds/compute/JCloudsCloud.java#L299-L303 >>> >>> -- >>> oliver >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Jenkins Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-dev/418b92f5-e0ca-c85b-ecf2-bc4d5a184422%40gmail.com >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/15982b9f-8c57-46fe-9476-195817f68d14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
