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
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
