Re: [razor] puppet module for razor

[Nan Liu]

On Thu, Nov 22, 2012 at 6:34 AM, david b. <david...@gmail.com> wrote:

Hi,

is there any plan to extend the current razor module to go beyond the basic installation of a razor server and allow advanced configuration?

I am asking because the environments that i am looking to manage with razor would be segregated in sub-clusters each handled by an assigned OPS support stack (pxe, config, monitoring, ...).

The current module can be broken down further. I think there's some limitations that require tftp and razor to reside on the same system and I don't know that has been resolved.

 

Those OPS support stacks are themselves managed via puppet and in order to integrate razor in this kind of infrastructure i would be looking for support for basic operations like:

 - adding & removing images

 - adding & removing models

 - setting up tags and matchers

 - ...

The module supports razor image, model, tags, and policy as resources, so you can model these requirements in puppet:

https://github.com/puppetlabs/puppetlabs-razor/blob/master/tests/rz_resource.pp 

And there's some examples for more complicated deployments:

https://github.com/puppetlabs/puppetlabs-razor/blob/master/tests/openstack.pp

Is there something in particular you are looking for that also needs to be a resource?

Thanks,

Nan

[Tom McSweeney]

On Nov 22, 2012, at 12:21 PM, Nan Liu <n...@puppetlabs.com> wrote:
>
> The current module can be broken down further. I think there's some limitations that require tftp and razor to reside on the same system and I don't know that has been resolved.
>

Actually, with the recent changes to the Microkernel (v0.9.2.1 and later) I think we've removed the requirement that the Razor server and the tftp server be co-located. The Microkernel now searches for the Razor server using several sources (previously, it assumed that the next-server IP address that was returned from the DHCP server was the IP address of the Razor server):

First, it searches the boot command line to see if there was a parameter included in the boot command line that indicates the location of the razor server (this would require a change to how the Razor server generates it's iPXE boot script to take advantage of, but it's there if we want to make that change). The Microkernel first looks for a boot command line parameter that looks something like "razor.ip=1.2.3.4". If it finds a parameter like that, then that's what it uses as the IP address of the Razor server. If it doesn't find that parameter, then it looks for a boot command line parameter that looks something like "razor.server=some.server.name". If it finds that parameter, then it tries to resolve that hostname (some.server.name) on the local network in order to obtain the IP address of the Razor server.

If neither of those parameters are found, it then tries to resolve the hostname "razor" on the local network. If it is able to resolve that hostname (razor) on the local network then it uses the resulting IP address (if that hostname is resolved successfully) as the IP address for the razor server.

If it doesn't find the an IP address for the Razor server using any of the methods outlined above, the Microkernel will then (and only then) take the "next-server" IP address that was returned from the DHCP server and use that as the IP address for the Razor server. It is only in this "last resort" scenario that you MUST co-locate the Razor server with the TFTP server...

Does that make sense?

[Daniel Pittman]

On Thu, Nov 22, 2012 at 6:34 AM, david b. <david...@gmail.com> wrote:

G'day David.

> is there any plan to extend the current razor module to go beyond the basic
> installation of a razor server and allow advanced configuration?

I see you already got some answers, but I was curious about some of
your needs here...

> I am asking because the environments that i am looking to manage with razor
> would be segregated in sub-clusters each handled by an assigned OPS support
> stack (pxe, config, monitoring, ...).
>

> Those OPS support stacks are themselves managed via puppet and in order to
> integrate razor in this kind of infrastructure i would be looking for
> support for basic operations like:
> - adding & removing images
> - adding & removing models
> - setting up tags and matchers

It sounds to me like you want some sort of access control model here:
allow different teams *secured* access to different parts of the Razor
management tools. Is that actually right, or am I misunderstanding
your needs?

--
Daniel Pittman
⎋ Puppet Labs Developer – http://puppetlabs.com
♲ Made with 100 percent post-consumer electrons

[david brpr]

Hi Daniel,

I actually got the answer I needed 

... and it was a non-question really as I should have looked properly at the code of the module instead of simply scanning the manifest directory and then sending that post.

In regards to access control, we do have such requirements but they fall outside of razor responsibilities.

What would be more useful for us in the short term would be mechanisms to register arbitrary model templates and broker plugins. I was able to do it easily enough In a little POC I had running here, but I had to branch the code to make it work.

In any case, I have another post on that subject.

thank you for the follow up,

david. 

What would be more