[PATCH aeolus-configure] Suggested patches to enable default network selection on RHEV
by Vagner Farias
Hello,
Currently there's no way to select which default logical network to use when configuring RHEV Resource Providers. This can be very tricky on medium or large networks in which the default "rhevm" network is used only for management. In future RHEV/oVirt releases administrators most likely won't give users permissions on rhevm network.
Although there are initiatives to change how aeolus manages networks, perhaps a short term solution could be implemented until that time comes so that it's not required to change a hard coded setting in the code whenever the network to be used is different from "rhevm"
To achieve this, I patched the following components:
a) aeolus-configure, so that "network_name" becomes a required configuration for RHEV resource providers.
b) iwhd, enabling it to use a variable setting for the network.
c) imagefactory, in order to set "rhevm" as the default network if the packages are updated and aeolus-configure is not run again.
Probably the default network could be set in iwhd, but I thought it was easier to set it in imagefactory.
Notice that I'm not using the latest releases, but the ones used in CloudForms 1.1.1. Unfortunately I don't have the resources to test the patches in other releases.
I don't know which would be the best option to send the patches, so I'll include one per message.
diff -uNr aeolus-configure-2.8.11/conf/rhevm_configure aeolus-configure-2.8.11.network/conf/rhevm_configure
--- aeolus-configure-2.8.11/conf/rhevm_configure 2012-10-25 19:15:06.000000000 -0200
+++ aeolus-configure-2.8.11.network/conf/rhevm_configure 2013-01-24 20:34:21.434972317 -0200
@@ -27,4 +27,5 @@
# deltacloud_password: password
# deltacloud_api: https://rhevm.server.com:8443/api
# deltacloud_data_center: data center id
+ # network_name: rhevm
# push_timeout: 1800
diff -uNr aeolus-configure-2.8.11/recipes/aeolus/manifests/profiles/rhevm/instance.pp aeolus-configure-2.8.11.network/recipes/aeolus/manifests/profiles/rhevm/instance.pp
--- aeolus-configure-2.8.11/recipes/aeolus/manifests/profiles/rhevm/instance.pp 2012-10-25 19:15:06.000000000 -0200
+++ aeolus-configure-2.8.11.network/recipes/aeolus/manifests/profiles/rhevm/instance.pp 2013-01-24 20:24:40.094971363 -0200
@@ -19,14 +19,16 @@
$deltacloud_password,
$deltacloud_api,
$deltacloud_data_center,
- $push_timeout)
+ $push_timeout,
+ $network_name)
{
aeolus::rhevm::validate{"RHEV NFS export validation for ${name}":
rhevm_rest_api_url => "$deltacloud_api",
rhevm_data_center => "$deltacloud_data_center",
rhevm_username => "$deltacloud_username",
rhevm_password => "$deltacloud_password",
- rhevm_nfs_export => "$nfs_export"
+ rhevm_nfs_export => "$nfs_export",
+ rhevm_network_name => "$network_name"
}
file {"$nfs_mount_point":
diff -uNr aeolus-configure-2.8.11/recipes/aeolus/manifests/rhevm/validate.pp aeolus-configure-2.8.11.network/recipes/aeolus/manifests/rhevm/validate.pp
--- aeolus-configure-2.8.11/recipes/aeolus/manifests/rhevm/validate.pp 2012-10-25 19:15:06.000000000 -0200
+++ aeolus-configure-2.8.11.network/recipes/aeolus/manifests/rhevm/validate.pp 2013-01-24 21:10:21.458125960 -0200
@@ -1,5 +1,5 @@
-define aeolus::rhevm::validate($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export){
- $result = rhevm_validate_export_type($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export)
+define aeolus::rhevm::validate($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export,$rhevm_network_name){
+ $result = rhevm_validate_export_type($rhevm_rest_api_url,$rhevm_data_center,$rhevm_username,$rhevm_password,$rhevm_nfs_export,$rhevm_network_name)
notify {"${name}":
message => "the RHEV NFS export is on the correct storage domain and has type 'export' => ${result}"
}
diff -uNr aeolus-configure-2.8.11/recipes/aeolus/templates/rhevm.json aeolus-configure-2.8.11.network/recipes/aeolus/templates/rhevm.json
--- aeolus-configure-2.8.11/recipes/aeolus/templates/rhevm.json 2012-10-25 19:15:06.000000000 -0200
+++ aeolus-configure-2.8.11.network/recipes/aeolus/templates/rhevm.json 2013-01-24 20:32:32.964075078 -0200
@@ -10,6 +10,7 @@
"nfs-host": "<%= params['nfs_server'] %>",
"api-url": "<%= params['deltacloud_api'] %>",
"cluster": "_any_",
+ "network_name": "<%= params['network_name'] %>",
"timeout": <%= params['push_timeout'] %>
}<%= remaining_instances.zero? ? nil : ',' %>
<% end -%>
--
Vagner Farias
vfarias(a)redhat.com
11 years, 2 months
RFC - Messaging over social networks
by Angus Thomas
This is a problem which I've been thinking about in the context of
Winged Monkey, but it is more generally applicable.
We want Winged Monkey to be available on people’s phones, tablets etc so
that they can see the state of running instances, receive notifications
whenever there’s an outage etc..
So long as the users are standing fairly near the server which is
running Winged Monkey, and can get wifi connectivity to the same network
that the server is on, then it’s all relatively simple.
However, as soon as users step outside the building, it all gets a bit
more complex. In order for the users’ phone to be able to connect over
the internet to the Winged Monkey server, then either the phone is going
to need to have a VPN connection, which is a significant overhead, or
the Winged Monkey server instance is going to have to be directly
accessible over the internet. A lot of the organisations which are
potential users of Winged Monkey wouldn’t be prepared to do that.
We could use a social network as a messaging conduit between the Winged
Monkey server and a client application on users’ phones.
For the rest of this mail, I’ll expand in this in the context of
Twitter. I don’t *think* this use would be a violation the Twitter’s
terms of service. ( https://twitter.com/tos ). There are several public
social networks which could serve the purpose...
So, here’s how this could work:
* The Winged Monkey server would register a Twitter account, with
protected tweets.
* A user would install and run the Winged Monkey phone app. The first
run would also create a protected Twitter account, and when the user
authenticates, the two Twitter accounts start following each other.
* Thereafter Winged Monkey and the phone app use tweets to communicate
over the internet, sending instructions, status updates etc. as strings
up up to 140 characters. So long as both the server and the client app
poll frequently for new tweets, the responsiveness should be acceptable
to users.
Some of the benefits are:
* The communications are authenticated, with access permission which can
be very quickly revoked by unfollowing an account which is no longer
supported.
* The communications are also (moderately) secure, in the sense that
tweets from and between protected accounts aren’t generally readable.
* The timelines of the accounts constitute an audit history of events
etc.. It would be trivial to scrape that audit history from Twitter if
required.
* The principle benefit, though, is that the requirement for the Winged
Monkey server to be directly accessible over the internet is removed. So
long as the Winged Monkey server can make a client connection to
Twitter.com, stuff just works.
I’m not pretending that this is a flawless proposition, but I think
there’s enough of an idea here to want feedback. I’d love to hear a
better way to solve the problem.
Angus
11 years, 2 months
