Bare Metal Provision: Razor + Puppet + Batch Scripts

先留个坑在这里，接下来两个月就是拼命实现这个东西了！

第一阶段的难题：

　　1. razor 源码没有认真阅读，运行的整个细节流程还没能印入脑子里，前面做了很多半途而废的工作。

　　2. 在运营同事明确提醒，分发内核最好使用redhat和suse的情况下，图省事，直接使用了razor附带的MK，目前正痛苦地给MK装针对硬件的驱动。

　　3. razor的模型与流程还不能完全满足要求，尤其的开始安装OS之前的部分，需要重新设计。

　　4. Ruby依然不熟悉，之后的代码质量存在很大风险。

 

第二阶段(05.01)：

　　时间点上应该进入第二阶段了，新到的20台机器已经装配就绪，而且只需要安装原生的ubuntu model， 但依然困难重重:

　　1. MK 驱动还是很大的问题，现在只能折回去使用hp-stk-linux 来制作MK, 时间紧迫，需要尽快完成。同时这还不是完备的解决方案，因为无法解决多品牌机器驱动的问题,
　　　 第二季度一定有非HP的服务器上架，到时侯极有可能会陷入来一种机器做一个版本的MK的局面，那就有些疲于奔命了。

　　2. 深入读razor的源码，其实是可以解决很多目前所面临的问题的，如MK做硬件设置操作如何融入整个可控制的流程，windows安装过程如何与razor server交互并且在post-install阶段将控制权转交puppet master.

　　3. UI 已经在开发中，但是要真正集成进来又会是一个难题，最初的设计输入是直接提交表单，却没有想到机器是已经点亮的。这样一来就出现了这么一种怪异的流程：先通过UI提交表单，然后通知机房点亮机器。这明显不行。
         其细读MK controller 源码，就可以很清楚的了解到，完全可以先discover node，在由UI指定process，触发hardware setting job. 

　　4. 流程的设计不够完备，对于原生Razor 的理解不够深刻，第一阶段留下的坑在第二阶段就显露无疑。
　　　 读源码会是一个“痛苦”的过程，但却是真正解决问题的途径。

 

 

转载于:https://www.cnblogs.com/Alex-Python-Waiter/archive/2013/02/28/baremetal.html