Open Stack

Hi folks (operators and devs),

I was digging into some of godaddy code yesterday/everyday and it got me 
thinking about how other operators are handling customized internal 
integrations and what some of the common patterns are for how these 
integrations are typically performed (overall it doesn't feel like there 
are that many patterns that people can be doing in that many different 
ways). It got me thinking that there really isn't a best practices 
document that I know for these types of common integrations (perhaps 
this can be the start of one?) that operators and developers can provide 
feedback on (because perhaps there is a new or to-be new API that 
replaces an older style of integration).

This hopefully falls into the pattern (and/or is similar to) that is 
described in:

https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/api-no-more-extensions.html#alternatives-for-extension-owners

'''
Please bring forward the conversation to the wider community anyway. 
There are a lot of OpenStack deploys, and issues that you think are 
specific to your environment may not be. And in conversation with the 
upstream operator and developer communities we could probably come up 
with a generic facility that supports your use.
'''

So let me describe some of the internal integrations we've had to do and 
see if these sound familiar to what others have had to do and it'd be 
nice to share how those integrations were performed (or even if the 
integration that was done is similar or done in a different manner, 
that's cool to):

(1) Requirement we have is to register virtual machines booted with a 
in-house dns solution and to also delete dns names registered on 
deletion being triggered.

The steps this will do is on reception of a 
'compute.instance.create.end' event being received (the program that 
does this listens on the notifications queue of nova) logic will proceed 
that will (direct comment from routine here):

'Creates A and PTR records based off of the instance's hostname and 
fixed ip.'

This goes about and has further logic to realize this statement (its 
error robustness is a different discussion, but I digress) and the 
'compute.instance.delete.end' event does the reverse:

'Removes instance's DNS entries. Will remove A and PTR records.'

Now sidestepping the choice of using the notifications queue (and having 
a consumer on that) for this which IMHO has issues in that it's out of 
band, has no way to stop a VM from being created, or set a state of the 
VM like ERROR_DNS_SETUP if it fails and so-on (ie if a create dns record 
fails, how does the delete know that it shouldn't try to delete and 
such...) I was wondering how others are doing this kind of similar 
actions. I believe that they might be more native integration with 
neutron that is possible here to solve this using a native solution instead?

(2) Requirement that for all created instances we register into a 
home-grown cmdb solution with the 'fixed_ips' that the instance was 
built with, the environment it was built with, information about the 
instances image (family) and so-on (the following is a more complete 
gathering of info that we send):

     server = sr_manager.build_server_object(
         environmentID=cmdb_env_id,
         hostname=instance.hostname,
         serialNumber=instance.instance_id,
         fqdn=fqdn,
         rack=_short_hostname(instance.host),
         operatingSystemIdentifier=os_spec,
         operatingSystemFamily=os_family,
         ramMB=instance.memory_mb,
         teamID=cmdb_team_id,
         teamName=cmdb_team_name,
         drivesGB=instance.disk_gb,
         ...
         nics=cmdb_nics
     )

So similar to (1) we have also plugged into the notifications queue with 
the same queue consumer and hook-in to do this out of band system 
registration (which is really a eventually/best-effort population into 
the home grown cmdb due to mentioned issues about about robustness and 
failures). I was wondering what others are doing for this kind of in 
house cmdb (which most companies have) and how they are doing VM 
registration into that (are people even bothering to do that?); oh btw, 
on removal it triggers a removal/retirement process from that same 
system using a function like:

     sr_manager.retire_server(instance.hostname, instance.user_id)

(3) On deletion (only) we in the same consumer connect into corporate 
LDAP and delete the instance hostname from that system and delete the 
instance from registration into a variant of 
https://fedorahosted.org/spacewalk/ (the registration of the instance 
into these systems happens on instance boot); so this got me wondering 
how do others register/deregister virtual machines created into such 
systems (we can't be the only one using corporate LDAP/spacewalk in this 
manner)?

(4) A few more, but this is long enough for now ;)

-Josh