From terashima.naoya at np.css.fujitsu.com Mon Sep 1 00:56:33 2008 From: terashima.naoya at np.css.fujitsu.com (Naoya Terashima) Date: Mon, 1 Sep 2008 09:56:33 +0900 Subject: [Ovirt-devel] Trouble on loading the VM onto the node References: <018201c909c6$569db340$b16f210a@FMAFC020FC868C> <48B7D9F3.5080207@redhat.com> <01c401c909ce$fbdb8370$b16f210a@FMAFC020FC868C> <48B7E60B.5040309@redhat.com> Message-ID: <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> Hi I felt relieved to hear VM is running within one of three node. Thank you. But how can I find out which node VM in running on? I logged in every node to see if which has VM but I couldn't find out. Every node I logged in didn't seemd to have VM. Sorry for my repetitious question but please teach me how to find out which node has VM. ----- Original Message ----- From: "Chris Lalancette" To: "Naoya Terashima" Cc: Sent: Friday, August 29, 2008 9:05 PM Subject: Re: [Ovirt-devel] Trouble on loading the VM onto the node > Naoya Terashima wrote: > > Hi > > > > Thank you for your reply. > > You mean, a VM is automatically loaded onto appropriate node? > > So, could you tell me how to confirm which node are picked. > > I coudn't confirm which node are chosen by the command > > > > #virsh start node3 > > #virsh start node4 > > #virsh start node5. > > > > I attach Screenshot.png which describe the situation. > > a VM named aaaa are running but seem separated from every node. > > I would appreciate it if you could give me an adivice about it. > > OK, yes, everything seems to be up and running. What you have to realize is > that node3, node4, and node5 are running as managed nodes; think of them as > actual, physical hardware. That means that VM aaaa is actually running *within* > one of those nodes; you have to look on the nodes themselves to find out which > one it's running on. > > Chris Lalancette From pmyers at redhat.com Mon Sep 1 04:01:17 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 01 Sep 2008 00:01:17 -0400 Subject: [Ovirt-devel] Trouble on loading the VM onto the node In-Reply-To: <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> References: <018201c909c6$569db340$b16f210a@FMAFC020FC868C> <48B7D9F3.5080207@redhat.com> <01c401c909ce$fbdb8370$b16f210a@FMAFC020FC868C> <48B7E60B.5040309@redhat.com> <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> Message-ID: <48BB690D.8030801@redhat.com> Naoya Terashima wrote: > Hi > > I felt relieved to hear VM is running within one of three node. > Thank you. > But how can I find out which node VM in running on? > I logged in every node to see if which has VM but I couldn't find out. > Every node I logged in didn't seemd to have VM. > Sorry for my repetitious question but please teach me how to find out > which node has VM. Right now the web UI does not expose which host is running a particular VM (note to self, we should add this). So the best way to tell if a VM is running on a particular node is to use the virsh list command as follows: From the host running the ovirt-appliance: # virsh -c qemu+ssh://192.168.50.3/system list Use the IP address of the node you want to check. node3 is 50.3, node4 is 50.4, etc... If you get errors about known_hosts having offending keys, prune the known_hosts file first: # ssh-keygen -R 192.168.50.3 or # ssh-keygen -R node3.priv.ovirt.org (This is because the node generates a new ssh key on each boot. This is something we haven't cleaned up yet) If you don't see your vm name listed in one of the virsh list commands it means the VM is not running on any node. If the UI says it's running, but virsh list doesn't confirm it, this is probably a bug. If this is the case, please send us the log files in /var/log/ovirt-wui from the appliance as they may help us figure out what is not working properly. Thanks, Perry From terashima.naoya at np.css.fujitsu.com Mon Sep 1 05:18:24 2008 From: terashima.naoya at np.css.fujitsu.com (Naoya Terashima) Date: Mon, 1 Sep 2008 14:18:24 +0900 Subject: [Ovirt-devel] Trouble on loading the VM onto the node References: <018201c909c6$569db340$b16f210a@FMAFC020FC868C> <48B7D9F3.5080207@redhat.com> <01c401c909ce$fbdb8370$b16f210a@FMAFC020FC868C> <48B7E60B.5040309@redhat.com> <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> <48BB690D.8030801@redhat.com> Message-ID: <01c901c90bf2$28a653b0$b16f210a@FMAFC020FC868C> Hi Thank you for your very intelligible explanation. I did the command #virsh -c qemu+ssh://192.168.50.3/system list #virsh -c qemu+ssh://192.168.50.4/system list #virsh -c qemu+ssh://192.168.50.5/system list and I could see the VM named dddd running on the node3. Thank you! But I still feel strange because I could see only one VM named dddd running though I'm running four VMs(aaaa, bbbb, cccc, and dddd). Could this be a bug? I attach the files in /var/log/ovirt-wui except rails.log and some screenshots. Screenshots explains how many VM are running now and how much resorces are used. please let me know where the problem is. Thank you ----- Original Message ----- From: "Perry N. Myers" To: "Naoya Terashima" Cc: "Chris Lalancette" ; Sent: Monday, September 01, 2008 1:01 PM Subject: Re: [Ovirt-devel] Trouble on loading the VM onto the node > Naoya Terashima wrote: > > Hi > > > > I felt relieved to hear VM is running within one of three node. > > Thank you. > > But how can I find out which node VM in running on? > > I logged in every node to see if which has VM but I couldn't find out. > > Every node I logged in didn't seemd to have VM. > > Sorry for my repetitious question but please teach me how to find out > > which node has VM. > > Right now the web UI does not expose which host is running a particular VM > (note to self, we should add this). > > So the best way to tell if a VM is running on a particular node is to use > the virsh list command as follows: > > From the host running the ovirt-appliance: > # virsh -c qemu+ssh://192.168.50.3/system list > > Use the IP address of the node you want to check. node3 is 50.3, node4 is > 50.4, etc... > > If you get errors about known_hosts having offending keys, prune the > known_hosts file first: > # ssh-keygen -R 192.168.50.3 > or > # ssh-keygen -R node3.priv.ovirt.org > > (This is because the node generates a new ssh key on each boot. This is > something we haven't cleaned up yet) > > If you don't see your vm name listed in one of the virsh list commands it > means the VM is not running on any node. If the UI says it's running, but > virsh list doesn't confirm it, this is probably a bug. If this is the > case, please send us the log files in /var/log/ovirt-wui from the > appliance as they may help us figure out what is not working properly. > > Thanks, > > Perry > -------------- next part -------------- A non-text attachment was scrubbed... Name: host-browser.log Type: application/octet-stream Size: 47554 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: host-status.log Type: application/octet-stream Size: 2856 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mongrel.log Type: application/octet-stream Size: 12042 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot1.png Type: image/png Size: 123879 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot2.png Type: image/png Size: 100690 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot3.png Type: image/png Size: 100108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: taskomatic.log Type: application/octet-stream Size: 55996 bytes Desc: not available URL: From pmyers at redhat.com Mon Sep 1 05:25:58 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 01 Sep 2008 01:25:58 -0400 Subject: [Ovirt-devel] Trouble on loading the VM onto the node In-Reply-To: <01c901c90bf2$28a653b0$b16f210a@FMAFC020FC868C> References: <018201c909c6$569db340$b16f210a@FMAFC020FC868C> <48B7D9F3.5080207@redhat.com> <01c401c909ce$fbdb8370$b16f210a@FMAFC020FC868C> <48B7E60B.5040309@redhat.com> <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> <48BB690D.8030801@redhat.com> <01c901c90bf2$28a653b0$b16f210a@FMAFC020FC868C> Message-ID: <48BB7CE6.1040703@redhat.com> Naoya Terashima wrote: > Hi > > Thank you for your very intelligible explanation. > I did the command > > #virsh -c qemu+ssh://192.168.50.3/system list > #virsh -c qemu+ssh://192.168.50.4/system list > #virsh -c qemu+ssh://192.168.50.5/system list > > and I could see the VM named dddd running on the node3. > Thank you! > But I still feel strange because I could see only one VM named dddd running > though I'm running four VMs(aaaa, bbbb, cccc, and dddd). > Could this be a bug? > I attach the files in /var/log/ovirt-wui except rails.log and some > screenshots. > Screenshots explains how many VM are running now and how much resorces are > used. > please let me know where the problem is. Check: # virsh -c qemu+ssh://192.168.50.136/system list You don't just have node3, node4 and node5 running. You also have a node136 according to your taskomatic logs. It could be that some vms are running on that node. node3, 4 and 5 are the 'fake' nodes that run on the same host as the ovirt appliance. node136 would be a real node running on a bare metal box. Let me know what looking at node136 tells you. Thanks, Perry From terashima.naoya at np.css.fujitsu.com Mon Sep 1 05:57:20 2008 From: terashima.naoya at np.css.fujitsu.com (Naoya Terashima) Date: Mon, 1 Sep 2008 14:57:20 +0900 Subject: [Ovirt-devel] Trouble on loading the VM onto the node References: <018201c909c6$569db340$b16f210a@FMAFC020FC868C> <48B7D9F3.5080207@redhat.com> <01c401c909ce$fbdb8370$b16f210a@FMAFC020FC868C> <48B7E60B.5040309@redhat.com> <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> <48BB690D.8030801@redhat.com> <01c901c90bf2$28a653b0$b16f210a@FMAFC020FC868C> <48BB7CE6.1040703@redhat.com> Message-ID: <01d901c90bf7$98ab4a80$b16f210a@FMAFC020FC868C> I tried #virsh -c qemu+ssh://192.168.50.136/system list But message "No route to host" came out. In the first place,I can't see node136 by the command #virsh list --all The output by the command is 1 developer running 2 node3 running 3 node4 running 4 node5 running - ovirt-appliance shut off But surely there is the node 136 in the Hardware Pool named Test (child of default). So what should I do? ----- Original Message ----- From: "Perry N. Myers" To: "Naoya Terashima" Cc: Sent: Monday, September 01, 2008 2:25 PM Subject: Re: [Ovirt-devel] Trouble on loading the VM onto the node > Naoya Terashima wrote: > > Hi > > > > Thank you for your very intelligible explanation. > > I did the command > > > > #virsh -c qemu+ssh://192.168.50.3/system list > > #virsh -c qemu+ssh://192.168.50.4/system list > > #virsh -c qemu+ssh://192.168.50.5/system list > > > > and I could see the VM named dddd running on the node3. > > Thank you! > > But I still feel strange because I could see only one VM named dddd running > > though I'm running four VMs(aaaa, bbbb, cccc, and dddd). > > Could this be a bug? > > I attach the files in /var/log/ovirt-wui except rails.log and some > > screenshots. > > Screenshots explains how many VM are running now and how much resorces are > > used. > > please let me know where the problem is. > > Check: > > # virsh -c qemu+ssh://192.168.50.136/system list > > You don't just have node3, node4 and node5 running. You also have a > node136 according to your taskomatic logs. It could be that some vms are > running on that node. > > node3, 4 and 5 are the 'fake' nodes that run on the same host as the ovirt > appliance. node136 would be a real node running on a bare metal box. > > Let me know what looking at node136 tells you. > > Thanks, > > Perry From pmyers at redhat.com Mon Sep 1 15:28:08 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 01 Sep 2008 11:28:08 -0400 Subject: [Ovirt-devel] Trouble on loading the VM onto the node In-Reply-To: <01d901c90bf7$98ab4a80$b16f210a@FMAFC020FC868C> References: <018201c909c6$569db340$b16f210a@FMAFC020FC868C> <48B7D9F3.5080207@redhat.com> <01c401c909ce$fbdb8370$b16f210a@FMAFC020FC868C> <48B7E60B.5040309@redhat.com> <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> <48BB690D.8030801@redhat.com> <01c901c90bf2$28a653b0$b16f210a@FMAFC020FC868C> <48BB7CE6.1040703@redhat.com> <01d901c90bf7$98ab4a80$b16f210a@FMAFC020FC868C> Message-ID: <48BC0A08.9080401@redhat.com> Naoya Terashima wrote: > I tried > > #virsh -c qemu+ssh://192.168.50.136/system list > > But message "No route to host" came out. > In the first place,I can't see node136 by the command > > #virsh list --all node136 might not be a real node... It could be the result of a recursive Node boot. That can happen if you allow a Node to PXE boot to the Node itself (then you have a node running within a node). Version 0.92-1 of the software makes it more difficult for this scenario to happen, since we've begun integration with cobbler to handle provisioning. So you can probably just ignore node136 then. > The output by the command is > > 1 developer running > 2 node3 running > 3 node4 running > 4 node5 running > - ovirt-appliance shut off I see you have ovirt-appliance present which is version 0.92-1 of oVirt. But you are currently running developer. Can you get rid of the older version (0.91-1) and try only running 0.92-1? If there is a problem I'd like to make sure it's in the latest version of the code. No sense in debugging a version of the code that is out of date. > But surely there is the node 136 in the Hardware Pool named Test (child of > default). > So what should I do? If you don't see the other nodes running on node3, 4 or 5 it means they are not actively running right now. It could be that the status fields in the WUI are not correct. Can you sign onto the IRC channel on freenode.net? (The channel name is #ovirt) It might be easier to figure this out if we worked over IRC instead of email. Thanks, Perry From terashima.naoya at np.css.fujitsu.com Tue Sep 2 00:57:23 2008 From: terashima.naoya at np.css.fujitsu.com (Naoya Terashima) Date: Tue, 2 Sep 2008 09:57:23 +0900 Subject: [Ovirt-devel] Trouble on loading the VM onto the node References: <018201c909c6$569db340$b16f210a@FMAFC020FC868C> <48B7D9F3.5080207@redhat.com> <01c401c909ce$fbdb8370$b16f210a@FMAFC020FC868C> <48B7E60B.5040309@redhat.com> <00de01c90bcd$94251830$b16f210a@FMAFC020FC868C> <48BB690D.8030801@redhat.com> <01c901c90bf2$28a653b0$b16f210a@FMAFC020FC868C> <48BB7CE6.1040703@redhat.com> <01d901c90bf7$98ab4a80$b16f210a@FMAFC020FC868C> <48BC0A08.9080401@redhat.com> Message-ID: <00ce01c90c96$dc41fe70$b16f210a@FMAFC020FC868C> Thank you very much for your advice. I tried to upgrade ovirt from 91 to 92 before but I failed so now I'm using 91 (I posted here "Touble on updating oVirt"). I'll try it again or I'll use IRC. Thank you ----- Original Message ----- From: "Perry N. Myers" To: "Naoya Terashima" Cc: Sent: Tuesday, September 02, 2008 12:28 AM Subject: Re: [Ovirt-devel] Trouble on loading the VM onto the node > Naoya Terashima wrote: > > I tried > > > > #virsh -c qemu+ssh://192.168.50.136/system list > > > > But message "No route to host" came out. > > In the first place,I can't see node136 by the command > > > > #virsh list --all > > node136 might not be a real node... It could be the result of a recursive > Node boot. That can happen if you allow a Node to PXE boot to the Node > itself (then you have a node running within a node). > > Version 0.92-1 of the software makes it more difficult for this scenario > to happen, since we've begun integration with cobbler to handle provisioning. > > So you can probably just ignore node136 then. > > > The output by the command is > > > > 1 developer running > > 2 node3 running > > 3 node4 running > > 4 node5 running > > - ovirt-appliance shut off > > I see you have ovirt-appliance present which is version 0.92-1 of oVirt. > But you are currently running developer. Can you get rid of the older > version (0.91-1) and try only running 0.92-1? If there is a problem I'd > like to make sure it's in the latest version of the code. No sense in > debugging a version of the code that is out of date. > > > But surely there is the node 136 in the Hardware Pool named Test (child of > > default). > > So what should I do? > > If you don't see the other nodes running on node3, 4 or 5 it means they > are not actively running right now. It could be that the status fields in > the WUI are not correct. > > Can you sign onto the IRC channel on freenode.net? (The channel name is > #ovirt) It might be easier to figure this out if we worked over IRC > instead of email. > > Thanks, > > Perry From mmorsi at redhat.com Tue Sep 2 01:18:17 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Mon, 01 Sep 2008 21:18:17 -0400 Subject: [Ovirt-devel] [PATCH] Fixes to broken tests (1/2) In-Reply-To: <48BB0B43.2070807@redhat.com> References: <1220215846-28759-1-git-send-email-mmorsi@redhat.com> <48BB0B43.2070807@redhat.com> Message-ID: <48BC9459.2000605@redhat.com> Alan Pevec wrote: >> @@ -114,12 +114,14 @@ if File.exists? File.dirname(__FILE__) + >> '/../selenium.rb' >> >> "selenium.isElementPresent(\"//div[@id='vm_action_results']/div[3]/div/div[2]/a\")", >> >> 10000) >> @browser.click >> "//div[@id='vm_action_results']/div[3]/div/div[2]/a" >> + sleep 5 # give vm time to start > > Why is sleep needed here at all if wait_for_condition below is > expecting 'running' to show up? > In general, using sleep for synchronization is wrong, although it > might seem to work. As far as I can tell the vm tab doesn't get automatically updated via javascript when the state of a vm changes, thus I need to wait a little time and manually refresh the page before I check for the status. I could do an assertion on the backend, and check the actual vm table entry itself, but these are interface tests, thus assertions should be on interface components. > >> @browser.click "//div[@id='side']/ul/li/ul/li[1]/span/a" >> @browser.wait_for_condition( >> - >> "selenium.isElementPresent(\"//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div\")", >> + >> "selenium.isElementPresent(\"//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div\") && " + >> + "selenium.getText(\"//table[@id='vms_grid']/tbody/tr[" >> + (num_vms.to_i + 1).to_s + "]/td[7]/div\") == \"running\"", >> 20000) >> - assert_equal("running", >> - @browser.get_text("//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div")) >> + #assert_equal("running", >> + #@browser.get_text("//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div")) > > What happens if wait_for_condition times out? Will selenium raise an > exception, failing the test or it just continues? If latter, you need > to keep the assert. > In general, if removing lines, just delete them instead of commenting, > we have git to keep the history. Selenium raises an exception when wait_for_condition times out and the test fails so the assertion can be safely removed. My bad on the commenting, just code I forgot to remove, will keep it in mind in the future. > >> # stop / destroy vm >> @browser.click "//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[1]/div/input" >> @@ -128,12 +130,14 @@ if File.exists? File.dirname(__FILE__) + >> '/../selenium.rb' >> >> "selenium.isElementPresent(\"//div[@id='vm_action_results']/div[3]/div/div[2]/a\")", >> >> 10000) >> @browser.click >> "//div[@id='vm_action_results']/div[3]/div/div[2]/a" >> + sleep 5 # give vm time to stop > > same questions as above > >> @browser.click "//div[@id='side']/ul/li/ul/li[1]/span/a" >> @browser.wait_for_condition( >> - >> "selenium.isElementPresent(\"//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div\")", >> + >> "selenium.isElementPresent(\"//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div\") && " + >> + "selenium.getText(\"//table[@id='vms_grid']/tbody/tr[" >> + (num_vms.to_i + 1).to_s + "]/td[7]/div\") == \"stopped\"", >> 20000) >> - assert_equal("stopped", >> - @browser.get_text("//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div")) >> + #assert_equal("stopped", >> + #@browser.get_text("//table[@id='vms_grid']/tbody/tr[" + >> (num_vms.to_i + 1).to_s + "]/td[7]/div")) > From clalance at redhat.com Tue Sep 2 08:37:10 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 2 Sep 2008 10:37:10 +0200 Subject: [Ovirt-devel] [PATCH]: Minor cleanup of DEBUG statements in ovirt-identify-node Message-ID: <1220344631-3908-1-git-send-email-clalance@redhat.com> Compiling ovirt-identify-node on x86_64 results in a warning about size_t; this patch fixes them up so it will work on both i386 and x86_64. From clalance at redhat.com Tue Sep 2 08:37:11 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 2 Sep 2008 10:37:11 +0200 Subject: [Ovirt-devel] [PATCH]: Minor cleanup of DEBUG statements in ovirt-identify-node In-Reply-To: <1220344631-3908-1-git-send-email-clalance@redhat.com> References: <1220344631-3908-1-git-send-email-clalance@redhat.com> Message-ID: <1220344631-3908-2-git-send-email-clalance@redhat.com> Minor cleanup of the DEBUG print statements in ovirt-identify-node. Signed-off-by: Chris Lalancette diff --git a/ovirt-managed-node/ovirt-identify-node/comm.c b/ovirt-managed-node/ovirt-identify-node/comm.c index 16dc3b8..ee5e174 100644 --- a/ovirt-managed-node/ovirt-identify-node/comm.c +++ b/ovirt-managed-node/ovirt-identify-node/comm.c @@ -35,14 +35,14 @@ saferead(int fd, char *buf, size_t count) len_left = count; - DEBUG("Begin saferead(%d, %p, %d)\n", fd, buf, count); + DEBUG("Begin saferead(%d, %p, %zd)\n", fd, buf, count); while (!done) { DEBUG("Before read(%d,%p,%d)\n", fd, buf + offset, len_left); bytes = read(fd, buf + offset, len_left); - DEBUG("After read: bytes=%d\n", bytes); + DEBUG("After read: bytes=%zd\n", bytes); if (bytes == 0) { done = 1; @@ -56,7 +56,7 @@ saferead(int fd, char *buf, size_t count) done = 1; } - DEBUG("End of decision loop: offset=%d, len_left=%dl, done=%d\n", + DEBUG("End of decision loop: offset=%zd, len_left=%dl, done=%d\n", offset, len_left, done); } From clalance at redhat.com Tue Sep 2 08:38:56 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 2 Sep 2008 10:38:56 +0200 Subject: [Ovirt-devel] [PATCH]: Fix up handling of blank UUID's in host-browser Message-ID: <1220344736-3970-1-git-send-email-clalance@redhat.com> Fix a small bug in the handling of blank UUID's in host-browser. Signed-off-by: Chris Lalancette diff --git a/wui/src/host-browser/host-browser.rb b/wui/src/host-browser/host-browser.rb index 881b2ae..d800688 100755 --- a/wui/src/host-browser/host-browser.rb +++ b/wui/src/host-browser/host-browser.rb @@ -110,7 +110,7 @@ class HostBrowser nic_info << nic else - raise Exception.new("ERRINFO! Excepted key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]/ + raise Exception.new("ERRINFO! Expected key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]*/ key, value = info.split("=") From clalance at redhat.com Tue Sep 2 08:40:54 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 2 Sep 2008 10:40:54 +0200 Subject: [Ovirt-devel] [PATCH]: Remove bogus iptables physdev iptables rule in ovirt init script Message-ID: <1220344854-3996-1-git-send-email-clalance@redhat.com> Remove the setting up of the physdev-is-bridged rule in the ovirt init script. This is now being properly handled by the ovirt-host-creator %post section. Signed-off-by: Chris Lalancette diff --git a/ovirt-managed-node/scripts/ovirt b/ovirt-managed-node/scripts/ovirt index ba1f20c..232da49 100644 --- a/ovirt-managed-node/scripts/ovirt +++ b/ovirt-managed-node/scripts/ovirt @@ -11,10 +11,6 @@ . /etc/init.d/ovirt-functions start() { - # Regardless of how iptables is configured, we always need the physdev bridge, - # and it needs to be at the front of the forward chain - iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT - krb5_conf=/etc/krb5.conf krb5_tab=/etc/libvirt/krb5.tab # retrieve config from local oVirt partition if available From clalance at redhat.com Tue Sep 2 08:41:46 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 2 Sep 2008 10:41:46 +0200 Subject: [Ovirt-devel] [PATCH]: Remove some commented out code in the ovirt-awake script Message-ID: <1220344906-4020-1-git-send-email-clalance@redhat.com> Just remove a little commented out code in ovirt-awake. Signed-off-by: Chris Lalancette diff --git a/ovirt-managed-node/scripts/ovirt-awake b/ovirt-managed-node/scripts/ovirt-awake index fc03c9a..7c1225a 100644 --- a/ovirt-managed-node/scripts/ovirt-awake +++ b/ovirt-managed-node/scripts/ovirt-awake @@ -43,8 +43,6 @@ function receive-text () { } start () { -# find-server identify tcp - connect-to-server receive-text From clalance at redhat.com Tue Sep 2 08:43:15 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 2 Sep 2008 10:43:15 +0200 Subject: [Ovirt-devel] [PATCH]: Exactly match the bridge in create_wui_appliance Message-ID: <1220344995-4050-1-git-send-email-clalance@redhat.com> Fix up the awk script to *exactly* match the bridge we are looking for. This is an issue if you happen to have multiple bridges up, like ovirtbr0, ovirtbr1, and now the script basically scribbles over them when looking for things. Signed-off-by: Chris Lalancette diff --git a/wui-appliance/create-wui-appliance.sh b/wui-appliance/create-wui-appliance.sh index 2527675..d68b009 100755 --- a/wui-appliance/create-wui-appliance.sh +++ b/wui-appliance/create-wui-appliance.sh @@ -221,7 +221,7 @@ fi # Remove old bridge device if it exists sed -i "/# $BRIDGENAME/d" /etc/rc.d/rc.local old_bridge=$(brctl show \ - | awk -v BRIDGENAME=$BRIDGENAME '$1~BRIDGENAME {print $4}') + | awk -v BRIDGENAME=$BRIDGENAME '$1==BRIDGENAME {print $4}') if [ -n "$old_bridge" ]; then echo "Removing old bridge $old_bridge" ifconfig $old_bridge down From mmorsi at redhat.com Tue Sep 2 09:35:00 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Tue, 2 Sep 2008 05:35:00 -0400 Subject: [Ovirt-devel] [PATCH] added ability to reprovision vm via edit vm form Message-ID: <1220348100-10281-1-git-send-email-mmorsi@redhat.com> --- wui/src/app/controllers/vm_controller.rb | 29 +++++++++++++++++------------ wui/src/app/views/vm/_form.rhtml | 2 +- 2 files changed, 18 insertions(+), 13 deletions(-) diff --git a/wui/src/app/controllers/vm_controller.rb b/wui/src/app/controllers/vm_controller.rb index e55ec28..6d32427 100644 --- a/wui/src/app/controllers/vm_controller.rb +++ b/wui/src/app/controllers/vm_controller.rb @@ -193,6 +193,21 @@ class VmController < ApplicationController end protected + def _setup_provisioning + @provisioning_options = [[Vm::PXE_OPTION_LABEL, Vm::PXE_OPTION_VALUE], + [Vm::HD_OPTION_LABEL, Vm::HD_OPTION_VALUE]] + # FIXME add cobbler images too + begin + @provisioning_options += Cobbler::Profile.find.collect do |profile| + [profile.name + Vm::COBBLER_PROFILE_SUFFIX, + Vm::COBBLER_PREFIX + Vm::PROVISIONING_DELIMITER + + Vm::PROFILE_PREFIX + Vm::PROVISIONING_DELIMITER + profile.name] + end + rescue + #if cobbler doesn't respond/is misconfigured/etc just don't add profiles + end + end + def pre_new # if no vm_resource_pool is passed in, find (or auto-create) it based on hardware_pool_id unless params[:vm_resource_pool_id] @@ -229,18 +244,7 @@ class VmController < ApplicationController @perm_obj = @vm.vm_resource_pool @redir_controller = 'resources' @current_pool_id=@perm_obj.id - @provisioning_options = [[Vm::PXE_OPTION_LABEL, Vm::PXE_OPTION_VALUE], - [Vm::HD_OPTION_LABEL, Vm::HD_OPTION_VALUE]] - # FIXME add cobbler images too - begin - @provisioning_options += Cobbler::Profile.find.collect do |profile| - [profile.name + Vm::COBBLER_PROFILE_SUFFIX, - Vm::COBBLER_PREFIX + Vm::PROVISIONING_DELIMITER + - Vm::PROFILE_PREFIX + Vm::PROVISIONING_DELIMITER + profile.name] - end - rescue - #if cobbler doesn't respond/is misconfigured/etc just don't add profiles - end + _setup_provisioning end def pre_create params[:vm][:state] = Vm::STATE_PENDING @@ -267,6 +271,7 @@ class VmController < ApplicationController @perm_obj = @vm.vm_resource_pool @redir_obj = @vm @current_pool_id=@perm_obj.id + _setup_provisioning end def pre_vm_action pre_edit diff --git a/wui/src/app/views/vm/_form.rhtml b/wui/src/app/views/vm/_form.rhtml index 60ed003..0dfe940 100644 --- a/wui/src/app/views/vm/_form.rhtml +++ b/wui/src/app/views/vm/_form.rhtml @@ -8,7 +8,7 @@ <%= hidden_field_tag 'hardware_pool_id', @hardware_pool.id if @hardware_pool %> <%= text_field_with_label "Name:", "vm", "description", {:style=>"width:250px;"} %> - <%= select_with_label "Operating System:", 'vm', 'provisioning_and_boot_settings', @provisioning_options, :style=>"width:250px;" if create %> + <%= select_with_label "Operating System:", 'vm', 'provisioning_and_boot_settings', @provisioning_options, :style=>"width:250px;" %>
Resources
-- 1.5.4.1 From terashima.naoya at np.css.fujitsu.com Tue Sep 2 10:21:00 2008 From: terashima.naoya at np.css.fujitsu.com (Naoya Terashima) Date: Tue, 2 Sep 2008 19:21:00 +0900 Subject: [Ovirt-devel] The way of migration on oVirt WebUI Message-ID: <027f01c90ce5$98dcefb0$b16f210a@FMAFC020FC868C> Hi I'd like to do migration using oVirt WebUI(oVirt 0.91-1). Please let me know the how or useful page about it. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clalance at redhat.com Tue Sep 2 11:47:41 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 02 Sep 2008 13:47:41 +0200 Subject: [Ovirt-devel] The way of migration on oVirt WebUI In-Reply-To: <027f01c90ce5$98dcefb0$b16f210a@FMAFC020FC868C> References: <027f01c90ce5$98dcefb0$b16f210a@FMAFC020FC868C> Message-ID: <48BD27DD.1080200@redhat.com> Naoya Terashima wrote: > Hi > > I'd like to do migration using oVirt WebUI(oVirt 0.91-1). > Please let me know the how or useful page about it. Migration is not supported in 0.91-1. You'll have to upgrade to 0.92 to get that functionality. Assuming you do upgrade, there are a couple of different ways to migrate: 1) In an individual VM details pane, you can say "migrate to another host". This will migrate this VM to another suitable host. 2) In the Host pane, you can say "Clear Host", which basically means "Clear all running VMs off of this host, and don't put any more on here". The idea is that maybe you want to take a particular host down for maintenance. Chris Lalancette From dpierce at redhat.com Tue Sep 2 12:54:27 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Tue, 2 Sep 2008 08:54:27 -0400 Subject: [Ovirt-devel] Re: : Minor cleanup of DEBUG statements in ovirt-identify-node In-Reply-To: <1220344631-3908-2-git-send-email-clalance@redhat.com> References: <1220344631-3908-1-git-send-email-clalance@redhat.com> <1220344631-3908-2-git-send-email-clalance@redhat.com> Message-ID: <20080902125427.GA7606@redhat.com> +++ Chris Lalancette [02/09/08 10:37 +0200]: > Minor cleanup of the DEBUG print statements in ovirt-identify-node. > > Signed-off-by: Chris Lalancette > >diff --git a/ovirt-managed-node/ovirt-identify-node/comm.c b/ovirt-managed-node/ovirt-identify-node/comm.c >index 16dc3b8..ee5e174 100644 >--- a/ovirt-managed-node/ovirt-identify-node/comm.c >+++ b/ovirt-managed-node/ovirt-identify-node/comm.c >@@ -35,14 +35,14 @@ saferead(int fd, char *buf, size_t count) > > len_left = count; > >- DEBUG("Begin saferead(%d, %p, %d)\n", fd, buf, count); >+ DEBUG("Begin saferead(%d, %p, %zd)\n", fd, buf, count); > > while (!done) { > DEBUG("Before read(%d,%p,%d)\n", fd, buf + offset, len_left); > > bytes = read(fd, buf + offset, len_left); > >- DEBUG("After read: bytes=%d\n", bytes); >+ DEBUG("After read: bytes=%zd\n", bytes); > > if (bytes == 0) { > done = 1; >@@ -56,7 +56,7 @@ saferead(int fd, char *buf, size_t count) > done = 1; > } > >- DEBUG("End of decision loop: offset=%d, len_left=%dl, done=%d\n", >+ DEBUG("End of decision loop: offset=%zd, len_left=%dl, done=%d\n", > offset, len_left, done); > } > ACK. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dpierce at redhat.com Tue Sep 2 13:09:20 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Tue, 2 Sep 2008 09:09:20 -0400 Subject: [Ovirt-devel] Re: : Fix up handling of blank UUID's in host-browser In-Reply-To: <1220344736-3970-1-git-send-email-clalance@redhat.com> References: <1220344736-3970-1-git-send-email-clalance@redhat.com> Message-ID: <20080902130919.GB7606@redhat.com> +++ Chris Lalancette [02/09/08 10:38 +0200]: > Fix a small bug in the handling of blank UUID's in host-browser. > > Signed-off-by: Chris Lalancette > >diff --git a/wui/src/host-browser/host-browser.rb b/wui/src/host-browser/host-browser.rb >index 881b2ae..d800688 100755 >--- a/wui/src/host-browser/host-browser.rb >+++ b/wui/src/host-browser/host-browser.rb >@@ -110,7 +110,7 @@ class HostBrowser > nic_info << nic > else > >- raise Exception.new("ERRINFO! Excepted key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]/ >+ raise Exception.new("ERRINFO! Expected key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]*/ > > key, value = info.split("=") > > >_______________________________________________ >Ovirt-devel mailing list >Ovirt-devel at redhat.com >https://www.redhat.com/mailman/listinfo/ovirt-devel ACK. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From clalance at redhat.com Tue Sep 2 13:10:52 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 02 Sep 2008 15:10:52 +0200 Subject: [Ovirt-devel] Re: : Minor cleanup of DEBUG statements in ovirt-identify-node In-Reply-To: <20080902125427.GA7606@redhat.com> References: <1220344631-3908-1-git-send-email-clalance@redhat.com> <1220344631-3908-2-git-send-email-clalance@redhat.com> <20080902125427.GA7606@redhat.com> Message-ID: <48BD3B5C.2070903@redhat.com> Darryl L. Pierce wrote: > +++ Chris Lalancette [02/09/08 10:37 +0200]: >> Minor cleanup of the DEBUG print statements in ovirt-identify-node. >> >> Signed-off-by: Chris Lalancette ... > ACK. Thanks, committed. Chris Lalancette From clalance at redhat.com Tue Sep 2 13:11:11 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 02 Sep 2008 15:11:11 +0200 Subject: [Ovirt-devel] Re: : Fix up handling of blank UUID's in host-browser In-Reply-To: <20080902130919.GB7606@redhat.com> References: <1220344736-3970-1-git-send-email-clalance@redhat.com> <20080902130919.GB7606@redhat.com> Message-ID: <48BD3B6F.3090202@redhat.com> Darryl L. Pierce wrote: > +++ Chris Lalancette [02/09/08 10:38 +0200]: >> Fix a small bug in the handling of blank UUID's in host-browser. >> >> Signed-off-by: Chris Lalancette ... > ACK. > Thanks, committed. Chris Lalancette From sseago at redhat.com Tue Sep 2 13:39:25 2008 From: sseago at redhat.com (Scott Seago) Date: Tue, 02 Sep 2008 09:39:25 -0400 Subject: [Ovirt-devel] [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <1220348100-10281-1-git-send-email-mmorsi@redhat.com> References: <1220348100-10281-1-git-send-email-mmorsi@redhat.com> Message-ID: <48BD420D.7000004@redhat.com> Mohammed Morsi wrote: > --- > wui/src/app/controllers/vm_controller.rb | 29 +++++++++++++++++------------ > wui/src/app/views/vm/_form.rhtml | 2 +- > 2 files changed, 18 insertions(+), 13 deletions(-) > > diff --git a/wui/src/app/controllers/vm_controller.rb b/wui/src/app/controllers/vm_controller.rb > index e55ec28..6d32427 100644 > --- a/wui/src/app/controllers/vm_controller.rb > +++ b/wui/src/app/controllers/vm_controller.rb > @@ -267,6 +271,7 @@ class VmController < ApplicationController > @perm_obj = @vm.vm_resource_pool > @redir_obj = @vm > @current_pool_id=@perm_obj.id > + _setup_provisioning > end > def pre_vm_action > pre_edit > diff --git a/wui/src/app/views/vm/_form.rhtml b/wui/src/app/views/vm/_form.rhtml > index 60ed003..0dfe940 100644 > --- a/wui/src/app/views/vm/_form.rhtml > +++ b/wui/src/app/views/vm/_form.rhtml > @@ -8,7 +8,7 @@ > <%= hidden_field_tag 'hardware_pool_id', @hardware_pool.id if @hardware_pool %> > > <%= text_field_with_label "Name:", "vm", "description", {:style=>"width:250px;"} %> > - <%= select_with_label "Operating System:", 'vm', 'provisioning_and_boot_settings', @provisioning_options, :style=>"width:250px;" if create %> > + <%= select_with_label "Operating System:", 'vm', 'provisioning_and_boot_settings', @provisioning_options, :style=>"width:250px;" %> >
> >
Resources
> The UI needs to make it clear that changing the provisioning bits on a running VM will potentially wipe the contents of the current VM and reprovision from scratch. In addition, if the VM is currently running, should we provide the user an easy way to force an immediate reboot (so the provisioning can take effect). Currently we have a 'start VM now' button for creating VMs -- maybe for edit, we should provide the option to start/restart VM now. Also, we need to be careful in how we handle the boot device and cobbler profile fields. Currently cobbler profile is only set on create -- so the above won't actually register a new cobbler system (and what of the old cobbler system -- do we need to un-register it? There's also the automatic update of the boot device on successful boot -- I don't think the above will cause any problems with that though. Scott From slinabery at redhat.com Tue Sep 2 15:08:22 2008 From: slinabery at redhat.com (Steve Linabery) Date: Tue, 2 Sep 2008 10:08:22 -0500 Subject: [Ovirt-devel] [rich@annexia.org: Flash / haxe] In-Reply-To: <20080831130824.GD16710@redhat.com> References: <20080831130824.GD16710@redhat.com> Message-ID: <20080902150822.GA2749@redhat.com> On Sun, Aug 31, 2008 at 09:08:25AM -0400, Hugh O. Brock wrote: > ----- Forwarded message from Richard Jones ----- > > > Hugh: > > > > http://haxe.org/doc/intro > > > > Never heard of this before now, but this is some open source language > > thing which can generate Flash (.swf) as in this rather cute example: > > > > http://blog.haxe.org/entry/33 > > > > I know zip about it apart from this, but thought it might be > > interesting to investigate for oVirt. > > > > Update - well what do you know, written in OCaml :-) More on Wikipedia: > > > > http://en.wikipedia.org/wiki/HaXe > > > > Rich. > > > > -- > > Richard Jones > > Red Hat > > > ----- End forwarded message ----- > > Thought I would forward this on to the group. My understanding is that > we already have some version of open tools for generating .swf, but > it's always worth looking around. Steve? > > Take care, > --Hugh > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel That's an interesting project...especially if we needed to build something from the ground up. Thanks for forwarding that link. Steve From pmyers at redhat.com Tue Sep 2 16:23:26 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 02 Sep 2008 12:23:26 -0400 Subject: [Ovirt-devel] [PATCH]: Remove bogus iptables physdev iptables rule in ovirt init script In-Reply-To: <1220344854-3996-1-git-send-email-clalance@redhat.com> References: <1220344854-3996-1-git-send-email-clalance@redhat.com> Message-ID: <48BD687E.80502@redhat.com> Chris Lalancette wrote: > Remove the setting up of the physdev-is-bridged rule in the ovirt init script. > This is now being properly handled by the ovirt-host-creator %post section. > > Signed-off-by: Chris Lalancette ACK. For times when the ovirt-node is 'installed' on bare-metal F9, we'll have to provide an easy way for setting up bridges though which will include adding this iptables rule. Perry > diff --git a/ovirt-managed-node/scripts/ovirt b/ovirt-managed-node/scripts/ovirt > index ba1f20c..232da49 100644 > --- a/ovirt-managed-node/scripts/ovirt > +++ b/ovirt-managed-node/scripts/ovirt > @@ -11,10 +11,6 @@ > . /etc/init.d/ovirt-functions > > start() { > - # Regardless of how iptables is configured, we always need the physdev bridge, > - # and it needs to be at the front of the forward chain > - iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT > - > krb5_conf=/etc/krb5.conf > krb5_tab=/etc/libvirt/krb5.tab > # retrieve config from local oVirt partition if available > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Tue Sep 2 16:24:46 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 02 Sep 2008 12:24:46 -0400 Subject: [Ovirt-devel] [PATCH]: Remove some commented out code in the ovirt-awake script In-Reply-To: <1220344906-4020-1-git-send-email-clalance@redhat.com> References: <1220344906-4020-1-git-send-email-clalance@redhat.com> Message-ID: <48BD68CE.8090403@redhat.com> Chris Lalancette wrote: > Just remove a little commented out code in ovirt-awake. > > Signed-off-by: Chris Lalancette Trivial change, just push it :) Perry > diff --git a/ovirt-managed-node/scripts/ovirt-awake b/ovirt-managed-node/scripts/ovirt-awake > index fc03c9a..7c1225a 100644 > --- a/ovirt-managed-node/scripts/ovirt-awake > +++ b/ovirt-managed-node/scripts/ovirt-awake > @@ -43,8 +43,6 @@ function receive-text () { > } > > start () { > -# find-server identify tcp > - > connect-to-server > > receive-text > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Tue Sep 2 16:30:49 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 02 Sep 2008 12:30:49 -0400 Subject: [Ovirt-devel] [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48BD420D.7000004@redhat.com> References: <1220348100-10281-1-git-send-email-mmorsi@redhat.com> <48BD420D.7000004@redhat.com> Message-ID: <48BD6A39.8020209@redhat.com> Scott Seago wrote: > Mohammed Morsi wrote: >> --- >> wui/src/app/controllers/vm_controller.rb | 29 >> +++++++++++++++++------------ >> wui/src/app/views/vm/_form.rhtml | 2 +- >> 2 files changed, 18 insertions(+), 13 deletions(-) >> >> diff --git a/wui/src/app/controllers/vm_controller.rb >> b/wui/src/app/controllers/vm_controller.rb >> index e55ec28..6d32427 100644 >> --- a/wui/src/app/controllers/vm_controller.rb >> +++ b/wui/src/app/controllers/vm_controller.rb >> @@ -267,6 +271,7 @@ class VmController < ApplicationController >> @perm_obj = @vm.vm_resource_pool >> @redir_obj = @vm >> @current_pool_id=@perm_obj.id >> + _setup_provisioning >> end >> def pre_vm_action >> pre_edit >> diff --git a/wui/src/app/views/vm/_form.rhtml >> b/wui/src/app/views/vm/_form.rhtml >> index 60ed003..0dfe940 100644 >> --- a/wui/src/app/views/vm/_form.rhtml >> +++ b/wui/src/app/views/vm/_form.rhtml >> @@ -8,7 +8,7 @@ >> <%= hidden_field_tag 'hardware_pool_id', @hardware_pool.id if >> @hardware_pool %> >> >> <%= text_field_with_label "Name:", "vm", "description", >> {:style=>"width:250px;"} %> >> - <%= select_with_label "Operating System:", 'vm', >> 'provisioning_and_boot_settings', @provisioning_options, >> :style=>"width:250px;" if create %> >> + <%= select_with_label "Operating System:", 'vm', >> 'provisioning_and_boot_settings', @provisioning_options, >> :style=>"width:250px;" %> >>
>> >>
Resources
>> > > The UI needs to make it clear that changing the provisioning bits on a > running VM will potentially wipe the contents of the current VM and > reprovision from scratch. In addition, if the VM is currently running, > should we provide the user an easy way to force an immediate reboot (so > the provisioning can take effect). Currently we have a 'start VM now' > button for creating VMs -- maybe for edit, we should provide the option > to start/restart VM now. This is not always the case... This new UI for changing the provisioning could also be used to 'boot a rescue ISO' or something like that. In which case it's not going to blow away your existing disk. A rescue ISO in cobbler looks the same as an F9 install ISO... > Also, we need to be careful in how we handle the boot device and cobbler > profile fields. Currently cobbler profile is only set on create -- so > the above won't actually register a new cobbler system (and what of the > old cobbler system -- do we need to un-register it? There's also the > automatic update of the boot device on successful boot -- I don't think > the above will cause any problems with that though. Maybe we should treat editing the provisioning information as a create call. i.e. if you change the VM in this way it removes the exising vm and creates a new one. Would that work? If unregistration of a system is necessary we should make that happen in the create call in taskomatic for ALL creates. i.e. whenever create is called it should first try to delete the system record in cobbler (and fail silently if that record does not exist) and then create a new one. That will handle the reprovisioning case. Perry From mmorsi at redhat.com Tue Sep 2 17:43:13 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Tue, 02 Sep 2008 13:43:13 -0400 Subject: [Ovirt-devel] [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48BD6A39.8020209@redhat.com> References: <1220348100-10281-1-git-send-email-mmorsi@redhat.com> <48BD420D.7000004@redhat.com> <48BD6A39.8020209@redhat.com> Message-ID: <48BD7B31.1090804@redhat.com> Perry N. Myers wrote: > Scott Seago wrote: >> Mohammed Morsi wrote: >>> --- >>> wui/src/app/controllers/vm_controller.rb | 29 >>> +++++++++++++++++------------ >>> wui/src/app/views/vm/_form.rhtml | 2 +- >>> 2 files changed, 18 insertions(+), 13 deletions(-) >>> >>> diff --git a/wui/src/app/controllers/vm_controller.rb >>> b/wui/src/app/controllers/vm_controller.rb >>> index e55ec28..6d32427 100644 >>> --- a/wui/src/app/controllers/vm_controller.rb >>> +++ b/wui/src/app/controllers/vm_controller.rb >>> @@ -267,6 +271,7 @@ class VmController < ApplicationController >>> @perm_obj = @vm.vm_resource_pool >>> @redir_obj = @vm >>> @current_pool_id=@perm_obj.id >>> + _setup_provisioning >>> end >>> def pre_vm_action >>> pre_edit >>> diff --git a/wui/src/app/views/vm/_form.rhtml >>> b/wui/src/app/views/vm/_form.rhtml >>> index 60ed003..0dfe940 100644 >>> --- a/wui/src/app/views/vm/_form.rhtml >>> +++ b/wui/src/app/views/vm/_form.rhtml >>> @@ -8,7 +8,7 @@ >>> <%= hidden_field_tag 'hardware_pool_id', @hardware_pool.id if >>> @hardware_pool %> >>> >>> <%= text_field_with_label "Name:", "vm", "description", >>> {:style=>"width:250px;"} %> >>> - <%= select_with_label "Operating System:", 'vm', >>> 'provisioning_and_boot_settings', @provisioning_options, >>> :style=>"width:250px;" if create %> >>> + <%= select_with_label "Operating System:", 'vm', >>> 'provisioning_and_boot_settings', @provisioning_options, >>> :style=>"width:250px;" %> >>>
>>> >>>
Resources
>>> >> >> The UI needs to make it clear that changing the provisioning bits on >> a running VM will potentially wipe the contents of the current VM and >> reprovision from scratch. In addition, if the VM is currently >> running, should we provide the user an easy way to force an immediate >> reboot (so the provisioning can take effect). Currently we have a >> 'start VM now' button for creating VMs -- maybe for edit, we should >> provide the option to start/restart VM now. > > This is not always the case... This new UI for changing the > provisioning could also be used to 'boot a rescue ISO' or something > like that. In which case it's not going to blow away your existing > disk. A rescue ISO in cobbler looks the same as an F9 install ISO... > >> Also, we need to be careful in how we handle the boot device and >> cobbler profile fields. Currently cobbler profile is only set on >> create -- so the above won't actually register a new cobbler system >> (and what of the old cobbler system -- do we need to un-register it? >> There's also the automatic update of the boot device on successful >> boot -- I don't think the above will cause any problems with that >> though. Correct me if I'm wrong but upon submitting the edit vm form, vm.save! is invoked after which if you look at the database you will see the 'boot device' is updated and the 'provisioning' field is set to the correct cobbler profile. I'm not sure why we would have to unregister it (as opposed to just overwriting what profile is used), is there some reason why we should? (perhaps another system can't use the cobbler profile until its unregistered?) > > Maybe we should treat editing the provisioning information as a create > call. i.e. if you change the VM in this way it removes the exising vm > and creates a new one. Would that work? I'm not a huge fan of deleting / recreating as we have the need of history (for graphing and what not) and this might throw a monkey wrench into how we track that, eg we'd have to retain the old vm to lookup information about it and what not. > > If unregistration of a system is necessary we should make that happen > in the create call in taskomatic for ALL creates. i.e. whenever > create is called it should first try to delete the system record in > cobbler (and fail silently if that record does not exist) and then > create a new one. > > That will handle the reprovisioning case. > > Perry Just to make everything perfectly clear you are looking for the following additional requirements to be satisfied is addition to whats already there 1. On editing a vm, if a different boot device / provisioning method is selected, display a confirmation dialog that this _might _ overwrite the current vm if the user is not careful. Clicking 'ok' should cause the app to proceed as normal, clicking cancel should take the user back to the edit vm form. 2. When editing a vm, if it is stopped, provide the 'start now' checkbox, and if it is running provide a 'restart now' checkbox. Clicking either will register the appropriated event in the tasks table for task-o-matic to pick up. 3. If neccessary (pending questions above) perform additional steps to unregister / register cobbler profile for edited vm (besides just writing to the 'boot device' and 'provisioning' fields of the vm table, what else needs to be done for this? a new task in the tasks table?) -Mo From sseago at redhat.com Tue Sep 2 18:01:34 2008 From: sseago at redhat.com (Scott Seago) Date: Tue, 02 Sep 2008 14:01:34 -0400 Subject: [Ovirt-devel] [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48BD7B31.1090804@redhat.com> References: <1220348100-10281-1-git-send-email-mmorsi@redhat.com> <48BD420D.7000004@redhat.com> <48BD6A39.8020209@redhat.com> <48BD7B31.1090804@redhat.com> Message-ID: <48BD7F7E.8070209@redhat.com> Mohammed Morsi wrote: > Perry N. Myers wrote: > >> Scott Seago wrote: >> >>> Mohammed Morsi wrote: >>> >>>> --- >>>> wui/src/app/controllers/vm_controller.rb | 29 >>>> +++++++++++++++++------------ >>>> wui/src/app/views/vm/_form.rhtml | 2 +- >>>> 2 files changed, 18 insertions(+), 13 deletions(-) >>>> >>>> diff --git a/wui/src/app/controllers/vm_controller.rb >>>> b/wui/src/app/controllers/vm_controller.rb >>>> index e55ec28..6d32427 100644 >>>> --- a/wui/src/app/controllers/vm_controller.rb >>>> +++ b/wui/src/app/controllers/vm_controller.rb >>>> @@ -267,6 +271,7 @@ class VmController < ApplicationController >>>> @perm_obj = @vm.vm_resource_pool >>>> @redir_obj = @vm >>>> @current_pool_id=@perm_obj.id >>>> + _setup_provisioning >>>> end >>>> def pre_vm_action >>>> pre_edit >>>> diff --git a/wui/src/app/views/vm/_form.rhtml >>>> b/wui/src/app/views/vm/_form.rhtml >>>> index 60ed003..0dfe940 100644 >>>> --- a/wui/src/app/views/vm/_form.rhtml >>>> +++ b/wui/src/app/views/vm/_form.rhtml >>>> @@ -8,7 +8,7 @@ >>>> <%= hidden_field_tag 'hardware_pool_id', @hardware_pool.id if >>>> @hardware_pool %> >>>> >>>> <%= text_field_with_label "Name:", "vm", "description", >>>> {:style=>"width:250px;"} %> >>>> - <%= select_with_label "Operating System:", 'vm', >>>> 'provisioning_and_boot_settings', @provisioning_options, >>>> :style=>"width:250px;" if create %> >>>> + <%= select_with_label "Operating System:", 'vm', >>>> 'provisioning_and_boot_settings', @provisioning_options, >>>> :style=>"width:250px;" %> >>>>
>>>> >>>>
Resources
>>>> >>>> >>> The UI needs to make it clear that changing the provisioning bits on >>> a running VM will potentially wipe the contents of the current VM and >>> reprovision from scratch. In addition, if the VM is currently >>> running, should we provide the user an easy way to force an immediate >>> reboot (so the provisioning can take effect). Currently we have a >>> 'start VM now' button for creating VMs -- maybe for edit, we should >>> provide the option to start/restart VM now. >>> >> This is not always the case... This new UI for changing the >> provisioning could also be used to 'boot a rescue ISO' or something >> like that. In which case it's not going to blow away your existing >> disk. A rescue ISO in cobbler looks the same as an F9 install ISO... >> >> Right -- it's definitely not always the case -- but it is one of the common cases. >>> Also, we need to be careful in how we handle the boot device and >>> cobbler profile fields. Currently cobbler profile is only set on >>> create -- so the above won't actually register a new cobbler system >>> (and what of the old cobbler system -- do we need to un-register it? >>> There's also the automatic update of the boot device on successful >>> boot -- I don't think the above will cause any problems with that >>> though. >>> > Correct me if I'm wrong but upon submitting the edit vm form, vm.save! > is invoked after which if you look at the database you will see the > 'boot device' is updated and the 'provisioning' field is set to the > correct cobbler profile. I'm not sure why we would have to unregister it > (as opposed to just overwriting what profile is used), is there some > reason why we should? (perhaps another system can't use the cobbler > profile until its unregistered?) > > I"m not sure if cobbler systems can be edited like that. Either way we'd have to update the cobbler system -- either by deleting and recreating it, or by editing it. My main point was that the cobbler system is only currently created/modified at create_vm time. The issue here is that if we don't tell cobbler that this system needs a new profile, it will still use the old one. > >> Maybe we should treat editing the provisioning information as a create >> call. i.e. if you change the VM in this way it removes the exising vm >> and creates a new one. Would that work? >> > I'm not a huge fan of deleting / recreating as we have the need of > history (for graphing and what not) and this might throw a monkey wrench > into how we track that, eg we'd have to retain the old vm to lookup > information about it and what not. > > Well we could still use a 'create' call even if the db record isn't dropped. I think it would be cleaner to create a 'reprovision' task instead -- this task would do the same thing as the 'create_vm' task, except it would be a valid action on a stopped VM. So for a running vm, we'd want to: 1) stop VM 2) reprovision VM 3) start VM. For a stopped VM, all we'd need to do is issue the reprovision_vm call -- and when the VM is next started, it would get the new OS/rescue/etc. > >> If unregistration of a system is necessary we should make that happen >> in the create call in taskomatic for ALL creates. i.e. whenever >> create is called it should first try to delete the system record in >> cobbler (and fail silently if that record does not exist) and then >> create a new one. >> >> That will handle the reprovisioning case. >> >> Perry >> > > Just to make everything perfectly clear you are looking for the > following additional requirements to be satisfied is addition to whats > already there > 1. On editing a vm, if a different boot device / provisioning method is > selected, display a confirmation dialog that this _might _ overwrite the > current vm if the user is not careful. Clicking 'ok' should cause the > app to proceed as normal, clicking cancel should take the user back to > the edit vm form. > Something like this -- I'm not even sure we need a confirmation dialog -- it may be sufficient for the form itself to make this clear in the text surrounding the provisioning section. > 2. When editing a vm, if it is stopped, provide the 'start now' > checkbox, and if it is running provide a 'restart now' checkbox. > Clicking either will register the appropriated event in the tasks table > for task-o-matic to pick up. > Yes, I think so. Right now the 'start now' checkbox is only shown for creating VMs. For editing VMs it's more complex though, so I"m not sure exactly what we want, as there are 4 different scenarios: 1) VM stopped, provisioning unchanged: 2) VM running, provisioning unchanged 3) VM stopped, reprovisioning 4) VM running, reprovisioning There are also the other VM states (suspended, etc) which we wouldn't want to do anything with. so I think for the edit case we'd want to show a 'restart' checkbox if it's running, and show a 'start' checkbox if it's stopped. Upon save, we issue tasks as appropriate. If 'restart' is selected, we create both 'stop' and 'start' tasks -- if 'start' is selected, only the 'start' task. And the fun part: if we're reprovisioning, we need the 'reprovision' task included as well -- and this has to be submitted 'before' any start tasks. > 3. If neccessary (pending questions above) perform additional steps to > unregister / register cobbler profile for edited vm (besides just > writing to the 'boot device' and 'provisioning' fields of the vm table, > what else needs to be done for this? a new task in the tasks table?) > > Cobbler needs to be updated so that the cobbler system matches what we want installed. Currently this is only done for 'create_vm' actions -- so the new 'reprovision_vm' task suggested above would be the appropriate place to do this. > -Mo > Scott From imain at redhat.com Wed Sep 3 01:04:14 2008 From: imain at redhat.com (Ian Main) Date: Tue, 2 Sep 2008 18:04:14 -0700 Subject: [Ovirt-devel] VM Installation problem (and proposed solution) In-Reply-To: <48B79244.6090102@redhat.com> References: <48B6C226.80601@redhat.com> <20080828152639.GD26373@redhat.com> <48B79244.6090102@redhat.com> Message-ID: <20080902180414.23416986@tp.mains.net> On Fri, 29 Aug 2008 08:08:04 +0200 Chris Lalancette wrote: > Daniel P. Berrange wrote: > > On Thu, Aug 28, 2008 at 05:20:06PM +0200, Chris Lalancette wrote: > >> Hello all (Ian especially), > >> apevec pointed out a problem with installation of guests under oVirt. What > >> currently happens is that after you finish the installation of (say) Fedora in a > >> VM, the VM reboots, but then immediately PXE boots again. This is because we > >> haven't killed the guest and re-defined the XML to have the boot device be the > >> hard drive, like it should. > > > > You don't have to wait for installation to finish before re-defining the > > XML with hard drive as the boot device > > > > You can define the post-install XML config the moment the guest has booted. > > When it shuts down, libvirt will automatically switch over to the newly > > defined config. This is how virt-install handles it. > > Yes, true. The difference is because of the asynchronous nature of taskomatic, > we basically kick off the guest on the node, and then go on to do other things. > The next time we would hear anything about this guest is when host-status > eventually polled it and noticed it "shutoff" (even though we think it is > running). So then we would need to perform the heuristic of "if this was > install time, and the guest is now dead, restart it". Just doing all of this > out on the node will reduce our round-trips to the server, and do the whole > thing in a more timely fashion. That's why I think it is better to do this > whole thing remotely on the node. That could certainly work. Also once qpid is setup and working we'll get updates about the domain dying much sooner and could respond then if necessary. Sounds like the other method would be better however. Ian From apevec at redhat.com Wed Sep 3 09:37:21 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 03 Sep 2008 11:37:21 +0200 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs Message-ID: <48BE5AD1.9030201@redhat.com> I propose to rename oVirt package names as follows: ovirt-host-image -> ovirt-node-image ovirt-managed-node -> ovirt-node ovirt-wui -> ovirt-server (to be split later into one subpkg per daemon) and directory renames: ovirt-managed-node -> node/ ovirt-host-creator -> node/image wui -> server wui-appliance -> server/appliance Does anyone have an issue with the proposal? It's already too late for such restructuring, but we do it now or never... Complete patch is not that useful, so I'm not posting it (it's > 8MB) From berrange at redhat.com Wed Sep 3 09:39:37 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Sep 2008 10:39:37 +0100 Subject: [Ovirt-devel] VM Installation problem (and proposed solution) In-Reply-To: <48B79244.6090102@redhat.com> References: <48B6C226.80601@redhat.com> <20080828152639.GD26373@redhat.com> <48B79244.6090102@redhat.com> Message-ID: <20080903093937.GA20308@redhat.com> On Fri, Aug 29, 2008 at 08:08:04AM +0200, Chris Lalancette wrote: > Daniel P. Berrange wrote: > > On Thu, Aug 28, 2008 at 05:20:06PM +0200, Chris Lalancette wrote: > >> Hello all (Ian especially), > >> apevec pointed out a problem with installation of guests under oVirt. What > >> currently happens is that after you finish the installation of (say) Fedora in a > >> VM, the VM reboots, but then immediately PXE boots again. This is because we > >> haven't killed the guest and re-defined the XML to have the boot device be the > >> hard drive, like it should. > > > > You don't have to wait for installation to finish before re-defining the > > XML with hard drive as the boot device > > > > You can define the post-install XML config the moment the guest has booted. > > When it shuts down, libvirt will automatically switch over to the newly > > defined config. This is how virt-install handles it. > > Yes, true. The difference is because of the asynchronous nature of taskomatic, > we basically kick off the guest on the node, and then go on to do other things. > The next time we would hear anything about this guest is when host-status > eventually polled it and noticed it "shutoff" (even though we think it is > running). So then we would need to perform the heuristic of "if this was > install time, and the guest is now dead, restart it". Just doing all of this > out on the node will reduce our round-trips to the server, and do the whole > thing in a more timely fashion. That's why I think it is better to do this > whole thing remotely on the node. The trouble with this is that it does not map onto a libvirt API cleanly. The idea behind the AMQP binding was to map 1-to-1 onto the libvirt API and not invent oVirt specific constructs in the API. I think we need to come up with some way to perform this automatic reboot with different XML within the scope of the libvirt API. Not quite sure what that would mean though. Perhaps a new lifecycle action for the tag, to explicitly represent a 'destroy+restart' semantic. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From clalance at redhat.com Wed Sep 3 09:44:32 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 03 Sep 2008 11:44:32 +0200 Subject: [Ovirt-devel] VM Installation problem (and proposed solution) In-Reply-To: <20080903093937.GA20308@redhat.com> References: <48B6C226.80601@redhat.com> <20080828152639.GD26373@redhat.com> <48B79244.6090102@redhat.com> <20080903093937.GA20308@redhat.com> Message-ID: <48BE5C80.1020202@redhat.com> Daniel P. Berrange wrote: >> Yes, true. The difference is because of the asynchronous nature of taskomatic, >> we basically kick off the guest on the node, and then go on to do other things. >> The next time we would hear anything about this guest is when host-status >> eventually polled it and noticed it "shutoff" (even though we think it is >> running). So then we would need to perform the heuristic of "if this was >> install time, and the guest is now dead, restart it". Just doing all of this >> out on the node will reduce our round-trips to the server, and do the whole >> thing in a more timely fashion. That's why I think it is better to do this >> whole thing remotely on the node. > > The trouble with this is that it does not map onto a libvirt API cleanly. > The idea behind the AMQP binding was to map 1-to-1 onto the libvirt API > and not invent oVirt specific constructs in the API. I think we need to > come up with some way to perform this automatic reboot with different XML > within the scope of the libvirt API. Not quite sure what that would mean > though. Perhaps a new lifecycle action for the tag, to explicitly > represent a 'destroy+restart' semantic. Hm, but I'm confused. While I know we definitely wanted to implement all of the libvirt calls in the AMQP bindings (so it could be re-used), I was pretty sure we were going to have custom oVirt methods anyway (Ian, am I right here?). That being said, I'm not against having a new lifecycle action for ; that would make life easier for virt-install too, I would imagine. Chris Lalancette From berrange at redhat.com Wed Sep 3 09:51:09 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Sep 2008 10:51:09 +0100 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs In-Reply-To: <48BE5AD1.9030201@redhat.com> References: <48BE5AD1.9030201@redhat.com> Message-ID: <20080903095109.GD20308@redhat.com> On Wed, Sep 03, 2008 at 11:37:21AM +0200, Alan Pevec wrote: > I propose to rename oVirt package names as follows: > > ovirt-host-image -> ovirt-node-image > ovirt-managed-node -> ovirt-node > ovirt-wui -> ovirt-server (to be split later into one subpkg per daemon) > > and directory renames: > > ovirt-managed-node -> node/ > ovirt-host-creator -> node/image > wui -> server > wui-appliance -> server/appliance > > Does anyone have an issue with the proposal? > It's already too late for such restructuring, but we do it now or never... IMHO, rather than just rename the directories in GIT you should create separate repos for each of those 4 top level directories. There's no good reason to keep those pieces in the same repo. They're worked on by different people and we should enforce strong separation in the code repo, to ensure a stable versioned interfaces to be developed for any interaction between independant pieces. Otherwise things just get sloppy and you get into a mess like Xen, where every single piece of the entire infrastructure has to come from an exact matching release otherwise the ABIs are incompatible. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Wed Sep 3 09:59:25 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 03 Sep 2008 05:59:25 -0400 Subject: [Ovirt-devel] VM Installation problem (and proposed solution) In-Reply-To: <20080903093937.GA20308@redhat.com> References: <48B6C226.80601@redhat.com> <20080828152639.GD26373@redhat.com> <48B79244.6090102@redhat.com> <20080903093937.GA20308@redhat.com> Message-ID: <48BE5FFD.1010300@redhat.com> Daniel P. Berrange wrote: > On Fri, Aug 29, 2008 at 08:08:04AM +0200, Chris Lalancette wrote: >> Daniel P. Berrange wrote: >>> On Thu, Aug 28, 2008 at 05:20:06PM +0200, Chris Lalancette wrote: >>>> Hello all (Ian especially), >>>> apevec pointed out a problem with installation of guests under oVirt. What >>>> currently happens is that after you finish the installation of (say) Fedora in a >>>> VM, the VM reboots, but then immediately PXE boots again. This is because we >>>> haven't killed the guest and re-defined the XML to have the boot device be the >>>> hard drive, like it should. >>> You don't have to wait for installation to finish before re-defining the >>> XML with hard drive as the boot device >>> >>> You can define the post-install XML config the moment the guest has booted. >>> When it shuts down, libvirt will automatically switch over to the newly >>> defined config. This is how virt-install handles it. >> Yes, true. The difference is because of the asynchronous nature of taskomatic, >> we basically kick off the guest on the node, and then go on to do other things. >> The next time we would hear anything about this guest is when host-status >> eventually polled it and noticed it "shutoff" (even though we think it is >> running). So then we would need to perform the heuristic of "if this was >> install time, and the guest is now dead, restart it". Just doing all of this >> out on the node will reduce our round-trips to the server, and do the whole >> thing in a more timely fashion. That's why I think it is better to do this >> whole thing remotely on the node. > > The trouble with this is that it does not map onto a libvirt API cleanly. > The idea behind the AMQP binding was to map 1-to-1 onto the libvirt API > and not invent oVirt specific constructs in the API. I think we need to > come up with some way to perform this automatic reboot with different XML > within the scope of the libvirt API. Not quite sure what that would mean > though. Perhaps a new lifecycle action for the tag, to explicitly > represent a 'destroy+restart' semantic. I agree with you that solving this in a libvirt way would be better (I like the destroy+restart semantic idea that seems very clean). However, I do think that not every ovirt action will be able to be a 1-1 map with libvirt and we might need ovirt specific AMQP calls. For example, libvirt doesn't know anything about a call like "set the collectd performance gathering interval to 5 minutes" or "reboot the physical node" I'm sure there will be other things that also will not fit into libvirt. So what I'm thinking is that we need libvirt-qpid and ovirt-qpid. Does this make sense? But as for adding the new lifecycle action for on-reboot, if you think that is the best way to solve this problem then this is what we should do. Let me know how that proceeds. Thanks, Perry From berrange at redhat.com Wed Sep 3 10:04:17 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Sep 2008 11:04:17 +0100 Subject: [Ovirt-devel] VM Installation problem (and proposed solution) In-Reply-To: <48BE5C80.1020202@redhat.com> References: <48B6C226.80601@redhat.com> <20080828152639.GD26373@redhat.com> <48B79244.6090102@redhat.com> <20080903093937.GA20308@redhat.com> <48BE5C80.1020202@redhat.com> Message-ID: <20080903100417.GE20308@redhat.com> On Wed, Sep 03, 2008 at 11:44:32AM +0200, Chris Lalancette wrote: > Daniel P. Berrange wrote: > >> Yes, true. The difference is because of the asynchronous nature of taskomatic, > >> we basically kick off the guest on the node, and then go on to do other things. > >> The next time we would hear anything about this guest is when host-status > >> eventually polled it and noticed it "shutoff" (even though we think it is > >> running). So then we would need to perform the heuristic of "if this was > >> install time, and the guest is now dead, restart it". Just doing all of this > >> out on the node will reduce our round-trips to the server, and do the whole > >> thing in a more timely fashion. That's why I think it is better to do this > >> whole thing remotely on the node. > > > > The trouble with this is that it does not map onto a libvirt API cleanly. > > The idea behind the AMQP binding was to map 1-to-1 onto the libvirt API > > and not invent oVirt specific constructs in the API. I think we need to > > come up with some way to perform this automatic reboot with different XML > > within the scope of the libvirt API. Not quite sure what that would mean > > though. Perhaps a new lifecycle action for the tag, to explicitly > > represent a 'destroy+restart' semantic. > > Hm, but I'm confused. While I know we definitely wanted to implement all of the > libvirt calls in the AMQP bindings (so it could be re-used), I was pretty sure > we were going to have custom oVirt methods anyway (Ian, am I right here?). Well there's several different aspects to this. I expect there to be 2 or even 3 separate, independant schemas implemented by the agent. A libvirt schema, a collectd / monitoring schema, and possibly an oVirt specific schema. We should aim to put everything in the generic schemas and only resort to using the oVirt specific schema if we really do not have any other choice. We shouldn't do a oVirt specific schema just because it is 'easy' in the short term - that leads to long term maintainence pain. For this particular problem, I rather hope we could find a way todo it within the scope of libvirt because its a quite a reasonable action to want todo and has nothing specific to oVirt about it Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Wed Sep 3 10:08:15 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 03 Sep 2008 06:08:15 -0400 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs In-Reply-To: <20080903095109.GD20308@redhat.com> References: <48BE5AD1.9030201@redhat.com> <20080903095109.GD20308@redhat.com> Message-ID: <48BE620F.3000303@redhat.com> Daniel P. Berrange wrote: > On Wed, Sep 03, 2008 at 11:37:21AM +0200, Alan Pevec wrote: >> I propose to rename oVirt package names as follows: >> >> ovirt-host-image -> ovirt-node-image >> ovirt-managed-node -> ovirt-node >> ovirt-wui -> ovirt-server (to be split later into one subpkg per daemon) >> >> and directory renames: >> >> ovirt-managed-node -> node/ >> ovirt-host-creator -> node/image >> wui -> server >> wui-appliance -> server/appliance >> >> Does anyone have an issue with the proposal? >> It's already too late for such restructuring, but we do it now or never... > > IMHO, rather than just rename the directories in GIT you should create > separate repos for each of those 4 top level directories. There's no > good reason to keep those pieces in the same repo. They're worked on > by different people and we should enforce strong separation in the code > repo, to ensure a stable versioned interfaces to be developed for any > interaction between independant pieces. Otherwise things just get sloppy > and you get into a mess like Xen, where every single piece of the entire > infrastructure has to come from an exact matching release otherwise the > ABIs are incompatible. Dan, I'm not opposed to having separate repos for: ovirt-node ovirt-server-suite ovirt-node-image ovirt-appliance Though it does change our build environment drastically since the notion of 'build-all' completely breaks. Any suggestions for how we should incorporate build-all into this new layout? Perry From berrange at redhat.com Wed Sep 3 10:15:32 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Sep 2008 11:15:32 +0100 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs In-Reply-To: <48BE620F.3000303@redhat.com> References: <48BE5AD1.9030201@redhat.com> <20080903095109.GD20308@redhat.com> <48BE620F.3000303@redhat.com> Message-ID: <20080903101532.GF20308@redhat.com> On Wed, Sep 03, 2008 at 06:08:15AM -0400, Perry N. Myers wrote: > Daniel P. Berrange wrote: > >On Wed, Sep 03, 2008 at 11:37:21AM +0200, Alan Pevec wrote: > >>I propose to rename oVirt package names as follows: > >> > >>ovirt-host-image -> ovirt-node-image > >>ovirt-managed-node -> ovirt-node > >>ovirt-wui -> ovirt-server (to be split later into one subpkg per daemon) > >> > >>and directory renames: > >> > >>ovirt-managed-node -> node/ > >>ovirt-host-creator -> node/image > >>wui -> server > >>wui-appliance -> server/appliance > >> > >>Does anyone have an issue with the proposal? > >>It's already too late for such restructuring, but we do it now or never... > > > >IMHO, rather than just rename the directories in GIT you should create > >separate repos for each of those 4 top level directories. There's no > >good reason to keep those pieces in the same repo. They're worked on > >by different people and we should enforce strong separation in the code > >repo, to ensure a stable versioned interfaces to be developed for any > >interaction between independant pieces. Otherwise things just get sloppy > >and you get into a mess like Xen, where every single piece of the entire > >infrastructure has to come from an exact matching release otherwise the > >ABIs are incompatible. > > Dan, > > I'm not opposed to having separate repos for: > > ovirt-node > ovirt-server-suite > ovirt-node-image > ovirt-appliance > > Though it does change our build environment drastically since the notion > of 'build-all' completely breaks. Any suggestions for how we should > incorporate build-all into this new layout? Don't have a build all. A developer working on the WUI has no need to build the managed node, and vica-verca. They can use pre-built RPMs of the bits they are not working on. Autobuild is specifically designed to be able to do end-to-end builds of a set of dependant packages, and report on them individually. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Wed Sep 3 10:19:58 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 03 Sep 2008 06:19:58 -0400 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs In-Reply-To: <20080903101532.GF20308@redhat.com> References: <48BE5AD1.9030201@redhat.com> <20080903095109.GD20308@redhat.com> <48BE620F.3000303@redhat.com> <20080903101532.GF20308@redhat.com> Message-ID: <48BE64CE.7070802@redhat.com> Daniel P. Berrange wrote: > On Wed, Sep 03, 2008 at 06:08:15AM -0400, Perry N. Myers wrote: >> Daniel P. Berrange wrote: >>> On Wed, Sep 03, 2008 at 11:37:21AM +0200, Alan Pevec wrote: >>>> I propose to rename oVirt package names as follows: >>>> >>>> ovirt-host-image -> ovirt-node-image >>>> ovirt-managed-node -> ovirt-node >>>> ovirt-wui -> ovirt-server (to be split later into one subpkg per daemon) >>>> >>>> and directory renames: >>>> >>>> ovirt-managed-node -> node/ >>>> ovirt-host-creator -> node/image >>>> wui -> server >>>> wui-appliance -> server/appliance >>>> >>>> Does anyone have an issue with the proposal? >>>> It's already too late for such restructuring, but we do it now or never... >>> IMHO, rather than just rename the directories in GIT you should create >>> separate repos for each of those 4 top level directories. There's no >>> good reason to keep those pieces in the same repo. They're worked on >>> by different people and we should enforce strong separation in the code >>> repo, to ensure a stable versioned interfaces to be developed for any >>> interaction between independant pieces. Otherwise things just get sloppy >>> and you get into a mess like Xen, where every single piece of the entire >>> infrastructure has to come from an exact matching release otherwise the >>> ABIs are incompatible. >> Dan, >> >> I'm not opposed to having separate repos for: >> >> ovirt-node >> ovirt-server-suite >> ovirt-node-image >> ovirt-appliance >> >> Though it does change our build environment drastically since the notion >> of 'build-all' completely breaks. Any suggestions for how we should >> incorporate build-all into this new layout? > > Don't have a build all. A developer working on the WUI has no need to build > the managed node, and vica-verca. They can use pre-built RPMs of the bits > they are not working on. Autobuild is specifically designed to be able to > do end-to-end builds of a set of dependant packages, and report on them > individually. Ok, right now everyone that works on oVirt uses build-all extensively... and most of those folks don't have access to an autobuild server to automate the process for them. So we need some replacement for build-all for people in the community who want to build from scratch instead of using prebuilt appliance. So just saying 'don't have build-all, use autobuild instead' is not really a valid option unless we replace it with something equally easy to use... Perry From rjones at redhat.com Wed Sep 3 10:23:47 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 3 Sep 2008 11:23:47 +0100 Subject: [Ovirt-devel] [rich@annexia.org: Flash / haxe] In-Reply-To: <20080831130824.GD16710@redhat.com> References: <20080831130824.GD16710@redhat.com> Message-ID: <20080903102347.GA15465@amd.home.annexia.org> On Sun, Aug 31, 2008 at 09:08:25AM -0400, Hugh O. Brock wrote: > Thought I would forward this on to the group. My understanding is that > we already have some version of open tools for generating .swf, but > it's always worth looking around. Steve? Are we using MTASC to build swf files from ActionScript? Anyhow, I built some packages of nako+haxe, here: https://bugzilla.redhat.com/show_bug.cgi?id=460779 https://bugzilla.redhat.com/show_bug.cgi?id=460780 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From berrange at redhat.com Wed Sep 3 10:26:30 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Sep 2008 11:26:30 +0100 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs In-Reply-To: <48BE64CE.7070802@redhat.com> References: <48BE5AD1.9030201@redhat.com> <20080903095109.GD20308@redhat.com> <48BE620F.3000303@redhat.com> <20080903101532.GF20308@redhat.com> <48BE64CE.7070802@redhat.com> Message-ID: <20080903102630.GG20308@redhat.com> On Wed, Sep 03, 2008 at 06:19:58AM -0400, Perry N. Myers wrote: > Daniel P. Berrange wrote: > >On Wed, Sep 03, 2008 at 06:08:15AM -0400, Perry N. Myers wrote: > >> > >>I'm not opposed to having separate repos for: > >> > >>ovirt-node > >>ovirt-server-suite > >>ovirt-node-image > >>ovirt-appliance > >> > >>Though it does change our build environment drastically since the notion > >>of 'build-all' completely breaks. Any suggestions for how we should > >>incorporate build-all into this new layout? > > > >Don't have a build all. A developer working on the WUI has no need to build > >the managed node, and vica-verca. They can use pre-built RPMs of the bits > >they are not working on. Autobuild is specifically designed to be able to > >do end-to-end builds of a set of dependant packages, and report on them > >individually. > > Ok, right now everyone that works on oVirt uses build-all extensively... > and most of those folks don't have access to an autobuild server to > automate the process for them. So we need some replacement for build-all > for people in the community who want to build from scratch instead of > using prebuilt appliance. > > So just saying 'don't have build-all, use autobuild instead' is not really > a valid option unless we replace it with something equally easy to use... Well the whole idea is to have stable, reliable interfaces between the modules. So if you want to work on / build the latest WUI code you can download the latest pre-built managed node binary from the ovirt.org website, and not have to worry about building something you're not interested in changing. In the scenario where you really do want to build all 4 pieces from scratch, its really not that hard to type 'build' in each of the 4 directories. If it was too troublesome, you could even create a shell script 'build-all' to run for i in node server appliance ; do (cd $i && build ) ; done It would be trivial to make the auto-build output available too - we could simply add a post-build stage to it which publishes nightly RPMs onto the public oVirt website FTP area, so latest binaries are always available for working against, As a comparison - consider someone working on Fedora - they don't want a build-all script for everything in Fedora - they only care about building the package they're playing with. Or someone working on virt-manager - they don't neeed a 'build-all' script which builds Xen, libvirt, and virt-amanger all in one go - they simply use a pre-built Xen & libvirt binary, and only focus on the bits they care about. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Wed Sep 3 10:37:16 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 03 Sep 2008 06:37:16 -0400 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs In-Reply-To: <20080903102630.GG20308@redhat.com> References: <48BE5AD1.9030201@redhat.com> <20080903095109.GD20308@redhat.com> <48BE620F.3000303@redhat.com> <20080903101532.GF20308@redhat.com> <48BE64CE.7070802@redhat.com> <20080903102630.GG20308@redhat.com> Message-ID: <48BE68DC.7050501@redhat.com> Daniel P. Berrange wrote: > On Wed, Sep 03, 2008 at 06:19:58AM -0400, Perry N. Myers wrote: >> Daniel P. Berrange wrote: >>> On Wed, Sep 03, 2008 at 06:08:15AM -0400, Perry N. Myers wrote: >>>> I'm not opposed to having separate repos for: >>>> >>>> ovirt-node >>>> ovirt-server-suite >>>> ovirt-node-image >>>> ovirt-appliance >>>> >>>> Though it does change our build environment drastically since the notion >>>> of 'build-all' completely breaks. Any suggestions for how we should >>>> incorporate build-all into this new layout? >>> Don't have a build all. A developer working on the WUI has no need to build >>> the managed node, and vica-verca. They can use pre-built RPMs of the bits >>> they are not working on. Autobuild is specifically designed to be able to >>> do end-to-end builds of a set of dependant packages, and report on them >>> individually. >> Ok, right now everyone that works on oVirt uses build-all extensively... >> and most of those folks don't have access to an autobuild server to >> automate the process for them. So we need some replacement for build-all >> for people in the community who want to build from scratch instead of >> using prebuilt appliance. >> >> So just saying 'don't have build-all, use autobuild instead' is not really >> a valid option unless we replace it with something equally easy to use... > > Well the whole idea is to have stable, reliable interfaces between the > modules. So if you want to work on / build the latest WUI code you can > download the latest pre-built managed node binary from the ovirt.org > website, and not have to worry about building something you're not > interested in changing. In the scenario where you really do want to build > all 4 pieces from scratch, its really not that hard to type 'build' in > each of the 4 directories. If it was too troublesome, you could even > create a shell script 'build-all' to run > > for i in node server appliance ; do (cd $i && build ) ; done > > It would be trivial to make the auto-build output available too - we could > simply add a post-build stage to it which publishes nightly RPMs onto the > public oVirt website FTP area, so latest binaries are always available > for working against, > > As a comparison - consider someone working on Fedora - they don't want > a build-all script for everything in Fedora - they only care about building > the package they're playing with. Or someone working on virt-manager - they > don't neeed a 'build-all' script which builds Xen, libvirt, and virt-amanger > all in one go - they simply use a pre-built Xen & libvirt binary, and only > focus on the bits they care about. That model works fine for: 1. Someone only working on the Server and can just use last available version of Node 2. Someone only working on the Node and can just use last available version of Server What about: Someone working on integration between Server and Node and needs to build both? build-all cannot be trivialized into a for loop that does build on all for separate git checkouts. It's more involved than that. We use a common tmp directory for yum cache to build the node and appliance. And RPMs generated from ovirt-node and ovirt-server would need to get placed into that cache for build of ovirt-node-image and ovirt-appliance. build-all.sh could be used as we use it now even with 4 separate repos underneath it, but the question becomes 'what repo does build-all.sh live in?' given that it is fairly complex. Hmm. Perhaps we need an 'ovirt' repo that contains build-all.sh and things like ovirt-release RPM build. Perry From berrange at redhat.com Wed Sep 3 10:48:34 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Sep 2008 11:48:34 +0100 Subject: [Ovirt-devel] RFC w/o PATCH: Renaming oVirt RPMs In-Reply-To: <48BE68DC.7050501@redhat.com> References: <48BE5AD1.9030201@redhat.com> <20080903095109.GD20308@redhat.com> <48BE620F.3000303@redhat.com> <20080903101532.GF20308@redhat.com> <48BE64CE.7070802@redhat.com> <20080903102630.GG20308@redhat.com> <48BE68DC.7050501@redhat.com> Message-ID: <20080903104834.GH20308@redhat.com> On Wed, Sep 03, 2008 at 06:37:16AM -0400, Perry N. Myers wrote: > > That model works fine for: > 1. Someone only working on the Server and can just use last available > version of Node > 2. Someone only working on the Node and can just use last available > version of Server > > What about: > Someone working on integration between Server and Node and needs to build > both? > > build-all cannot be trivialized into a for loop that does build on all for > separate git checkouts. It's more involved than that. We use a common > tmp directory for yum cache to build the node and appliance. And RPMs > generated from ovirt-node and ovirt-server would need to get placed into > that cache for build of ovirt-node-image and ovirt-appliance. That can be solved by using consistent conventions in the build scripts of each module. Have the build include a YUM config pointing to the nightly build YUM repo on ovirt.org, and have it use a local cache in some pre-defined (but overridable) location (eg, $HOME/ovirt-build/yum-cache) and also have it pull in RPMs from a local repo (eg $HOME/ovirt-build/local-repo). So by default it'll pull from the website, and if someone does do a local build of a dependant bit it'll get stuffed into the local YUM repo thus overriding the build on the website. If you ensure that the 'release' part of the RPM version numbers always contains something based on the timestamp, then package versioning will 'just work' between the local build and the website build eg eg, the nightly builds would be numbered like ovirt-node-1.0.0-1.auto1234556 and the local developer builds would be numbered like ovirt-node-1.0.0-1.fred123456 where 'fred' is their local username just to distinguish the RPM from an automated build. Since RPM ignores alpha characters in version comparisons, the embedded timestamp in the local build will appear newer than the latest nightly build. When the next nightly build occurrs, that will in turn compare newer, as you'd expect. And the next day the developer will automatically get that newer RPM from ovirt.org instead of their older local copy - until they do a newer build locally. And so on. > build-all.sh could be used as we use it now even with 4 separate repos > underneath it, but the question becomes 'what repo does build-all.sh live > in?' given that it is fairly complex. Hmm. Perhaps we need an 'ovirt' > repo that contains build-all.sh and things like ovirt-release RPM build. You could have an ovirt-build repo if there are some helper scripts that could be useful for developers doing builds, but at its most generic level each module's build process should be self-contained and just expect its dependancies to be pre-installed, or in an available YUM repo - so that it easily translates into an RPM %build script. Any scripts building across modules can just be optional convenience add-ons for developers Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From terashima.naoya at np.css.fujitsu.com Wed Sep 3 13:12:07 2008 From: terashima.naoya at np.css.fujitsu.com (Naoya Terashima) Date: Wed, 3 Sep 2008 22:12:07 +0900 Subject: [Ovirt-devel] The way of migration on oVirt WebUI References: <027f01c90ce5$98dcefb0$b16f210a@FMAFC020FC868C> <48BD27DD.1080200@redhat.com> Message-ID: <001001c90dc6$aac60680$b16f210a@FMAFC020FC868C> Hi Sorry,I couldn't locate individual VM details pane. I attach Screenshot so please tell me Where it is?? Thanks ----- Original Message ----- From: "Chris Lalancette" To: "Naoya Terashima" Cc: Sent: Tuesday, September 02, 2008 8:47 PM Subject: Re: [Ovirt-devel] The way of migration on oVirt WebUI > Naoya Terashima wrote: > > Hi > > > > I'd like to do migration using oVirt WebUI(oVirt 0.91-1). > > Please let me know the how or useful page about it. > > Migration is not supported in 0.91-1. You'll have to upgrade to 0.92 to get > that functionality. Assuming you do upgrade, there are a couple of different > ways to migrate: > > 1) In an individual VM details pane, you can say "migrate to another host". > This will migrate this VM to another suitable host. > > 2) In the Host pane, you can say "Clear Host", which basically means "Clear all > running VMs off of this host, and don't put any more on here". The idea is that > maybe you want to take a particular host down for maintenance. > > Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 103031 bytes Desc: not available URL: From pmyers at redhat.com Wed Sep 3 13:57:00 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 03 Sep 2008 09:57:00 -0400 Subject: [Ovirt-devel] The way of migration on oVirt WebUI In-Reply-To: <001001c90dc6$aac60680$b16f210a@FMAFC020FC868C> References: <027f01c90ce5$98dcefb0$b16f210a@FMAFC020FC868C> <48BD27DD.1080200@redhat.com> <001001c90dc6$aac60680$b16f210a@FMAFC020FC868C> Message-ID: <48BE97AC.60708@redhat.com> Naoya Terashima wrote: > Hi > > Sorry,I couldn't locate individual VM details pane. > I attach Screenshot so please tell me Where it is?? On the screen you were on, you just need to select one of the VMs by clicking on it. Then in the pane below which says "Select a VM above" the details for that VM will appear. Until you select a VM, there are no details to show. Thanks, Perry From slinabery at redhat.com Wed Sep 3 13:59:07 2008 From: slinabery at redhat.com (Steve Linabery) Date: Wed, 3 Sep 2008 08:59:07 -0500 Subject: [Ovirt-devel] [rich@annexia.org: Flash / haxe] In-Reply-To: <20080903102347.GA15465@amd.home.annexia.org> References: <20080831130824.GD16710@redhat.com> <20080903102347.GA15465@amd.home.annexia.org> Message-ID: <20080903135906.GA24495@redhat.com> On Wed, Sep 03, 2008 at 11:23:47AM +0100, Richard W.M. Jones wrote: > On Sun, Aug 31, 2008 at 09:08:25AM -0400, Hugh O. Brock wrote: > > Thought I would forward this on to the group. My understanding is that > > we already have some version of open tools for generating .swf, but > > it's always worth looking around. Steve? > > Are we using MTASC to build swf files from ActionScript? > Actually I have been using the mxmlc program that is included with the adobe open flex sdk. I don't see any haxe stuff or mtasc in f9 repo...I suspect either one would be easier to package for Fedora than the flex sdk. I'll check them out since I'm not wedded to mxmlc at this point. > Anyhow, I built some packages of nako+haxe, here: > > https://bugzilla.redhat.com/show_bug.cgi?id=460779 > https://bugzilla.redhat.com/show_bug.cgi?id=460780 > > Rich. > Thanks for the info, Steve From rjones at redhat.com Wed Sep 3 14:09:14 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 3 Sep 2008 15:09:14 +0100 Subject: [Ovirt-devel] [rich@annexia.org: Flash / haxe] In-Reply-To: <20080903135906.GA24495@redhat.com> References: <20080831130824.GD16710@redhat.com> <20080903102347.GA15465@amd.home.annexia.org> <20080903135906.GA24495@redhat.com> Message-ID: <20080903140914.GC14966@amd.home.annexia.org> On Wed, Sep 03, 2008 at 08:59:07AM -0500, Steve Linabery wrote: > Actually I have been using the mxmlc program that is included with > the adobe open flex sdk. > > I don't see any haxe stuff or mtasc in f9 repo...I suspect either > one would be easier to package for Fedora than the flex sdk. Yes, I guess MTASC upstream isn't active since they decided to switch to haxe (it's the same upstream people). Haxe should get into Fedora at some point - see the two review requests below - and then I'll backport to F-9. It ships in Debian at the moment so I guess there is no legal/licensing problem. > > https://bugzilla.redhat.com/show_bug.cgi?id=460779 > > https://bugzilla.redhat.com/show_bug.cgi?id=460780 I quite like the idea of targeting widgets, which is well-supported as of Firefox 3 & Safari, and may be partially supported by an IE plugin: http://en.wikipedia.org/wiki/Canvas_(HTML_element) http://excanvas.sourceforge.net/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From berrange at redhat.com Wed Sep 3 14:13:52 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 3 Sep 2008 15:13:52 +0100 Subject: [Ovirt-devel] [rich@annexia.org: Flash / haxe] In-Reply-To: <20080903140914.GC14966@amd.home.annexia.org> References: <20080831130824.GD16710@redhat.com> <20080903102347.GA15465@amd.home.annexia.org> <20080903135906.GA24495@redhat.com> <20080903140914.GC14966@amd.home.annexia.org> Message-ID: <20080903141352.GM20308@redhat.com> On Wed, Sep 03, 2008 at 03:09:14PM +0100, Richard W.M. Jones wrote: > On Wed, Sep 03, 2008 at 08:59:07AM -0500, Steve Linabery wrote: > > Actually I have been using the mxmlc program that is included with > > the adobe open flex sdk. > > > > I don't see any haxe stuff or mtasc in f9 repo...I suspect either > > one would be easier to package for Fedora than the flex sdk. > > Yes, I guess MTASC upstream isn't active since they decided to switch > to haxe (it's the same upstream people). > > Haxe should get into Fedora at some point - see the two review > requests below - and then I'll backport to F-9. It ships in Debian at > the moment so I guess there is no legal/licensing problem. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=460779 > > > https://bugzilla.redhat.com/show_bug.cgi?id=460780 > > I quite like the idea of targeting widgets, which is > well-supported as of Firefox 3 & Safari, and may be partially > supported by an IE plugin: Yes, having something which would work with Canvas, falling back to Flash if not available would be the near ideal scenario. That provides good windows support (effectively every windows machine has flash), and still allows use of state of the art standards compliant HTML for browsers with Canvas support Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From dpierce at redhat.com Wed Sep 3 14:14:32 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Wed, 3 Sep 2008 10:14:32 -0400 Subject: [Ovirt-devel] Re: Default configuration for a new managed node... In-Reply-To: <20080827174414.GA16498@redhat.com> References: <20080827140250.GD3920@redhat.com> <48B5904B.1050106@redhat.com> <20080827174414.GA16498@redhat.com> Message-ID: <20080903141432.GD22779@redhat.com> +++ Darryl L. Pierce [27/08/08 13:44 -0400]: >> Hm, Alan is the expert here, but I thought we already did that. There was >> something like "defaultdb" or something that was set up for this, and it already >> pulled the default configuration down. Maybe I'm misunderstanding what you >> mean, though. > > What we have now is a hardcoded configuration file that gets sent down to all > managed nodes on startup. The new controller, though, is replacing having an > actual file on disk that gets pulled: instead, it generates the configuration > at request time. > > So I _could_ have the generator return that configuration if it's given a mac > address that's not in the database. But I think we should be sure that's the > right thing to do. Here's a question that Alan can answer: If a node has a NIC that's not in the database, then the configuration that's returned will return nothing for deleting the files for that NIC in /etc/sysconfig/networking-scripts. So, when networking is restarted, those new NICs will come up with whatever local network configuration is present, yes? -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rjones at redhat.com Wed Sep 3 14:34:02 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 3 Sep 2008 15:34:02 +0100 Subject: [Ovirt-devel] [rich@annexia.org: Flash / haxe] In-Reply-To: <20080903141352.GM20308@redhat.com> References: <20080831130824.GD16710@redhat.com> <20080903102347.GA15465@amd.home.annexia.org> <20080903135906.GA24495@redhat.com> <20080903140914.GC14966@amd.home.annexia.org> <20080903141352.GM20308@redhat.com> Message-ID: <20080903143402.GE14966@amd.home.annexia.org> Be nice but ... MTASC doesn't support ActionScript 3. haXe can _generate_ AS3 as well as Flash directly, but won't compile AS3. So while this is all nice to have, it's not practical if we're going to reuse an external AS3 library such as http://teethgrinder.co.uk/open-flash-chart-2/ Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From sseago at redhat.com Wed Sep 3 15:04:00 2008 From: sseago at redhat.com (Scott Seago) Date: Wed, 3 Sep 2008 11:04:00 -0400 Subject: [Ovirt-devel] [PATCH] initial push of smart pool code. Message-ID: <1220454240-13940-1-git-send-email-sseago@redhat.com> This isn't complete, but I want to get it committed before the repo refactoring. This patch includes the controller refactoring needed for adding the new smart pool controllers, but I have not yet added any code to the new controllers. The models are in place for smart pools, but they aren't used anywhere yet. In addition, I've added a new DirectoryPool pool type that is used solely as a placeholder -- so that we can have a common root for all hardware and smart pools, and that we can organize smart pools by user. Since we need this pushed before the repo refactoring, this patch should be acked if it doesn't break anything. Separate review comments are, of course, welcome -- but anything that doesn't break the WUI will be fixed in a subsequent (post-repo-reorg) patch) Signed-off-by: Scott Seago --- wui/src/app/controllers/application.rb | 3 +- wui/src/app/controllers/hardware_controller.rb | 111 ++-------------- wui/src/app/controllers/pool_controller.rb | 132 ++++++++++++++++++++ wui/src/app/controllers/resources_controller.rb | 128 ++++--------------- wui/src/app/controllers/smart_pool_controller.rb | 22 ++++ wui/src/app/controllers/tree_controller.rb | 4 +- wui/src/app/models/directory_pool.rb | 60 +++++++++ wui/src/app/models/hardware_pool.rb | 18 +-- wui/src/app/models/host.rb | 3 + wui/src/app/models/pool.rb | 21 +++ wui/src/app/models/smart_pool.rb | 47 +++++++ wui/src/app/models/smart_pool_tag.rb | 37 ++++++ wui/src/app/models/storage_pool.rb | 3 + wui/src/app/models/vm.rb | 4 + wui/src/app/views/hardware/show_hosts.rhtml | 2 +- wui/src/app/views/hardware/show_storage.rhtml | 2 +- wui/src/app/views/layouts/_navigation_tabs.rhtml | 10 +- wui/src/app/views/resources/edit.rhtml | 4 +- wui/src/app/views/resources/quick_summary.rhtml | 20 ++-- wui/src/app/views/resources/show.rhtml | 12 +- wui/src/app/views/resources/show_tasks.rhtml | 4 +- wui/src/app/views/resources/show_users.rhtml | 2 +- wui/src/app/views/resources/show_vms.rhtml | 12 +- wui/src/db/migrate/017_add_smart_pools.rb | 62 +++++++++ wui/src/dutils/active_record_env.rb | 4 + wui/src/script/grant_admin_privileges | 4 +- .../betternestedset/lib/better_nested_set.rb | 37 ++++-- 27 files changed, 503 insertions(+), 265 deletions(-) create mode 100644 wui/src/app/controllers/pool_controller.rb create mode 100644 wui/src/app/controllers/smart_pool_controller.rb create mode 100644 wui/src/app/models/directory_pool.rb create mode 100644 wui/src/app/models/smart_pool.rb create mode 100644 wui/src/app/models/smart_pool_tag.rb create mode 100644 wui/src/db/migrate/017_add_smart_pools.rb diff --git a/wui/src/app/controllers/application.rb b/wui/src/app/controllers/application.rb index b95577a..3126748 100644 --- a/wui/src/app/controllers/application.rb +++ b/wui/src/app/controllers/application.rb @@ -29,8 +29,7 @@ class ApplicationController < ActionController::Base before_filter :pre_new, :only => [:new] before_filter :pre_create, :only => [:create] before_filter :pre_edit, :only => [:edit, :update, :destroy] - before_filter :pre_show, :only => [:show, :show_vms, :show_users, - :show_hosts, :show_storage] + before_filter :pre_show, :only => [:show] before_filter :authorize_admin, :only => [:new, :create, :edit, :update, :destroy] before_filter :is_logged_in diff --git a/wui/src/app/controllers/hardware_controller.rb b/wui/src/app/controllers/hardware_controller.rb index 7c1d916..091ce97 100644 --- a/wui/src/app/controllers/hardware_controller.rb +++ b/wui/src/app/controllers/hardware_controller.rb @@ -18,7 +18,7 @@ # also available at http://www.gnu.org/copyleft/gpl.html. # -class HardwareController < ApplicationController +class HardwareController < PoolController XML_OPTS = { :include => [ :storage_pools, :hosts, :quota ] @@ -31,10 +31,8 @@ class HardwareController < ApplicationController verify :method => [:post, :delete], :only => :destroy, :redirect_to => { :action => :list } - before_filter :pre_json, :only => [:vm_pools_json, :users_json, - :storage_volumes_json, :show_tasks, :tasks] - before_filter :pre_modify, :only => [:add_hosts, :move_hosts, - :add_storage, :move_storage, + before_filter :pre_modify, :only => [:add_hosts, :move_hosts, + :add_storage, :move_storage, :create_storage, :delete_storage] def index @@ -60,27 +58,6 @@ class HardwareController < ApplicationController end end - def show - set_perms(@perm_obj) - unless @can_view - flash[:notice] = 'You do not have permission to view this hardware pool: redirecting to top level' - respond_to do |format| - format.html { redirect_to :controller => "dashboard" } - format.xml { head :forbidden } - end - return - end - respond_to do |format| - format.html { - render :layout => 'tabs-and-content' if params[:ajax] - render :layout => false if params[:nolayout] - } - format.xml { - render :xml => @pool.to_xml(XML_OPTS) - } - end - end - def json_view_tree json_tree_internal(Permission::PRIV_VIEW, false) end @@ -121,11 +98,6 @@ class HardwareController < ApplicationController show end - def show_users - @roles = Permission::ROLES.keys - show - end - def show_hosts @hardware_pools = HardwarePool.find :all show @@ -145,53 +117,23 @@ class HardwareController < ApplicationController ["Host Task", "HostTask"], ["Storage Task", "StorageTask", "break"], ["Show All", ""]] - @task_states = [["Queued", Task::STATE_QUEUED], - ["Running", Task::STATE_RUNNING], - ["Paused", Task::STATE_PAUSED], - ["Finished", Task::STATE_FINISHED], - ["Failed", Task::STATE_FAILED], - ["Canceled", Task::STATE_CANCELED, "break"], - ["Show All", ""]] - params[:page]=1 - params[:sortname]="tasks.created_at" - params[:sortorder]="desc" - @tasks = tasks_internal - show - end - - def tasks - render :json => tasks_internal.to_json + super end def tasks_internal @task_type = params[:task_type] @task_type ||="" - @task_state = params[:task_state] - @task_state ||=Task::STATE_QUEUED - conditions = {} - conditions[:type] = @task_type unless @task_type.empty? - conditions[:state] = @task_state unless @task_state.empty? - find_opts = {:include => [:storage_pool, :host, :vm]} - find_opts[:conditions] = conditions unless conditions.empty? - attr_list = [] - attr_list << :id if params[:checkboxes] - attr_list += [:type_label, :task_obj, :action, :state, :user, :created_at, :args, :message] - json_hash(@pool.tasks, attr_list, [:all], find_opts) - end - - def quick_summary - pre_show - render :layout => 'selection' + super end def hosts_json if params[:exclude_host] - pre_json + pre_show hosts = @pool.hosts find_opts = {:conditions => ["id != ?", params[:exclude_host]]} include_pool = false elsif params[:id] - pre_json + pre_show hosts = @pool.hosts find_opts = {} include_pool = false @@ -219,14 +161,9 @@ class HardwareController < ApplicationController {:finder => 'call_finder', :conditions => ["type = 'VmResourcePool'"]}) end - def users_json - json_list(@pool.permissions, - [:grid_id, :uid, :user_role, :source]) - end - def storage_pools_json if params[:id] - pre_json + pre_show storage_pools = @pool.storage_pools find_opts = {} include_pool = false @@ -258,7 +195,7 @@ class HardwareController < ApplicationController def new @resource_type = params[:resource_type] @resource_ids = params[:resource_ids] - render :layout => 'popup' + super end def create @@ -293,10 +230,6 @@ class HardwareController < ApplicationController end end - def edit - render :layout => 'popup' - end - def update if params[:hardware_pool] # FIXME: For the REST API, we allow moving hosts/storage through @@ -455,28 +388,23 @@ class HardwareController < ApplicationController :alert => alert } } format.xml { head status } end - end + end - private + protected #filter methods def pre_new @pool = HardwarePool.new - @parent = Pool.find(params[:parent_id]) - @perm_obj = @parent - @current_pool_id=@parent.id + super end def pre_create # FIXME: REST and browsers send params differently. Should be fixed # in the views if params[:pool] @pool = HardwarePool.new(params[:pool]) - @parent = Pool.find(params[:parent_id]) else @pool = HardwarePool.new(params[:hardware_pool]) - @parent = Pool.find(params[:hardware_pool][:parent_id]) end - @perm_obj = @parent - @current_pool_id=@parent.id + super end def pre_edit @pool = HardwarePool.find(params[:id]) @@ -486,18 +414,7 @@ class HardwareController < ApplicationController end def pre_show @pool = HardwarePool.find(params[:id]) - @perm_obj = @pool - @current_pool_id=@pool.id - set_perms(@perm_obj) - unless @can_view - flash[:notice] = 'You do not have permission to view this Hardware Pool: redirecting to top level' - # FIXME: figure out the return type and render appropriately - redirect_to :action => 'list' - return - end - end - def pre_json - pre_show + super end def pre_modify pre_edit diff --git a/wui/src/app/controllers/pool_controller.rb b/wui/src/app/controllers/pool_controller.rb new file mode 100644 index 0000000..ce41701 --- /dev/null +++ b/wui/src/app/controllers/pool_controller.rb @@ -0,0 +1,132 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. +# + +class PoolController < ApplicationController + + before_filter :pre_show_pool, :only => [:show_vms, :show_users, + :show_hosts, :show_storage, + :users_json, :show_tasks, :tasks, + :vms_json, :vm_pools_json, + :storage_volumes_json, :quick_summary] + + def show + respond_to do |format| + format.html { + render :layout => 'tabs-and-content' if params[:ajax] + render :layout => false if params[:nolayout] + } + format.xml { + render :xml => @pool.to_xml(XML_OPTS) + } + end + end + + def quick_summary + render :layout => 'selection' + end + + # resource's users list page + def show_users + @roles = Permission::ROLES.keys + show + end + + def users_json + json_list(@pool.permissions, + [:grid_id, :uid, :user_role, :source]) + end + + def show_tasks + @task_states = [["Queued", Task::STATE_QUEUED], + ["Running", Task::STATE_RUNNING], + ["Paused", Task::STATE_PAUSED], + ["Finished", Task::STATE_FINISHED], + ["Failed", Task::STATE_FAILED], + ["Canceled", Task::STATE_CANCELED, "break"], + ["Show All", ""]] + params[:page]=1 + params[:sortname]="tasks.created_at" + params[:sortorder]="desc" + @tasks = tasks_internal + show + end + + def tasks + render :json => tasks_internal.to_json + end + + def tasks_internal + @task_state = params[:task_state] + @task_state ||=Task::STATE_QUEUED + conditions = {} + conditions[:type] = @task_type unless @task_type.empty? + conditions[:state] = @task_state unless @task_state.empty? + find_opts = {:include => [:storage_pool, :host, :vm]} + find_opts[:conditions] = conditions unless conditions.empty? + attr_list = [] + attr_list << :id if params[:checkboxes] + attr_list += [:type_label, :task_obj, :action, :state, :user, :created_at, :args, :message] + json_hash(@pool.tasks, attr_list, [:all], find_opts) + end + + def new + render :layout => 'popup' + end + + def edit + render :layout => 'popup' + end + + protected + def pre_new + @parent = Pool.find(params[:parent_id]) + @perm_obj = @parent + @redir_controller = @perm_obj.get_controller + @current_pool_id=@parent.id + end + def pre_create + #this is currently only true for the rest API for hardware pools + if params[:hardware_pool] + @parent = Pool.find(params[:hardware_pool][:parent_id]) + else + @parent = Pool.find(params[:parent_id]) + end + @perm_obj = @parent + @redir_controller = @perm_obj.get_controller + @current_pool_id=@parent.id + end + def pre_show_pool + pre_show + end + def pre_show + @perm_obj = @pool + @current_pool_id=@pool.id + set_perms(@perm_obj) + unless @can_view + flash[:notice] = 'You do not have permission to view this pool pool: redirecting to top level' + respond_to do |format| + format.html { redirect_to :controller => "dashboard" } + format.xml { head :forbidden } + end + return + end + end + +end diff --git a/wui/src/app/controllers/resources_controller.rb b/wui/src/app/controllers/resources_controller.rb index 5a8276c..a0a65a6 100644 --- a/wui/src/app/controllers/resources_controller.rb +++ b/wui/src/app/controllers/resources_controller.rb @@ -17,14 +17,12 @@ # MA 02110-1301, USA. A copy of the GNU General Public License is # also available at http://www.gnu.org/copyleft/gpl.html. -class ResourcesController < ApplicationController +class ResourcesController < PoolController def index list render :action => 'list' end - before_filter :pre_json, :only => [:vms_json, :users_json, - :show_tasks, :tasks] before_filter :pre_vm_actions, :only => [:vm_actions] # GETs should be safe (see http://www.w3.org/2001/tag/doc/whenToUseGet.html) @@ -49,17 +47,7 @@ class ResourcesController < ApplicationController ["Resume", VmTask::ACTION_RESUME_VM], ["Save", VmTask::ACTION_SAVE_VM], ["Restore", VmTask::ACTION_RESTORE_VM]] - if params[:ajax] - render :layout => 'tabs-and-content' - end - if params[:nolayout] - render :layout => false - end - end - - def quick_summary - pre_show - render :layout => 'selection' + super end # resource's vms list page @@ -73,81 +61,36 @@ class ResourcesController < ApplicationController show end - # resource's users list page - def show_users - @roles = Permission::ROLES.keys - show - end - - def show_tasks - @task_states = [["Queued", Task::STATE_QUEUED], - ["Running", Task::STATE_RUNNING], - ["Paused", Task::STATE_PAUSED], - ["Finished", Task::STATE_FINISHED], - ["Failed", Task::STATE_FAILED], - ["Canceled", Task::STATE_CANCELED, "break"], - ["Show All", ""]] - params[:page]=1 - params[:sortname]="tasks.created_at" - params[:sortorder]="desc" - @tasks = tasks_internal - show - end - - def tasks - render :json => tasks_internal.to_json - end - def tasks_internal + @task_type = "" @task_state = params[:task_state] - @task_state ||=Task::STATE_QUEUED - conditions = {} - conditions[:state] = @task_state unless @task_state.empty? - find_opts = {:include => [:storage_pool, :host, :vm]} - find_opts[:conditions] = conditions unless conditions.empty? - attr_list = [] - attr_list << :id if params[:checkboxes] - attr_list += [:type_label, :task_obj, :action, :state, :user, :created_at, :args, :message] - json_hash(@vm_resource_pool.tasks, attr_list, [:all], find_opts) + super end def vms_json - json_list(@vm_resource_pool.vms, + json_list(@pool.vms, [:id, :description, :uuid, :num_vcpus_allocated, :memory_allocated_in_mb, :vnic_mac_addr, :state, :id]) end - def users_json - json_list(@vm_resource_pool.permissions, - [:grid_id, :uid, :user_role, :source]) - end - - def new - render :layout => 'popup' - end - def create begin - @vm_resource_pool.create_with_parent(@parent) + @pool.create_with_parent(@parent) render :json => { :object => "vm_resource_pool", :success => true, :alert => "Virtual Machine Pool was successfully created." } rescue render :json => { :object => "vm_resource_pool", :success => false, - :errors => @vm_resource_pool.errors.localize_error_messages.to_a} + :errors => @pool.errors.localize_error_messages.to_a} end end - def edit - render :layout => 'popup' - end - def update begin - @vm_resource_pool.update_attributes!(params[:vm_resource_pool]) + @pool.update_attributes!(params[:vm_resource_pool]) render :json => { :object => "vm_resource_pool", :success => true, :alert => "Virtual Machine Pool was successfully modified." } rescue render :json => { :object => "vm_resource_pool", :success => false, - :errors => @vm_resource_pool.errors.localize_error_messages.to_a} + :errors => @pool.errors.localize_error_messages.to_a} end end @@ -174,7 +117,7 @@ class ResourcesController < ApplicationController end def destroy - if @vm_resource_pool.destroy + if @pool.destroy alert="Virtual Machine Pool was successfully deleted." success=true else @@ -192,7 +135,7 @@ class ResourcesController < ApplicationController @success_list = [] @failure_list = [] begin - @vm_resource_pool.transaction do + @pool.transaction do @vms.each do |vm| if vm.queue_action(@user, @action) @success_list << vm @@ -212,45 +155,30 @@ class ResourcesController < ApplicationController protected def pre_new - @vm_resource_pool = VmResourcePool.new - @parent = Pool.find(params[:parent_id]) - @perm_obj = @parent - @redir_controller = @perm_obj.get_controller - @current_pool_id=@parent.id + @pool = VmResourcePool.new + super end def pre_create - @vm_resource_pool = VmResourcePool.new(params[:vm_resource_pool]) - @parent = Pool.find(params[:parent_id]) - @perm_obj = @parent - @redir_controller = @perm_obj.get_controller - @current_pool_id=@parent.id - end - def pre_show - @vm_resource_pool = VmResourcePool.find(params[:id]) - @perm_obj = @vm_resource_pool - @current_pool_id=@vm_resource_pool.id - set_perms(@perm_obj) - @is_hwpool_admin = @vm_resource_pool.parent.can_modify(@user) - unless @can_view - flash[:notice] = 'You do not have permission to view this VM Resource Pool: redirecting to top level' - redirect_to :action => 'dashboard' - end + @pool = VmResourcePool.new(params[:vm_resource_pool]) + super end def pre_edit - @vm_resource_pool = VmResourcePool.find(params[:id]) - @parent = @vm_resource_pool.parent - @perm_obj = @vm_resource_pool.parent - @redir_obj = @vm_resource_pool - @current_pool_id=@vm_resource_pool.id + @pool = VmResourcePool.find(params[:id]) + @parent = @pool.parent + @perm_obj = @pool.parent + @redir_obj = @pool + @current_pool_id=@pool.id end - def pre_json - pre_show + def pre_show + @pool = VmResourcePool.find(params[:id]) + @is_hwpool_admin = @pool.parent.can_modify(@user) + super end def pre_vm_actions - @vm_resource_pool = VmResourcePool.find(params[:id]) - @parent = @vm_resource_pool.parent - @perm_obj = @vm_resource_pool - @redir_obj = @vm_resource_pool + @pool = VmResourcePool.find(params[:id]) + @parent = @pool.parent + @perm_obj = @pool + @redir_obj = @pool authorize_user end diff --git a/wui/src/app/controllers/smart_pool_controller.rb b/wui/src/app/controllers/smart_pool_controller.rb new file mode 100644 index 0000000..eb087a6 --- /dev/null +++ b/wui/src/app/controllers/smart_pool_controller.rb @@ -0,0 +1,22 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. +# + +class SmartPoolController < ApplicationController +end diff --git a/wui/src/app/controllers/tree_controller.rb b/wui/src/app/controllers/tree_controller.rb index c7dbe35..5ad8426 100644 --- a/wui/src/app/controllers/tree_controller.rb +++ b/wui/src/app/controllers/tree_controller.rb @@ -1,10 +1,10 @@ class TreeController < ApplicationController def fetch_nav - @pools = Pool.root.full_set_nested(:method => :json_hash_element) + @pools = HardwarePool.get_default_pool.full_set_nested(:method => :json_hash_element) end def fetch_json - render :json => Pool.root.full_set_nested(:method => :json_hash_element).to_json + render :json => HardwarePool.get_default_pool.full_set_nested(:method => :json_hash_element).to_json end end diff --git a/wui/src/app/models/directory_pool.rb b/wui/src/app/models/directory_pool.rb new file mode 100644 index 0000000..f62d980 --- /dev/null +++ b/wui/src/app/models/directory_pool.rb @@ -0,0 +1,60 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class DirectoryPool < Pool + + ROOT_NAME = "root" + HARDWARE_ROOT = "hardware" + SMART_ROOT = "users" + + def self.get_directory_root + self.root(:conditions=>"type='DirectoryPool'") + end + + def self.get_hardware_root + dir_root = get_directory_root + dir_root ? dir_root.named_child(HARDWARE_ROOT) : nil + end + + def self.get_smart_root + dir_root = get_directory_root + dir_root ? dir_root.named_child(SMART_ROOT) : nil + end + + def self.get_user_root(user) + smart_root = get_smart_root + smart_root ? smart_root.named_child(user) : nil + end + + def self.get_or_create_user_root(user) + user_root = get_user_root(user) + unless user_root + DirectoryPool.transaction do + user_root = DirectoryPool.new(:name => user) + user_root.create_with_parent(get_smart_root) + permission = Permission.new({:pool_id => user_root.id, + :uid => user, + :user_role => Permission::ROLE_SUPER_ADMIN}) + #we don't need save_with_new_children here since there are no children yet + permission.save! + end + end + end + +end diff --git a/wui/src/app/models/hardware_pool.rb b/wui/src/app/models/hardware_pool.rb index 5409862..160f663 100644 --- a/wui/src/app/models/hardware_pool.rb +++ b/wui/src/app/models/hardware_pool.rb @@ -19,6 +19,8 @@ class HardwarePool < Pool + DEFAULT_POOL_NAME = "default" + has_many :tasks, :dependent => :nullify def all_storage_volumes StorageVolume.find(:all, :include => {:storage_pool => :hardware_pool}, :conditions => "pools.id = #{id}") @@ -34,7 +36,8 @@ class HardwarePool < Pool # note: doesn't currently join w/ permissions def self.get_default_pool - self.root + hw_root = DirectoryPool.get_hardware_root + hw_root ? hw_root.named_child(DEFAULT_POOL_NAME) : nil end def create_with_resources(parent, resource_type= nil, resource_ids=[]) @@ -98,17 +101,4 @@ class HardwarePool < Pool return {:total => total, :labels => labels} end - def self.find_by_path(path) - segs = path.split("/") - unless segs.shift.empty? - raise "Path must be absolute, but is #{path}" - end - default_pool = get_default_pool - if segs.shift == default_pool.name - segs.inject(default_pool) do |pool, seg| - pool.sub_hardware_pools.find { |p| p.name == seg } if pool - end - end - end - end diff --git a/wui/src/app/models/host.rb b/wui/src/app/models/host.rb index 5b32653..3fc3abb 100644 --- a/wui/src/app/models/host.rb +++ b/wui/src/app/models/host.rb @@ -40,6 +40,9 @@ class Host < ActiveRecord::Base end end + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags + acts_as_xapian :texts => [ :hostname, :uuid, :hypervisor_type, :arch ], :values => [ [ :created_at, 0, "created_at", :date ], [ :updated_at, 1, "updated_at", :date ] ], diff --git a/wui/src/app/models/pool.rb b/wui/src/app/models/pool.rb index 6599c72..9d71fa5 100644 --- a/wui/src/app/models/pool.rb +++ b/wui/src/app/models/pool.rb @@ -42,12 +42,15 @@ class Pool < ActiveRecord::Base end end + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags # used to allow parent traversal before obj is saved to the db # (needed for view code 'create' form) attr_accessor :tmp_parent validates_presence_of :name + validates_uniqueness_of :name, :scope => :parent_id # overloading this method such that we can use permissions.admins to get all the admins for an object has_many :permissions, :dependent => :destroy, :order => "id ASC" do @@ -125,6 +128,11 @@ class Pool < ActiveRecord::Base self_and_siblings.select {|pool| pool[:type] == self.class.name} end + def named_child(child_name) + matches = children(:conditions=>"name='#{child_name}'") + matches ? matches[0] : nil + end + def can_view(user) has_privilege(user, Permission::PRIV_VIEW) end @@ -252,6 +260,19 @@ class Pool < ActiveRecord::Base permissions.collect {|perm| perm.uid} end + def self.find_by_path(path) + segs = path.split("/") + unless segs.shift.empty? + raise "Path must be absolute, but is #{path}" + end + default_pool = DirectoryPool.get_directory_root + if segs.shift == default_pool.name + segs.inject(default_pool) do |pool, seg| + pool.children.find { |p| p.name == seg } if pool + end + end + end + protected def traverse_parents if id diff --git a/wui/src/app/models/smart_pool.rb b/wui/src/app/models/smart_pool.rb new file mode 100644 index 0000000..e672c5b --- /dev/null +++ b/wui/src/app/models/smart_pool.rb @@ -0,0 +1,47 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class SmartPool < Pool + has_many :smart_pool_tags, :dependent => :destroy + has_many :tagged_pools, :through => :smart_pool_tags, :source => :pool, + :conditions => "smart_pool_tags.tagged_type = 'Pool'" + has_many :tagged_storage_pools, :through => :smart_pool_tags, + :source => :storage_pool, + :conditions => "smart_pool_tags.tagged_type = 'StoragePool'" + has_many :tagged_hosts, :through => :smart_pool_tags, :source => :host, + :conditions => "smart_pool_tags.tagged_type = 'Host'" + has_many :tagged_vms, :through => :smart_pool_tags, :source => :vm, + :conditions => "smart_pool_tags.tagged_type = 'Vm'" + + + def create_for_user(user) + create_with_parent(DirectoryPool.get_or_create_user_root(user)) + end + + def add_item(item) + tag = SmartPoolTag.new(:smart_pool => self, :tagged => item) + tag.save! + end + def remove_item(item) + smart_pool_tags.find(:first, :conditions=> { + :tagged_type=>item.class.base_class.to_s, + :tagged_id=>item.id}).destroy + end + +end diff --git a/wui/src/app/models/smart_pool_tag.rb b/wui/src/app/models/smart_pool_tag.rb new file mode 100644 index 0000000..e135ddf --- /dev/null +++ b/wui/src/app/models/smart_pool_tag.rb @@ -0,0 +1,37 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class SmartPoolTag < ActiveRecord::Base + belongs_to :smart_pool + belongs_to :tagged, :polymorphic => true + belongs_to :pool, :class_name => "Pool", + :foreign_key => "tagged_id" + belongs_to :storage_pool, :class_name => "StoragePool", + :foreign_key => "tagged_id" + belongs_to :host, :class_name => "Host", + :foreign_key => "tagged_id" + belongs_to :vm, :class_name => "Vm", + :foreign_key => "tagged_id" + + validates_uniqueness_of :smart_pool_id, :scope => [:tagged_id, :tagged_type] + + def tagged_type=(sType) + super(sType.to_s.classify.constantize.base_class.to_s) + end +end diff --git a/wui/src/app/models/storage_pool.rb b/wui/src/app/models/storage_pool.rb index 460b49d..bc98f8e 100644 --- a/wui/src/app/models/storage_pool.rb +++ b/wui/src/app/models/storage_pool.rb @@ -30,6 +30,9 @@ class StoragePool < ActiveRecord::Base end end + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags + validates_presence_of :ip_addr, :hardware_pool_id acts_as_xapian :texts => [ :ip_addr, :target, :export_path, :type ], diff --git a/wui/src/app/models/vm.rb b/wui/src/app/models/vm.rb index 80c7efb..cde28af 100644 --- a/wui/src/app/models/vm.rb +++ b/wui/src/app/models/vm.rb @@ -28,6 +28,10 @@ class Vm < ActiveRecord::Base end end has_and_belongs_to_many :storage_volumes + + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags + validates_presence_of :uuid, :description, :num_vcpus_allocated, :memory_allocated_in_mb, :memory_allocated, :vnic_mac_addr diff --git a/wui/src/app/views/hardware/show_hosts.rhtml b/wui/src/app/views/hardware/show_hosts.rhtml index f88c64b..31c575d 100644 --- a/wui/src/app/views/hardware/show_hosts.rhtml +++ b/wui/src/app/views/hardware/show_hosts.rhtml @@ -27,7 +27,7 @@ hosts = get_selected_hosts() if (validate_selected(hosts, "host")) { $.post('<%= url_for :controller => "hardware", :action => "move_hosts", :id => @pool %>', - { resource_ids: hosts.toString(), target_pool_id: <%= Pool.root.id %> }, + { resource_ids: hosts.toString(), target_pool_id: <%= HardwarePool.get_default_pool.id %> }, function(data,status){ $tabs.tabs("load",$tabs.data('selected.tabs')); if (data.alert) { diff --git a/wui/src/app/views/hardware/show_storage.rhtml b/wui/src/app/views/hardware/show_storage.rhtml index 02b5180..564b9ed 100644 --- a/wui/src/app/views/hardware/show_storage.rhtml +++ b/wui/src/app/views/hardware/show_storage.rhtml @@ -18,7 +18,7 @@ storage = get_selected_storage() if (validate_selected(storage, "storage pool")) { $.post('<%= url_for :controller => "hardware", :action => "move_storage", :id => @pool %>', - { resource_ids: storage.toString(), target_pool_id: <%= Pool.root.id %> }, + { resource_ids: storage.toString(), target_pool_id: <%= HardwarePool.get_default_pool.id %> }, function(data,status){ $tabs.tabs("load",$tabs.data('selected.tabs')); if (data.alert) { diff --git a/wui/src/app/views/layouts/_navigation_tabs.rhtml b/wui/src/app/views/layouts/_navigation_tabs.rhtml index 629ab93..4b0f18d 100644 --- a/wui/src/app/views/layouts/_navigation_tabs.rhtml +++ b/wui/src/app/views/layouts/_navigation_tabs.rhtml @@ -15,7 +15,7 @@ -<% elsif controller.controller_name == "resources" and @vm_resource_pool != nil %> +<% elsif controller.controller_name == "resources" and @pool != nil %>
    - - - - + + + +
<% elsif controller.controller_name == "search" %>
    diff --git a/wui/src/app/views/resources/edit.rhtml b/wui/src/app/views/resources/edit.rhtml index a101247..c6fd264 100644 --- a/wui/src/app/views/resources/edit.rhtml +++ b/wui/src/app/views/resources/edit.rhtml @@ -7,7 +7,7 @@
    - <%= hidden_field_tag 'id', @vm_resource_pool.id %> + <%= hidden_field_tag 'id', @pool.id %> <%= render :partial => 'form' %>
    <%= popup_footer("$('#vm_pool_form').submit()", "Edit Virtual Machine Pool") %> @@ -26,7 +26,7 @@ $(function() { refresh_summary('vmpool_selection', '<%= url_for :controller => "resources", :action => "quick_summary" %>', - <%= @vm_resource_pool.id %>) + <%= @pool.id %>) } } }; diff --git a/wui/src/app/views/resources/quick_summary.rhtml b/wui/src/app/views/resources/quick_summary.rhtml index 60d0df7..31c4033 100644 --- a/wui/src/app/views/resources/quick_summary.rhtml +++ b/wui/src/app/views/resources/quick_summary.rhtml @@ -1,21 +1,21 @@ <%- content_for :title do -%> - <%=h @vm_resource_pool.name %> quota + <%=h @pool.name %> quota <%- end -%> <%- content_for :action_links do -%> <%if @is_hwpool_admin -%> <%= link_to image_tag("icon_edit.png") + " Edit", - {:controller => 'resources', :action => 'edit', :id => @vm_resource_pool}, + {:controller => 'resources', :action => 'edit', :id => @pool}, :rel=>"facebox[.bolder]", :class=>"selection_facebox" %> - <%if @vm_resource_pool.quota -%> + <%if @pool.quota -%> <%= link_to image_tag("icon_edit.png") + " Edit Quota", - {:controller => 'quota', :action => 'edit', :id => @vm_resource_pool.quota}, + {:controller => 'quota', :action => 'edit', :id => @pool.quota}, :rel=>"facebox[.bolder]", :class=>"selection_facebox" %> <%= image_tag "icon_x.png" %> Revert to Default Quota <% else -%> <%= link_to image_tag("icon_edit.png") + " Edit Quota", - {:controller => 'quota', :action => 'new', :pool_id => @vm_resource_pool }, + {:controller => 'quota', :action => 'new', :pool_id => @pool }, :rel=>"facebox[.bolder]", :class=>"selection_facebox" %> <% end -%> <% end -%> @@ -25,13 +25,13 @@ function delete_vm_quota() { $(document).trigger('close.facebox'); - $.post('<%= url_for :controller => "quota", :action => "destroy", :id => @vm_resource_pool.quota %>', + $.post('<%= url_for :controller => "quota", :action => "destroy", :id => @pool.quota %>', {x: 1}, function(data,status){ refresh_summary('vmpool_selection', '<%= url_for :controller => "resources", :action => "quick_summary" %>', - <%= @vm_resource_pool.id %>); + <%= @pool.id %>); if (data.alert) { $.jGrowl(data.alert); } @@ -39,8 +39,8 @@ } - - <% resources = @vm_resource_pool.full_resources %> + + <% resources = @pool.full_resources %>

    <% for item in resources[:labels] %> @@ -60,5 +60,5 @@
    - <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @vm_resource_pool.id, :target => 'resource' %> + <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @pool.id, :target => 'resource' %>
    diff --git a/wui/src/app/views/resources/show.rhtml b/wui/src/app/views/resources/show.rhtml index 0db3a1b..789465b 100644 --- a/wui/src/app/views/resources/show.rhtml +++ b/wui/src/app/views/resources/show.rhtml @@ -1,18 +1,18 @@
    -
    <%= image_tag "icon_vmpool.png", :style=>"vertical-align:middle;" %> <%= @vm_resource_pool.name %>


    +
    <%= image_tag "icon_vmpool.png", :style=>"vertical-align:middle;" %> <%= @pool.name %>


    <%= image_tag "icon_smry_res.png", :style=>"vertical-align:middle;" %> Resources

    - <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @vm_resource_pool.id, :params => { :target => 'vcpu' } %> - <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @vm_resource_pool.id, :params => { :target => 'vram' } %> + <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @pool.id, :params => { :target => 'vcpu' } %> + <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @pool.id, :params => { :target => 'vram' } %>


    <%= image_tag "icon_smry_his.png", :style=>"vertical-align:middle;" %> History

    - <%= render_component :controller=> 'graph', :action => 'history_graphs', :id => @vm_resource_pool.id, :params => { :poolType => 'vm' } %> + <%= render_component :controller=> 'graph', :action => 'history_graphs', :id => @pool.id, :params => { :poolType => 'vm' } %>
    <%= image_tag "icon_smry_perf.png", :style=>"vertical-align:middle;" %> Performance

    - <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @vm_resource_pool.id, :params => { :poolType => 'vm' } %> + <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @pool.id, :params => { :poolType => 'vm' } %>
    @@ -23,6 +23,6 @@ refresh_summary('vmpool_selection', '<%= url_for :controller => "resources", :action => "quick_summary" %>', - <%= @vm_resource_pool.id %>) + <%= @pool.id %>) diff --git a/wui/src/app/views/resources/show_tasks.rhtml b/wui/src/app/views/resources/show_tasks.rhtml index 493264b..6c92779 100644 --- a/wui/src/app/views/resources/show_tasks.rhtml +++ b/wui/src/app/views/resources/show_tasks.rhtml @@ -24,7 +24,7 @@ function apply_task_state_filter(task_state) { $tabs.tabs("url", $tabs.data("selected.tabs"), - "<%= url_for :action => 'show_tasks', :id => @vm_resource_pool.id, + "<%= url_for :action => 'show_tasks', :id => @pool.id, :nolayout => :true %>" + "&task_state=" + task_state); $tabs.tabs("load", $tabs.data("selected.tabs")); @@ -37,7 +37,7 @@ <%= render :partial => "/task/grid", :locals => { :table_id => "vm_tasks_grid", :task_type => nil, :task_state => @task_state, - :pool => @vm_resource_pool, + :pool => @pool, :checkboxes => false, :on_select => "vm_tasks_grid_select" } %>
    diff --git a/wui/src/app/views/resources/show_users.rhtml b/wui/src/app/views/resources/show_users.rhtml index 7e2538d..f23018c 100644 --- a/wui/src/app/views/resources/show_users.rhtml +++ b/wui/src/app/views/resources/show_users.rhtml @@ -1,2 +1,2 @@ <%= render :partial => "/user/show", :locals => { :parent_controller => "resources", - :pool => @vm_resource_pool } %> + :pool => @pool } %> diff --git a/wui/src/app/views/resources/show_vms.rhtml b/wui/src/app/views/resources/show_vms.rhtml index 45e0089..857f56b 100644 --- a/wui/src/app/views/resources/show_vms.rhtml +++ b/wui/src/app/views/resources/show_vms.rhtml @@ -1,6 +1,6 @@
      -
    • <%= image_tag "icon_addhost.png", :style => "vertical-align:middle;" %>  Add Virtual Machine
      • +
    • <%= image_tag "icon_addhost.png", :style => "vertical-align:middle;" %>  Add Virtual Machine
    • <%= image_tag "icon_move.png", :style => "vertical-align:middle;" %>  Actions    <%= image_tag "icon_toolbar_arrow.gif", :style => "vertical-align:middle;" %>
        @@ -28,7 +28,7 @@ { vms = get_selected_vms() if (validate_selected(vms, "vm")) { - $.post('<%= url_for :controller => "vm", :action => "delete", :id => @vm_resource_pool %>', + $.post('<%= url_for :controller => "vm", :action => "delete", :id => @pool %>', { vm_ids: vms.toString() }, function(data,status){ $tabs.tabs("load",$tabs.data('selected.tabs')); @@ -47,7 +47,7 @@ if (validate_selected(vms, "vm")) { jQuery.facebox('
        '); $('#vm_action_results').load('<%= url_for :controller => "resources", - :action => "vm_actions", :id => @vm_resource_pool %>', + :action => "vm_actions", :id => @pool %>', { vm_ids: vms.toString(), vm_action: action }); } } @@ -66,10 +66,10 @@
        -<% if @vm_resource_pool.vms.size != 0 %> +<% if @pool.vms.size != 0 %>
        <%= render :partial => "/vm/grid", :locals => { :table_id => "vms_grid", - :pool => @vm_resource_pool, + :pool => @pool, :on_select => "vms_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", @@ -88,7 +88,7 @@
        No vms found in this pool.

        <%= image_tag "icon_addhost.png", :style => "vertical-align:middle;" %>   - Add first virtual machine to resource pool + Add first virtual machine to resource pool
        diff --git a/wui/src/db/migrate/017_add_smart_pools.rb b/wui/src/db/migrate/017_add_smart_pools.rb new file mode 100644 index 0000000..6d83c02 --- /dev/null +++ b/wui/src/db/migrate/017_add_smart_pools.rb @@ -0,0 +1,62 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class AddSmartPools < ActiveRecord::Migration + def self.up + create_table :smart_pool_tags do |t| + t.integer :smart_pool_id, :null => false + t.integer :tagged_id, :null => false + t.string :tagged_type, :null => false + end + execute "alter table smart_pool_tags add constraint + fk_smart_pool_tags_pool_id + foreign key (smart_pool_id) references pools(id)" + execute "alter table smart_pool_tags add constraint + unique_smart_pool_tags + unique (smart_pool_id, tagged_id, tagged_type)" + + begin + dir_root = DirectoryPool.get_directory_root + unless dir_root + Pool.transaction do + dir_root = DirectoryPool.create(:name=>DirectoryPool::ROOT_NAME) + hw_root = DirectoryPool.new(:name=>DirectoryPool::HARDWARE_ROOT) + hw_root.create_with_parent(dir_root) + smart_root = DirectoryPool.new(:name=>DirectoryPool::SMART_ROOT) + smart_root.create_with_parent(dir_root) + default_pool = Pool.root(:conditions=>"type='HardwarePool'") + default_pool = HardwarePool.create( :name=>'default') unless default_pool + default_pool.move_to_child_of(hw_root) + default_pool.permissions.each do |permission| + new_permission = Permission.new({:pool_id => dir_root.id, + :uid => permission.uid, + :user_role => permission.user_role}) + new_permission.save! + end + end + end + rescue + puts "Could not create DirectoryPool hierarchy..." + end + end + + def self.down + drop_table :smart_pool_tags + end +end diff --git a/wui/src/dutils/active_record_env.rb b/wui/src/dutils/active_record_env.rb index 9b7b416..14593f7 100644 --- a/wui/src/dutils/active_record_env.rb +++ b/wui/src/dutils/active_record_env.rb @@ -58,6 +58,8 @@ require 'models/permission.rb' require 'models/quota.rb' require 'models/hardware_pool.rb' +require 'models/directory_pool.rb' +require 'models/smart_pool.rb' require 'models/host.rb' require 'models/cpu.rb' require 'models/nic.rb' @@ -77,4 +79,6 @@ require 'models/nfs_storage_pool.rb' require 'models/storage_volume.rb' require 'models/iscsi_storage_volume.rb' require 'models/nfs_storage_volume.rb' +require 'models/smart_pool.rb' +require 'models/smart_pool_tag.rb' diff --git a/wui/src/script/grant_admin_privileges b/wui/src/script/grant_admin_privileges index 82595cb..c263b9c 100755 --- a/wui/src/script/grant_admin_privileges +++ b/wui/src/script/grant_admin_privileges @@ -13,10 +13,10 @@ ActiveLdap::Base.establish_connection :base => base, :host => host, :try_sasl => if Account.exists?("uid=#{uid}") puts "Creating an admin account for #{uid}..." - $hwpool = HardwarePool.get_default_pool + $pool = DirectoryPool.get_directory_root permission = Permission.create(:user_role => Permission::ROLE_SUPER_ADMIN, :uid => uid, - :pool_id => $hwpool.id) + :pool_id => $pool.id) else puts "Unable to verify user: uid=#{uid}" end diff --git a/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb b/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb index cdcf0c6..e91ca93 100644 --- a/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb +++ b/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb @@ -81,13 +81,22 @@ module SymetrieCom # Returns the single root for the class (or just the first root, if there are several). # Deprecation note: the original acts_as_nested_set allowed roots to have parent_id = 0, # so we currently do the same. This silliness will not be tolerated in future versions, however. - def root - acts_as_nested_set_options[:class].find(:first, :conditions => "(#{acts_as_nested_set_options[:parent_column]} IS NULL OR #{acts_as_nested_set_options[:parent_column]} = 0)") + def root(find_opts={}) + roots_internal(:first, find_opts) end # Returns the roots and/or virtual roots of all trees. See the explanation of virtual roots in the README. - def roots - acts_as_nested_set_options[:class].find(:all, :conditions => "(#{acts_as_nested_set_options[:parent_column]} IS NULL OR #{acts_as_nested_set_options[:parent_column]} = 0)", :order => "#{acts_as_nested_set_options[:left_column]}") + def roots(find_opts={}) + roots_internal(:all, find_opts) + end + def roots_internal(all_or_one, find_opts={}) + conditions = "(#{acts_as_nested_set_options[:parent_column]} IS NULL" + conditions += " OR #{acts_as_nested_set_options[:parent_column]} = 0)" + order_col = "#{acts_as_nested_set_options[:left_column]}" + opts = merge_incoming_opts({:conditions => conditions, + :order => order_col}, + find_opts) + acts_as_nested_set_options[:class].find(all_or_one, opts) end # Checks the left/right indexes of all records, @@ -128,6 +137,14 @@ module SymetrieCom items.map! {|e| "(#{acts_as_nested_set_options[:left_column]} BETWEEN #{e[acts_as_nested_set_options[:left_column]]} AND #{e[acts_as_nested_set_options[:right_column]]})" } "(#{items.join(' OR ')})" end + + # accept incoming opts to allow filtering of results. + # So far only tested in limited use cases encountered in oVirt devel. + def merge_incoming_opts(set_opts, incoming_opts) + new_conditions = incoming_opts.delete(:conditions) + set_opts[:conditions] = "(#{set_opts[:conditions]}) AND (#{new_conditions})" if new_conditions + set_opts.merge(incoming_opts) + end end @@ -255,7 +272,7 @@ module SymetrieCom elsif new_record? || self[right_col_name] - self[left_col_name] == 1 return [self] end - opts = merge_incoming_opts({:conditions => "#{scope_condition} #{exclude_str} AND (#{left_col_name} BETWEEN #{self[left_col_name]} AND #{self[right_col_name]})", + opts = base_set_class.merge_incoming_opts({:conditions => "#{scope_condition} #{exclude_str} AND (#{left_col_name} BETWEEN #{self[left_col_name]} AND #{self[right_col_name]})", :order => left_col_name}, find_opts) base_set_class.find(:all, opts) @@ -270,7 +287,7 @@ module SymetrieCom # Returns this record's immediate children. def children(find_opts={}) - opts = merge_incoming_opts({:conditions => "#{scope_condition} AND #{parent_col_name} = #{self.id}", + opts = base_set_class.merge_incoming_opts({:conditions => "#{scope_condition} AND #{parent_col_name} = #{self.id}", :order => left_col_name}, find_opts) base_set_class.find(:all, opts) @@ -585,14 +602,6 @@ module SymetrieCom self.class.connection.quote(value, column) end - # accept incoming opts to allow filtering of results. - # So far only tested in limited use cases encountered in oVirt devel. - def merge_incoming_opts(set_opts, incoming_opts) - new_conditions = incoming_opts.delete(:conditions) - set_opts[:conditions] = "(#{set_opts[:conditions]}) AND (#{new_conditions})" if new_conditions - set_opts.merge(incoming_opts) - end - end end end -- 1.5.5.1 From sseago at redhat.com Wed Sep 3 16:12:31 2008 From: sseago at redhat.com (Scott Seago) Date: Wed, 3 Sep 2008 12:12:31 -0400 Subject: [Ovirt-devel] [PATCH] initial push of smart pool code. (revised) Message-ID: <1220458351-3678-1-git-send-email-sseago@redhat.com> This isn't complete, but I want to get it committed before the repo refactoring. This patch includes the controller refactoring needed for adding the new smart pool controllers, but I have not yet added any code to the new controllers. The models are in place for smart pools, but they aren't used anywhere yet. In addition, I've added a new DirectoryPool pool type that is used solely as a placeholder -- so that we can have a common root for all hardware and smart pools, and that we can organize smart pools by user. Since we need this pushed before the repo refactoring, this patch should be acked if it doesn't break anything. Separate review comments are, of course, welcome -- but anything that doesn't break the WUI will be fixed in a subsequent (post-repo-reorg) patch) Signed-off-by: Scott Seago --- wui/src/app/controllers/application.rb | 3 +- wui/src/app/controllers/hardware_controller.rb | 111 ++-------------- wui/src/app/controllers/pool_controller.rb | 132 ++++++++++++++++++++ wui/src/app/controllers/resources_controller.rb | 128 ++++--------------- wui/src/app/controllers/smart_pool_controller.rb | 22 ++++ wui/src/app/controllers/tree_controller.rb | 4 +- wui/src/app/models/directory_pool.rb | 60 +++++++++ wui/src/app/models/hardware_pool.rb | 18 +-- wui/src/app/models/host.rb | 3 + wui/src/app/models/pool.rb | 21 +++ wui/src/app/models/smart_pool.rb | 47 +++++++ wui/src/app/models/smart_pool_tag.rb | 37 ++++++ wui/src/app/models/storage_pool.rb | 3 + wui/src/app/models/vm.rb | 4 + wui/src/app/views/hardware/show_hosts.rhtml | 2 +- wui/src/app/views/hardware/show_storage.rhtml | 2 +- wui/src/app/views/layouts/_navigation_tabs.rhtml | 10 +- wui/src/app/views/resources/edit.rhtml | 4 +- wui/src/app/views/resources/quick_summary.rhtml | 20 ++-- wui/src/app/views/resources/show.rhtml | 12 +- wui/src/app/views/resources/show_tasks.rhtml | 4 +- wui/src/app/views/resources/show_users.rhtml | 2 +- wui/src/app/views/resources/show_vms.rhtml | 12 +- wui/src/db/migrate/017_add_smart_pools.rb | 62 +++++++++ wui/src/dutils/active_record_env.rb | 4 + wui/src/script/grant_admin_privileges | 9 +- .../betternestedset/lib/better_nested_set.rb | 37 ++++-- 27 files changed, 506 insertions(+), 267 deletions(-) create mode 100644 wui/src/app/controllers/pool_controller.rb create mode 100644 wui/src/app/controllers/smart_pool_controller.rb create mode 100644 wui/src/app/models/directory_pool.rb create mode 100644 wui/src/app/models/smart_pool.rb create mode 100644 wui/src/app/models/smart_pool_tag.rb create mode 100644 wui/src/db/migrate/017_add_smart_pools.rb diff --git a/wui/src/app/controllers/application.rb b/wui/src/app/controllers/application.rb index b95577a..3126748 100644 --- a/wui/src/app/controllers/application.rb +++ b/wui/src/app/controllers/application.rb @@ -29,8 +29,7 @@ class ApplicationController < ActionController::Base before_filter :pre_new, :only => [:new] before_filter :pre_create, :only => [:create] before_filter :pre_edit, :only => [:edit, :update, :destroy] - before_filter :pre_show, :only => [:show, :show_vms, :show_users, - :show_hosts, :show_storage] + before_filter :pre_show, :only => [:show] before_filter :authorize_admin, :only => [:new, :create, :edit, :update, :destroy] before_filter :is_logged_in diff --git a/wui/src/app/controllers/hardware_controller.rb b/wui/src/app/controllers/hardware_controller.rb index 7c1d916..091ce97 100644 --- a/wui/src/app/controllers/hardware_controller.rb +++ b/wui/src/app/controllers/hardware_controller.rb @@ -18,7 +18,7 @@ # also available at http://www.gnu.org/copyleft/gpl.html. # -class HardwareController < ApplicationController +class HardwareController < PoolController XML_OPTS = { :include => [ :storage_pools, :hosts, :quota ] @@ -31,10 +31,8 @@ class HardwareController < ApplicationController verify :method => [:post, :delete], :only => :destroy, :redirect_to => { :action => :list } - before_filter :pre_json, :only => [:vm_pools_json, :users_json, - :storage_volumes_json, :show_tasks, :tasks] - before_filter :pre_modify, :only => [:add_hosts, :move_hosts, - :add_storage, :move_storage, + before_filter :pre_modify, :only => [:add_hosts, :move_hosts, + :add_storage, :move_storage, :create_storage, :delete_storage] def index @@ -60,27 +58,6 @@ class HardwareController < ApplicationController end end - def show - set_perms(@perm_obj) - unless @can_view - flash[:notice] = 'You do not have permission to view this hardware pool: redirecting to top level' - respond_to do |format| - format.html { redirect_to :controller => "dashboard" } - format.xml { head :forbidden } - end - return - end - respond_to do |format| - format.html { - render :layout => 'tabs-and-content' if params[:ajax] - render :layout => false if params[:nolayout] - } - format.xml { - render :xml => @pool.to_xml(XML_OPTS) - } - end - end - def json_view_tree json_tree_internal(Permission::PRIV_VIEW, false) end @@ -121,11 +98,6 @@ class HardwareController < ApplicationController show end - def show_users - @roles = Permission::ROLES.keys - show - end - def show_hosts @hardware_pools = HardwarePool.find :all show @@ -145,53 +117,23 @@ class HardwareController < ApplicationController ["Host Task", "HostTask"], ["Storage Task", "StorageTask", "break"], ["Show All", ""]] - @task_states = [["Queued", Task::STATE_QUEUED], - ["Running", Task::STATE_RUNNING], - ["Paused", Task::STATE_PAUSED], - ["Finished", Task::STATE_FINISHED], - ["Failed", Task::STATE_FAILED], - ["Canceled", Task::STATE_CANCELED, "break"], - ["Show All", ""]] - params[:page]=1 - params[:sortname]="tasks.created_at" - params[:sortorder]="desc" - @tasks = tasks_internal - show - end - - def tasks - render :json => tasks_internal.to_json + super end def tasks_internal @task_type = params[:task_type] @task_type ||="" - @task_state = params[:task_state] - @task_state ||=Task::STATE_QUEUED - conditions = {} - conditions[:type] = @task_type unless @task_type.empty? - conditions[:state] = @task_state unless @task_state.empty? - find_opts = {:include => [:storage_pool, :host, :vm]} - find_opts[:conditions] = conditions unless conditions.empty? - attr_list = [] - attr_list << :id if params[:checkboxes] - attr_list += [:type_label, :task_obj, :action, :state, :user, :created_at, :args, :message] - json_hash(@pool.tasks, attr_list, [:all], find_opts) - end - - def quick_summary - pre_show - render :layout => 'selection' + super end def hosts_json if params[:exclude_host] - pre_json + pre_show hosts = @pool.hosts find_opts = {:conditions => ["id != ?", params[:exclude_host]]} include_pool = false elsif params[:id] - pre_json + pre_show hosts = @pool.hosts find_opts = {} include_pool = false @@ -219,14 +161,9 @@ class HardwareController < ApplicationController {:finder => 'call_finder', :conditions => ["type = 'VmResourcePool'"]}) end - def users_json - json_list(@pool.permissions, - [:grid_id, :uid, :user_role, :source]) - end - def storage_pools_json if params[:id] - pre_json + pre_show storage_pools = @pool.storage_pools find_opts = {} include_pool = false @@ -258,7 +195,7 @@ class HardwareController < ApplicationController def new @resource_type = params[:resource_type] @resource_ids = params[:resource_ids] - render :layout => 'popup' + super end def create @@ -293,10 +230,6 @@ class HardwareController < ApplicationController end end - def edit - render :layout => 'popup' - end - def update if params[:hardware_pool] # FIXME: For the REST API, we allow moving hosts/storage through @@ -455,28 +388,23 @@ class HardwareController < ApplicationController :alert => alert } } format.xml { head status } end - end + end - private + protected #filter methods def pre_new @pool = HardwarePool.new - @parent = Pool.find(params[:parent_id]) - @perm_obj = @parent - @current_pool_id=@parent.id + super end def pre_create # FIXME: REST and browsers send params differently. Should be fixed # in the views if params[:pool] @pool = HardwarePool.new(params[:pool]) - @parent = Pool.find(params[:parent_id]) else @pool = HardwarePool.new(params[:hardware_pool]) - @parent = Pool.find(params[:hardware_pool][:parent_id]) end - @perm_obj = @parent - @current_pool_id=@parent.id + super end def pre_edit @pool = HardwarePool.find(params[:id]) @@ -486,18 +414,7 @@ class HardwareController < ApplicationController end def pre_show @pool = HardwarePool.find(params[:id]) - @perm_obj = @pool - @current_pool_id=@pool.id - set_perms(@perm_obj) - unless @can_view - flash[:notice] = 'You do not have permission to view this Hardware Pool: redirecting to top level' - # FIXME: figure out the return type and render appropriately - redirect_to :action => 'list' - return - end - end - def pre_json - pre_show + super end def pre_modify pre_edit diff --git a/wui/src/app/controllers/pool_controller.rb b/wui/src/app/controllers/pool_controller.rb new file mode 100644 index 0000000..ce41701 --- /dev/null +++ b/wui/src/app/controllers/pool_controller.rb @@ -0,0 +1,132 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. +# + +class PoolController < ApplicationController + + before_filter :pre_show_pool, :only => [:show_vms, :show_users, + :show_hosts, :show_storage, + :users_json, :show_tasks, :tasks, + :vms_json, :vm_pools_json, + :storage_volumes_json, :quick_summary] + + def show + respond_to do |format| + format.html { + render :layout => 'tabs-and-content' if params[:ajax] + render :layout => false if params[:nolayout] + } + format.xml { + render :xml => @pool.to_xml(XML_OPTS) + } + end + end + + def quick_summary + render :layout => 'selection' + end + + # resource's users list page + def show_users + @roles = Permission::ROLES.keys + show + end + + def users_json + json_list(@pool.permissions, + [:grid_id, :uid, :user_role, :source]) + end + + def show_tasks + @task_states = [["Queued", Task::STATE_QUEUED], + ["Running", Task::STATE_RUNNING], + ["Paused", Task::STATE_PAUSED], + ["Finished", Task::STATE_FINISHED], + ["Failed", Task::STATE_FAILED], + ["Canceled", Task::STATE_CANCELED, "break"], + ["Show All", ""]] + params[:page]=1 + params[:sortname]="tasks.created_at" + params[:sortorder]="desc" + @tasks = tasks_internal + show + end + + def tasks + render :json => tasks_internal.to_json + end + + def tasks_internal + @task_state = params[:task_state] + @task_state ||=Task::STATE_QUEUED + conditions = {} + conditions[:type] = @task_type unless @task_type.empty? + conditions[:state] = @task_state unless @task_state.empty? + find_opts = {:include => [:storage_pool, :host, :vm]} + find_opts[:conditions] = conditions unless conditions.empty? + attr_list = [] + attr_list << :id if params[:checkboxes] + attr_list += [:type_label, :task_obj, :action, :state, :user, :created_at, :args, :message] + json_hash(@pool.tasks, attr_list, [:all], find_opts) + end + + def new + render :layout => 'popup' + end + + def edit + render :layout => 'popup' + end + + protected + def pre_new + @parent = Pool.find(params[:parent_id]) + @perm_obj = @parent + @redir_controller = @perm_obj.get_controller + @current_pool_id=@parent.id + end + def pre_create + #this is currently only true for the rest API for hardware pools + if params[:hardware_pool] + @parent = Pool.find(params[:hardware_pool][:parent_id]) + else + @parent = Pool.find(params[:parent_id]) + end + @perm_obj = @parent + @redir_controller = @perm_obj.get_controller + @current_pool_id=@parent.id + end + def pre_show_pool + pre_show + end + def pre_show + @perm_obj = @pool + @current_pool_id=@pool.id + set_perms(@perm_obj) + unless @can_view + flash[:notice] = 'You do not have permission to view this pool pool: redirecting to top level' + respond_to do |format| + format.html { redirect_to :controller => "dashboard" } + format.xml { head :forbidden } + end + return + end + end + +end diff --git a/wui/src/app/controllers/resources_controller.rb b/wui/src/app/controllers/resources_controller.rb index 5a8276c..a0a65a6 100644 --- a/wui/src/app/controllers/resources_controller.rb +++ b/wui/src/app/controllers/resources_controller.rb @@ -17,14 +17,12 @@ # MA 02110-1301, USA. A copy of the GNU General Public License is # also available at http://www.gnu.org/copyleft/gpl.html. -class ResourcesController < ApplicationController +class ResourcesController < PoolController def index list render :action => 'list' end - before_filter :pre_json, :only => [:vms_json, :users_json, - :show_tasks, :tasks] before_filter :pre_vm_actions, :only => [:vm_actions] # GETs should be safe (see http://www.w3.org/2001/tag/doc/whenToUseGet.html) @@ -49,17 +47,7 @@ class ResourcesController < ApplicationController ["Resume", VmTask::ACTION_RESUME_VM], ["Save", VmTask::ACTION_SAVE_VM], ["Restore", VmTask::ACTION_RESTORE_VM]] - if params[:ajax] - render :layout => 'tabs-and-content' - end - if params[:nolayout] - render :layout => false - end - end - - def quick_summary - pre_show - render :layout => 'selection' + super end # resource's vms list page @@ -73,81 +61,36 @@ class ResourcesController < ApplicationController show end - # resource's users list page - def show_users - @roles = Permission::ROLES.keys - show - end - - def show_tasks - @task_states = [["Queued", Task::STATE_QUEUED], - ["Running", Task::STATE_RUNNING], - ["Paused", Task::STATE_PAUSED], - ["Finished", Task::STATE_FINISHED], - ["Failed", Task::STATE_FAILED], - ["Canceled", Task::STATE_CANCELED, "break"], - ["Show All", ""]] - params[:page]=1 - params[:sortname]="tasks.created_at" - params[:sortorder]="desc" - @tasks = tasks_internal - show - end - - def tasks - render :json => tasks_internal.to_json - end - def tasks_internal + @task_type = "" @task_state = params[:task_state] - @task_state ||=Task::STATE_QUEUED - conditions = {} - conditions[:state] = @task_state unless @task_state.empty? - find_opts = {:include => [:storage_pool, :host, :vm]} - find_opts[:conditions] = conditions unless conditions.empty? - attr_list = [] - attr_list << :id if params[:checkboxes] - attr_list += [:type_label, :task_obj, :action, :state, :user, :created_at, :args, :message] - json_hash(@vm_resource_pool.tasks, attr_list, [:all], find_opts) + super end def vms_json - json_list(@vm_resource_pool.vms, + json_list(@pool.vms, [:id, :description, :uuid, :num_vcpus_allocated, :memory_allocated_in_mb, :vnic_mac_addr, :state, :id]) end - def users_json - json_list(@vm_resource_pool.permissions, - [:grid_id, :uid, :user_role, :source]) - end - - def new - render :layout => 'popup' - end - def create begin - @vm_resource_pool.create_with_parent(@parent) + @pool.create_with_parent(@parent) render :json => { :object => "vm_resource_pool", :success => true, :alert => "Virtual Machine Pool was successfully created." } rescue render :json => { :object => "vm_resource_pool", :success => false, - :errors => @vm_resource_pool.errors.localize_error_messages.to_a} + :errors => @pool.errors.localize_error_messages.to_a} end end - def edit - render :layout => 'popup' - end - def update begin - @vm_resource_pool.update_attributes!(params[:vm_resource_pool]) + @pool.update_attributes!(params[:vm_resource_pool]) render :json => { :object => "vm_resource_pool", :success => true, :alert => "Virtual Machine Pool was successfully modified." } rescue render :json => { :object => "vm_resource_pool", :success => false, - :errors => @vm_resource_pool.errors.localize_error_messages.to_a} + :errors => @pool.errors.localize_error_messages.to_a} end end @@ -174,7 +117,7 @@ class ResourcesController < ApplicationController end def destroy - if @vm_resource_pool.destroy + if @pool.destroy alert="Virtual Machine Pool was successfully deleted." success=true else @@ -192,7 +135,7 @@ class ResourcesController < ApplicationController @success_list = [] @failure_list = [] begin - @vm_resource_pool.transaction do + @pool.transaction do @vms.each do |vm| if vm.queue_action(@user, @action) @success_list << vm @@ -212,45 +155,30 @@ class ResourcesController < ApplicationController protected def pre_new - @vm_resource_pool = VmResourcePool.new - @parent = Pool.find(params[:parent_id]) - @perm_obj = @parent - @redir_controller = @perm_obj.get_controller - @current_pool_id=@parent.id + @pool = VmResourcePool.new + super end def pre_create - @vm_resource_pool = VmResourcePool.new(params[:vm_resource_pool]) - @parent = Pool.find(params[:parent_id]) - @perm_obj = @parent - @redir_controller = @perm_obj.get_controller - @current_pool_id=@parent.id - end - def pre_show - @vm_resource_pool = VmResourcePool.find(params[:id]) - @perm_obj = @vm_resource_pool - @current_pool_id=@vm_resource_pool.id - set_perms(@perm_obj) - @is_hwpool_admin = @vm_resource_pool.parent.can_modify(@user) - unless @can_view - flash[:notice] = 'You do not have permission to view this VM Resource Pool: redirecting to top level' - redirect_to :action => 'dashboard' - end + @pool = VmResourcePool.new(params[:vm_resource_pool]) + super end def pre_edit - @vm_resource_pool = VmResourcePool.find(params[:id]) - @parent = @vm_resource_pool.parent - @perm_obj = @vm_resource_pool.parent - @redir_obj = @vm_resource_pool - @current_pool_id=@vm_resource_pool.id + @pool = VmResourcePool.find(params[:id]) + @parent = @pool.parent + @perm_obj = @pool.parent + @redir_obj = @pool + @current_pool_id=@pool.id end - def pre_json - pre_show + def pre_show + @pool = VmResourcePool.find(params[:id]) + @is_hwpool_admin = @pool.parent.can_modify(@user) + super end def pre_vm_actions - @vm_resource_pool = VmResourcePool.find(params[:id]) - @parent = @vm_resource_pool.parent - @perm_obj = @vm_resource_pool - @redir_obj = @vm_resource_pool + @pool = VmResourcePool.find(params[:id]) + @parent = @pool.parent + @perm_obj = @pool + @redir_obj = @pool authorize_user end diff --git a/wui/src/app/controllers/smart_pool_controller.rb b/wui/src/app/controllers/smart_pool_controller.rb new file mode 100644 index 0000000..eb087a6 --- /dev/null +++ b/wui/src/app/controllers/smart_pool_controller.rb @@ -0,0 +1,22 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. +# + +class SmartPoolController < ApplicationController +end diff --git a/wui/src/app/controllers/tree_controller.rb b/wui/src/app/controllers/tree_controller.rb index c7dbe35..5ad8426 100644 --- a/wui/src/app/controllers/tree_controller.rb +++ b/wui/src/app/controllers/tree_controller.rb @@ -1,10 +1,10 @@ class TreeController < ApplicationController def fetch_nav - @pools = Pool.root.full_set_nested(:method => :json_hash_element) + @pools = HardwarePool.get_default_pool.full_set_nested(:method => :json_hash_element) end def fetch_json - render :json => Pool.root.full_set_nested(:method => :json_hash_element).to_json + render :json => HardwarePool.get_default_pool.full_set_nested(:method => :json_hash_element).to_json end end diff --git a/wui/src/app/models/directory_pool.rb b/wui/src/app/models/directory_pool.rb new file mode 100644 index 0000000..f62d980 --- /dev/null +++ b/wui/src/app/models/directory_pool.rb @@ -0,0 +1,60 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class DirectoryPool < Pool + + ROOT_NAME = "root" + HARDWARE_ROOT = "hardware" + SMART_ROOT = "users" + + def self.get_directory_root + self.root(:conditions=>"type='DirectoryPool'") + end + + def self.get_hardware_root + dir_root = get_directory_root + dir_root ? dir_root.named_child(HARDWARE_ROOT) : nil + end + + def self.get_smart_root + dir_root = get_directory_root + dir_root ? dir_root.named_child(SMART_ROOT) : nil + end + + def self.get_user_root(user) + smart_root = get_smart_root + smart_root ? smart_root.named_child(user) : nil + end + + def self.get_or_create_user_root(user) + user_root = get_user_root(user) + unless user_root + DirectoryPool.transaction do + user_root = DirectoryPool.new(:name => user) + user_root.create_with_parent(get_smart_root) + permission = Permission.new({:pool_id => user_root.id, + :uid => user, + :user_role => Permission::ROLE_SUPER_ADMIN}) + #we don't need save_with_new_children here since there are no children yet + permission.save! + end + end + end + +end diff --git a/wui/src/app/models/hardware_pool.rb b/wui/src/app/models/hardware_pool.rb index 5409862..160f663 100644 --- a/wui/src/app/models/hardware_pool.rb +++ b/wui/src/app/models/hardware_pool.rb @@ -19,6 +19,8 @@ class HardwarePool < Pool + DEFAULT_POOL_NAME = "default" + has_many :tasks, :dependent => :nullify def all_storage_volumes StorageVolume.find(:all, :include => {:storage_pool => :hardware_pool}, :conditions => "pools.id = #{id}") @@ -34,7 +36,8 @@ class HardwarePool < Pool # note: doesn't currently join w/ permissions def self.get_default_pool - self.root + hw_root = DirectoryPool.get_hardware_root + hw_root ? hw_root.named_child(DEFAULT_POOL_NAME) : nil end def create_with_resources(parent, resource_type= nil, resource_ids=[]) @@ -98,17 +101,4 @@ class HardwarePool < Pool return {:total => total, :labels => labels} end - def self.find_by_path(path) - segs = path.split("/") - unless segs.shift.empty? - raise "Path must be absolute, but is #{path}" - end - default_pool = get_default_pool - if segs.shift == default_pool.name - segs.inject(default_pool) do |pool, seg| - pool.sub_hardware_pools.find { |p| p.name == seg } if pool - end - end - end - end diff --git a/wui/src/app/models/host.rb b/wui/src/app/models/host.rb index 5b32653..3fc3abb 100644 --- a/wui/src/app/models/host.rb +++ b/wui/src/app/models/host.rb @@ -40,6 +40,9 @@ class Host < ActiveRecord::Base end end + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags + acts_as_xapian :texts => [ :hostname, :uuid, :hypervisor_type, :arch ], :values => [ [ :created_at, 0, "created_at", :date ], [ :updated_at, 1, "updated_at", :date ] ], diff --git a/wui/src/app/models/pool.rb b/wui/src/app/models/pool.rb index 6599c72..9d71fa5 100644 --- a/wui/src/app/models/pool.rb +++ b/wui/src/app/models/pool.rb @@ -42,12 +42,15 @@ class Pool < ActiveRecord::Base end end + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags # used to allow parent traversal before obj is saved to the db # (needed for view code 'create' form) attr_accessor :tmp_parent validates_presence_of :name + validates_uniqueness_of :name, :scope => :parent_id # overloading this method such that we can use permissions.admins to get all the admins for an object has_many :permissions, :dependent => :destroy, :order => "id ASC" do @@ -125,6 +128,11 @@ class Pool < ActiveRecord::Base self_and_siblings.select {|pool| pool[:type] == self.class.name} end + def named_child(child_name) + matches = children(:conditions=>"name='#{child_name}'") + matches ? matches[0] : nil + end + def can_view(user) has_privilege(user, Permission::PRIV_VIEW) end @@ -252,6 +260,19 @@ class Pool < ActiveRecord::Base permissions.collect {|perm| perm.uid} end + def self.find_by_path(path) + segs = path.split("/") + unless segs.shift.empty? + raise "Path must be absolute, but is #{path}" + end + default_pool = DirectoryPool.get_directory_root + if segs.shift == default_pool.name + segs.inject(default_pool) do |pool, seg| + pool.children.find { |p| p.name == seg } if pool + end + end + end + protected def traverse_parents if id diff --git a/wui/src/app/models/smart_pool.rb b/wui/src/app/models/smart_pool.rb new file mode 100644 index 0000000..e672c5b --- /dev/null +++ b/wui/src/app/models/smart_pool.rb @@ -0,0 +1,47 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class SmartPool < Pool + has_many :smart_pool_tags, :dependent => :destroy + has_many :tagged_pools, :through => :smart_pool_tags, :source => :pool, + :conditions => "smart_pool_tags.tagged_type = 'Pool'" + has_many :tagged_storage_pools, :through => :smart_pool_tags, + :source => :storage_pool, + :conditions => "smart_pool_tags.tagged_type = 'StoragePool'" + has_many :tagged_hosts, :through => :smart_pool_tags, :source => :host, + :conditions => "smart_pool_tags.tagged_type = 'Host'" + has_many :tagged_vms, :through => :smart_pool_tags, :source => :vm, + :conditions => "smart_pool_tags.tagged_type = 'Vm'" + + + def create_for_user(user) + create_with_parent(DirectoryPool.get_or_create_user_root(user)) + end + + def add_item(item) + tag = SmartPoolTag.new(:smart_pool => self, :tagged => item) + tag.save! + end + def remove_item(item) + smart_pool_tags.find(:first, :conditions=> { + :tagged_type=>item.class.base_class.to_s, + :tagged_id=>item.id}).destroy + end + +end diff --git a/wui/src/app/models/smart_pool_tag.rb b/wui/src/app/models/smart_pool_tag.rb new file mode 100644 index 0000000..e135ddf --- /dev/null +++ b/wui/src/app/models/smart_pool_tag.rb @@ -0,0 +1,37 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class SmartPoolTag < ActiveRecord::Base + belongs_to :smart_pool + belongs_to :tagged, :polymorphic => true + belongs_to :pool, :class_name => "Pool", + :foreign_key => "tagged_id" + belongs_to :storage_pool, :class_name => "StoragePool", + :foreign_key => "tagged_id" + belongs_to :host, :class_name => "Host", + :foreign_key => "tagged_id" + belongs_to :vm, :class_name => "Vm", + :foreign_key => "tagged_id" + + validates_uniqueness_of :smart_pool_id, :scope => [:tagged_id, :tagged_type] + + def tagged_type=(sType) + super(sType.to_s.classify.constantize.base_class.to_s) + end +end diff --git a/wui/src/app/models/storage_pool.rb b/wui/src/app/models/storage_pool.rb index 460b49d..bc98f8e 100644 --- a/wui/src/app/models/storage_pool.rb +++ b/wui/src/app/models/storage_pool.rb @@ -30,6 +30,9 @@ class StoragePool < ActiveRecord::Base end end + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags + validates_presence_of :ip_addr, :hardware_pool_id acts_as_xapian :texts => [ :ip_addr, :target, :export_path, :type ], diff --git a/wui/src/app/models/vm.rb b/wui/src/app/models/vm.rb index 80c7efb..cde28af 100644 --- a/wui/src/app/models/vm.rb +++ b/wui/src/app/models/vm.rb @@ -28,6 +28,10 @@ class Vm < ActiveRecord::Base end end has_and_belongs_to_many :storage_volumes + + has_many :smart_pool_tags, :as => :tagged, :dependent => :destroy + has_many :smart_pools, :through => :smart_pool_tags + validates_presence_of :uuid, :description, :num_vcpus_allocated, :memory_allocated_in_mb, :memory_allocated, :vnic_mac_addr diff --git a/wui/src/app/views/hardware/show_hosts.rhtml b/wui/src/app/views/hardware/show_hosts.rhtml index f88c64b..31c575d 100644 --- a/wui/src/app/views/hardware/show_hosts.rhtml +++ b/wui/src/app/views/hardware/show_hosts.rhtml @@ -27,7 +27,7 @@ hosts = get_selected_hosts() if (validate_selected(hosts, "host")) { $.post('<%= url_for :controller => "hardware", :action => "move_hosts", :id => @pool %>', - { resource_ids: hosts.toString(), target_pool_id: <%= Pool.root.id %> }, + { resource_ids: hosts.toString(), target_pool_id: <%= HardwarePool.get_default_pool.id %> }, function(data,status){ $tabs.tabs("load",$tabs.data('selected.tabs')); if (data.alert) { diff --git a/wui/src/app/views/hardware/show_storage.rhtml b/wui/src/app/views/hardware/show_storage.rhtml index 02b5180..564b9ed 100644 --- a/wui/src/app/views/hardware/show_storage.rhtml +++ b/wui/src/app/views/hardware/show_storage.rhtml @@ -18,7 +18,7 @@ storage = get_selected_storage() if (validate_selected(storage, "storage pool")) { $.post('<%= url_for :controller => "hardware", :action => "move_storage", :id => @pool %>', - { resource_ids: storage.toString(), target_pool_id: <%= Pool.root.id %> }, + { resource_ids: storage.toString(), target_pool_id: <%= HardwarePool.get_default_pool.id %> }, function(data,status){ $tabs.tabs("load",$tabs.data('selected.tabs')); if (data.alert) { diff --git a/wui/src/app/views/layouts/_navigation_tabs.rhtml b/wui/src/app/views/layouts/_navigation_tabs.rhtml index 629ab93..4b0f18d 100644 --- a/wui/src/app/views/layouts/_navigation_tabs.rhtml +++ b/wui/src/app/views/layouts/_navigation_tabs.rhtml @@ -15,7 +15,7 @@
      -<% elsif controller.controller_name == "resources" and @vm_resource_pool != nil %> +<% elsif controller.controller_name == "resources" and @pool != nil %>
        - - - - + + + +
      <% elsif controller.controller_name == "search" %>
        diff --git a/wui/src/app/views/resources/edit.rhtml b/wui/src/app/views/resources/edit.rhtml index a101247..c6fd264 100644 --- a/wui/src/app/views/resources/edit.rhtml +++ b/wui/src/app/views/resources/edit.rhtml @@ -7,7 +7,7 @@
        - <%= hidden_field_tag 'id', @vm_resource_pool.id %> + <%= hidden_field_tag 'id', @pool.id %> <%= render :partial => 'form' %>
        <%= popup_footer("$('#vm_pool_form').submit()", "Edit Virtual Machine Pool") %> @@ -26,7 +26,7 @@ $(function() { refresh_summary('vmpool_selection', '<%= url_for :controller => "resources", :action => "quick_summary" %>', - <%= @vm_resource_pool.id %>) + <%= @pool.id %>) } } }; diff --git a/wui/src/app/views/resources/quick_summary.rhtml b/wui/src/app/views/resources/quick_summary.rhtml index 60d0df7..31c4033 100644 --- a/wui/src/app/views/resources/quick_summary.rhtml +++ b/wui/src/app/views/resources/quick_summary.rhtml @@ -1,21 +1,21 @@ <%- content_for :title do -%> - <%=h @vm_resource_pool.name %> quota + <%=h @pool.name %> quota <%- end -%> <%- content_for :action_links do -%> <%if @is_hwpool_admin -%> <%= link_to image_tag("icon_edit.png") + " Edit", - {:controller => 'resources', :action => 'edit', :id => @vm_resource_pool}, + {:controller => 'resources', :action => 'edit', :id => @pool}, :rel=>"facebox[.bolder]", :class=>"selection_facebox" %> - <%if @vm_resource_pool.quota -%> + <%if @pool.quota -%> <%= link_to image_tag("icon_edit.png") + " Edit Quota", - {:controller => 'quota', :action => 'edit', :id => @vm_resource_pool.quota}, + {:controller => 'quota', :action => 'edit', :id => @pool.quota}, :rel=>"facebox[.bolder]", :class=>"selection_facebox" %> <%= image_tag "icon_x.png" %> Revert to Default Quota <% else -%> <%= link_to image_tag("icon_edit.png") + " Edit Quota", - {:controller => 'quota', :action => 'new', :pool_id => @vm_resource_pool }, + {:controller => 'quota', :action => 'new', :pool_id => @pool }, :rel=>"facebox[.bolder]", :class=>"selection_facebox" %> <% end -%> <% end -%> @@ -25,13 +25,13 @@ function delete_vm_quota() { $(document).trigger('close.facebox'); - $.post('<%= url_for :controller => "quota", :action => "destroy", :id => @vm_resource_pool.quota %>', + $.post('<%= url_for :controller => "quota", :action => "destroy", :id => @pool.quota %>', {x: 1}, function(data,status){ refresh_summary('vmpool_selection', '<%= url_for :controller => "resources", :action => "quick_summary" %>', - <%= @vm_resource_pool.id %>); + <%= @pool.id %>); if (data.alert) { $.jGrowl(data.alert); } @@ -39,8 +39,8 @@ } - - <% resources = @vm_resource_pool.full_resources %> + + <% resources = @pool.full_resources %>

        <% for item in resources[:labels] %> @@ -60,5 +60,5 @@
    - <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @vm_resource_pool.id, :target => 'resource' %> + <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @pool.id, :target => 'resource' %>
    diff --git a/wui/src/app/views/resources/show.rhtml b/wui/src/app/views/resources/show.rhtml index 0db3a1b..789465b 100644 --- a/wui/src/app/views/resources/show.rhtml +++ b/wui/src/app/views/resources/show.rhtml @@ -1,18 +1,18 @@
    -
    <%= image_tag "icon_vmpool.png", :style=>"vertical-align:middle;" %> <%= @vm_resource_pool.name %>


    +
    <%= image_tag "icon_vmpool.png", :style=>"vertical-align:middle;" %> <%= @pool.name %>


    <%= image_tag "icon_smry_res.png", :style=>"vertical-align:middle;" %> Resources

    - <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @vm_resource_pool.id, :params => { :target => 'vcpu' } %> - <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @vm_resource_pool.id, :params => { :target => 'vram' } %> + <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @pool.id, :params => { :target => 'vcpu' } %> + <%= render_component :controller=> 'graph', :action => 'availability_graph', :id => @pool.id, :params => { :target => 'vram' } %>


    <%= image_tag "icon_smry_his.png", :style=>"vertical-align:middle;" %> History

    - <%= render_component :controller=> 'graph', :action => 'history_graphs', :id => @vm_resource_pool.id, :params => { :poolType => 'vm' } %> + <%= render_component :controller=> 'graph', :action => 'history_graphs', :id => @pool.id, :params => { :poolType => 'vm' } %>
    <%= image_tag "icon_smry_perf.png", :style=>"vertical-align:middle;" %> Performance

    - <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @vm_resource_pool.id, :params => { :poolType => 'vm' } %> + <%= render_component :controller=> 'graph', :action => 'snapshot_graph', :id => @pool.id, :params => { :poolType => 'vm' } %>
    @@ -23,6 +23,6 @@ refresh_summary('vmpool_selection', '<%= url_for :controller => "resources", :action => "quick_summary" %>', - <%= @vm_resource_pool.id %>) + <%= @pool.id %>) diff --git a/wui/src/app/views/resources/show_tasks.rhtml b/wui/src/app/views/resources/show_tasks.rhtml index 493264b..6c92779 100644 --- a/wui/src/app/views/resources/show_tasks.rhtml +++ b/wui/src/app/views/resources/show_tasks.rhtml @@ -24,7 +24,7 @@ function apply_task_state_filter(task_state) { $tabs.tabs("url", $tabs.data("selected.tabs"), - "<%= url_for :action => 'show_tasks', :id => @vm_resource_pool.id, + "<%= url_for :action => 'show_tasks', :id => @pool.id, :nolayout => :true %>" + "&task_state=" + task_state); $tabs.tabs("load", $tabs.data("selected.tabs")); @@ -37,7 +37,7 @@ <%= render :partial => "/task/grid", :locals => { :table_id => "vm_tasks_grid", :task_type => nil, :task_state => @task_state, - :pool => @vm_resource_pool, + :pool => @pool, :checkboxes => false, :on_select => "vm_tasks_grid_select" } %>
    diff --git a/wui/src/app/views/resources/show_users.rhtml b/wui/src/app/views/resources/show_users.rhtml index 7e2538d..f23018c 100644 --- a/wui/src/app/views/resources/show_users.rhtml +++ b/wui/src/app/views/resources/show_users.rhtml @@ -1,2 +1,2 @@ <%= render :partial => "/user/show", :locals => { :parent_controller => "resources", - :pool => @vm_resource_pool } %> + :pool => @pool } %> diff --git a/wui/src/app/views/resources/show_vms.rhtml b/wui/src/app/views/resources/show_vms.rhtml index 45e0089..857f56b 100644 --- a/wui/src/app/views/resources/show_vms.rhtml +++ b/wui/src/app/views/resources/show_vms.rhtml @@ -1,6 +1,6 @@
      -
    • <%= image_tag "icon_addhost.png", :style => "vertical-align:middle;" %>  Add Virtual Machine
      • +
    • <%= image_tag "icon_addhost.png", :style => "vertical-align:middle;" %>  Add Virtual Machine
    • <%= image_tag "icon_move.png", :style => "vertical-align:middle;" %>  Actions    <%= image_tag "icon_toolbar_arrow.gif", :style => "vertical-align:middle;" %>
        @@ -28,7 +28,7 @@ { vms = get_selected_vms() if (validate_selected(vms, "vm")) { - $.post('<%= url_for :controller => "vm", :action => "delete", :id => @vm_resource_pool %>', + $.post('<%= url_for :controller => "vm", :action => "delete", :id => @pool %>', { vm_ids: vms.toString() }, function(data,status){ $tabs.tabs("load",$tabs.data('selected.tabs')); @@ -47,7 +47,7 @@ if (validate_selected(vms, "vm")) { jQuery.facebox('
        '); $('#vm_action_results').load('<%= url_for :controller => "resources", - :action => "vm_actions", :id => @vm_resource_pool %>', + :action => "vm_actions", :id => @pool %>', { vm_ids: vms.toString(), vm_action: action }); } } @@ -66,10 +66,10 @@
        -<% if @vm_resource_pool.vms.size != 0 %> +<% if @pool.vms.size != 0 %>
        <%= render :partial => "/vm/grid", :locals => { :table_id => "vms_grid", - :pool => @vm_resource_pool, + :pool => @pool, :on_select => "vms_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", @@ -88,7 +88,7 @@
        No vms found in this pool.

        <%= image_tag "icon_addhost.png", :style => "vertical-align:middle;" %>   - Add first virtual machine to resource pool + Add first virtual machine to resource pool
        diff --git a/wui/src/db/migrate/017_add_smart_pools.rb b/wui/src/db/migrate/017_add_smart_pools.rb new file mode 100644 index 0000000..6d83c02 --- /dev/null +++ b/wui/src/db/migrate/017_add_smart_pools.rb @@ -0,0 +1,62 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +class AddSmartPools < ActiveRecord::Migration + def self.up + create_table :smart_pool_tags do |t| + t.integer :smart_pool_id, :null => false + t.integer :tagged_id, :null => false + t.string :tagged_type, :null => false + end + execute "alter table smart_pool_tags add constraint + fk_smart_pool_tags_pool_id + foreign key (smart_pool_id) references pools(id)" + execute "alter table smart_pool_tags add constraint + unique_smart_pool_tags + unique (smart_pool_id, tagged_id, tagged_type)" + + begin + dir_root = DirectoryPool.get_directory_root + unless dir_root + Pool.transaction do + dir_root = DirectoryPool.create(:name=>DirectoryPool::ROOT_NAME) + hw_root = DirectoryPool.new(:name=>DirectoryPool::HARDWARE_ROOT) + hw_root.create_with_parent(dir_root) + smart_root = DirectoryPool.new(:name=>DirectoryPool::SMART_ROOT) + smart_root.create_with_parent(dir_root) + default_pool = Pool.root(:conditions=>"type='HardwarePool'") + default_pool = HardwarePool.create( :name=>'default') unless default_pool + default_pool.move_to_child_of(hw_root) + default_pool.permissions.each do |permission| + new_permission = Permission.new({:pool_id => dir_root.id, + :uid => permission.uid, + :user_role => permission.user_role}) + new_permission.save! + end + end + end + rescue + puts "Could not create DirectoryPool hierarchy..." + end + end + + def self.down + drop_table :smart_pool_tags + end +end diff --git a/wui/src/dutils/active_record_env.rb b/wui/src/dutils/active_record_env.rb index 9b7b416..14593f7 100644 --- a/wui/src/dutils/active_record_env.rb +++ b/wui/src/dutils/active_record_env.rb @@ -58,6 +58,8 @@ require 'models/permission.rb' require 'models/quota.rb' require 'models/hardware_pool.rb' +require 'models/directory_pool.rb' +require 'models/smart_pool.rb' require 'models/host.rb' require 'models/cpu.rb' require 'models/nic.rb' @@ -77,4 +79,6 @@ require 'models/nfs_storage_pool.rb' require 'models/storage_volume.rb' require 'models/iscsi_storage_volume.rb' require 'models/nfs_storage_volume.rb' +require 'models/smart_pool.rb' +require 'models/smart_pool_tag.rb' diff --git a/wui/src/script/grant_admin_privileges b/wui/src/script/grant_admin_privileges index 82595cb..866fd44 100755 --- a/wui/src/script/grant_admin_privileges +++ b/wui/src/script/grant_admin_privileges @@ -13,10 +13,11 @@ ActiveLdap::Base.establish_connection :base => base, :host => host, :try_sasl => if Account.exists?("uid=#{uid}") puts "Creating an admin account for #{uid}..." - $hwpool = HardwarePool.get_default_pool - permission = Permission.create(:user_role => Permission::ROLE_SUPER_ADMIN, - :uid => uid, - :pool_id => $hwpool.id) + $pool = DirectoryPool.get_directory_root + permission = Permission.new(:user_role => Permission::ROLE_SUPER_ADMIN, + :uid => uid, + :pool_id => $pool.id) + permission.save_with_new_children else puts "Unable to verify user: uid=#{uid}" end diff --git a/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb b/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb index cdcf0c6..e91ca93 100644 --- a/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb +++ b/wui/src/vendor/plugins/betternestedset/lib/better_nested_set.rb @@ -81,13 +81,22 @@ module SymetrieCom # Returns the single root for the class (or just the first root, if there are several). # Deprecation note: the original acts_as_nested_set allowed roots to have parent_id = 0, # so we currently do the same. This silliness will not be tolerated in future versions, however. - def root - acts_as_nested_set_options[:class].find(:first, :conditions => "(#{acts_as_nested_set_options[:parent_column]} IS NULL OR #{acts_as_nested_set_options[:parent_column]} = 0)") + def root(find_opts={}) + roots_internal(:first, find_opts) end # Returns the roots and/or virtual roots of all trees. See the explanation of virtual roots in the README. - def roots - acts_as_nested_set_options[:class].find(:all, :conditions => "(#{acts_as_nested_set_options[:parent_column]} IS NULL OR #{acts_as_nested_set_options[:parent_column]} = 0)", :order => "#{acts_as_nested_set_options[:left_column]}") + def roots(find_opts={}) + roots_internal(:all, find_opts) + end + def roots_internal(all_or_one, find_opts={}) + conditions = "(#{acts_as_nested_set_options[:parent_column]} IS NULL" + conditions += " OR #{acts_as_nested_set_options[:parent_column]} = 0)" + order_col = "#{acts_as_nested_set_options[:left_column]}" + opts = merge_incoming_opts({:conditions => conditions, + :order => order_col}, + find_opts) + acts_as_nested_set_options[:class].find(all_or_one, opts) end # Checks the left/right indexes of all records, @@ -128,6 +137,14 @@ module SymetrieCom items.map! {|e| "(#{acts_as_nested_set_options[:left_column]} BETWEEN #{e[acts_as_nested_set_options[:left_column]]} AND #{e[acts_as_nested_set_options[:right_column]]})" } "(#{items.join(' OR ')})" end + + # accept incoming opts to allow filtering of results. + # So far only tested in limited use cases encountered in oVirt devel. + def merge_incoming_opts(set_opts, incoming_opts) + new_conditions = incoming_opts.delete(:conditions) + set_opts[:conditions] = "(#{set_opts[:conditions]}) AND (#{new_conditions})" if new_conditions + set_opts.merge(incoming_opts) + end end @@ -255,7 +272,7 @@ module SymetrieCom elsif new_record? || self[right_col_name] - self[left_col_name] == 1 return [self] end - opts = merge_incoming_opts({:conditions => "#{scope_condition} #{exclude_str} AND (#{left_col_name} BETWEEN #{self[left_col_name]} AND #{self[right_col_name]})", + opts = base_set_class.merge_incoming_opts({:conditions => "#{scope_condition} #{exclude_str} AND (#{left_col_name} BETWEEN #{self[left_col_name]} AND #{self[right_col_name]})", :order => left_col_name}, find_opts) base_set_class.find(:all, opts) @@ -270,7 +287,7 @@ module SymetrieCom # Returns this record's immediate children. def children(find_opts={}) - opts = merge_incoming_opts({:conditions => "#{scope_condition} AND #{parent_col_name} = #{self.id}", + opts = base_set_class.merge_incoming_opts({:conditions => "#{scope_condition} AND #{parent_col_name} = #{self.id}", :order => left_col_name}, find_opts) base_set_class.find(:all, opts) @@ -585,14 +602,6 @@ module SymetrieCom self.class.connection.quote(value, column) end - # accept incoming opts to allow filtering of results. - # So far only tested in limited use cases encountered in oVirt devel. - def merge_incoming_opts(set_opts, incoming_opts) - new_conditions = incoming_opts.delete(:conditions) - set_opts[:conditions] = "(#{set_opts[:conditions]}) AND (#{new_conditions})" if new_conditions - set_opts.merge(incoming_opts) - end - end end end -- 1.5.5.1 From dpierce at redhat.com Wed Sep 3 17:38:07 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Wed, 3 Sep 2008 13:38:07 -0400 Subject: [Ovirt-devel] Re: initial push of smart pool code. (revised) In-Reply-To: <1220458351-3678-1-git-send-email-sseago@redhat.com> References: <1220458351-3678-1-git-send-email-sseago@redhat.com> Message-ID: <20080903173806.GD29538@redhat.com> +++ Scott Seago [03/09/08 12:12 -0400]: >This isn't complete, but I want to get it committed before the repo refactoring. This patch includes the controller refactoring needed for adding the new smart pool controllers, but I have not yet added any code to the new controllers. The models are in place for smart pools, but they aren't used anywhere yet. In addition, I've added a new DirectoryPool pool type that is used solely as a placeholder -- so that we can have a common root for all hardware and smart pools, and that we can organize smart pools by user. > >Since we need this pushed before the repo refactoring, this patch should be acked if it doesn't break anything. Separate review comments are, of course, welcome -- but anything that doesn't break the WUI will be fixed in a subsequent (post-repo-reorg) patch) ACK. The revised patch doesn't break any functionality tested. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lutter at redhat.com Wed Sep 3 18:14:35 2008 From: lutter at redhat.com (David Lutterkort) Date: Wed, 03 Sep 2008 18:14:35 +0000 Subject: [Ovirt-devel] Re: Default configuration for a new managed node... In-Reply-To: <20080903141432.GD22779@redhat.com> References: <20080827140250.GD3920@redhat.com> <48B5904B.1050106@redhat.com> <20080827174414.GA16498@redhat.com> <20080903141432.GD22779@redhat.com> Message-ID: <1220465675.4728.471.camel@localhost.localdomain> On Wed, 2008-09-03 at 10:14 -0400, Darryl L. Pierce wrote: > If a node has a NIC that's not in the database, then the configuration that's > returned will return nothing for deleting the files for that NIC in > /etc/sysconfig/networking-scripts. So, when networking is restarted, those > new NICs will come up with whatever local network configuration is present, > yes? Isn't that just 'nothing', since there is no ifcfg-* file for that NIC ? If we ever persist config information on the node, we also need to make sure that ifcfg-* files for NICs that were removed from the system are deleted. David From imain at redhat.com Wed Sep 3 18:43:12 2008 From: imain at redhat.com (Ian Main) Date: Wed, 3 Sep 2008 11:43:12 -0700 Subject: [Ovirt-devel] [PATCH] Added the current date/time stamp to the host-browser log. In-Reply-To: <1219952899-23188-1-git-send-email-dpierce@redhat.com> References: <1219952899-23188-1-git-send-email-dpierce@redhat.com> Message-ID: <20080903114312.15db81e1@tp.mains.net> On Thu, 28 Aug 2008 15:48:19 -0400 "Darryl L. Pierce" wrote: > The format of the log is "MMM DD HH:MM:SS [ip address] " for all > log entries. Looks good. ACK. Ian From lutter at redhat.com Thu Sep 4 00:25:51 2008 From: lutter at redhat.com (David Lutterkort) Date: Thu, 04 Sep 2008 00:25:51 +0000 Subject: [Ovirt-devel] [PATCH] initial push of smart pool code. (revised) In-Reply-To: <1220458351-3678-1-git-send-email-sseago@redhat.com> References: <1220458351-3678-1-git-send-email-sseago@redhat.com> Message-ID: <1220487951.4728.529.camel@localhost.localdomain> On Wed, 2008-09-03 at 12:12 -0400, Scott Seago wrote: > This isn't complete, but I want to get it committed before the repo > refactoring. This patch includes the controller refactoring needed for > adding the new smart pool controllers, but I have not yet added any > code to the new controllers. The models are in place for smart pools, > but they aren't used anywhere yet. In addition, I've added a new > DirectoryPool pool type that is used solely as a placeholder -- so > that we can have a common root for all hardware and smart pools, and > that we can organize smart pools by user. > > Since we need this pushed before the repo refactoring, this patch > should be acked if it doesn't break anything. Separate review comments > are, of course, welcome -- but anything that doesn't break the WUI > will be fixed in a subsequent (post-repo-reorg) patch) > > Signed-off-by: Scott Seago Looks good overall. > diff --git a/wui/src/app/controllers/hardware_controller.rb b/wui/src/app/controllers/hardware_controller.rb > index 7c1d916..091ce97 100644 > --- a/wui/src/app/controllers/hardware_controller.rb > +++ b/wui/src/app/controllers/hardware_controller.rb > @@ -18,7 +18,7 @@ > # also available at http://www.gnu.org/copyleft/gpl.html. > # > > -class HardwareController < ApplicationController > +class HardwareController < PoolController > > XML_OPTS = { > :include => [ :storage_pools, :hosts, :quota ] XML_OPTS also needs to be moved to PoolController, since it's used in show. > diff --git a/wui/src/app/models/pool.rb b/wui/src/app/models/pool.rb > index 6599c72..9d71fa5 100644 > --- a/wui/src/app/models/pool.rb > +++ b/wui/src/app/models/pool.rb > + def self.find_by_path(path) > + segs = path.split("/") > + unless segs.shift.empty? > + raise "Path must be absolute, but is #{path}" > + end > + default_pool = DirectoryPool.get_directory_root > + if segs.shift == default_pool.name > + segs.inject(default_pool) do |pool, seg| > + pool.children.find { |p| p.name == seg } if pool > + end > + end > + end This should probably be changed a little - I don't think there's a need to expose the internal /root prefix, i.e. we should have paths like /hardware/default/mypool and /users/joe/hispool. David From terashima.naoya at np.css.fujitsu.com Thu Sep 4 00:45:25 2008 From: terashima.naoya at np.css.fujitsu.com (Naoya Terashima) Date: Thu, 4 Sep 2008 09:45:25 +0900 Subject: [Ovirt-devel] About the process of generating nodes Message-ID: <00bc01c90e27$855651f0$b16f210a@FMAFC020FC868C> I have a question. When I unpacked ovirt-appliance-0.92-1-i386.tar, create-wui-appliance.sh and ovirt-appliance.img was came out. But There are no img files of nodes. How come node3, node4, and node5 are generated without img file? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmyers at redhat.com Thu Sep 4 00:51:14 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 03 Sep 2008 20:51:14 -0400 Subject: [Ovirt-devel] About the process of generating nodes In-Reply-To: <00bc01c90e27$855651f0$b16f210a@FMAFC020FC868C> References: <00bc01c90e27$855651f0$b16f210a@FMAFC020FC868C> Message-ID: <48BF3102.7040702@redhat.com> Naoya Terashima wrote: > I have a question. > When I unpacked ovirt-appliance-0.92-1-i386.tar, create-wui-appliance.sh > and ovirt-appliance.img was came out. > But There are no img files of nodes. > How come node3, node4, and node5 are generated without img file? In the oVirt Appliance that you downloaded the oVirt Nodes are booted from a PXE server running on the appliance. So the images for the Nodes are embedded in the appliance in the /var/lib/tftpd directory. Perry From jim at meyering.net Thu Sep 4 10:01:22 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 04 Sep 2008 12:01:22 +0200 Subject: [Ovirt-devel] (new?) build-all -a failure, plus temporary work-around Message-ID: <87k5dsmdql.fsf@rho.meyering.net> "build-all -a" worked fine when I ran it, yesterday, but today it failed with this: cannot create directory `.../ovirt/wui/rpm-build/BUILDROOT/ovirt-wui-0.93-1.1.200809040929git825a783.fc10.x86_64': No such file or directory -------------------- $ sudo ./build-all.sh -a ... + cd ovirt-wui-0.93 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.TD3EpF + umask 022 + cd /home/meyering/w/co/ovirt/wui/rpm-build + cd ovirt-wui-0.93 + LANG=C + export LANG + unset DISPLAY + exit 0 Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.IE9Pl1 + umask 022 + cd /home/meyering/w/co/ovirt/wui/rpm-build + cd ovirt-wui-0.93 + LANG=C + export LANG + unset DISPLAY + test x/home/meyering/w/co/ovirt/wui/rpm-build/BUILDROOT/ovirt-wui-0.93-1.1.200809040929git825a783.fc10.x86_64 '!=' x + rm -rf /home/meyering/w/co/ovirt/wui/rpm-build/BUILDROOT/ovirt-wui-0.93-1.1.200809040929git825a783.fc10.x86_64 + mkdir /home/meyering/w/co/ovirt/wui/rpm-build/BUILDROOT/ovirt-wui-0.93-1.1.200809040929git825a783.fc10.x86_64 mkdir: cannot create directory `/home/meyering/w/co/ovirt/wui/rpm-build/BUILDROOT/ovirt-wui-0.93-1.1.200809040929git825a783.fc10.x86_64': No such file or directory error: Bad exit status from /var/tmp/rpm-tmp.IE9Pl1 (%install) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.IE9Pl1 (%install) make: *** [rpms] Error 1 [Exit 2] Note that BUILDROOT doesn't exist yet: $ ls wui/rpm-build/ ovirt-wui-0.93/ ovirt-wui-0.93.tar.gz version The code that prepares that particular rpm-build directory is in wui/Makefile, but there are at least two other spots with identical sequences of commands (down to unnecessary trialing slash): $ g grep cp.version ovirt-host-creator/Makefile: cp version rpm-build/ ovirt-managed-node/Makefile: cp version rpm-build/ wui/Makefile: cp version rpm-build/ This patch fixes the immediate problem, however, ... diff --git a/wui/Makefile b/wui/Makefile index 0819cfe..c58f279 100644 --- a/wui/Makefile +++ b/wui/Makefile @@ -21,6 +21,7 @@ tar: clean mkdir -p rpm-build tar zcvf rpm-build/$(NV).tar.gz $(NV) cp version rpm-build/ + mkdir rpm-build/BUILDROOT rm -rf $(NV) # convience method to simulate make install, not for production use The following one makes the same change to the other two rules: (this isn't really a patch proposal, since I'll first have to see if we can factor out the duplication). Will report back soon. diff --git a/ovirt-host-creator/Makefile b/ovirt-host-creator/Makefile index d1dbfc2..fe20373 100644 --- a/ovirt-host-creator/Makefile +++ b/ovirt-host-creator/Makefile @@ -26,6 +26,7 @@ tar: clean ovirt.iso mkdir -p rpm-build tar zcvf rpm-build/$(NV).tar $(NV) cp version rpm-build/ + mkdir rpm-build/BUILDROOT rm -rf $(NV) .PHONY: all clean tar distclean diff --git a/ovirt-managed-node/Makefile b/ovirt-managed-node/Makefile index bf42e39..7ea8cb8 100644 --- a/ovirt-managed-node/Makefile +++ b/ovirt-managed-node/Makefile @@ -34,6 +34,7 @@ tar: clean mkdir -p rpm-build tar zcvf rpm-build/$(NV).tar.gz $(NV) cp version rpm-build/ + mkdir rpm-build/BUILDROOT rm -rf $(NV) .PHONY: all clean tar diff --git a/wui/Makefile b/wui/Makefile index 0819cfe..c58f279 100644 --- a/wui/Makefile +++ b/wui/Makefile @@ -21,6 +21,7 @@ tar: clean mkdir -p rpm-build tar zcvf rpm-build/$(NV).tar.gz $(NV) cp version rpm-build/ + mkdir rpm-build/BUILDROOT rm -rf $(NV) # convience method to simulate make install, not for production use From jim at meyering.net Thu Sep 4 10:07:43 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 04 Sep 2008 12:07:43 +0200 Subject: [Ovirt-devel] (new?) build-all -a failure, plus temporary work-around In-Reply-To: <87k5dsmdql.fsf@rho.meyering.net> (Jim Meyering's message of "Thu, 04 Sep 2008 12:01:22 +0200") References: <87k5dsmdql.fsf@rho.meyering.net> Message-ID: <87ej40mdg0.fsf@rho.meyering.net> Jim Meyering wrote: > "build-all -a" worked fine when I ran it, yesterday, but today > it failed with this: Alan Pevec asked the right question: "you're using rawhide, right?" I answered "Yep, and just upgraded it last night.". So this may well be due to a new version of rpm. From mmorsi at redhat.com Thu Sep 4 11:15:54 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Thu, 4 Sep 2008 07:15:54 -0400 Subject: [Ovirt-devel] [PATCH] added ability to reprovision vm via edit vm form Message-ID: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> --- wui/src/app/controllers/vm_controller.rb | 73 +++++++++++++++++++++++++----- wui/src/app/views/vm/_form.rhtml | 6 ++- 2 files changed, 65 insertions(+), 14 deletions(-) diff --git a/wui/src/app/controllers/vm_controller.rb b/wui/src/app/controllers/vm_controller.rb index e55ec28..82d8952 100644 --- a/wui/src/app/controllers/vm_controller.rb +++ b/wui/src/app/controllers/vm_controller.rb @@ -96,6 +96,28 @@ class VmController < ApplicationController end params[:vm][:needs_restart] = 1 if needs_restart @vm.update_attributes!(params[:vm]) + _setup_vm_provision(params) + + if (params[:start_now] and @vm.get_action_list.include?(VmTask::ACTION_START_VM) ) + @task = VmTask.new({ :user => @user, + :vm_id => @vm.id, + :action => VmTask::ACTION_START_VM, + :state => Task::STATE_QUEUED}) + @task.save! + elsif ( params[:restart_now] and @vm.get_action_list.include?(VmTask::ACTION_SHUTDOWN_VM) ) + @task = VmTask.new({ :user => @user, + :vm_id => @vm.id, + :action => VmTask::ACTION_SHUTDOWN_VM, + :state => Task::STATE_QUEUED}) + @task.save! + @task = VmTask.new({ :user => @user, + :vm_id => @vm.id, + :action => VmTask::ACTION_START_VM, + :state => Task::STATE_QUEUED}) + @task.save! + end + + render :json => { :object => "vm", :success => true, :alert => 'Vm was successfully updated.' } rescue @@ -193,6 +215,43 @@ class VmController < ApplicationController end protected + def _setup_provisioning_options + @provisioning_options = [[Vm::PXE_OPTION_LABEL, Vm::PXE_OPTION_VALUE], + [Vm::HD_OPTION_LABEL, Vm::HD_OPTION_VALUE]] + # FIXME add cobbler images too + begin + @provisioning_options += Cobbler::Profile.find.collect do |profile| + [profile.name + Vm::COBBLER_PROFILE_SUFFIX, profile.name] + + end + rescue + #if cobbler doesn't respond/is misconfigured/etc just don't add profiles + end + end + + def _setup_vm_provision(params) + # spaces are invalid in the cobbler name + name = params[:vm][:description].gsub(" ", "-") + provision = params[:vm][:provisioning_and_boot_settings] + unless provision == Vm::PXE_OPTION_VALUE or + provision == Vm::HD_OPTION_VALUE + found = false + Cobbler::System.find.each{ |system| + if system.name == name + system.profile = provision + system.save + found = true + end + } + unless found + system = Cobbler::System.create("name" => name, + "profile" => provision) + # do we need to set any of the other system attributes? + system.save + end + end + end + def pre_new # if no vm_resource_pool is passed in, find (or auto-create) it based on hardware_pool_id unless params[:vm_resource_pool_id] @@ -229,18 +288,7 @@ class VmController < ApplicationController @perm_obj = @vm.vm_resource_pool @redir_controller = 'resources' @current_pool_id=@perm_obj.id - @provisioning_options = [[Vm::PXE_OPTION_LABEL, Vm::PXE_OPTION_VALUE], - [Vm::HD_OPTION_LABEL, Vm::HD_OPTION_VALUE]] - # FIXME add cobbler images too - begin - @provisioning_options += Cobbler::Profile.find.collect do |profile| - [profile.name + Vm::COBBLER_PROFILE_SUFFIX, - Vm::COBBLER_PREFIX + Vm::PROVISIONING_DELIMITER + - Vm::PROFILE_PREFIX + Vm::PROVISIONING_DELIMITER + profile.name] - end - rescue - #if cobbler doesn't respond/is misconfigured/etc just don't add profiles - end + _setup_provisioning_options end def pre_create params[:vm][:state] = Vm::STATE_PENDING @@ -267,6 +315,7 @@ class VmController < ApplicationController @perm_obj = @vm.vm_resource_pool @redir_obj = @vm @current_pool_id=@perm_obj.id + _setup_provisioning_options end def pre_vm_action pre_edit diff --git a/wui/src/app/views/vm/_form.rhtml b/wui/src/app/views/vm/_form.rhtml index 60ed003..3d4cd79 100644 --- a/wui/src/app/views/vm/_form.rhtml +++ b/wui/src/app/views/vm/_form.rhtml @@ -8,7 +8,8 @@ <%= hidden_field_tag 'hardware_pool_id', @hardware_pool.id if @hardware_pool %> <%= text_field_with_label "Name:", "vm", "description", {:style=>"width:250px;"} %> - <%= select_with_label "Operating System:", 'vm', 'provisioning_and_boot_settings', @provisioning_options, :style=>"width:250px;" if create %> + <%= select_with_label "Operating System:", 'vm', 'provisioning_and_boot_settings', @provisioning_options, :style=>"width:250px;" %> + <% if controller.action_name == "edit" %>*Warning* Editing provision could overwrite vm<% end %>
        Resources
        @@ -50,7 +51,8 @@
        - <%= check_box_tag_with_label "Start VM Now? (pending current resource availability)", "start_now", nil if create%> + <%= check_box_tag_with_label "Start VM Now? (pending current resource availability)", "start_now", nil if create or @vm.state == Vm::STATE_STOPPED %> + <%= check_box_tag_with_label "Restart VM Now? (pending current resource availability)", "restart_now", nil if @vm.state == Vm::STATE_RUNNING %> diff --git a/wui/src/app/views/resources/_grid.rhtml b/wui/src/app/views/resources/_grid.rhtml index 301a7aa..908eac7 100644 --- a/wui/src/app/views/resources/_grid.rhtml +++ b/wui/src/app/views/resources/_grid.rhtml @@ -35,7 +35,12 @@ } function <%= table_id %>_load_widget(celDiv) { - load_widget(celDiv, "resource"); + //FIXME: there is no real data save for vmpool load, so stub out for now + var loadAvg = getAverage(2.3); + var loadCss = (loadAvg >50) ? "load_graph_high" : "load_graph_low"; + $(celDiv).html('
        '); }; diff --git a/wui/src/public/javascripts/ovirt.js b/wui/src/public/javascripts/ovirt.js index 9a0d4b7..af0b9f6 100644 --- a/wui/src/public/javascripts/ovirt.js +++ b/wui/src/public/javascripts/ovirt.js @@ -28,6 +28,13 @@ function validate_selected(selected_array, name) } } +function getAverage(val) { + if (isNaN(val)) return 0; + //FIXME: currently using a magic number of 5 which should be replaced + //with comething more meaningful. + return (val/5 < 1) ? ((val/5) * 100) : 100; +} + function add_hosts(url) { hosts= get_selected_checkboxes("addhosts_grid_form"); diff --git a/wui/src/public/stylesheets/components.css b/wui/src/public/stylesheets/components.css index 56cadf2..16eaf62 100644 --- a/wui/src/public/stylesheets/components.css +++ b/wui/src/public/stylesheets/components.css @@ -253,8 +253,14 @@ /* load graphs in flexigrid */ .load_graph { + padding: 0px !important; + height: 10px; + border:#F5AFA8 solid 1px; } +.load_graph_low {background: url(../images/chart_horiz_blue.png) repeat-x;} +.load_graph_high {background: url(../images/chart_horiz_orange.png) repeat-x;} + /************************* * details pane style * *************************/ diff --git a/wui/src/public/stylesheets/flexigrid/flexigrid.css b/wui/src/public/stylesheets/flexigrid/flexigrid.css index f8f8037..cd1902f 100644 --- a/wui/src/public/stylesheets/flexigrid/flexigrid.css +++ b/wui/src/public/stylesheets/flexigrid/flexigrid.css @@ -469,7 +469,7 @@ div.colCopy { .flexigrid div.bDiv td { border-bottom: 1px solid #fff; - vertical-align: top; + /*vertical-align: top;*/ white-space: nowrap; } -- 1.5.5.1 From clalance at redhat.com Thu Sep 4 16:32:58 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 04 Sep 2008 18:32:58 +0200 Subject: [Ovirt-devel] NIC bonding and failover... In-Reply-To: <20080904152858.GA14259@redhat.com> References: <20080904152858.GA14259@redhat.com> Message-ID: <48C00DBA.8040803@redhat.com> Darryl L. Pierce wrote: > GOAL: > > To allow the user to create a bonding to enslave two or more network > interfaces together. Bonded interfaces can then be used for load balancing > and fail-over. > > DESIGN CONSIDERATIONS: > > The two primary modes of operation are round-robin and failover. With > round-robin you get a general load-balancing scheme between the enslaved > interfaces. With failover, the primary interface is used until it fails, then > the backup(s) are used. I think for now, if we concentrate on these two, that will cover the majority of cases, and we can add the more complex cases later. However, you have to be aware that there are multiple ways to set these up. I'm definitely not a bonding expert, but I do know that some types of setups (blades, for instance), cannot do the most efficient "ethtool" checking of path failover; they must use some kind of arp_interval ping to determine if the other path is still up. So you need to expose not only "Round-robin" and "failover", but you also need to expose which method the admin wants to use. Chris Lalancette From dpierce at redhat.com Thu Sep 4 17:03:43 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 4 Sep 2008 13:03:43 -0400 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <48C00DBA.8040803@redhat.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> Message-ID: <20080904170342.GB18735@redhat.com> +++ Chris Lalancette [04/09/08 18:32 +0200]: >Darryl L. Pierce wrote: >> GOAL: >> >> To allow the user to create a bonding to enslave two or more network >> interfaces together. Bonded interfaces can then be used for load balancing >> and fail-over. >> >> DESIGN CONSIDERATIONS: >> >> The two primary modes of operation are round-robin and failover. With >> round-robin you get a general load-balancing scheme between the enslaved >> interfaces. With failover, the primary interface is used until it fails, then >> the backup(s) are used. > >I think for now, if we concentrate on these two, that will cover the majority of >cases, and we can add the more complex cases later. However, you have to be >aware that there are multiple ways to set these up. I'm definitely not a >bonding expert, but I do know that some types of setups (blades, for instance), >cannot do the most efficient "ethtool" checking of path failover; they must use >some kind of arp_interval ping to determine if the other path is still up. So >you need to expose not only "Round-robin" and "failover", but you also need to >expose which method the admin wants to use. I'm in the not-an-expert camp as well. But, whe nyou say "expose which method" what do you mean there? From my understanding, the way you would configure bonding is to load the bonding module and specify which mode to use there via "modprobe bonding mode=[#] miimon=[interval]". Is there some additional set of arguments to the module? -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From clalance at redhat.com Thu Sep 4 17:46:13 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 04 Sep 2008 19:46:13 +0200 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <20080904170342.GB18735@redhat.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> <20080904170342.GB18735@redhat.com> Message-ID: <48C01EE5.2030200@redhat.com> Darryl L. Pierce wrote: > I'm in the not-an-expert camp as well. But, whe nyou say "expose which > method" what do you mean there? From my understanding, the way you would > configure bonding is to load the bonding module and specify which mode to use > there via "modprobe bonding mode=[#] miimon=[interval]". Is there some The above is correct. And, miimon is the preferred way to do *if you can use it*. As I understand it, what the miimon method does is to periodically check the status of the link as the kernel understand it (using the same method that mii-tool, for instance, would). However, in blade setups, they tend to have an internal switch that the blades connect to, and then that switch connects to the outside world. In this case, monitoring the status of the link on an individual blade doesn't tell you much; it only tells you whether you are connected to the internal switch, not if you are connected to the external network. In these cases, you actually have to use the arp_ping method (it's not called that, but something similar). In this method, you actually periodically try to reach the "other" path via an ARP frame, to test your connectivity. So you would actually load the module like: modprobe bond mode=# arp_ping=ip arp_interval=xxx That's what I'm saying you have to expose; the ability to choose miimon (probably the default), or arp_ping, or another method (there may be more, these are just the two I know about). Chris Lalancette From dpierce at redhat.com Thu Sep 4 18:11:03 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 4 Sep 2008 14:11:03 -0400 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <48C01EE5.2030200@redhat.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> <20080904170342.GB18735@redhat.com> <48C01EE5.2030200@redhat.com> Message-ID: <20080904181103.GD24602@redhat.com> +++ Chris Lalancette [04/09/08 19:46 +0200]: >modprobe bond mode=# arp_ping=ip arp_interval=xxx > >That's what I'm saying you have to expose; the ability to choose miimon >(probably the default), or arp_ping, or another method (there may be more, these >are just the two I know about). Ah, okay, I see what you're saying. We could store with the bonding record the arp ping and interval settings. If either is present, then we'd include the appropriate argument in the modprobe line. Would those to be advanced options? IOW, should they be present on the configuration screen or should they only show if the user selects to configure advanced settings? -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From konrad at virtualiron.com Thu Sep 4 18:12:34 2008 From: konrad at virtualiron.com (Konrad Rzeszutek) Date: Thu, 4 Sep 2008 14:12:34 -0400 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <48C01EE5.2030200@redhat.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> <20080904170342.GB18735@redhat.com> <48C01EE5.2030200@redhat.com> Message-ID: <20080904181234.GB25386@mars.virtualiron.com> On Thu, Sep 04, 2008 at 07:46:13PM +0200, Chris Lalancette wrote: > Darryl L. Pierce wrote: > > I'm in the not-an-expert camp as well. But, whe nyou say "expose which > > method" what do you mean there? From my understanding, the way you would > > configure bonding is to load the bonding module and specify which mode to use > > there via "modprobe bonding mode=[#] miimon=[interval]". Is there some .. snip .. > modprobe bond mode=# arp_ping=ip arp_interval=xxx You still need the steps to enslave a NIC to the bond, setting which type it is, etc. What about a situation in which you want two types of bonds (ie, bond0 is fault tolerant, while bond1 is the load balance one - you can't just say 'modprobe bond1 mode=3). And then comes the monitoring part - are you going to send events if a slave goes down? I would be curious to know what you guys think is the right way to solve these problems? From clalance at redhat.com Thu Sep 4 18:43:24 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 04 Sep 2008 20:43:24 +0200 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <20080904181234.GB25386@mars.virtualiron.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> <20080904170342.GB18735@redhat.com> <48C01EE5.2030200@redhat.com> <20080904181234.GB25386@mars.virtualiron.com> Message-ID: <48C02C4C.1050706@redhat.com> Konrad Rzeszutek wrote: > On Thu, Sep 04, 2008 at 07:46:13PM +0200, Chris Lalancette wrote: >> Darryl L. Pierce wrote: >>> I'm in the not-an-expert camp as well. But, whe nyou say "expose which >>> method" what do you mean there? From my understanding, the way you would >>> configure bonding is to load the bonding module and specify which mode to use >>> there via "modprobe bonding mode=[#] miimon=[interval]". Is there some > .. snip .. >> modprobe bond mode=# arp_ping=ip arp_interval=xxx > > You still need the steps to enslave a NIC to the bond, setting which type it is, etc. Right, this will all be done at boot time, based on what the admin configures. > What about a situation in which you want two types of bonds (ie, bond0 is fault tolerant, > while bond1 is the load balance one - you can't just say 'modprobe bond1 mode=3). There is some way to do that in modern Linux systems....this is the part where I'm not an expert :). > > And then comes the monitoring part - are you going to send events if a slave goes > down? Yeah, that's definitely something we would want to know about. Maybe we can have some collectd plugin that does this for us; I'm not certain at the moment. > > I would be curious to know what you guys think is the right way to solve these problems? Don't get me wrong; there are a lot of issues around bonding. But I guess we'll start small and build from there :). Chris Lalancette From jeffschroed at gmail.com Thu Sep 4 18:49:24 2008 From: jeffschroed at gmail.com (Jeff Schroeder) Date: Thu, 4 Sep 2008 11:49:24 -0700 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <48C02C4C.1050706@redhat.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> <20080904170342.GB18735@redhat.com> <48C01EE5.2030200@redhat.com> <20080904181234.GB25386@mars.virtualiron.com> <48C02C4C.1050706@redhat.com> Message-ID: On Thu, Sep 4, 2008 at 11:43 AM, Chris Lalancette wrote: ... > Don't get me wrong; there are a lot of issues around bonding. But I guess we'll > start small and build from there :). With multiple bonds, you're going to need to specify the maxbonds parameter. I've seen the kernel get angry several times if you don't specify this when using more than 1 bonded pair of nics. Don't remember if that was RHEL4 or RHEL5 I saw that on, but it was pretty recent. -- Jeff Schroeder Don't drink and derive, alcohol and analysis don't mix. http://www.digitalprognosis.com From konrad at virtualiron.com Thu Sep 4 19:10:45 2008 From: konrad at virtualiron.com (Konrad Rzeszutek) Date: Thu, 4 Sep 2008 15:10:45 -0400 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <48C02C4C.1050706@redhat.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> <20080904170342.GB18735@redhat.com> <48C01EE5.2030200@redhat.com> <20080904181234.GB25386@mars.virtualiron.com> <48C02C4C.1050706@redhat.com> Message-ID: <20080904191045.GA25777@mars.virtualiron.com> On Thu, Sep 04, 2008 at 08:43:24PM +0200, Chris Lalancette wrote: > Konrad Rzeszutek wrote: > > On Thu, Sep 04, 2008 at 07:46:13PM +0200, Chris Lalancette wrote: > >> Darryl L. Pierce wrote: > >>> I'm in the not-an-expert camp as well. But, whe nyou say "expose which > >>> method" what do you mean there? From my understanding, the way you would > >>> configure bonding is to load the bonding module and specify which mode to use > >>> there via "modprobe bonding mode=[#] miimon=[interval]". Is there some > > .. snip .. > >> modprobe bond mode=# arp_ping=ip arp_interval=xxx > > > > You still need the steps to enslave a NIC to the bond, setting which type it is, etc. > > Right, this will all be done at boot time, based on what the admin configures. What is the delivery mechanism? Is it going to be similar to the way the krb5.tab is being found+pulled. And then the config file would be parsed and set the right things? Or would this be done via libvirt (http://wiki.libvirt.org/page/TodoNICBonding) .. snip .. > > I would be curious to know what you guys think is the right way to solve these problems? > > Don't get me wrong; there are a lot of issues around bonding. But I guess we'll > start small and build from there :). Yes definitely. I am trying to grok the libvirt+ovirt way and figured that asking questions like these would crystallize a good understanding in my mind. > > Chris Lalancette From dpierce at redhat.com Thu Sep 4 19:17:12 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 4 Sep 2008 15:17:12 -0400 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <20080904191045.GA25777@mars.virtualiron.com> References: <20080904152858.GA14259@redhat.com> <48C00DBA.8040803@redhat.com> <20080904170342.GB18735@redhat.com> <48C01EE5.2030200@redhat.com> <20080904181234.GB25386@mars.virtualiron.com> <48C02C4C.1050706@redhat.com> <20080904191045.GA25777@mars.virtualiron.com> Message-ID: <20080904191711.GK24602@redhat.com> +++ Konrad Rzeszutek [04/09/08 15:10 -0400]: >> > You still need the steps to enslave a NIC to the bond, setting which type it is, etc. >> >> Right, this will all be done at boot time, based on what the admin configures. > > > >What is the delivery mechanism? Is it going to be similar to the way the krb5.tab is >being found+pulled. And then the config file would be parsed and set the right >things? Or would this be done via libvirt (http://wiki.libvirt.org/page/TodoNICBonding) After the node identifies itself to the oVirt server, it downloads a configuration file. That file is processed by augtool[1]. The managed node that restarts the network service, which will take down all network interfaces and then bring them back up, applying the network configuration that was just retrieved. [1] http://augeas.net/ -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From imain at redhat.com Thu Sep 4 20:34:03 2008 From: imain at redhat.com (Ian Main) Date: Thu, 4 Sep 2008 13:34:03 -0700 Subject: [Ovirt-devel] VM Installation problem (and proposed solution) In-Reply-To: <48BE5FFD.1010300@redhat.com> References: <48B6C226.80601@redhat.com> <20080828152639.GD26373@redhat.com> <48B79244.6090102@redhat.com> <20080903093937.GA20308@redhat.com> <48BE5FFD.1010300@redhat.com> Message-ID: <20080904133403.73d50586@tp.mains.net> On Wed, 03 Sep 2008 05:59:25 -0400 "Perry N. Myers" wrote: > Daniel P. Berrange wrote: > > On Fri, Aug 29, 2008 at 08:08:04AM +0200, Chris Lalancette wrote: > >> Daniel P. Berrange wrote: > >>> On Thu, Aug 28, 2008 at 05:20:06PM +0200, Chris Lalancette wrote: > >>>> Hello all (Ian especially), > >>>> apevec pointed out a problem with installation of guests under oVirt. What > >>>> currently happens is that after you finish the installation of (say) Fedora in a > >>>> VM, the VM reboots, but then immediately PXE boots again. This is because we > >>>> haven't killed the guest and re-defined the XML to have the boot device be the > >>>> hard drive, like it should. > >>> You don't have to wait for installation to finish before re-defining the > >>> XML with hard drive as the boot device > >>> > >>> You can define the post-install XML config the moment the guest has booted. > >>> When it shuts down, libvirt will automatically switch over to the newly > >>> defined config. This is how virt-install handles it. > >> Yes, true. The difference is because of the asynchronous nature of taskomatic, > >> we basically kick off the guest on the node, and then go on to do other things. > >> The next time we would hear anything about this guest is when host-status > >> eventually polled it and noticed it "shutoff" (even though we think it is > >> running). So then we would need to perform the heuristic of "if this was > >> install time, and the guest is now dead, restart it". Just doing all of this > >> out on the node will reduce our round-trips to the server, and do the whole > >> thing in a more timely fashion. That's why I think it is better to do this > >> whole thing remotely on the node. > > > > The trouble with this is that it does not map onto a libvirt API cleanly. > > The idea behind the AMQP binding was to map 1-to-1 onto the libvirt API > > and not invent oVirt specific constructs in the API. I think we need to > > come up with some way to perform this automatic reboot with different XML > > within the scope of the libvirt API. Not quite sure what that would mean > > though. Perhaps a new lifecycle action for the tag, to explicitly > > represent a 'destroy+restart' semantic. > > I agree with you that solving this in a libvirt way would be better (I > like the destroy+restart semantic idea that seems very clean). > > However, I do think that not every ovirt action will be able to be a 1-1 > map with libvirt and we might need ovirt specific AMQP calls. For > example, libvirt doesn't know anything about a call like "set the collectd > performance gathering interval to 5 minutes" or "reboot the physical node" > I'm sure there will be other things that also will not fit into libvirt. > > So what I'm thinking is that we need libvirt-qpid and ovirt-qpid. Does > this make sense? Yes, that's likely what will end up happening. It would be nice to have it all in one binary, but I suspect that won't happen because of the packaging; having libvirt-qpid be a standalone thing. > > But as for adding the new lifecycle action for on-reboot, if you think > that is the best way to solve this problem then this is what we should do. > Let me know how that proceeds. I like that best as well. Ian From jim at meyering.net Fri Sep 5 07:08:25 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 05 Sep 2008 09:08:25 +0200 Subject: [Ovirt-devel] [PATCH] docs/Makefile (publish): Remove no-op "TBD" rules. Message-ID: <87wshrhxxy.fsf@rho.meyering.net> Hmm... beginning to see a small problem here. I would have much preferred to see "docs/Makefile" in the patch itself. With sub-directories and the occasional file (like Makefile) that appears in each of the newly-split 6 repositories, there's ample room for misapplication of patches and general confusion. This fixes the warnings from "make -f ovirt.mk clean": make[1]: Entering directory `/f/mirror/ov2/docs' Makefile:16: warning: overriding commands for target `publish' release.mk:51: warning: ignoring old commands for target `publish' Makefile:19: warning: overriding commands for target `rpms' release.mk:46: warning: ignoring old commands for target `rpms' >From 35e94ddaf9e15439670ffbef14b0a752353b8348 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 08:59:35 +0200 Subject: [PATCH] Makefile (publish, rpms): Remove no-op "TBD" rules. They conflicted with the ones in release.mk. --- Makefile | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 74352d5..4555e4a 100644 --- a/Makefile +++ b/Makefile @@ -12,10 +12,4 @@ distclean: clean tar: clean echo "TBD" -publish: - echo "TBD" - -rpms: - echo "TBD" - .PHONY: all clean distclean tar -- 1.6.0.1.216.g1b23a From jim at meyering.net Fri Sep 5 07:11:46 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 05 Sep 2008 09:11:46 +0200 Subject: [Ovirt-devel] [PATCH] ovirt.mk: factor Message-ID: <87r67zhxsd.fsf@rho.meyering.net> Here's a patch to factor out some duplication. >From eb98bd5c75a4cbb7469b6e377df8dfcb0bc2034e Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 08:48:54 +0200 Subject: [PATCH] ovirt.mk: factor (for_each_subdir): Define. (clean, distclean, bumpgit, bumprelease, bumpversion): Use it. (status): Use cd-in-a-subshell, not pushd+popd. --- ovirt.mk | 54 ++++++++++++++++++------------------------------------ 1 files changed, 18 insertions(+), 36 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index eba36d6..e61f83b 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -10,59 +10,43 @@ SUBDIRS ?= release server node node-image appliance docs export OVIRT_CACHE_DIR ?= $(HOME)/ovirt-cache +define for_each_subdir + for dir in $(SUBDIRS); do \ + if test -d $$dir ; then \ + $(MAKE) -C $$dir $@ || exit 1 ; \ + fi ; \ + done +endef + all: dev-build update: $(SUBDIRS) $(SUBDIRS): - if ! test -d $@; then \ - git clone $(OVIRT_GIT_SERVER)/ovirt-$@ $@ ; \ - fi ; \ - cd $@ ; \ - if ! test "$(OVIRT_BRANCH)" = "master" ; then \ - git config remote.origin.fetch +$(OVIRT_BRANCH):$(OVIRT_BRANCH) ; \ - fi ; \ - git pull -v && git checkout $(OVIRT_BRANCH) ; \ + test -d $@ && : || git clone $(OVIRT_GIT_SERVER)/ovirt-$@ $@ + cd $@ && test "$(OVIRT_BRANCH)" = "master" && \ + git config remote.origin.fetch +$(OVIRT_BRANCH):$(OVIRT_BRANCH) + git pull -v && git checkout $(OVIRT_BRANCH) clean: - for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - $(MAKE) -C $$dir $@ || exit 1 ; \ - fi ; \ - done + $(for_each_subdir) distclean: - for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - $(MAKE) -C $$dir $@ || exit 1 ; \ - fi ; \ - done + $(for_each_subdir) bumpgit: - for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - $(MAKE) -C $$dir $@ || exit 1 ; \ - fi ; \ - done + $(for_each_subdir) bumprelease: - for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - $(MAKE) -C $$dir $@ || exit 1 ; \ - fi ; \ - done + $(for_each_subdir) bumpversion: - for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - $(MAKE) -C $$dir $@ || exit 1 ; \ - fi ; \ - done + $(for_each_subdir) status: for dir in $(SUBDIRS); do \ if test -d $$dir ; then \ - pushd $$dir ; git $@ ; popd > /dev/null ; \ + (cd $$dir && git $@) ; \ fi ; \ done @@ -85,5 +69,3 @@ ver-build: update bumpversion build .PHONY: all build clean distclean publish $(SUBDIRS) update status \ bumpgit bumprelease bumpversion dev-build rel-build ver-build - - -- 1.6.0.1.216.g1b23a From jim at meyering.net Fri Sep 5 07:16:10 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 05 Sep 2008 09:16:10 +0200 Subject: [Ovirt-devel] [PATCH] "make clean" should not don't remove my backups! Message-ID: <87od33hxl1.fsf@rho.meyering.net> It is not the job of "make clean" to remove a user's backup files. It should remove only those files that "make some-target" can create. FYI, these separately-created patches apply to docs and release subdirs. The docs patch has the "-f" option. >From 7e67831daada4213bd7ba9d1380f8ad9d2c17471 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 09:09:59 +0200 Subject: [PATCH] Makefile (clean): Do *not* remove user's backup files. --- Makefile | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 6cd2074..2698147 100644 --- a/Makefile +++ b/Makefile @@ -8,7 +8,6 @@ distclean: clean rm -rf rpm-build clean: - rm -rf *~ tar: clean mkdir -p rpm-build -- 1.6.0.1.216.g1b23a >From 3cfa62cf661c35dac828ee1785df3828dce2a2aa Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 09:09:40 +0200 Subject: [PATCH] Makefile (clean): Do *not* remove user's backup files. --- Makefile | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 4555e4a..b458ed5 100644 --- a/Makefile +++ b/Makefile @@ -4,7 +4,6 @@ all: rpms include release.mk clean: - rm -f *~ distclean: clean rm -rf rpm-build -- 1.6.0.1.216.g1b23a From jim at meyering.net Fri Sep 5 07:31:12 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 05 Sep 2008 09:31:12 +0200 Subject: [Ovirt-devel] avoid warnings from "make clean" with parallel make Message-ID: <87iqtbhwvz.fsf@rho.meyering.net> Without the patches below, a top level "make -f release/ovirt.mk clean" gets warnings with parallel make (i.e. either with -j2 or with MAKEFLAGS=-j$n in the environment). for dir in release server node node-image appliance docs; do if test -d $dir ; then make -C $dir clean || exit 1 ; fi ; done make[1]: Entering directory `/f/mirror/ov2/release' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. make[1]: Nothing to be done for `clean'. make[1]: Leaving directory `/f/mirror/ov2/release' make[1]: Entering directory `/f/mirror/ov2/server' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. rm -f ovirt*.gz ovirt*.rpm rm -rf ovirt-server-* dist build make[1]: Leaving directory `/f/mirror/ov2/server' make[1]: Entering directory `/f/mirror/ov2/node' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. make -C ovirt-identify-node clean make[2]: Entering directory `/f/mirror/ov2/node/ovirt-identify-node' rm -rf comm.o gather.o hal_support.o main.o protocol.o ovirt-identify-node make[2]: Leaving directory `/f/mirror/ov2/node/ovirt-identify-node' rm -rf ovirt-node-0.92 make[1]: Leaving directory `/f/mirror/ov2/node' make[1]: Entering directory `/f/mirror/ov2/node-image' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. rm -rf ovirt-node-image-* make[1]: Leaving directory `/f/mirror/ov2/node-image' make[1]: Entering directory `/f/mirror/ov2/appliance' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. rm -f ovirt-appliance-* make[1]: Leaving directory `/f/mirror/ov2/appliance' make[1]: Entering directory `/f/mirror/ov2/docs' make[1]: warning: jobserver unavailable: using -j1. Add `+' to parent make rule. make[1]: Nothing to be done for `clean'. make[1]: Leaving directory `/f/mirror/ov2/docs' These are for node/ and release/ respectively: >From f44150eae5beef4f4a801f904db91b6fa8af7ae5 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 09:28:36 +0200 Subject: [PATCH] * Makefile (clean): Prefix with '+' to avoid warning w/-j. --- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index be136c2..0f182dd 100644 --- a/Makefile +++ b/Makefile @@ -22,7 +22,7 @@ all: rpms include release.mk clean: - make -C ovirt-identify-node clean + +$(MAKE) -C ovirt-identify-node clean rm -rf $(NV) distclean: clean -- 1.6.0.1.216.g1b23a >From 91f77ef54e060828e3f7c04e76c385d038913031 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 09:27:39 +0200 Subject: [PATCH] * ovirt.mk (for_each_subdir): Prefix with '+' to avoid warning w/-j. --- ovirt.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index e61f83b..78ee0f5 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -11,7 +11,7 @@ SUBDIRS ?= release server node node-image appliance docs export OVIRT_CACHE_DIR ?= $(HOME)/ovirt-cache define for_each_subdir - for dir in $(SUBDIRS); do \ + +for dir in $(SUBDIRS); do \ if test -d $$dir ; then \ $(MAKE) -C $$dir $@ || exit 1 ; \ fi ; \ -- 1.6.0.1.216.g1b23a From clalance at redhat.com Fri Sep 5 07:57:04 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 5 Sep 2008 09:57:04 +0200 Subject: [Ovirt-devel] [PATCH]: Allow the WUI to manage the hardware it is running on In-Reply-To: References: Message-ID: <1220601430-12218-1-git-send-email-clalance@redhat.com> This patch series allows the WUI to manage the underlying hardware it is running on. b/ovirt-host-creator/common-pkgs.ks | 2 b/ovirt-host-creator/ovirt-host-image.spec | 4 b/ovirt-managed-node/Makefile | 3 b/ovirt-managed-node/ovirt-listen-awake/COPYING | 339 ++++++++++ b/ovirt-managed-node/ovirt-listen-awake/Makefile | 36 + b/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host | 51 + b/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.c | 213 ++++++ b/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.init | 49 + b/ovirt-managed-node/ovirt-listen-awake/ovirt-unconvert-host | 30 b/ovirt-managed-node/ovirt-managed-node.spec | 6 b/ovirt-managed-node/scripts/ovirt-functions | 25 b/wui-appliance/create-wui-appliance.sh | 2 b/wui-appliance/wui-devel.ks | 13 ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host | 2 ovirt-managed-node/ovirt-managed-node.spec | 83 +- wui-appliance/create-wui-appliance.sh | 2 16 files changed, 820 insertions(+), 40 deletions(-) From clalance at redhat.com Fri Sep 5 07:57:05 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 5 Sep 2008 09:57:05 +0200 Subject: [Ovirt-devel] [PATCH]: Allow the WUI to manage the hardware it is running on In-Reply-To: References: Message-ID: <1220601430-12218-2-git-send-email-clalance@redhat.com> Add ovirt-listen-awake daemon. This is a very small daemon that the managed node can communicate with to send simple messages to the host it is running on. It's used so that the managed node can "managed" the hardware it is running on, removing the need for the fake managed nodes. Signed-off-by: Chris Lalancette diff --git a/ovirt-managed-node/Makefile b/ovirt-managed-node/Makefile index bf42e39..2c47334 100644 --- a/ovirt-managed-node/Makefile +++ b/ovirt-managed-node/Makefile @@ -23,6 +23,7 @@ include ../common/release.mk clean: make -C ovirt-identify-node clean + make -C ovirt-listen-awake clean rm -rf $(NV) distclean: clean @@ -30,7 +31,7 @@ distclean: clean tar: clean mkdir -p $(NV) - cp -a logrotate ovirt-identify-node scripts $(NV) + cp -a logrotate ovirt-identify-node ovirt-listen-awake scripts $(NV) mkdir -p rpm-build tar zcvf rpm-build/$(NV).tar.gz $(NV) cp version rpm-build/ diff --git a/ovirt-managed-node/ovirt-listen-awake/COPYING b/ovirt-managed-node/ovirt-listen-awake/COPYING new file mode 100644 index 0000000..d511905 --- /dev/null +++ b/ovirt-managed-node/ovirt-listen-awake/COPYING @@ -0,0 +1,339 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Lesser General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License along + with this program; if not, write to the Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Lesser General +Public License instead of this License. diff --git a/ovirt-managed-node/ovirt-listen-awake/Makefile b/ovirt-managed-node/ovirt-listen-awake/Makefile new file mode 100644 index 0000000..a7cf207 --- /dev/null +++ b/ovirt-managed-node/ovirt-listen-awake/Makefile @@ -0,0 +1,36 @@ +# Copyright (C) 2008 Red Hat, Inc. +# Written by Chris Lalancette +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +CC=gcc +CFLAGS=-Wall -c -g $(shell pkg-config --cflags dbus-1) +OBJECTS=ovirt-listen-awake.o +TARGET=ovirt-listen-awake +SOURCES=ovirt-listen-awake.c + +all: $(TARGET) + +.c.o: + $(CC) $(CFLAGS) $< -o $@ + +clean: + rm -rf $(OBJECTS) $(TARGET) *~ + +$(TARGET): $(OBJECTS) + $(CC) -o $@ $(OBJECTS) $(LFLAGS) + +.PHONY: all clean diff --git a/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.c b/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.c new file mode 100644 index 0000000..ceb32dc --- /dev/null +++ b/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.c @@ -0,0 +1,213 @@ +/* ovirt-listen-awake: daemon to listen for and respond to AWAKE requests + * + * Copyright (C) 2008 Red Hat, Inc. + * Written by Chris Lalancette + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. A copy of the GNU General Public License is + * also available at http://www.gnu.org/copyleft/gpl.html. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +// We only ever expect to receive the strings "AWAKE" or "IDENTIFY", so +// 20 bytes is more than enough +#define BUFLEN 20 +#define LOGFILE "/var/log/ovirt-host.log" + +static int streq(char *first, char *second) +{ + int first_len, second_len; + + first_len = strlen(first); + second_len = strlen(second); + + if (first_len == second_len && strncmp(first, second, first_len) == 0) + return 1; + return 0; +} + +static void strip_space(char *buffer) +{ + int i; + + i = 0; + while (buffer[i] != '\0') { + if (isspace(buffer[i])) { + // once we see the first whitespace character, we are done + buffer[i] ='\0'; + break; + } + i++; + } +} + +static int listenSocket(int listen_port) +{ + struct sockaddr_in a; + int s,yes; + + if (listen_port < 0) { + fprintf(stderr, "Invalid listen_port %d\n", listen_port); + return -1; + } + + s = socket(AF_INET, SOCK_STREAM, 0); + if (s < 0) { + fprintf(stderr, "Failed creating socket: %s\n", strerror(errno)); + return -1; + } + yes = 1; + if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,(char *)&yes, sizeof (yes)) < 0) { + fprintf(stderr, "Failed setsockopt: %s\n", strerror(errno)); + close(s); + return -1; + } + memset (&a, 0, sizeof (a)); + a.sin_port = htons (listen_port); + a.sin_family = AF_INET; + if (bind(s, (struct sockaddr *) &a, sizeof (a)) < 0) { + fprintf(stderr, "Error binding to port %d: %s\n", listen_port, + strerror(errno)); + close(s); + return -1; + } + listen(s, 10); + return s; +} + +static void usage(void) +{ + printf("Usage: host-startup [OPTIONS]\n"); + printf("OPTIONS:\n"); + printf(" -h\tShow this help message\n"); + printf(" -n\tDo not daemonize (useful for debugging\n"); + exit(1); +} + +int main(int argc, char *argv[]) +{ + int listen, conn; + struct sockaddr_in client_address; + unsigned int addrlen; + FILE *conn_stream; + FILE *logfile; + char buffer[BUFLEN]; + int c; + int do_daemon; + + do_daemon = 1; + + while ((c=getopt(argc, argv, ":hn")) != -1) { + switch(c) { + case 'h': + usage(); + break; + case 'n': + do_daemon = 0; + break; + default: + usage(); + } + } + + if ((argc-optind) != 0) + usage(); + + listen = listenSocket(7777); + if (listen < 0) + return 2; + + if (do_daemon) { + logfile = fopen(LOGFILE,"a+"); + if (logfile == NULL) { + fprintf(stderr, "Error opening logfile %s: %s\n", + LOGFILE, strerror(errno)); + return 3; + } + + // NOTE: this closes stdout and stderr + daemon(0, 0); + + // so re-open them to the logfile here + dup2(fileno(logfile), STDOUT_FILENO); + dup2(fileno(logfile), STDERR_FILENO); + } + + while (1) { + addrlen = sizeof(client_address); + memset(&client_address, 0, addrlen); + memset(buffer, 0, BUFLEN); + conn = accept(listen, (struct sockaddr *)&client_address, &addrlen); + if (conn < 0) { + fprintf(stderr, "Error accepting socket: %s\n", strerror(errno)); + continue; + } + + conn_stream = fdopen(conn, "r"); + if (conn_stream == NULL) { + fprintf(stderr, "Error converting fd to stream: %s\n", strerror(errno)); + close(conn); + continue; + } + + if (fgets(buffer, BUFLEN, conn_stream) == NULL) { + fprintf(stderr, "Error receiving data: %s\n", strerror(errno)); + fclose(conn_stream); + continue; + } + + strip_space(buffer); + + if (streq(buffer, "IDENTIFY")) { + // run ovirt-identify-node against 192.168.50.2 (the WUI node) + fprintf(stderr, "Doing identify\n"); + // FIXME: it would be best to call the "find_srv" shell script here to + // find out where we should contact. However, we would still have to + // hardcode which DNS server to use (192.168.50.2), and which domain + // name to use "priv.ovirt.org" to get this to work. I don't have + // a good idea how to solve this at the moment. + system("ovirt-identify-node -s 192.168.50.2 -p 12120"); + } + else if (streq(buffer, "AWAKE")) { + // run ovirt-awake against 192.168.50.2 + fprintf(stderr, "Doing awake\n"); + // FIXME: I hate to duplicate this stuff here, but I can't use the + // ovirt init scripts as-is; they depend too much on the environment + // (in particular, which DNS server to use to resolve, and which + // domainname). Until I come up with a good solution for that, I'll + // have to leave this as-is. + system("wget -q http://192.168.50.2:80/ipa/config/krb5.ini -O /etc/krb5.conf"); + system("ovirt-awake start 192.168.50.2 12120 /etc/libvirt/krb5.tab"); + } + else { + fprintf(stderr, "Unknown command %s\n", buffer); + } + + fclose(conn_stream); + } + + close(listen); + fclose(logfile); + + return 0; +} diff --git a/ovirt-managed-node/ovirt-managed-node.spec b/ovirt-managed-node/ovirt-managed-node.spec index 4f5c245..c64a8d4 100644 --- a/ovirt-managed-node/ovirt-managed-node.spec +++ b/ovirt-managed-node/ovirt-managed-node.spec @@ -29,6 +29,7 @@ oVirt managed node to interact with the oVirt server. %build make -C ovirt-identify-node +make -C ovirt-listen-awake %install %{__rm} -rf %{buildroot} @@ -42,6 +43,7 @@ make -C ovirt-identify-node %{__install} -p -m0755 scripts/ovirt-awake %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-identify-node/ovirt-identify-node %{buildroot}%{_sbindir} +%{__install} -p -m0755 ovirt-listen-awake/ovirt-listen-awake %{buildroot}%{_sbindir} %{__install} -p -m0644 scripts/ovirt-functions %{buildroot}%{_initrddir} %{__install} -p -m0755 scripts/ovirt-early %{buildroot}%{_initrddir} @@ -129,6 +131,7 @@ fi %defattr(-,root,root,0755) %{_sbindir}/ovirt-awake %{_sbindir}/ovirt-identify-node +%{_sbindir}/ovirt-listen-awake %{_initrddir}/ovirt-early %{_initrddir}/ovirt %{_initrddir}/ovirt-post @@ -146,6 +149,9 @@ fi %doc ovirt-identify-node/COPYING %changelog +* Fri Aug 22 2008 Chris Lalancette - 0.92 0.5 +- Add the ovirt-listen-awake daemon to the RPM + * Fri Aug 22 2008 Chris Lalancette - 0.92 0.4 - Re-arrange the directory layout, in preparation for ovirt-listen-awake From clalance at redhat.com Fri Sep 5 07:57:06 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 5 Sep 2008 09:57:06 +0200 Subject: [Ovirt-devel] [PATCH]: Allow the WUI to manage the hardware it is running on In-Reply-To: References: Message-ID: <1220601430-12218-3-git-send-email-clalance@redhat.com> In the rc.local, attempt to contact the host we are running on. If we succeed, great, we can manage it with the rest of the nodes. If we fail, no big deal, it just won't be available. Note that we can't do this in the ovirt-wui-dev initscript because it happens too early in boot (we need at least host-browser up for this to have a chance of working). Signed-off-by: Chris Lalancette diff --git a/wui-appliance/wui-devel.ks b/wui-appliance/wui-devel.ks index e9ca6cc..02c6baa 100644 --- a/wui-appliance/wui-devel.ks +++ b/wui-appliance/wui-devel.ks @@ -25,9 +25,22 @@ set /files/etc/sysconfig/network-scripts/ifcfg-eth1/DNS1 192.168.50.2 save EOF +# the code to contact the host we are running on and make it configure itself +# note that this has to be done in rc.local (as opposed to ovirt-wui-dev) +# because when ovirt-wui-dev starts, the host-browser is not yet running +cat >> /etc/rc.d/rc.local << \EOF +# Try to contact the host we are running on; if we succeed, we'll use it as +# one of the managed nodes; if not, no big deal +exec 3<> /dev/tcp/192.168.50.1/7777 +echo "AWAKE" 1>&3 +exec 3<> /dev/tcp/192.168.50.1/7777 +echo "IDENTIFY" 1>&3 +EOF + # make sure to update the /etc/hosts with the list of all possible DHCP # addresses we can hand out; dnsmasq uses this sed -i -e 's/management\.priv\.ovirt\.org//' /etc/hosts +echo "192.168.50.1 physical.priv.ovirt.org" >> /etc/hosts echo "192.168.50.2 management.priv.ovirt.org" >> /etc/hosts for i in `seq 3 252` ; do echo "192.168.50.$i node$i.priv.ovirt.org" >> /etc/hosts From clalance at redhat.com Fri Sep 5 07:57:07 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 5 Sep 2008 09:57:07 +0200 Subject: [Ovirt-devel] [PATCH]: Allow the WUI to manage the hardware it is running on In-Reply-To: References: Message-ID: <1220601430-12218-4-git-send-email-clalance@redhat.com> A rather large re-write of the ovirt-managed-node spec file. The reason for this is so that we can introduce the concept of the "stateful" ovirt node; that is, one which is already installed and running with an OS. To accomplish this, we add two subpackages: ovirt-managed-node-stateless, and ovirt-managed-node-stateful. They both depend on ovirt-managed-node, which holds most of the necessary binaries. The two subpackages have subtly different %post scripts, since you don't necessarily want to do all of the stuff from stateless on a stateful box. There is also a minor change to common-pkgs to require ovirt-managed-node-stateless, the addition of an init script for ovirt-managed-node-stateful, and the addition of two helper scripts for the stateful case to let you turn your machine into an ovirt-managed node. Signed-off-by: Chris Lalancette diff --git a/ovirt-host-creator/common-pkgs.ks b/ovirt-host-creator/common-pkgs.ks index bc08358..2bc779e 100644 --- a/ovirt-host-creator/common-pkgs.ks +++ b/ovirt-host-creator/common-pkgs.ks @@ -28,7 +28,7 @@ bind-utils syslinux cronie hal -ovirt-managed-node +ovirt-managed-node-stateless -policycoreutils -audit-libs-python -hdparm diff --git a/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host b/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host new file mode 100755 index 0000000..98e695d --- /dev/null +++ b/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host @@ -0,0 +1,51 @@ +#!/bin/bash + +. /etc/init.d/ovirt-functions + +if [ $# -ne 0 ]; then + echo "Usage: ovirt-convert-host" + exit 1 +fi + +backup_file() { + dir=$(dirname $1) + mkdir -p $OVIRT_BACKUP_DIR/${dir:1} + cp -pf $1 $OVIRT_BACKUP_DIR/${dir:1} +} + +echo "This script will make a number of changes to your system to enable it to" +echo "work as an ovirt managed node. You can later undo these changes by" +echo "running /usr/sbin/ovirt-unconvert-host. Do you want to proceed? [y/N]?" +read yesno + +if [ "$yesno" != "y" -a "$yesno" != "Y" ]; then + exit 2 +fi + +mkdir -p $OVIRT_BACKUP_DIR + +backup_file /etc/sysconfig/network +sed -i -e 's/^HOSTNAME=.*/HOSTNAME=physical.priv.ovirt.org/' /etc/sysconfig/network + +backup_file /etc/hosts +if [ $( grep -c "physical.priv.ovirt.org" /etc/hosts ) -eq 0 ]; then + echo "192.168.50.1 physical.priv.ovirt.org" >> /etc/hosts +fi +if [ $( grep -c "management.priv.ovirt.org" /etc/hosts ) -eq 0 ]; then + echo "192.168.50.2 management.priv.ovirt.org" >> /etc/hosts +fi + +/sbin/chkconfig ovirt-listen-awake on +/sbin/chkconfig collectd on + +backup_file /etc/sysconfig/libvirtd +backup_file /etc/libvirt/qemu.conf +backup_file /etc/libvirt/libvirtd.conf +backup_file /etc/sasl2/libvirt.conf +ovirt_setup_libvirtd + +backup_file /etc/sysconfig/iptables +/usr/sbin/lokkit -n -t ovirtbr + +echo "Setup complete. To make the changes take effect, shut down any running +guests and reboot the host" diff --git a/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.init b/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.init new file mode 100644 index 0000000..a6bb78a --- /dev/null +++ b/ovirt-managed-node/ovirt-listen-awake/ovirt-listen-awake.init @@ -0,0 +1,49 @@ +#!/bin/bash +# +# +# ovirt-listen-awake startup script for ovirt-listen-awake +# +# chkconfig: - 97 03 +# description: ovirt-listen-awake is a daemon to listen for requests from +# the ovirt VM manager. When it receives one, it contacts the machine +# back with details so that it is added to the ovirt host pool. + +DAEMON=/usr/sbin/ovirt-listen-awake + +. /etc/init.d/functions + +start() { + echo -n "Starting ovirt-listen-awake: " + daemon $DAEMON + RETVAL=$? + echo +} + +stop() { + echo -n "Shutting down ovirt-listen-awake: " + killproc ovirt-listen-awake + RETVAL=$? + echo +} + +case "$1" in + start) + start + ;; + stop) + stop + ;; + restart) + stop + start + ;; + status) + status $DAEMON + RETVAL=$? + ;; + *) + echo "Usage: ovirt-listen-awake {start|stop|restart|status}" + exit 1 + ;; +esac +exit $RETVAL diff --git a/ovirt-managed-node/ovirt-listen-awake/ovirt-unconvert-host b/ovirt-managed-node/ovirt-listen-awake/ovirt-unconvert-host new file mode 100755 index 0000000..cfaa51d --- /dev/null +++ b/ovirt-managed-node/ovirt-listen-awake/ovirt-unconvert-host @@ -0,0 +1,30 @@ +#!/bin/bash + +. /etc/init.d/ovirt-functions + +if [ $# -ne 0 ]; then + echo "Usage: ovirt-unconvert-host" + exit 1 +fi + +if [ ! -d $OVIRT_BACKUP_DIR ]; then + echo "The oVirt backup directory $OVIRT_BACKUP_DIR doesn't exist; can't" + echo "unconvert the host" + exit 2 +fi + +unbackup_file() { + # note that $1 will have a / on the front, so we don't need to add our own + cp -pf $OVIRT_BACKUP_DIR$1 $1 +} + +/sbin/chkconfig ovirt-listen-awake off +/sbin/chkconfig collectd off + +unbackup_file /etc/sysconfig/network +unbackup_file /etc/hosts +unbackup_file /etc/sysconfig/libvirtd +unbackup_file /etc/libvirt/qemu.conf +unbackup_file /etc/libvirt/libvirtd.conf +unbackup_file /etc/sasl2/libvirt.conf +unbackup_file /etc/sysconfig/iptables diff --git a/ovirt-managed-node/ovirt-managed-node.spec b/ovirt-managed-node/ovirt-managed-node.spec index c64a8d4..3c83935 100644 --- a/ovirt-managed-node/ovirt-managed-node.spec +++ b/ovirt-managed-node/ovirt-managed-node.spec @@ -15,6 +15,8 @@ BuildRequires: libvirt-devel BuildRequires: dbus-devel hal-devel Requires: libvirt Requires: hal +Requires: collectd +Requires: cyrus-sasl-gssapi ExclusiveArch: %{ix86} x86_64 %define app_root %{_datadir}/%{name} @@ -23,6 +25,20 @@ ExclusiveArch: %{ix86} x86_64 Provides a series of daemons and support utilities to allow an oVirt managed node to interact with the oVirt server. +%package stateless +Summary: ovirt-managed-node scripts for stateless +Group: Applications/System +Requires: %{name} = %{version}-%{release} +%description stateless +This package does configuration for a stateless ovirt managed node. + +%package stateful +Summary: ovirt-managed-node scripts for existing machines +Group: Applications/System +Requires: %{name} = %{version}-%{release} +%description stateful +This package does configuration for a stateful ovirt managed node. + %prep %setup -q @@ -44,6 +60,9 @@ make -C ovirt-listen-awake %{__install} -p -m0755 scripts/ovirt-awake %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-identify-node/ovirt-identify-node %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-listen-awake/ovirt-listen-awake %{buildroot}%{_sbindir} +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-listen-awake.init %{buildroot}%{_initrddir}/ovirt-listen-awake +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-convert-host %{buildroot}%{_sbindir} +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-unconvert-host %{buildroot}%{_sbindir} %{__install} -p -m0644 scripts/ovirt-functions %{buildroot}%{_initrddir} %{__install} -p -m0755 scripts/ovirt-early %{buildroot}%{_initrddir} @@ -52,8 +71,6 @@ make -C ovirt-listen-awake %{__install} -p -m0644 scripts/collectd %{buildroot}%{_sysconfdir}/chkconfig.d %{__install} -p -m0644 scripts/collectd.conf.in %{buildroot}%{_sysconfdir} -%{__install} -p -m0755 scripts/kvm-ifup %{buildroot}%{_sysconfdir} -%{__install} -p -m0755 scripts/dhclient-exit-hooks %{buildroot}%{_sysconfdir} %{__install} -p -m0755 logrotate/ovirt-logrotate %{buildroot}%{_sysconfdir}/cron.hourly %{__install} -p -m0644 logrotate/ovirt-logrotate.conf %{buildroot}%{_sysconfdir}/logrotate.d @@ -63,40 +80,25 @@ echo "oVirt Managed Node release %{version}-%{release}" > %{buildroot}%{_sysconf %clean %{__rm} -rf %{buildroot} -%post +%post stateful +/sbin/chkconfig --add ovirt-listen-awake +# this is ugly; we need collectd to start *after* libvirtd, so we own the +# /etc/chkconfig.d/collectd file, and then have to re-define collectd here +/sbin/chkconfig --add collectd + +%post stateless /sbin/chkconfig --add ovirt-early /sbin/chkconfig ovirt-early on /sbin/chkconfig --add ovirt /sbin/chkconfig ovirt on /sbin/chkconfig --add ovirt-post /sbin/chkconfig ovirt-post on -/sbin/chkconfig --add collectd -/sbin/chkconfig collectd on - -# just to get a boot warning to shut up -touch /etc/resolv.conf - -# make libvirtd listen on the external interfaces -sed -i -e "s/^#\(LIBVIRTD_ARGS=\"--listen\"\).*/\1/" /etc/sysconfig/libvirtd -# set up qemu daemon to allow outside VNC connections -sed -i -e "s/^[[:space:]]*#[[:space:]]*\(vnc_listen = \"0.0.0.0\"\).*/\1/" \ - /etc/libvirt/qemu.conf - -# set up libvirtd to listen on TCP (for kerberos) -sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ - -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ - /etc/libvirt/libvirtd.conf +. /etc/init.d/ovirt-functions ; ovirt_setup_libvirtd # make sure we don't autostart virbr0 on libvirtd startup rm -f /etc/libvirt/qemu/networks/autostart/default.xml -# with the new libvirt (0.4.0), make sure we we setup gssapi in the mech_list -if [ `egrep -c "^mech_list: gssapi" /etc/sasl2/libvirt.conf` -eq 0 ]; then - sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" /etc/sasl2/libvirt.conf - echo "mech_list: gssapi" >> /etc/sasl2/libvirt.conf -fi - # remove the /etc/krb5.conf file; it will be fetched on bootup rm -f /etc/krb5.conf @@ -120,25 +122,22 @@ cat < /etc/issue EOF cp -p /etc/issue /etc/issue.net -%preun +%preun stateless if [ "$1" = 0 ] ; then /sbin/chkconfig --del ovirt-early /sbin/chkconfig --del ovirt /sbin/chkconfig --del ovirt-post fi +%preun stateful +if [ "$1" = 0 ] ; then + /sbin/chkconfig --del ovirt-listen-awake +fi + %files %defattr(-,root,root,0755) %{_sbindir}/ovirt-awake %{_sbindir}/ovirt-identify-node -%{_sbindir}/ovirt-listen-awake -%{_initrddir}/ovirt-early -%{_initrddir}/ovirt -%{_initrddir}/ovirt-post -%{_sysconfdir}/kvm-ifup -%{_sysconfdir}/dhclient-exit-hooks -%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf -%config %{_sysconfdir}/cron.hourly/ovirt-logrotate %defattr(-,root,root,0644) %{_initrddir}/ovirt-functions %{_sysconfdir}/collectd.conf.in @@ -148,7 +147,23 @@ fi %doc ovirt-identify-node/AUTHOR ovirt-identify-node/ChangeLog %doc ovirt-identify-node/COPYING +%files stateful +%{_initrddir}/ovirt-listen-awake +%{_sbindir}/ovirt-listen-awake +%{_sbindir}/ovirt-convert-host +%{_sbindir}/ovirt-unconvert-host + +%files stateless +%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf +%config %{_sysconfdir}/cron.hourly/ovirt-logrotate +%{_initrddir}/ovirt-early +%{_initrddir}/ovirt +%{_initrddir}/ovirt-post + %changelog +* Thu Aug 28 2008 Chris Lalancette - 0.92 0.6 +- Rewrite the whole spec to make sub-packages for stateless vs. stateful + * Fri Aug 22 2008 Chris Lalancette - 0.92 0.5 - Add the ovirt-listen-awake daemon to the RPM diff --git a/ovirt-managed-node/scripts/ovirt-functions b/ovirt-managed-node/scripts/ovirt-functions index 083e13d..24a28df 100644 --- a/ovirt-managed-node/scripts/ovirt-functions +++ b/ovirt-managed-node/scripts/ovirt-functions @@ -5,6 +5,8 @@ OVIRT_LOGFILE=/var/log/ovirt.log # label of the oVirt partition OVIRT_LABEL=OVIRT +OVIRT_BACKUP_DIR=/var/lib/ovirt-backup + find_srv() { local dnsreply @@ -21,3 +23,26 @@ die() { echo "$@" 1>&2; failure; echo 1>&2; exit 1 } + +ovirt_setup_libvirtd() { + # just to get a boot warning to shut up + touch /etc/resolv.conf + + # make libvirtd listen on the external interfaces + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ + /etc/sysconfig/libvirtd + + # set up qemu daemon to allow outside VNC connections + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ + /etc/libvirt/qemu.conf + # set up libvirtd to listen on TCP (for kerberos) + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ + /etc/libvirt/libvirtd.conf + + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list + if [ `egrep -c "^mech_list: gssapi" /etc/sasl2/libvirt.conf` -eq 0 ]; then + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" /etc/sasl2/libvirt.conf + echo "mech_list: gssapi" >> /etc/sasl2/libvirt.conf + fi +} From clalance at redhat.com Fri Sep 5 07:57:09 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 5 Sep 2008 09:57:09 +0200 Subject: [Ovirt-devel] [PATCH]: Allow the WUI to manage the hardware it is running on In-Reply-To: References: Message-ID: <1220601430-12218-6-git-send-email-clalance@redhat.com> 1) Removed a redundant BuildRequires line. 2) More importantly, added a %post script for the pxe RPM to run cobbler sync iff cobbler exists. With this in place, running "rpm -Uvh" with a new ovirt-managed-node-pxe RPM will actually cause managed nodes to pick up the new image instead of the old one. Signed-off-by: Chris Lalancette diff --git a/ovirt-host-creator/ovirt-host-image.spec b/ovirt-host-creator/ovirt-host-image.spec index 0475cab..94c169e 100644 --- a/ovirt-host-creator/ovirt-host-image.spec +++ b/ovirt-host-creator/ovirt-host-image.spec @@ -24,7 +24,6 @@ At the moment, this RPM just packages prebuilt ISO. %package pxe Summary: oVirt Managed Node boot PXE image Group: Applications/System -BuildRequires: livecd-tools >= 017 %description pxe The PXE boot image for oVirt Managed Node network boot from oVirt Admin Node. @@ -55,6 +54,9 @@ mkdir %{buildroot} %clean %{__rm} -rf %{buildroot} +%post pxe +[ -x /usr/bin/cobbler ] && /usr/bin/cobbler sync + %files %defattr(-,root,root,0644) %{app_root}/ovirt.iso From clalance at redhat.com Fri Sep 5 07:57:08 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 5 Sep 2008 09:57:08 +0200 Subject: [Ovirt-devel] [PATCH]: Allow the WUI to manage the hardware it is running on In-Reply-To: References: Message-ID: <1220601430-12218-5-git-send-email-clalance@redhat.com> Fix up the awk script to *exactly* match the bridge we are looking for. This is an issue if you happen to have multiple bridges up, like ovirtbr0, ovirtbr1 and now the script basically scribbles over them when looking for things. Signed-off-by: Chris Lalancette diff --git a/wui-appliance/create-wui-appliance.sh b/wui-appliance/create-wui-appliance.sh index d8137b1..b81ed68 100755 --- a/wui-appliance/create-wui-appliance.sh +++ b/wui-appliance/create-wui-appliance.sh @@ -221,7 +221,7 @@ fi # Remove old bridge device if it exists sed -i "/# $BRIDGENAME/d" /etc/rc.d/rc.local old_bridge=$(brctl show \ - | awk -v BRIDGENAME=$BRIDGENAME '$1~BRIDGENAME {print $4}') + | awk -v BRIDGENAME=$BRIDGENAME '$1==BRIDGENAME {print $4}') if [ -n "$old_bridge" ]; then echo "Removing old bridge $old_bridge" ifconfig $old_bridge down From clalance at redhat.com Fri Sep 5 07:57:10 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 5 Sep 2008 09:57:10 +0200 Subject: [Ovirt-devel] [PATCH]: Allow the WUI to manage the hardware it is running on In-Reply-To: References: Message-ID: <1220601430-12218-7-git-send-email-clalance@redhat.com> Two last fixes. Since we are currently hardcoding ovirtbr0 in taskomatic, we have to call the bridge on the host ovirtbr0 to allow guests to start. This limitation should go away fairly soon with Darryl's network discovery work, but we need it for now. Signed-off-by: Chris Lalancette diff --git a/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host b/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host index 98e695d..45351b1 100755 --- a/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host +++ b/ovirt-managed-node/ovirt-listen-awake/ovirt-convert-host @@ -45,7 +45,7 @@ backup_file /etc/sasl2/libvirt.conf ovirt_setup_libvirtd backup_file /etc/sysconfig/iptables -/usr/sbin/lokkit -n -t ovirtbr +/usr/sbin/lokkit -n -t ovirtbr0 echo "Setup complete. To make the changes take effect, shut down any running guests and reboot the host" diff --git a/wui-appliance/create-wui-appliance.sh b/wui-appliance/create-wui-appliance.sh index b81ed68..e1857b9 100755 --- a/wui-appliance/create-wui-appliance.sh +++ b/wui-appliance/create-wui-appliance.sh @@ -10,7 +10,7 @@ RAM=768 IMGDIR_DEFAULT=/var/lib/libvirt/images NAME_DEFAULT=ovirt-appliance NET_SCRIPTS=/etc/sysconfig/network-scripts -BRIDGENAME=ovirtbr +BRIDGENAME=ovirtbr0 imgdir=$IMGDIR_DEFAULT name=$NAME_DEFAULT From mmorsi at redhat.com Fri Sep 5 10:10:17 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Fri, 05 Sep 2008 06:10:17 -0400 Subject: [Ovirt-devel] [PATCH] Remove svg bar graphs, replace with css. In-Reply-To: <1220543364-15579-1-git-send-email-jguiditt@redhat.com> References: <1220543364-15579-1-git-send-email-jguiditt@redhat.com> Message-ID: <48C10589.5040703@redhat.com> Jason Guiditta wrote: > NOTE: This is only for graphs in a flexigrid, as they > did not have the arrow, which will be more problematic > if not impossible to do with css (though maybe with js). > > Load average for host is based on 5 (apparently this is > some agreed-upon temporary scale). There is no real load > for vm pools in the database, so these are stubbed out > for now. > > Signed-off-by: Jason Guiditta > --- > wui/src/app/controllers/hardware_controller.rb | 2 +- > wui/src/app/views/host/_grid.rhtml | 6 +++++- > wui/src/app/views/resources/_grid.rhtml | 7 ++++++- > wui/src/public/javascripts/ovirt.js | 7 +++++++ > wui/src/public/stylesheets/components.css | 6 ++++++ > wui/src/public/stylesheets/flexigrid/flexigrid.css | 2 +- > 6 files changed, 26 insertions(+), 4 deletions(-) > > diff --git a/wui/src/app/controllers/hardware_controller.rb b/wui/src/app/controllers/hardware_controller.rb > index 091ce97..a366e4c 100644 > --- a/wui/src/app/controllers/hardware_controller.rb > +++ b/wui/src/app/controllers/hardware_controller.rb > @@ -150,7 +150,7 @@ class HardwareController < PoolController > attr_list << :id if params[:checkboxes] > attr_list << :hostname > attr_list << [:hardware_pool, :name] if include_pool > - attr_list += [:uuid, :hypervisor_type, :num_cpus, :cpu_speed, :arch, :memory_in_mb, :status_str, :id] > + attr_list += [:uuid, :hypervisor_type, :num_cpus, :cpu_speed, :arch, :memory_in_mb, :status_str, :load_average] > json_list(hosts, attr_list, [:all], find_opts) > end > > diff --git a/wui/src/app/views/host/_grid.rhtml b/wui/src/app/views/host/_grid.rhtml > index ac24e0c..553adf9 100644 > --- a/wui/src/app/views/host/_grid.rhtml > +++ b/wui/src/app/views/host/_grid.rhtml > @@ -54,7 +54,11 @@ > } > function <%= table_id %>_load_widget(celDiv) > { > - load_widget(celDiv, "host"); > + var loadAvg = getAverage($(celDiv).html()); > + var loadCss = (loadAvg >50) ? "load_graph_high" : "load_graph_low"; > + $(celDiv).html('
        + class="load_graph ' + loadCss + '" \n\ > + style="width: ' + loadAvg + '%;">
        '); > }; > > > diff --git a/wui/src/app/views/resources/_grid.rhtml b/wui/src/app/views/resources/_grid.rhtml > index 301a7aa..908eac7 100644 > --- a/wui/src/app/views/resources/_grid.rhtml > +++ b/wui/src/app/views/resources/_grid.rhtml > @@ -35,7 +35,12 @@ > } > function <%= table_id %>_load_widget(celDiv) > { > - load_widget(celDiv, "resource"); > + //FIXME: there is no real data save for vmpool load, so stub out for now > + var loadAvg = getAverage(2.3); > + var loadCss = (loadAvg >50) ? "load_graph_high" : "load_graph_low"; > + $(celDiv).html('
        + class="load_graph ' + loadCss + '" \n\ > + style="width: ' + loadAvg + '%;">
        '); > }; > > > diff --git a/wui/src/public/javascripts/ovirt.js b/wui/src/public/javascripts/ovirt.js > index 9a0d4b7..af0b9f6 100644 > --- a/wui/src/public/javascripts/ovirt.js > +++ b/wui/src/public/javascripts/ovirt.js > @@ -28,6 +28,13 @@ function validate_selected(selected_array, name) > } > } > > +function getAverage(val) { > + if (isNaN(val)) return 0; > + //FIXME: currently using a magic number of 5 which should be replaced > + //with comething more meaningful. > + return (val/5 < 1) ? ((val/5) * 100) : 100; > +} > + > Just wondering why the value 5 was chosen to divide by, was this an arbitrary decision? > function add_hosts(url) > { > hosts= get_selected_checkboxes("addhosts_grid_form"); > diff --git a/wui/src/public/stylesheets/components.css b/wui/src/public/stylesheets/components.css > index 56cadf2..16eaf62 100644 > --- a/wui/src/public/stylesheets/components.css > +++ b/wui/src/public/stylesheets/components.css > @@ -253,8 +253,14 @@ > > /* load graphs in flexigrid */ > .load_graph { > + padding: 0px !important; > + height: 10px; > + border:#F5AFA8 solid 1px; > } > > +.load_graph_low {background: url(../images/chart_horiz_blue.png) repeat-x;} > +.load_graph_high {background: url(../images/chart_horiz_orange.png) repeat-x;} > + > /************************* > * details pane style * > *************************/ > diff --git a/wui/src/public/stylesheets/flexigrid/flexigrid.css b/wui/src/public/stylesheets/flexigrid/flexigrid.css > index f8f8037..cd1902f 100644 > --- a/wui/src/public/stylesheets/flexigrid/flexigrid.css > +++ b/wui/src/public/stylesheets/flexigrid/flexigrid.css > @@ -469,7 +469,7 @@ div.colCopy { > .flexigrid div.bDiv td > { > border-bottom: 1px solid #fff; > - vertical-align: top; > + /*vertical-align: top;*/ > white-space: nowrap; > } > > Everything thats there looks good, so ACK. I believe you missed the load graph on the resource pool / virtual machines tab though. -Mo From mmorsi at redhat.com Fri Sep 5 12:18:08 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Fri, 05 Sep 2008 08:18:08 -0400 Subject: [Ovirt-devel] [PATCH] Remove svg bar graphs, replace with css. In-Reply-To: <48C10589.5040703@redhat.com> References: <1220543364-15579-1-git-send-email-jguiditt@redhat.com> <48C10589.5040703@redhat.com> Message-ID: <48C12380.4020707@redhat.com> Mohammed Morsi wrote: > Jason Guiditta wrote: > >> NOTE: This is only for graphs in a flexigrid, as they >> did not have the arrow, which will be more problematic >> if not impossible to do with css (though maybe with js). >> >> Load average for host is based on 5 (apparently this is >> some agreed-upon temporary scale). There is no real load >> for vm pools in the database, so these are stubbed out >> for now. >> >> Signed-off-by: Jason Guiditta >> --- >> wui/src/app/controllers/hardware_controller.rb | 2 +- >> wui/src/app/views/host/_grid.rhtml | 6 +++++- >> wui/src/app/views/resources/_grid.rhtml | 7 ++++++- >> wui/src/public/javascripts/ovirt.js | 7 +++++++ >> wui/src/public/stylesheets/components.css | 6 ++++++ >> wui/src/public/stylesheets/flexigrid/flexigrid.css | 2 +- >> 6 files changed, 26 insertions(+), 4 deletions(-) >> >> diff --git a/wui/src/app/controllers/hardware_controller.rb b/wui/src/app/controllers/hardware_controller.rb >> index 091ce97..a366e4c 100644 >> --- a/wui/src/app/controllers/hardware_controller.rb >> +++ b/wui/src/app/controllers/hardware_controller.rb >> @@ -150,7 +150,7 @@ class HardwareController < PoolController >> attr_list << :id if params[:checkboxes] >> attr_list << :hostname >> attr_list << [:hardware_pool, :name] if include_pool >> - attr_list += [:uuid, :hypervisor_type, :num_cpus, :cpu_speed, :arch, :memory_in_mb, :status_str, :id] >> + attr_list += [:uuid, :hypervisor_type, :num_cpus, :cpu_speed, :arch, :memory_in_mb, :status_str, :load_average] >> json_list(hosts, attr_list, [:all], find_opts) >> end >> >> diff --git a/wui/src/app/views/host/_grid.rhtml b/wui/src/app/views/host/_grid.rhtml >> index ac24e0c..553adf9 100644 >> --- a/wui/src/app/views/host/_grid.rhtml >> +++ b/wui/src/app/views/host/_grid.rhtml >> @@ -54,7 +54,11 @@ >> } >> function <%= table_id %>_load_widget(celDiv) >> { >> - load_widget(celDiv, "host"); >> + var loadAvg = getAverage($(celDiv).html()); >> + var loadCss = (loadAvg >50) ? "load_graph_high" : "load_graph_low"; >> + $(celDiv).html('
        > + class="load_graph ' + loadCss + '" \n\ >> + style="width: ' + loadAvg + '%;">
        '); >> }; >> >> >> diff --git a/wui/src/app/views/resources/_grid.rhtml b/wui/src/app/views/resources/_grid.rhtml >> index 301a7aa..908eac7 100644 >> --- a/wui/src/app/views/resources/_grid.rhtml >> +++ b/wui/src/app/views/resources/_grid.rhtml >> @@ -35,7 +35,12 @@ >> } >> function <%= table_id %>_load_widget(celDiv) >> { >> - load_widget(celDiv, "resource"); >> + //FIXME: there is no real data save for vmpool load, so stub out for now >> + var loadAvg = getAverage(2.3); >> + var loadCss = (loadAvg >50) ? "load_graph_high" : "load_graph_low"; >> + $(celDiv).html('
        > + class="load_graph ' + loadCss + '" \n\ >> + style="width: ' + loadAvg + '%;">
        '); >> }; >> >> >> diff --git a/wui/src/public/javascripts/ovirt.js b/wui/src/public/javascripts/ovirt.js >> index 9a0d4b7..af0b9f6 100644 >> --- a/wui/src/public/javascripts/ovirt.js >> +++ b/wui/src/public/javascripts/ovirt.js >> @@ -28,6 +28,13 @@ function validate_selected(selected_array, name) >> } >> } >> >> +function getAverage(val) { >> + if (isNaN(val)) return 0; >> + //FIXME: currently using a magic number of 5 which should be replaced >> + //with comething more meaningful. >> + return (val/5 < 1) ? ((val/5) * 100) : 100; >> +} >> + >> >> > Just wondering why the value 5 was chosen to divide by, was this an > arbitrary decision? > Scratch that, I should learn to read comments ;-p > > >> function add_hosts(url) >> { >> hosts= get_selected_checkboxes("addhosts_grid_form"); >> diff --git a/wui/src/public/stylesheets/components.css b/wui/src/public/stylesheets/components.css >> index 56cadf2..16eaf62 100644 >> --- a/wui/src/public/stylesheets/components.css >> +++ b/wui/src/public/stylesheets/components.css >> @@ -253,8 +253,14 @@ >> >> /* load graphs in flexigrid */ >> .load_graph { >> + padding: 0px !important; >> + height: 10px; >> + border:#F5AFA8 solid 1px; >> } >> >> +.load_graph_low {background: url(../images/chart_horiz_blue.png) repeat-x;} >> +.load_graph_high {background: url(../images/chart_horiz_orange.png) repeat-x;} >> + >> /************************* >> * details pane style * >> *************************/ >> diff --git a/wui/src/public/stylesheets/flexigrid/flexigrid.css b/wui/src/public/stylesheets/flexigrid/flexigrid.css >> index f8f8037..cd1902f 100644 >> --- a/wui/src/public/stylesheets/flexigrid/flexigrid.css >> +++ b/wui/src/public/stylesheets/flexigrid/flexigrid.css >> @@ -469,7 +469,7 @@ div.colCopy { >> .flexigrid div.bDiv td >> { >> border-bottom: 1px solid #fff; >> - vertical-align: top; >> + /*vertical-align: top;*/ >> white-space: nowrap; >> } >> >> >> > Everything thats there looks good, so ACK. I believe you missed the load > graph on the resource pool / virtual machines tab though. > > -Mo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mmorsi at redhat.com Fri Sep 5 12:35:36 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Fri, 05 Sep 2008 08:35:36 -0400 Subject: [Ovirt-devel] [PATCH] initial push of smart pool code. (revised) In-Reply-To: <1220458351-3678-1-git-send-email-sseago@redhat.com> References: <1220458351-3678-1-git-send-email-sseago@redhat.com> Message-ID: <48C12798.6000106@redhat.com> Scott Seago wrote: > This isn't complete, but I want to get it committed before the repo refactoring. This patch includes the controller refactoring needed for adding the new smart pool controllers, but I have not yet added any code to the new controllers. The models are in place for smart pools, but they aren't used anywhere yet. In addition, I've added a new DirectoryPool pool type that is used solely as a placeholder -- so that we can have a common root for all hardware and smart pools, and that we can organize smart pools by user. > > Since we need this pushed before the repo refactoring, this patch should be acked if it doesn't break anything. Separate review comments are, of course, welcome -- but anything that doesn't break the WUI will be fixed in a subsequent (post-repo-reorg) patch) > > diff --git a/wui/src/db/migrate/017_add_smart_pools.rb b/wui/src/db/migrate/017_add_smart_pools.rb > new file mode 100644 > index 0000000..6d83c02 > --- /dev/null > +++ b/wui/src/db/migrate/017_add_smart_pools.rb > @@ -0,0 +1,62 @@ > +# > +# Copyright (C) 2008 Red Hat, Inc. > +# Written by Scott Seago > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301, USA. A copy of the GNU General Public License is > +# also available at http://www.gnu.org/copyleft/gpl.html. > + > +class AddSmartPools < ActiveRecord::Migration > + def self.up > + create_table :smart_pool_tags do |t| > + t.integer :smart_pool_id, :null => false > + t.integer :tagged_id, :null => false > + t.string :tagged_type, :null => false > + end > + execute "alter table smart_pool_tags add constraint > + fk_smart_pool_tags_pool_id > + foreign key (smart_pool_id) references pools(id)" > + execute "alter table smart_pool_tags add constraint > + unique_smart_pool_tags > + unique (smart_pool_id, tagged_id, tagged_type)" > + > + begin > + dir_root = DirectoryPool.get_directory_root > + unless dir_root > + Pool.transaction do > + dir_root = DirectoryPool.create(:name=>DirectoryPool::ROOT_NAME) > + hw_root = DirectoryPool.new(:name=>DirectoryPool::HARDWARE_ROOT) > + hw_root.create_with_parent(dir_root) > + smart_root = DirectoryPool.new(:name=>DirectoryPool::SMART_ROOT) > + smart_root.create_with_parent(dir_root) > + default_pool = Pool.root(:conditions=>"type='HardwarePool'") > + default_pool = HardwarePool.create( :name=>'default') unless default_pool > + default_pool.move_to_child_of(hw_root) > + default_pool.permissions.each do |permission| > + new_permission = Permission.new({:pool_id => dir_root.id, > + :uid => permission.uid, > + :user_role => permission.user_role}) > + new_permission.save! > + end > + end > + end > + rescue > + puts "Could not create DirectoryPool hierarchy..." > + end > + end > + > + def self.down > + drop_table :smart_pool_tags > + end > +end > Post-push comment: I feel that this is going to break alot of test cases / the test suite as the pool test fixtures are now invalid (eg they don't contain the correct top-level pool heirarchy) and changing these means we will need to change alot of the validations in the test suite (unfortunately due to previous problems with the build system and the new repo setup this is hard to validate currently). Perhaps we can work together in the near future to refix this. -Mo From pmyers at redhat.com Fri Sep 5 13:47:53 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 05 Sep 2008 09:47:53 -0400 Subject: [Ovirt-devel] [PATCH] docs/Makefile (publish): Remove no-op "TBD" rules. In-Reply-To: <87wshrhxxy.fsf@rho.meyering.net> References: <87wshrhxxy.fsf@rho.meyering.net> Message-ID: <48C13889.6030902@redhat.com> Jim Meyering wrote: > Hmm... beginning to see a small problem here. > I would have much preferred to see "docs/Makefile" in the patch itself. > With sub-directories and the occasional file (like Makefile) > that appears in each of the newly-split 6 repositories, > there's ample room for misapplication of patches and general confusion. Thanks for cleaning this up.... What I did was just a hack to get things working :) As for the docs/Makefile problem. I suggest that we include in the patch comments what repo the patch is for. i.e. [ovirt-server], [ovirt-docs] that should help clear up any confusion. Perry From pmyers at redhat.com Fri Sep 5 13:49:03 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 05 Sep 2008 09:49:03 -0400 Subject: [Ovirt-devel] [PATCH] ovirt.mk: factor In-Reply-To: <87r67zhxsd.fsf@rho.meyering.net> References: <87r67zhxsd.fsf@rho.meyering.net> Message-ID: <48C138CF.8020104@redhat.com> Jim Meyering wrote: > Here's a patch to factor out some duplication. Ah, ACK I knew you would find a more efficient way to do that... :) Perry >>From eb98bd5c75a4cbb7469b6e377df8dfcb0bc2034e Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Fri, 5 Sep 2008 08:48:54 +0200 > Subject: [PATCH] ovirt.mk: factor > > (for_each_subdir): Define. > (clean, distclean, bumpgit, bumprelease, bumpversion): Use it. > (status): Use cd-in-a-subshell, not pushd+popd. > --- > ovirt.mk | 54 ++++++++++++++++++------------------------------------ > 1 files changed, 18 insertions(+), 36 deletions(-) > > diff --git a/ovirt.mk b/ovirt.mk > index eba36d6..e61f83b 100644 > --- a/ovirt.mk > +++ b/ovirt.mk > @@ -10,59 +10,43 @@ SUBDIRS ?= release server node node-image appliance docs > > export OVIRT_CACHE_DIR ?= $(HOME)/ovirt-cache > > +define for_each_subdir > + for dir in $(SUBDIRS); do \ > + if test -d $$dir ; then \ > + $(MAKE) -C $$dir $@ || exit 1 ; \ > + fi ; \ > + done > +endef > + > all: dev-build > > update: $(SUBDIRS) > > $(SUBDIRS): > - if ! test -d $@; then \ > - git clone $(OVIRT_GIT_SERVER)/ovirt-$@ $@ ; \ > - fi ; \ > - cd $@ ; \ > - if ! test "$(OVIRT_BRANCH)" = "master" ; then \ > - git config remote.origin.fetch +$(OVIRT_BRANCH):$(OVIRT_BRANCH) ; \ > - fi ; \ > - git pull -v && git checkout $(OVIRT_BRANCH) ; \ > + test -d $@ && : || git clone $(OVIRT_GIT_SERVER)/ovirt-$@ $@ > + cd $@ && test "$(OVIRT_BRANCH)" = "master" && \ > + git config remote.origin.fetch +$(OVIRT_BRANCH):$(OVIRT_BRANCH) > + git pull -v && git checkout $(OVIRT_BRANCH) > > clean: > - for dir in $(SUBDIRS); do \ > - if test -d $$dir ; then \ > - $(MAKE) -C $$dir $@ || exit 1 ; \ > - fi ; \ > - done > + $(for_each_subdir) > > distclean: > - for dir in $(SUBDIRS); do \ > - if test -d $$dir ; then \ > - $(MAKE) -C $$dir $@ || exit 1 ; \ > - fi ; \ > - done > + $(for_each_subdir) > > bumpgit: > - for dir in $(SUBDIRS); do \ > - if test -d $$dir ; then \ > - $(MAKE) -C $$dir $@ || exit 1 ; \ > - fi ; \ > - done > + $(for_each_subdir) > > bumprelease: > - for dir in $(SUBDIRS); do \ > - if test -d $$dir ; then \ > - $(MAKE) -C $$dir $@ || exit 1 ; \ > - fi ; \ > - done > + $(for_each_subdir) > > bumpversion: > - for dir in $(SUBDIRS); do \ > - if test -d $$dir ; then \ > - $(MAKE) -C $$dir $@ || exit 1 ; \ > - fi ; \ > - done > + $(for_each_subdir) > > status: > for dir in $(SUBDIRS); do \ > if test -d $$dir ; then \ > - pushd $$dir ; git $@ ; popd > /dev/null ; \ > + (cd $$dir && git $@) ; \ > fi ; \ > done > > @@ -85,5 +69,3 @@ ver-build: update bumpversion build > > .PHONY: all build clean distclean publish $(SUBDIRS) update status \ > bumpgit bumprelease bumpversion dev-build rel-build ver-build > - > - > -- > 1.6.0.1.216.g1b23a > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Fri Sep 5 13:50:09 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 05 Sep 2008 09:50:09 -0400 Subject: [Ovirt-devel] [PATCH] "make clean" should not don't remove my backups! In-Reply-To: <87od33hxl1.fsf@rho.meyering.net> References: <87od33hxl1.fsf@rho.meyering.net> Message-ID: <48C13911.1040402@redhat.com> Jim Meyering wrote: > It is not the job of "make clean" to remove a user's backup files. > It should remove only those files that "make some-target" can create. > > FYI, these separately-created patches apply to docs and release subdirs. > The docs patch has the "-f" option. ACK Perry From sseago at redhat.com Fri Sep 5 14:28:20 2008 From: sseago at redhat.com (Scott Seago) Date: Fri, 05 Sep 2008 10:28:20 -0400 Subject: [Ovirt-devel] [PATCH] initial push of smart pool code. (revised) In-Reply-To: <48C12798.6000106@redhat.com> References: <1220458351-3678-1-git-send-email-sseago@redhat.com> <48C12798.6000106@redhat.com> Message-ID: <48C14204.6070202@redhat.com> Mohammed Morsi wrote: > > Post-push comment: I feel that this is going to break alot of test cases > / the test suite as the pool test fixtures are now invalid (eg they > don't contain the correct top-level pool heirarchy) and changing these > means we will need to change alot of the validations in the test suite > (unfortunately due to previous problems with the build system and the > new repo setup this is hard to validate currently). Perhaps we can work > together in the near future to refix this. > > -Mo > Sure, no problem. I pushed that a bit before it was ready due to the repo refactoring -- I just made sure it didn't break the WUI, but otherwise: 1) it's still not complete (i.e. smart pools still don't have any UI) 2) as you mention, it probably breaks tests too So we need to get the tests in order now. Scott From pmyers at redhat.com Fri Sep 5 14:33:15 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 05 Sep 2008 10:33:15 -0400 Subject: [Ovirt-devel] avoid warnings from "make clean" with parallel make In-Reply-To: <87iqtbhwvz.fsf@rho.meyering.net> References: <87iqtbhwvz.fsf@rho.meyering.net> Message-ID: <48C1432B.9090501@redhat.com> Jim Meyering wrote: > Without the patches below, a top level "make -f release/ovirt.mk clean" > gets warnings with parallel make (i.e. either with -j2 or with MAKEFLAGS=-j$n > in the environment). ACK Perry From dpierce at redhat.com Fri Sep 5 14:52:54 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 5 Sep 2008 10:52:54 -0400 Subject: [Ovirt-devel] Latest additions to HAL Message-ID: <20080905145251.GB5867@redhat.com> I recently submitted a patch to the HAL team that provides extended CPU details that are used during node identification. I'm waiting on feedback from the HAL team at the moment. Hopefully an update will be released in future that will contain those additions. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From bguthro at virtualiron.com Fri Sep 5 15:00:14 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Fri, 5 Sep 2008 11:00:14 -0400 Subject: [Ovirt-devel] custom libvirt in ovirt? Message-ID: Hello, I'm looking into experimenting with oVirt, to use it as a test platform for some of the work we're planning on doing with libvirt. As such - I would like to use a custom built rpm for this build, rather than the one from f9, or ovirt.org Is there a recommended way to integrate a custom package into the build - or am I going to have to invent something to do this? Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Fri Sep 5 15:13:52 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 5 Sep 2008 16:13:52 +0100 Subject: [Ovirt-devel] custom libvirt in ovirt? In-Reply-To: References: Message-ID: <20080905151352.GM22542@redhat.com> On Fri, Sep 05, 2008 at 11:00:14AM -0400, Ben Guthro wrote: > > Hello, > > I'm looking into experimenting with oVirt, to use it as a test platform > for some of the work we're planning on doing with libvirt. > > As such - I would like to use a custom built rpm for this build, rather > than the one from f9, or ovirt.org > > Is there a recommended way to integrate a custom package into the build > - or am I going to have to invent something to do this? We're working on a new build process , splitting up the source repos in GIT into individual modules. As a nice side-effect of that the build process will be able to pull RPMs from a local YUM repository. SO you'd just be able to stuff your custom libvirt RPM into a local YUM repo and it'll be pulled in. I think Perry will be pushing out the new GIT repos very soon Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From clalance at redhat.com Fri Sep 5 15:13:32 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 05 Sep 2008 17:13:32 +0200 Subject: [Ovirt-devel] custom libvirt in ovirt? In-Reply-To: References: Message-ID: <48C14C9C.1020204@redhat.com> Ben Guthro wrote: > > Hello, > > I'm looking into experimenting with oVirt, to use it as a test platform > for some of the work we're planning on doing with libvirt. > > As such - I would like to use a custom built rpm for this build, rather > than the one from f9, or ovirt.org > > Is there a recommended way to integrate a custom package into the build > - or am I going to have to invent something to do this? It's pretty easy; the only thing you really have to do is make sure your custom libvirt rpm has a number greater than the one in the ovirt repo, and then add your repo to common/repos.ks.in before you run build-all. Then the automatic yum dependency stuff will pick it up. Be aware; we are carrying some custom patches in the ovirt.org libvirt, so if you use your own, certain things won't work (migration, in particular). Chris Lalancette From jim at meyering.net Fri Sep 5 16:12:46 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 05 Sep 2008 18:12:46 +0200 Subject: [Ovirt-devel] avoid nonzero exit status from "make -f ovirt.mk status" Message-ID: <87vdxah8qp.fsf@rho.meyering.net> Perry Myers reported that "make -f ovirt.mk status" fails, with output like this: # On branch next nothing to commit (working directory clean) # On branch next nothing to commit (working directory clean) # On branch next nothing to commit (working directory clean) # On branch next nothing to commit (working directory clean) # On branch next nothing to commit (working directory clean) # On branch next nothing to commit (working directory clean) make: *** [status] Error 1 That's because the failure of "git status" was leaking out to the shell. This fixes it: >From 6a268df91ee1c88a541c37a9f725bf5f4aa96553 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 18:09:56 +0200 Subject: [PATCH] * ovirt.mk (status): Ignore a nonzero exit status from git status. --- ovirt.mk | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index 78ee0f5..d94b280 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -46,7 +46,7 @@ bumpversion: status: for dir in $(SUBDIRS); do \ if test -d $$dir ; then \ - (cd $$dir && git $@) ; \ + (cd $$dir && git $@) || :; \ fi ; \ done -- 1.6.0.1.196.g01914 From pmyers at redhat.com Fri Sep 5 16:18:26 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 05 Sep 2008 12:18:26 -0400 Subject: [Ovirt-devel] avoid nonzero exit status from "make -f ovirt.mk status" In-Reply-To: <87vdxah8qp.fsf@rho.meyering.net> References: <87vdxah8qp.fsf@rho.meyering.net> Message-ID: <48C15BD2.9050801@redhat.com> Jim Meyering wrote: > Perry Myers reported that "make -f ovirt.mk status" fails, > with output like this: > > # On branch next > nothing to commit (working directory clean) > # On branch next > nothing to commit (working directory clean) > # On branch next > nothing to commit (working directory clean) > # On branch next > nothing to commit (working directory clean) > # On branch next > nothing to commit (working directory clean) > # On branch next > nothing to commit (working directory clean) > make: *** [status] Error 1 > > That's because the failure of "git status" was leaking > out to the shell. This fixes it: Ack :) Perry From jim at meyering.net Fri Sep 5 16:22:35 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 05 Sep 2008 18:22:35 +0200 Subject: [Ovirt-devel] avoid nonzero exit status from "make -f ovirt.mk status" In-Reply-To: <48C15BD2.9050801@redhat.com> (Perry N. Myers's message of "Fri, 05 Sep 2008 12:18:26 -0400") References: <87vdxah8qp.fsf@rho.meyering.net> <48C15BD2.9050801@redhat.com> Message-ID: <87prnih8ac.fsf@rho.meyering.net> "Perry N. Myers" wrote: >> That's because the failure of "git status" was leaking >> out to the shell. This fixes it: > > Ack :) Thanks. Pushed. From neil at brightbox.co.uk Sun Sep 7 09:10:27 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Sun, 7 Sep 2008 10:10:27 +0100 Subject: [Ovirt-devel] NIC bonding and failover... Message-ID: <50d9f33a0809070210t3d79d813l2adaccbe9a8147d2@mail.gmail.com> I would certainly suggest support for the Link Aggregation Control Protocal - LACP (which is mode 4 on the binding driver IIRC) for those cards and switches that support it. It makes the entire process completely automatic, very standard and link efficient. Only if that trunking fails (such as when there is no miimon or no LACP upstream switch) would I fall back to the more manual mechanisms. LACP is PXE for trunking and is supported on very cost effective switches. (HP 1800 8G for example). Regards Neil Wilson Brightbox systems From apevec at redhat.com Sun Sep 7 10:15:22 2008 From: apevec at redhat.com (Alan Pevec) Date: Sun, 7 Sep 2008 12:15:22 +0200 Subject: [Ovirt-devel] [PATCH] ovirt-node-image: require livecd-tools from ovirt.org repo for F9 Message-ID: <1220782522-31363-1-git-send-email-apevec@redhat.com> Signed-off-by: Alan Pevec --- ovirt-node-image.spec | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec index 297d711..9e47e54 100644 --- a/ovirt-node-image.spec +++ b/ovirt-node-image.spec @@ -12,7 +12,7 @@ License: Fedora Group: Applications/System BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot URL: http://ovirt.org/ -BuildRequires: livecd-tools >= 017 +BuildRequires: livecd-tools >= 017.1-2ovirt BuildRequires: syslinux %define app_root %{_datadir}/%{name} -- 1.5.5.1 From apevec at redhat.com Sun Sep 7 10:56:20 2008 From: apevec at redhat.com (Alan Pevec) Date: Sun, 7 Sep 2008 12:56:20 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] cleanup directory Message-ID: <1220784980-980-1-git-send-email-apevec@redhat.com> Signed-off-by: Alan Pevec --- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 58ae5e4..c51b04d 100644 --- a/Makefile +++ b/Makefile @@ -25,7 +25,7 @@ RPM_FLAGS += --define "ovirt_url $(OVIRT_URL)" endif clean: - rm -f $(pkg_name)-* + rm -rf $(pkg_name)-* distclean: clean rm -rf tmp repos.ks rpm-build -- 1.5.5.1 From apevec at redhat.com Sun Sep 7 10:57:12 2008 From: apevec at redhat.com (Alan Pevec) Date: Sun, 7 Sep 2008 12:57:12 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] use fedora_url for fedora_tree_url Message-ID: <1220785032-1049-1-git-send-email-apevec@redhat.com> Signed-off-by: Alan Pevec --- ovirt-appliance.spec | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index 4b65b57..bbc0e77 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -1,5 +1,8 @@ %{!?ovirt_cache_dir: %define ovirt_cache_dir /var/tmp/ovirt-cache} %{!?ovirt_url: %define ovirt_url http://ovirt.org/repos/ovirt} +%if %{fedora_url} +%define fedora_tree_url %{fedora_url}/releases/%{fedora}/Fedora/%{_arch}/os +%endif %{!?fedora_tree_url: %define fedora_tree_url http://download.fedoraproject.org/pub/fedora/linux/releases/%{fedora}/Fedora/%{_arch}/os} %define fedora_mirror http://mirrors.fedoraproject.org/mirrorlist -- 1.5.5.1 From sakaia at jp.fujitsu.com Mon Sep 8 06:36:22 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Mon, 08 Sep 2008 15:36:22 +0900 Subject: [Ovirt-devel] Question about ovirt migration Message-ID: <200809080636.m886aNaS008072@fjmscan501.ms.jp.fujitsu.com> Hi, I want to confirm the ovirt migration status. (This is available only usual version not developer version.) In my understanding, KVM supports migration, Qemu does not support migration at this moment. For this situation, ovirt for developer does not support migration. So we test migration. We need to use usual ovirt? Is this my understanding correct? +------+----+---+ +---+ | |Adm |Gst| |Gst| Qemu guest | |Node+---+--+------+ | | |Manag1|Manag2| KVM guest + +------------------+ | KVM | +-------------------------+ ==Developer version image== Ref qemu/migration.c migration.h in kvm-userspace start_migration, migrate_write, migrate_finish (which does not exist on qemu original code.) http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=blob;f=qemu/migration.c;h=a64a28744e89e3fc3f9bb0319f2ae3e0b703b375;hb=HEAD Thanks Atsushi SAKAI From clalance at redhat.com Mon Sep 8 06:53:24 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 08 Sep 2008 08:53:24 +0200 Subject: [Ovirt-devel] Question about ovirt migration In-Reply-To: <200809080636.m886aNaS008072@fjmscan501.ms.jp.fujitsu.com> References: <200809080636.m886aNaS008072@fjmscan501.ms.jp.fujitsu.com> Message-ID: <48C4CBE4.1070007@redhat.com> Atsushi SAKAI wrote: > Hi, > > I want to confirm the ovirt migration status. > (This is available only usual version not developer version.) > > In my understanding, > KVM supports migration, Qemu does not support migration at this moment. > For this situation, ovirt for developer does not support migration. > So we test migration. We need to use usual ovirt? > Is this my understanding correct? Well, no. Here's the deal: there is live migration code in upstream kvm userspace, but not in upstream qemu. What that means is that you can live migrate KVM guests, but you can *also* live migrate fully emulated guests, as long as you use the KVM binary to do it (which ovirt does). So you should be able to live migrate even when you are using the "fake" managed nodes. Chris Lalancette From sakaia at jp.fujitsu.com Mon Sep 8 08:07:12 2008 From: sakaia at jp.fujitsu.com (Atsushi SAKAI) Date: Mon, 08 Sep 2008 17:07:12 +0900 Subject: [Ovirt-devel] Question about ovirt migration In-Reply-To: <48C4CBE4.1070007@redhat.com> References: <48C4CBE4.1070007@redhat.com> Message-ID: <200809080807.m8887E4o007472@fjmscan501.ms.jp.fujitsu.com> Hi, Chris Thank you for your description. Then I want to understand the software layer for *fake* managed node. But, Nested KVM does not support at this moment.(Ref) Would you point the code of guest boot on fake managed node? Ref. [PATCH 0/9] [RFC] Add support for nested SVM (kernel) http://thread.gmane.org/gmane.comp.emulators.kvm.devel/21119 Thanks Atsushi SAKAI Chris Lalancette wrote: > Atsushi SAKAI wrote: > > Hi, > > > > I want to confirm the ovirt migration status. > > (This is available only usual version not developer version.) > > > > In my understanding, > > KVM supports migration, Qemu does not support migration at this moment. > > For this situation, ovirt for developer does not support migration. > > So we test migration. We need to use usual ovirt? > > Is this my understanding correct? > > Well, no. Here's the deal: there is live migration code in upstream kvm > userspace, but not in upstream qemu. What that means is that you can live > migrate KVM guests, but you can *also* live migrate fully emulated guests, as > long as you use the KVM binary to do it (which ovirt does). So you should be > able to live migrate even when you are using the "fake" managed nodes. > > Chris Lalancette From clalance at redhat.com Mon Sep 8 08:17:43 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 08 Sep 2008 10:17:43 +0200 Subject: [Ovirt-devel] Question about ovirt migration In-Reply-To: <200809080807.m8887E4o007472@fjmscan501.ms.jp.fujitsu.com> References: <48C4CBE4.1070007@redhat.com> <200809080807.m8887E4o007472@fjmscan501.ms.jp.fujitsu.com> Message-ID: <48C4DFA7.9070805@redhat.com> Atsushi SAKAI wrote: > Hi, Chris > > Thank you for your description. > > Then I want to understand the software layer for *fake* managed node. > But, Nested KVM does not support at this moment.(Ref) > Would you point the code of guest boot on fake managed node? > > Ref. > [PATCH 0/9] [RFC] Add support for nested SVM (kernel) > http://thread.gmane.org/gmane.comp.emulators.kvm.devel/21119 No, no. We aren't using this at all (it's not in KVM at the moment, I don't think, and even if it was, there is no reason to use it in our case). What happens is that when we install the WUI appliance, we also "install" 3 fake managed nodes alongside the WUI appliance. These are basically just libvirt XML files, that will PXE boot when you start them up. So, what happens is that you boot up the WUI appliance; once that is up, you can boot up your fake managed nodes. Each of these fake managed nodes appears in the WUI as Hosts where you can start guests. And, indeed, you can start guests inside of them; however, the guests inside of them are fully emulated only (not KVM accelerated), because we aren't using the nested SVM type stuff. In point of fact, the nested SVM stuff isn't really interesting to us; the whole point of ovirt is to manage physical hardware. So the fake managed nodes are just a useful abstraction to let people who have limited hardware at least see what ovirt can do. Chris Lalancette From pmyers at redhat.com Mon Sep 8 12:30:01 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 08:30:01 -0400 Subject: [Ovirt-devel] Question about ovirt migration In-Reply-To: <48C4DFA7.9070805@redhat.com> References: <48C4CBE4.1070007@redhat.com> <200809080807.m8887E4o007472@fjmscan501.ms.jp.fujitsu.com> <48C4DFA7.9070805@redhat.com> Message-ID: <48C51AC9.6010000@redhat.com> Chris Lalancette wrote: > Atsushi SAKAI wrote: >> Hi, Chris >> >> Thank you for your description. >> >> Then I want to understand the software layer for *fake* managed node. >> But, Nested KVM does not support at this moment.(Ref) >> Would you point the code of guest boot on fake managed node? >> >> Ref. >> [PATCH 0/9] [RFC] Add support for nested SVM (kernel) >> http://thread.gmane.org/gmane.comp.emulators.kvm.devel/21119 > > No, no. We aren't using this at all (it's not in KVM at the moment, I don't > think, and even if it was, there is no reason to use it in our case). What > happens is that when we install the WUI appliance, we also "install" 3 fake > managed nodes alongside the WUI appliance. These are basically just libvirt XML > files, that will PXE boot when you start them up. So, what happens is that you > boot up the WUI appliance; once that is up, you can boot up your fake managed > nodes. Each of these fake managed nodes appears in the WUI as Hosts where you > can start guests. And, indeed, you can start guests inside of them; however, > the guests inside of them are fully emulated only (not KVM accelerated), because > we aren't using the nested SVM type stuff. > > In point of fact, the nested SVM stuff isn't really interesting to us; the whole > point of ovirt is to manage physical hardware. So the fake managed nodes are > just a useful abstraction to let people who have limited hardware at least see > what ovirt can do. A further point... We are in the process of trying to get rid of the 'fake' oVirt Nodes. Instead of using fake Nodes, the oVirt Server will be able to manage: 1. Real physical hosts running the oVirt Node from PXE or USB boot 2. Real HW accelerated VMs running directly on the same host that runs the oVirt Appliance. In the case of #1 oVirt Server will be managing the oVirt Node (aka the Embedded Hypervisor) In the case of #2 oVirt Server will be managing a Fedora 9 host that has the oVirt Node RPM installed on it, to convert a stock Fedora 9 host into something that oVirt can manage. The 'fake' Nodes that we've been using up until now have been a developer convenience and were never meant to be used in production environments. They will be deprecated in favor of using methods #1 and #2 above. Thanks, Perry From pmyers at redhat.com Mon Sep 8 12:30:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 08:30:20 -0400 Subject: [Ovirt-devel] [PATCH] ovirt-node-image: require livecd-tools from ovirt.org repo for F9 In-Reply-To: <1220782522-31363-1-git-send-email-apevec@redhat.com> References: <1220782522-31363-1-git-send-email-apevec@redhat.com> Message-ID: <48C51ADC.9070405@redhat.com> Alan Pevec wrote: > Signed-off-by: Alan Pevec > --- > ovirt-node-image.spec | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) ACK > diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec > index 297d711..9e47e54 100644 > --- a/ovirt-node-image.spec > +++ b/ovirt-node-image.spec > @@ -12,7 +12,7 @@ License: Fedora > Group: Applications/System > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot > URL: http://ovirt.org/ > -BuildRequires: livecd-tools >= 017 > +BuildRequires: livecd-tools >= 017.1-2ovirt > BuildRequires: syslinux > > %define app_root %{_datadir}/%{name} -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Mon Sep 8 12:30:33 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 08:30:33 -0400 Subject: [Ovirt-devel] [PATCH ovirt-appliance] cleanup directory In-Reply-To: <1220784980-980-1-git-send-email-apevec@redhat.com> References: <1220784980-980-1-git-send-email-apevec@redhat.com> Message-ID: <48C51AE9.2070402@redhat.com> Alan Pevec wrote: > Signed-off-by: Alan Pevec > --- > Makefile | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) ACK > diff --git a/Makefile b/Makefile > index 58ae5e4..c51b04d 100644 > --- a/Makefile > +++ b/Makefile > @@ -25,7 +25,7 @@ RPM_FLAGS += --define "ovirt_url $(OVIRT_URL)" > endif > > clean: > - rm -f $(pkg_name)-* > + rm -rf $(pkg_name)-* > > distclean: clean > rm -rf tmp repos.ks rpm-build -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Mon Sep 8 12:31:12 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 08:31:12 -0400 Subject: [Ovirt-devel] [PATCH ovirt-appliance] use fedora_url for fedora_tree_url In-Reply-To: <1220785032-1049-1-git-send-email-apevec@redhat.com> References: <1220785032-1049-1-git-send-email-apevec@redhat.com> Message-ID: <48C51B10.3060109@redhat.com> Alan Pevec wrote: > Signed-off-by: Alan Pevec > --- > ovirt-appliance.spec | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec > index 4b65b57..bbc0e77 100644 > --- a/ovirt-appliance.spec > +++ b/ovirt-appliance.spec > @@ -1,5 +1,8 @@ > %{!?ovirt_cache_dir: %define ovirt_cache_dir /var/tmp/ovirt-cache} > %{!?ovirt_url: %define ovirt_url http://ovirt.org/repos/ovirt} > +%if %{fedora_url} > +%define fedora_tree_url %{fedora_url}/releases/%{fedora}/Fedora/%{_arch}/os > +%endif > %{!?fedora_tree_url: %define fedora_tree_url http://download.fedoraproject.org/pub/fedora/linux/releases/%{fedora}/Fedora/%{_arch}/os} > %define fedora_mirror http://mirrors.fedoraproject.org/mirrorlist > This is fine, but shouldn't this patch be done in conjunction with removing references to FEDORA_TREE_URL in the Makefiles? Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From jim at meyering.net Mon Sep 8 12:32:03 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 14:32:03 +0200 Subject: [Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide Message-ID: <87zlmiake4.fsf@rho.meyering.net> On Friday, I got this: *** ERROR: No build ID note found in /ov/node/rpm-build/BUILDROOT/ovirt-node-0.92-1.fc10.x86_64/usr/sbin/ovirt-identify-node Dan Berrange suggested that it might be because the .spec file mistakenly used ./configure rather than %configure. Actually, the spec file used neither. The fix was to autoconfiscate the package, and that's what I've done. It fixes the above problem, but ovirt as a whole still needs some more help on rawhide, since a top-level "make -f ovirt.mk build" still fails with this: Retrieving file:///me/ovirt-cache/yum/ovirt/repodata/repomd.xml ...OK Retrieving http://fr2.rpmfind.net/linux/fedora/development/x86_64/os/repodata/repomd.xml ...OK Error creating Live CD : Unable to download from repo : Cannot retrieve repository metadata (repomd.xml) for repository: f10-updates. Please verify its path and try again error: Bad exit status from /var/tmp/rpm-tmp.2S2HRK (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.2S2HRK (%build) make[1]: *** [rpms] Error 1 make[1]: Leaving directory `/ov/node-image' make: *** [publish] Error 1 Anyhow, first things first. I have 4 change sets, three tiny ones and the autoconfication one. Autoconfiscation fixes the problem mentioned in the title. However note that you'll need the following small tweak to release/ovirt.mk in order to actually use it. diff --git a/ovirt.mk b/ovirt.mk index e9bff32..9717d14 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -56,6 +56,8 @@ publish: if ! test -d $$dir ; then \ $(MAKE) $$dir || exit 1 ; \ fi ; \ + ( cd $$dir; test ! -f Makefile.in && ./autogen.sh ); \ + ( cd $$dir; test ! -f Makefile && ./configure ); \ $(MAKE) -C $$dir $@ || exit 1 ; \ done rm -f rpms And you'll also need this global Makefile change: find . -name Makefile|xargs grep -l mkdir.-p.rpm-build|xargs perl -pi -e \ 's,(mkdir -p rpm-build),$1/BUILDROOT,' to accomplish this: - mkdir -p rpm-build + mkdir -p rpm-build/BUILDROOT Yes, those constitute two more change sets I owe... Here's the big one: ------------------------------------------------------------------ >From c94b484fcefdb0d1ed8b35da837c35e44fd6b55e Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 5 Sep 2008 17:41:32 +0200 Subject: [PATCH] autoconfiscate Now, you can build with "./autogen.sh && ./configure && make". * ovirt-identify-node/Makefile.am: New file. * ovirt-identify-node/Makefile: Remove, now that it's generated. * configure.ac: New file. * autogen.sh: New file, based on the one from libvirt. * ovirt-identify-node/.gitignore: list ignorable files * .gitignore: list ignorable files * Makefile.am: merge with old Makefile, include release.mk, new rule: tar * Makefile: Remove file. * Makefile.am (tar): add chmod before rm -rf --- .gitignore | 14 ++++++- ovirt-identify-node/Makefile => Makefile.am | 45 +++++++++++++-------- autogen.sh | 57 +++++++++++++++++++++++++++ configure.ac | 13 ++++++ ovirt-identify-node/.gitignore | 11 +++++ Makefile => ovirt-identify-node/Makefile.am | 32 ++++++--------- ovirt-node.spec | 6 ++- 7 files changed, 139 insertions(+), 39 deletions(-) rename ovirt-identify-node/Makefile => Makefile.am (56%) create mode 100755 autogen.sh create mode 100644 configure.ac create mode 100644 ovirt-identify-node/.gitignore rename Makefile => ovirt-identify-node/Makefile.am (66%) diff --git a/.gitignore b/.gitignore index 5895b46..9f17923 100644 --- a/.gitignore +++ b/.gitignore @@ -1 +1,13 @@ -rpm-build +Makefile +Makefile.in +aclocal.m4 +autom4te.cache +config.h +config.h.in +config.log +config.status +configure +depcomp +install-sh +missing +stamp-h1 diff --git a/ovirt-identify-node/Makefile b/Makefile.am similarity index 56% rename from ovirt-identify-node/Makefile rename to Makefile.am index d5e4093..506dbd2 100644 --- a/ovirt-identify-node/Makefile +++ b/Makefile.am @@ -1,5 +1,4 @@ # Copyright (C) 2008 Red Hat, Inc. -# Written by Darryl L. Pierce # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -16,23 +15,33 @@ # MA 02110-1301, USA. A copy of the GNU General Public License is # also available at http://www.gnu.org/copyleft/gpl.html. -CC=gcc -CFLAGS=-Wall -c -g $(shell pkg-config --cflags dbus-1) -LFLAGS=-lhal -lvirt -OBJECTS=comm.o gather.o hal_support.o main.o protocol.o -TARGET=ovirt-identify-node -SOURCES=\ - ovirt-identify-node.c +SUBDIRS = ovirt-identify-node -all: $(TARGET) +EXTRA_DIST = \ + .gitignore \ + ovirt-node.spec \ + release.mk \ + version \ + scripts/collectd \ + scripts/collectd.conf.in \ + scripts/dhclient-exit-hooks \ + scripts/kvm-ifup \ + scripts/ovirt \ + scripts/ovirt-awake \ + scripts/ovirt-early \ + scripts/ovirt-functions \ + scripts/ovirt-post \ + logrotate/ovirt-logrotate \ + logrotate/ovirt-logrotate.conf -.c.o: - $(CC) $(CFLAGS) $< -o $@ +include release.mk -clean: - rm -rf $(OBJECTS) $(TARGET) - -$(TARGET): $(OBJECTS) - $(CC) -o $@ $(OBJECTS) $(LFLAGS) - -.PHONY: all clean +pkg_name = ovirt-node +.PHONY: tar +tar: dist + tar xf $(distdir).tar.gz + mkdir -p rpm-build/BUILDROOT + tar zcvf rpm-build/$(NV).tar.gz $(NV) + cp version rpm-build + chmod -R u+rwx $(NV) + rm -rf $(NV) diff --git a/autogen.sh b/autogen.sh new file mode 100755 index 0000000..77fe883 --- /dev/null +++ b/autogen.sh @@ -0,0 +1,57 @@ +#!/bin/sh +# Run this to generate configure and Makefile + +srcdir=`dirname $0` +test -z "$srcdir" && srcdir=. + +THEDIR=`pwd` +( + cd $srcdir + die=0 + + (autoconf --version) < /dev/null > /dev/null 2>&1 || { + echo + echo "You must have autoconf installed." + echo "Download the appropriate package for your distribution," + echo "or see http://www.gnu.org/software/autoconf" + die=1 + } + + (libtool --version) < /dev/null > /dev/null 2>&1 || { + echo + echo "You must have libtool installed." + echo "Download the appropriate package for your distribution," + echo "or see http://www.gnu.org/software/libtool" + die=1 + } + + (automake --version) < /dev/null > /dev/null 2>&1 || { + echo + die=1 + echo "You must have automake installed." + echo "Download the appropriate package for your distribution," + echo "or see http://www.gnu.org/software/automake" + } + + test $die = 1 && exit 1 + + test -f ovirt-identify-node.h || { + echo "You must run this script in the top-level directory" + exit 1 + } + + if test -z "$*"; then + echo "I am going to run ./configure with no arguments - if you wish " + echo "to pass any to it, please specify them on the $0 command line." + fi + + aclocal + autoheader + automake --add-missing + autoconf +) + +if test "x$OBJ_DIR" != x; then + mkdir -p "$OBJ_DIR" + cd "$OBJ_DIR" +fi diff --git a/configure.ac b/configure.ac new file mode 100644 index 0000000..c780142 --- /dev/null +++ b/configure.ac @@ -0,0 +1,13 @@ +# FIXME: version +AC_INIT([ovirt-node], [0.1], [ovirt-devel at redhat.com]) +AM_INIT_AUTOMAKE([-Wall -Werror foreign]) +AC_PROG_CC +AC_CONFIG_HEADERS([config.h]) + +# for ovirt-identify-node +PKG_CHECK_MODULES([DBUS], [dbus-1]) +PKG_CHECK_MODULES([HAL], [hal]) +PKG_CHECK_MODULES([VIRT], [libvirt]) + +AC_CONFIG_FILES([Makefile ovirt-identify-node/Makefile]) +AC_OUTPUT diff --git a/ovirt-identify-node/.gitignore b/ovirt-identify-node/.gitignore new file mode 100644 index 0000000..e684419 --- /dev/null +++ b/ovirt-identify-node/.gitignore @@ -0,0 +1,11 @@ +*.o +.deps +Makefile +Makefile.in +aclocal.m4 +autom4te.cache +depcomp +install-sh +missing +ovirt-identify-node +stamp-h1 diff --git a/Makefile b/ovirt-identify-node/Makefile.am similarity index 66% rename from Makefile rename to ovirt-identify-node/Makefile.am index 0f182dd..980901c 100644 --- a/Makefile +++ b/ovirt-identify-node/Makefile.am @@ -1,5 +1,4 @@ # Copyright (C) 2008 Red Hat, Inc. -# Written by Darryl L. Pierce # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -16,24 +15,19 @@ # MA 02110-1301, USA. A copy of the GNU General Public License is # also available at http://www.gnu.org/copyleft/gpl.html. -pkg_name = ovirt-node +bin_PROGRAMS = ovirt-identify-node -all: rpms -include release.mk +EXTRA_DIST = AUTHOR -clean: - +$(MAKE) -C ovirt-identify-node clean - rm -rf $(NV) +ovirt_identify_node_SOURCES = \ + ovirt-identify-node.h \ + comm.c \ + gather.c \ + hal_support.c \ + main.c \ + protocol.c -distclean: clean - rm -rf rpm-build - -tar: clean - mkdir -p $(NV) - cp -a logrotate ovirt-identify-node scripts $(NV) - mkdir -p rpm-build - tar zcvf rpm-build/$(NV).tar.gz $(NV) - cp version rpm-build/ - rm -rf $(NV) - -.PHONY: all distclean clean tar +ovirt_identify_node_LDADD = \ + $(LDADD) $(DBUS_LIBS) $(HAL_LIBS) $(VIRT_LIBS) +ovirt_identify_node_CPPFLAGS = \ + $(AM_CPPFLAGS) $(DBUS_CFLAGS) $(HAL_CFLAGS) $(VIRT_CFLAGS) diff --git a/ovirt-node.spec b/ovirt-node.spec index 059fad5..5c092b4 100644 --- a/ovirt-node.spec +++ b/ovirt-node.spec @@ -28,7 +28,8 @@ oVirt Node to interact with the oVirt server. %setup -q %build -make -C ovirt-identify-node +%configure +make %install %{__rm} -rf %{buildroot} @@ -146,6 +147,9 @@ fi %doc ovirt-identify-node/COPYING %changelog +* Mon Sep 8 2008 Jim Meyering - 0.92 0.4 +- Update ovirt-identify-node's build rule. + * Fri Aug 22 2008 Chris Lalancette - 0.92 0.4 - Re-arrange the directory layout, in preparation for ovirt-listen-awake -- 1.6.0.1.196.g01914 From jim at meyering.net Mon Sep 8 12:36:57 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 14:36:57 +0200 Subject: [Ovirt-devel] [PATCH] Use $(srcdir)/version, so this works from non-srcdir build, too. Message-ID: <87tzcqak5y.fsf@rho.meyering.net> Without this, a non-srcdir build in ovirt-node would fail. (btw, there are already significant differences in the various */release.mk files -- my guess is that this change can safely be applied to all) >From d77760811cf2251f3b56a30783656401948b5b31 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Sep 2008 13:33:07 +0200 Subject: [PATCH] Use $(srcdir)/version, so this works from non-srcdir build, too. Use '=', not ':=', so that VERSION can use the non-:= definition of srcdir. --- release.mk | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/release.mk b/release.mk index b89bd86..9bc6972 100644 --- a/release.mk +++ b/release.mk @@ -2,13 +2,13 @@ # It expects the including Makefile to define the "pkg_name" # variable, as well as a file named "version" in the current directory. -ARCH := $(shell uname -i) -VERSION := $(shell awk '{ print $$1 }' version) -RELEASE := $(shell awk '{ print $$2 }' version) +ARCH = $(shell uname -i) +VERSION = $(shell awk '{ print $$1 }' $(srcdir)/version) +RELEASE = $(shell awk '{ print $$2 }' $(srcdir)/version) NEWVERSION = $$(awk 'BEGIN { printf "%.2f", $(VERSION) + .01 }') NEWRELEASE = $$(($(RELEASE) + 1)) X = $$(awk '{ split($$2,r,"."); \ - printf("%d.%d\n", r[1], r[2]+1) }' version) + printf("%d.%d\n", r[1], r[2]+1) }' $(srcdir)/version) git_head = $$(git log -1 --pretty=format:%h) GITRELEASE = $(X).$$(date --utc +%Y%m%d%H%M)git$(git_head) DIST = $$(rpm --eval '%{dist}') -- 1.6.0.1.196.g01914 From jim at meyering.net Mon Sep 8 12:38:27 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 14:38:27 +0200 Subject: [Ovirt-devel] [PATCH] avoid warnings from gcc -Wshadow Message-ID: <87od2yak3g.fsf@rho.meyering.net> I usually build with gcc's -Wshadow option. That triggered some warnings, and since the changes are tiny, I fixed the code to avoid the warnings. >From d95342b0df5ba6af0315fbf8dd7b77abf04ccae8 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Sep 2008 10:05:48 +0200 Subject: [PATCH] avoid warnings from gcc -Wshadow * gather.c (get_nic_info): Avoid shadowing "index". * gather.c (get_nic_data): Avoid shadowing global "nic_info". --- ovirt-identify-node/gather.c | 10 +++++----- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/ovirt-identify-node/gather.c b/ovirt-identify-node/gather.c index 06b213e..4a664f7 100644 --- a/ovirt-identify-node/gather.c +++ b/ovirt-identify-node/gather.c @@ -192,7 +192,7 @@ create_nic_info(void) /* Determines the speed of the network interface. */ void -get_nic_data(char *nic, nic_info_ptr nic_info) +get_nic_data(char *nic, nic_info_ptr nic_info_p) { char *interface; @@ -233,7 +233,7 @@ get_nic_data(char *nic, nic_info_ptr nic_info) SUPPORTED_10baseT_Full)) bandwidth = 10; - snprintf(nic_info->bandwidth, BUFFER_LENGTH, "%d", bandwidth); + snprintf(nic_info_p->bandwidth, BUFFER_LENGTH, "%d", bandwidth); } } @@ -250,15 +250,15 @@ get_nic_info(void) int num_results; - int index; + int i; nics = libhal_find_device_by_capability(hal_ctx, "net", &num_results, &dbus_error); DEBUG("Found %d NICs\n", num_results); - for (index = 0; index < num_results; index++) { - char *nic = nics[index]; + for (i = 0; i < num_results; i++) { + char *nic = nics[i]; VERBOSE("Starting new NIC.\n"); -- 1.6.0.1.196.g01914 From pmyers at redhat.com Mon Sep 8 12:39:48 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 08:39:48 -0400 Subject: [Ovirt-devel] [PATCH] Use $(srcdir)/version, so this works from non-srcdir build, too. In-Reply-To: <87tzcqak5y.fsf@rho.meyering.net> References: <87tzcqak5y.fsf@rho.meyering.net> Message-ID: <48C51D14.2000207@redhat.com> Jim Meyering wrote: > Without this, a non-srcdir build in ovirt-node would fail. > (btw, there are already significant differences in the various > */release.mk files -- my guess is that this change can safely be > applied to all) Hmm. release.mk should be identical in all repos with the exception of ovirt-docs which has sections of it commented out to prevent build failures (temp hack while ovirt-docs lacks a spec file) Does this patch work where there is no srcdir? i.e. ovirt-node-image, ovirt-appliance, etc? Perry >>From d77760811cf2251f3b56a30783656401948b5b31 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Mon, 8 Sep 2008 13:33:07 +0200 > Subject: [PATCH] Use $(srcdir)/version, so this works from non-srcdir build, too. > > Use '=', not ':=', so that VERSION can use the non-:= definition of srcdir. > --- > release.mk | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/release.mk b/release.mk > index b89bd86..9bc6972 100644 > --- a/release.mk > +++ b/release.mk > @@ -2,13 +2,13 @@ > # It expects the including Makefile to define the "pkg_name" > # variable, as well as a file named "version" in the current directory. > > -ARCH := $(shell uname -i) > -VERSION := $(shell awk '{ print $$1 }' version) > -RELEASE := $(shell awk '{ print $$2 }' version) > +ARCH = $(shell uname -i) > +VERSION = $(shell awk '{ print $$1 }' $(srcdir)/version) > +RELEASE = $(shell awk '{ print $$2 }' $(srcdir)/version) > NEWVERSION = $$(awk 'BEGIN { printf "%.2f", $(VERSION) + .01 }') > NEWRELEASE = $$(($(RELEASE) + 1)) > X = $$(awk '{ split($$2,r,"."); \ > - printf("%d.%d\n", r[1], r[2]+1) }' version) > + printf("%d.%d\n", r[1], r[2]+1) }' $(srcdir)/version) > git_head = $$(git log -1 --pretty=format:%h) > GITRELEASE = $(X).$$(date --utc +%Y%m%d%H%M)git$(git_head) > DIST = $$(rpm --eval '%{dist}') -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From jim at meyering.net Mon Sep 8 12:39:50 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 14:39:50 +0200 Subject: [Ovirt-devel] [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. Message-ID: <87iqt6ak15.fsf@rho.meyering.net> Here's an even tinier change: Without this, a failing ovirt-logrotate would exit successfully. >From 2691a4203489e250fa1e8d64e3c52072f25929a3 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Sep 2008 11:43:06 +0200 Subject: [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. --- logrotate/ovirt-logrotate | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/logrotate/ovirt-logrotate b/logrotate/ovirt-logrotate index f0a2dde..a6a394d 100644 --- a/logrotate/ovirt-logrotate +++ b/logrotate/ovirt-logrotate @@ -6,5 +6,4 @@ EXITVALUE=$? if [ $EXITVALUE != 0 ]; then /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]" fi -exit 0 - +exit $EXITVALUE -- 1.6.0.1.196.g01914 From pmyers at redhat.com Mon Sep 8 12:41:07 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 08:41:07 -0400 Subject: [Ovirt-devel] [PATCH] avoid warnings from gcc -Wshadow In-Reply-To: <87od2yak3g.fsf@rho.meyering.net> References: <87od2yak3g.fsf@rho.meyering.net> Message-ID: <48C51D63.7030106@redhat.com> Jim Meyering wrote: > I usually build with gcc's -Wshadow option. > That triggered some warnings, and since the changes are tiny, > I fixed the code to avoid the warnings. ACK, should you also commit change so that we always build with -Wshadow as well? Perry From berrange at redhat.com Mon Sep 8 12:41:19 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 8 Sep 2008 13:41:19 +0100 Subject: [Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide In-Reply-To: <87zlmiake4.fsf@rho.meyering.net> References: <87zlmiake4.fsf@rho.meyering.net> Message-ID: <20080908124119.GN2315@redhat.com> On Mon, Sep 08, 2008 at 02:32:03PM +0200, Jim Meyering wrote: > On Friday, I got this: > > *** ERROR: No build ID note found in /ov/node/rpm-build/BUILDROOT/ovirt-node-0.92-1.fc10.x86_64/usr/sbin/ovirt-identify-node > --- a/ovirt-identify-node/Makefile > +++ b/Makefile.am > @@ -1,5 +1,4 @@ > # Copyright (C) 2008 Red Hat, Inc. > -# Written by Darryl L. Pierce > # > # This program is free software; you can redistribute it and/or modify > # it under the terms of the GNU General Public License as published by > @@ -16,23 +15,33 @@ > # MA 02110-1301, USA. A copy of the GNU General Public License is > # also available at http://www.gnu.org/copyleft/gpl.html. > > -CC=gcc > -CFLAGS=-Wall -c -g $(shell pkg-config --cflags dbus-1) > -LFLAGS=-lhal -lvirt > -OBJECTS=comm.o gather.o hal_support.o main.o protocol.o > -TARGET=ovirt-identify-node > -SOURCES=\ > - ovirt-identify-node.c > +SUBDIRS = ovirt-identify-node > > -all: $(TARGET) > +EXTRA_DIST = \ > + .gitignore \ > + ovirt-node.spec \ > + release.mk \ > + version \ > + scripts/collectd \ > + scripts/collectd.conf.in \ > + scripts/dhclient-exit-hooks \ > + scripts/kvm-ifup \ > + scripts/ovirt \ > + scripts/ovirt-awake \ > + scripts/ovirt-early \ > + scripts/ovirt-functions \ > + scripts/ovirt-post \ > + logrotate/ovirt-logrotate \ > + logrotate/ovirt-logrotate.conf > > -.c.o: > - $(CC) $(CFLAGS) $< -o $@ > +include release.mk > > -clean: > - rm -rf $(OBJECTS) $(TARGET) > - > -$(TARGET): $(OBJECTS) > - $(CC) -o $@ $(OBJECTS) $(LFLAGS) > - > -.PHONY: all clean > +pkg_name = ovirt-node > +.PHONY: tar > +tar: dist > + tar xf $(distdir).tar.gz > + mkdir -p rpm-build/BUILDROOT > + tar zcvf rpm-build/$(NV).tar.gz $(NV) > + cp version rpm-build > + chmod -R u+rwx $(NV) > + rm -rf $(NV) Do we really need to preserve this custom target when automake provides a perfectly good 'make dist'. It just seems to be taking the tar.gz, extracting it, and then re-creating it with files having a rpm-build/ prefix which is just wierd. RPMs should be built from the real tar.gz automake provides. > diff --git a/autogen.sh b/autogen.sh > --- /dev/null > +++ b/configure.ac > @@ -0,0 +1,13 @@ > +# FIXME: version > +AC_INIT([ovirt-node], [0.1], [ovirt-devel at redhat.com]) > +AM_INIT_AUTOMAKE([-Wall -Werror foreign]) > +AC_PROG_CC > +AC_CONFIG_HEADERS([config.h]) > + > +# for ovirt-identify-node > +PKG_CHECK_MODULES([DBUS], [dbus-1]) > +PKG_CHECK_MODULES([HAL], [hal]) > +PKG_CHECK_MODULES([VIRT], [libvirt]) Should check for minimum required versions really - I'm sure there's a minimal libvirt you need. If you don't know what version of DBus or HAL is required, then pick one from F9 and we can tweak it later eg, PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4]) Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Mon Sep 8 12:46:30 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 08:46:30 -0400 Subject: [Ovirt-devel] [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. In-Reply-To: <87iqt6ak15.fsf@rho.meyering.net> References: <87iqt6ak15.fsf@rho.meyering.net> Message-ID: <48C51EA6.3010104@redhat.com> Jim Meyering wrote: > Here's an even tinier change: > Without this, a failing ovirt-logrotate would exit successfully. > >>From 2691a4203489e250fa1e8d64e3c52072f25929a3 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Mon, 8 Sep 2008 11:43:06 +0200 > Subject: [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. > > --- > logrotate/ovirt-logrotate | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/logrotate/ovirt-logrotate b/logrotate/ovirt-logrotate > index f0a2dde..a6a394d 100644 > --- a/logrotate/ovirt-logrotate > +++ b/logrotate/ovirt-logrotate > @@ -6,5 +6,4 @@ EXITVALUE=$? > if [ $EXITVALUE != 0 ]; then > /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]" > fi > -exit 0 > - > +exit $EXITVALUE What happens if a logrotate script returns a non-zero value? Is there something that we need to catch and handle here? Perry From jim at meyering.net Mon Sep 8 12:49:37 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 14:49:37 +0200 Subject: [Ovirt-devel] [PATCH] Use $(srcdir)/version, so this works from non-srcdir build, too. In-Reply-To: <48C51D14.2000207@redhat.com> (Perry N. Myers's message of "Mon, 08 Sep 2008 08:39:48 -0400") References: <87tzcqak5y.fsf@rho.meyering.net> <48C51D14.2000207@redhat.com> Message-ID: <87d4jeajku.fsf@rho.meyering.net> "Perry N. Myers" wrote: > Jim Meyering wrote: >> Without this, a non-srcdir build in ovirt-node would fail. >> (btw, there are already significant differences in the various >> */release.mk files -- my guess is that this change can safely be >> applied to all) > > Hmm. release.mk should be identical in all repos with the exception > of ovirt-docs which has sections of it commented out to prevent build > failures (temp hack while ovirt-docs lacks a spec file) > > Does this patch work where there is no srcdir? i.e. ovirt-node-image, > ovirt-appliance, etc? Good catch. It'll need a srcdir definition in cases like that, so I'll add a conditional one here. It's not needed in this (node) directory, but would be in the others. This adjusted patch adds it: >From b967f6ed51500f846d5f076979b1b181014f7c65 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Sep 2008 13:33:07 +0200 Subject: [PATCH] Use $(srcdir)/version, so this works from non-srcdir build, too. Use '=', not ':=', so that VERSION can use the non-:= definition of srcdir. Provide a default definition of srcdir, for use in directories that haven't yet been autoconfiscated. --- release.mk | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/release.mk b/release.mk index b89bd86..7d9ddd0 100644 --- a/release.mk +++ b/release.mk @@ -2,13 +2,14 @@ # It expects the including Makefile to define the "pkg_name" # variable, as well as a file named "version" in the current directory. -ARCH := $(shell uname -i) -VERSION := $(shell awk '{ print $$1 }' version) -RELEASE := $(shell awk '{ print $$2 }' version) +srcdir ?= . +ARCH = $(shell uname -i) +VERSION = $(shell awk '{ print $$1 }' $(srcdir)/version) +RELEASE = $(shell awk '{ print $$2 }' $(srcdir)/version) NEWVERSION = $$(awk 'BEGIN { printf "%.2f", $(VERSION) + .01 }') NEWRELEASE = $$(($(RELEASE) + 1)) X = $$(awk '{ split($$2,r,"."); \ - printf("%d.%d\n", r[1], r[2]+1) }' version) + printf("%d.%d\n", r[1], r[2]+1) }' $(srcdir)/version) git_head = $$(git log -1 --pretty=format:%h) GITRELEASE = $(X).$$(date --utc +%Y%m%d%H%M)git$(git_head) DIST = $$(rpm --eval '%{dist}') -- 1.6.0.1.196.g01914 From jim at meyering.net Mon Sep 8 12:58:56 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 14:58:56 +0200 Subject: [Ovirt-devel] [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. In-Reply-To: <48C51EA6.3010104@redhat.com> (Perry N. Myers's message of "Mon, 08 Sep 2008 08:46:30 -0400") References: <87iqt6ak15.fsf@rho.meyering.net> <48C51EA6.3010104@redhat.com> Message-ID: <877i9maj5b.fsf@rho.meyering.net> "Perry N. Myers" wrote: > Jim Meyering wrote: >> Here's an even tinier change: >> Without this, a failing ovirt-logrotate would exit successfully. >> >>>From 2691a4203489e250fa1e8d64e3c52072f25929a3 Mon Sep 17 00:00:00 2001 >> From: Jim Meyering >> Date: Mon, 8 Sep 2008 11:43:06 +0200 >> Subject: [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. >> >> --- >> logrotate/ovirt-logrotate | 3 +-- >> 1 files changed, 1 insertions(+), 2 deletions(-) >> >> diff --git a/logrotate/ovirt-logrotate b/logrotate/ovirt-logrotate >> index f0a2dde..a6a394d 100644 >> --- a/logrotate/ovirt-logrotate >> +++ b/logrotate/ovirt-logrotate >> @@ -6,5 +6,4 @@ EXITVALUE=$? >> if [ $EXITVALUE != 0 ]; then >> /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]" >> fi >> -exit 0 >> - >> +exit $EXITVALUE > > What happens if a logrotate script returns a non-zero value? Is there > something that we need to catch and handle here? I noticed the problem via inspection and fixed it on principle ;-) In case someone runs ovirt-logrotate ... || notify-me-of-failure However, now I see that it is invoked solely via cron. In that case, the failure will be recorded via logger, but the exit status will be ignored. From pmyers at redhat.com Mon Sep 8 13:06:56 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 09:06:56 -0400 Subject: [Ovirt-devel] [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. In-Reply-To: <877i9maj5b.fsf@rho.meyering.net> References: <87iqt6ak15.fsf@rho.meyering.net> <48C51EA6.3010104@redhat.com> <877i9maj5b.fsf@rho.meyering.net> Message-ID: <48C52370.90405@redhat.com> Jim Meyering wrote: > "Perry N. Myers" wrote: >> Jim Meyering wrote: >>> Here's an even tinier change: >>> Without this, a failing ovirt-logrotate would exit successfully. >>> >>> >From 2691a4203489e250fa1e8d64e3c52072f25929a3 Mon Sep 17 00:00:00 2001 >>> From: Jim Meyering >>> Date: Mon, 8 Sep 2008 11:43:06 +0200 >>> Subject: [PATCH] * ovirt-logrotate (EXITVALUE): Propagate failure to exit, too. >>> >>> --- >>> logrotate/ovirt-logrotate | 3 +-- >>> 1 files changed, 1 insertions(+), 2 deletions(-) >>> >>> diff --git a/logrotate/ovirt-logrotate b/logrotate/ovirt-logrotate >>> index f0a2dde..a6a394d 100644 >>> --- a/logrotate/ovirt-logrotate >>> +++ b/logrotate/ovirt-logrotate >>> @@ -6,5 +6,4 @@ EXITVALUE=$? >>> if [ $EXITVALUE != 0 ]; then >>> /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]" >>> fi >>> -exit 0 >>> - >>> +exit $EXITVALUE >> What happens if a logrotate script returns a non-zero value? Is there >> something that we need to catch and handle here? > > I noticed the problem via inspection and fixed it on principle ;-) > In case someone runs ovirt-logrotate ... || notify-me-of-failure > > However, now I see that it is invoked solely via cron. In that case, > the failure will be recorded via logger, but the exit status will be ignored. That's what I thought... Still, there's not reason to artificially return zero in all cases. So I'd say go ahead and push this patch. ACK Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From jim at meyering.net Mon Sep 8 13:26:23 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 15:26:23 +0200 Subject: [Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide In-Reply-To: <20080908124119.GN2315@redhat.com> (Daniel P. Berrange's message of "Mon, 8 Sep 2008 13:41:19 +0100") References: <87zlmiake4.fsf@rho.meyering.net> <20080908124119.GN2315@redhat.com> Message-ID: <871vzuahvk.fsf@rho.meyering.net> "Daniel P. Berrange" wrote: > On Mon, Sep 08, 2008 at 02:32:03PM +0200, Jim Meyering wrote: >> --- a/ovirt-identify-node/Makefile >> +++ b/Makefile.am ... >> +include release.mk >> >> -clean: >> - rm -rf $(OBJECTS) $(TARGET) >> - >> -$(TARGET): $(OBJECTS) >> - $(CC) -o $@ $(OBJECTS) $(LFLAGS) >> - >> -.PHONY: all clean >> +pkg_name = ovirt-node >> +.PHONY: tar >> +tar: dist >> + tar xf $(distdir).tar.gz >> + mkdir -p rpm-build/BUILDROOT >> + tar zcvf rpm-build/$(NV).tar.gz $(NV) >> + cp version rpm-build >> + chmod -R u+rwx $(NV) >> + rm -rf $(NV) > > Do we really need to preserve this custom target when automake > provides a perfectly good 'make dist'. It just seems to be taking > the tar.gz, extracting it, and then re-creating it with files having > a rpm-build/ prefix which is just wierd. RPMs should be built from > the real tar.gz automake provides. Not really, but since other things (see 5 other copies of included release.mk) currently rely on that layout, this keeps my changes small and relatively safe. >> diff --git a/autogen.sh b/autogen.sh >> --- /dev/null >> +++ b/configure.ac >> @@ -0,0 +1,13 @@ >> +# FIXME: version >> +AC_INIT([ovirt-node], [0.1], [ovirt-devel at redhat.com]) >> +AM_INIT_AUTOMAKE([-Wall -Werror foreign]) >> +AC_PROG_CC >> +AC_CONFIG_HEADERS([config.h]) >> + >> +# for ovirt-identify-node >> +PKG_CHECK_MODULES([DBUS], [dbus-1]) >> +PKG_CHECK_MODULES([HAL], [hal]) >> +PKG_CHECK_MODULES([VIRT], [libvirt]) > > Should check for minimum required versions really - I'm sure there's > a minimal libvirt you need. If you don't know what version of DBus > or HAL is required, then pick one from F9 and we can tweak it later > > eg, > > PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4]) Thanks, but how about feature checks instead of version checks? IME, they're less work in the long run, assuming you can come up with a good witness to the desired feature. I.e., if some function was added for libvirt-0.4.4, a simple check for its existence in libvirt. I hesitated to use PKG_CHECK_MODULES, because of the grief it's given me in other projects ;-), but in an attempt to keep this change quick, small and simple I used it nonetheless. Well, in keeping with KISS, I'll take your advice after all. Here's the incremental change: F9 has hal-0.5.11-2 and dbus-1.2.1-1 diff --git a/configure.ac b/configure.ac index c780142..443f4d5 100644 --- a/configure.ac +++ b/configure.ac @@ -1,13 +1,13 @@ -# FIXME: version +# note: the version number here is overridden by the one in release.mk AC_INIT([ovirt-node], [0.1], [ovirt-devel at redhat.com]) AM_INIT_AUTOMAKE([-Wall -Werror foreign]) AC_PROG_CC AC_CONFIG_HEADERS([config.h]) # for ovirt-identify-node -PKG_CHECK_MODULES([DBUS], [dbus-1]) -PKG_CHECK_MODULES([HAL], [hal]) -PKG_CHECK_MODULES([VIRT], [libvirt]) +PKG_CHECK_MODULES([DBUS], [dbus-1 >= 1.2.1]) +PKG_CHECK_MODULES([HAL], [hal >= 0.5.11]) +PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4]) AC_CONFIG_FILES([Makefile ovirt-identify-node/Makefile]) AC_OUTPUT From berrange at redhat.com Mon Sep 8 13:36:57 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 8 Sep 2008 14:36:57 +0100 Subject: [Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide In-Reply-To: <871vzuahvk.fsf@rho.meyering.net> References: <87zlmiake4.fsf@rho.meyering.net> <20080908124119.GN2315@redhat.com> <871vzuahvk.fsf@rho.meyering.net> Message-ID: <20080908133657.GP2315@redhat.com> On Mon, Sep 08, 2008 at 03:26:23PM +0200, Jim Meyering wrote: > "Daniel P. Berrange" wrote: > > On Mon, Sep 08, 2008 at 02:32:03PM +0200, Jim Meyering wrote: > >> --- a/ovirt-identify-node/Makefile > >> +++ b/Makefile.am > ... > >> +include release.mk > >> > >> -clean: > >> - rm -rf $(OBJECTS) $(TARGET) > >> - > >> -$(TARGET): $(OBJECTS) > >> - $(CC) -o $@ $(OBJECTS) $(LFLAGS) > >> - > >> -.PHONY: all clean > >> +pkg_name = ovirt-node > >> +.PHONY: tar > >> +tar: dist > >> + tar xf $(distdir).tar.gz > >> + mkdir -p rpm-build/BUILDROOT > >> + tar zcvf rpm-build/$(NV).tar.gz $(NV) > >> + cp version rpm-build > >> + chmod -R u+rwx $(NV) > >> + rm -rf $(NV) > > > > Do we really need to preserve this custom target when automake > > provides a perfectly good 'make dist'. It just seems to be taking > > the tar.gz, extracting it, and then re-creating it with files having > > a rpm-build/ prefix which is just wierd. RPMs should be built from > > the real tar.gz automake provides. > > Not really, but since other things (see 5 other copies of included > release.mk) currently rely on that layout, this keeps my changes > small and relatively safe. Hmm, actually this is even more bizarre that I thought - it isn't actually creating the tar.gz with different prefix. Unless I'm missing something, can't it be simplified to > >> +tar: dist > >> + cp $(distdir).tar.gz rpm-build/ > >> + cp version rpm-build Ultimately 'release.mk'; should just call 'make dist' and look in the top level dir to start with, but good idea to separate that change from the main re-factoring. > >> + > >> +# for ovirt-identify-node > >> +PKG_CHECK_MODULES([DBUS], [dbus-1]) > >> +PKG_CHECK_MODULES([HAL], [hal]) > >> +PKG_CHECK_MODULES([VIRT], [libvirt]) > > > > Should check for minimum required versions really - I'm sure there's > > a minimal libvirt you need. If you don't know what version of DBus > > or HAL is required, then pick one from F9 and we can tweak it later > > > > eg, > > > > PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4]) > > Thanks, but how about feature checks instead of version checks? > IME, they're less work in the long run, assuming you can come > up with a good witness to the desired feature. I.e., if some > function was added for libvirt-0.4.4, a simple check for its > existence in libvirt. > > I hesitated to use PKG_CHECK_MODULES, because of the grief > it's given me in other projects ;-), but in an attempt to keep > this change quick, small and simple I used it nonetheless. > Well, in keeping with KISS, I'll take your advice after all. The trouble with checking for desired features, is which function do you check for as your 'base' level check. The idea of feature checks it to let someone backport a feature and not get tripped up by a version check, but there's still some level of basic functiuonality required. For GTK-VNC I make use of both approaches. A basic check for a reasonable known minimum version, and then feature checks for specific addons from newer versions we're able to work work GTK_REQUIRED=2.10.0 PKG_CHECK_MODULES(GTK, gtk+-2.0 >= $GTK_REQUIRED) AC_CHECK_LIB([gdk], [gdk_cairo_create], [WITH_GTK_CAIRO=1], [WITH_GTK_CAIRO=0]) > Here's the incremental change: ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jim at meyering.net Mon Sep 8 13:37:36 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 15:37:36 +0200 Subject: [Ovirt-devel] [PATCH] avoid warnings from gcc -Wshadow In-Reply-To: <48C51D63.7030106@redhat.com> (Perry N. Myers's message of "Mon, 08 Sep 2008 08:41:07 -0400") References: <87od2yak3g.fsf@rho.meyering.net> <48C51D63.7030106@redhat.com> Message-ID: <87vdx692sf.fsf@rho.meyering.net> "Perry N. Myers" wrote: > Jim Meyering wrote: >> I usually build with gcc's -Wshadow option. >> That triggered some warnings, and since the changes are tiny, >> I fixed the code to avoid the warnings. > > ACK, should you also commit change so that we always build with > -Wshadow as well? Yes. Even thought of that, but was lazy^W concentrating on getting things to work on rawhide, so let it slide. Now that you've prodded me, here's a low-investment patch: (for the whole-hog approach, look at libvirt's LIBVIRT_COMPILE_WARNINGS) >From 4584255f33ff21488dd516ee58ca1d9f914acedd Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Sep 2008 15:33:58 +0200 Subject: [PATCH] * configure.ac: If using gcc and default CFLAGS, enable some warnings. --- configure.ac | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 443f4d5..453d015 100644 --- a/configure.ac +++ b/configure.ac @@ -9,5 +9,9 @@ PKG_CHECK_MODULES([DBUS], [dbus-1 >= 1.2.1]) PKG_CHECK_MODULES([HAL], [hal >= 0.5.11]) PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4]) +# If using gcc and default CFLAGS, enable some warnings. +test x"$ac_ct_CC:$CFLAGS" = 'xgcc:-g -O2' \ + && CFLAGS="$CFLAGS -Wshadow -Wall -Werror" + AC_CONFIG_FILES([Makefile ovirt-identify-node/Makefile]) AC_OUTPUT -- 1.6.0.1.196.g01914 From jim at meyering.net Mon Sep 8 13:56:36 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 15:56:36 +0200 Subject: [Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide In-Reply-To: <20080908133657.GP2315@redhat.com> (Daniel P. Berrange's message of "Mon, 8 Sep 2008 14:36:57 +0100") References: <87zlmiake4.fsf@rho.meyering.net> <20080908124119.GN2315@redhat.com> <871vzuahvk.fsf@rho.meyering.net> <20080908133657.GP2315@redhat.com> Message-ID: <87iqt691wr.fsf@rho.meyering.net> "Daniel P. Berrange" wrote: > On Mon, Sep 08, 2008 at 03:26:23PM +0200, Jim Meyering wrote: >> "Daniel P. Berrange" wrote: >> > On Mon, Sep 08, 2008 at 02:32:03PM +0200, Jim Meyering wrote: >> >> --- a/ovirt-identify-node/Makefile >> >> +++ b/Makefile.am >> ... >> >> +include release.mk >> >> >> >> -clean: >> >> - rm -rf $(OBJECTS) $(TARGET) >> >> - >> >> -$(TARGET): $(OBJECTS) >> >> - $(CC) -o $@ $(OBJECTS) $(LFLAGS) >> >> - >> >> -.PHONY: all clean >> >> +pkg_name = ovirt-node >> >> +.PHONY: tar >> >> +tar: dist >> >> + tar xf $(distdir).tar.gz >> >> + mkdir -p rpm-build/BUILDROOT >> >> + tar zcvf rpm-build/$(NV).tar.gz $(NV) >> >> + cp version rpm-build >> >> + chmod -R u+rwx $(NV) >> >> + rm -rf $(NV) >> > >> > Do we really need to preserve this custom target when automake >> > provides a perfectly good 'make dist'. It just seems to be taking >> > the tar.gz, extracting it, and then re-creating it with files having >> > a rpm-build/ prefix which is just wierd. RPMs should be built from >> > the real tar.gz automake provides. >> >> Not really, but since other things (see 5 other copies of included >> release.mk) currently rely on that layout, this keeps my changes >> small and relatively safe. > > Hmm, actually this is even more bizarre that I thought - it isn't > actually creating the tar.gz with different prefix. Unless I'm > missing something, can't it be simplified to > >> >> +tar: dist >> >> + cp $(distdir).tar.gz rpm-build/ >> >> + cp version rpm-build You're right. It can certainly be simplified more. However, we still do need to create the BUILDROOT sub-directory: tar: dist mkdir -p rpm-build/BUILDROOT cp version $(distdir).tar.gz rpm-build > Ultimately 'release.mk'; should just call 'make dist' and look > in the top level dir to start with, but good idea to separate > that change from the main re-factoring. ... > > ACK Thanks for the speedy feedback. From mmorsi at redhat.com Mon Sep 8 14:36:33 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Mon, 08 Sep 2008 10:36:33 -0400 Subject: [Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide In-Reply-To: <87zlmiake4.fsf@rho.meyering.net> References: <87zlmiake4.fsf@rho.meyering.net> Message-ID: <48C53871.4030605@redhat.com> Jim Meyering wrote: > Anyhow, first things first. > I have 4 change sets, three tiny ones and the autoconfication one. > > Autoconfiscation fixes the problem mentioned in the title. > However note that you'll need the following small tweak to > release/ovirt.mk in order to actually use it. > > diff --git a/ovirt.mk b/ovirt.mk > index e9bff32..9717d14 100644 > --- a/ovirt.mk > +++ b/ovirt.mk > @@ -56,6 +56,8 @@ publish: > if ! test -d $$dir ; then \ > $(MAKE) $$dir || exit 1 ; \ > fi ; \ > + ( cd $$dir; test ! -f Makefile.in && ./autogen.sh ); \ > + ( cd $$dir; test ! -f Makefile && ./configure ); \ > $(MAKE) -C $$dir $@ || exit 1 ; \ > done > rm -f rpms > I'm assuming that the autoconfiscate patch below is to be applied only to the node side of things, correct? If that is the case, am I also correct in saying that this will fail with our current oVirt setup since ovirt-server and the other other repos don't currently have autogen.sh scripts? > diff --git a/autogen.sh b/autogen.sh > new file mode 100755 > index 0000000..77fe883 > --- /dev/null > +++ b/autogen.sh > @@ -0,0 +1,57 @@ > +#!/bin/sh > +# Run this to generate configure and Makefile > + > +srcdir=`dirname $0` > +test -z "$srcdir" && srcdir=. > + > +THEDIR=`pwd` > +( > + cd $srcdir > + die=0 > + > + (autoconf --version) < /dev/null > /dev/null 2>&1 || { > + echo > + echo "You must have autoconf installed." > + echo "Download the appropriate package for your distribution," > + echo "or see http://www.gnu.org/software/autoconf" > + die=1 > + } > + > + (libtool --version) < /dev/null > /dev/null 2>&1 || { > + echo > + echo "You must have libtool installed." > + echo "Download the appropriate package for your distribution," > + echo "or see http://www.gnu.org/software/libtool" > + die=1 > + } > + > + (automake --version) < /dev/null > /dev/null 2>&1 || { > + echo > + die=1 > + echo "You must have automake installed." > + echo "Download the appropriate package for your distribution," > + echo "or see http://www.gnu.org/software/automake" > + } > + > + test $die = 1 && exit 1 > + > + test -f ovirt-identify-node.h || { > + echo "You must run this script in the top-level directory" > + exit 1 > + } > Should this be test ! -f ovirt-identify-node.h? The way it is now, it fails if that file (which is in the ovirt-identify-node subdir) isn't present in the current directory. Other than that it looks good as far as I can tell; as after I applied that patch and made the aforementioned change I was able to run "autogen.sh" and "make" to produce the ovirt-node rpms. -Mo From jim at meyering.net Mon Sep 8 15:20:15 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 17:20:15 +0200 Subject: [Ovirt-devel] work around "*** ERROR: No build ID note found in..." on rawhide In-Reply-To: <48C53871.4030605@redhat.com> (Mohammed Morsi's message of "Mon, 08 Sep 2008 10:36:33 -0400") References: <87zlmiake4.fsf@rho.meyering.net> <48C53871.4030605@redhat.com> Message-ID: <877i9m8y1c.fsf@rho.meyering.net> Mohammed Morsi wrote: > Jim Meyering wrote: >> Anyhow, first things first. >> I have 4 change sets, three tiny ones and the autoconfication one. >> >> Autoconfiscation fixes the problem mentioned in the title. >> However note that you'll need the following small tweak to >> release/ovirt.mk in order to actually use it. ... > I'm assuming that the autoconfiscate patch below is to be applied only > to the node side of things, correct? Yes. > If that is the case, am I also > correct in saying that this will fail with our current oVirt setup since > ovirt-server and the other other repos don't currently have autogen.sh > scripts? No. This affects only the ovirt-node repo. The other repositories/subdirs are independent. >> diff --git a/autogen.sh b/autogen.sh ... >> + test -f ovirt-identify-node.h || { >> + echo "You must run this script in the top-level directory" >> + exit 1 >> + } >> > Should this be test ! -f ovirt-identify-node.h? The way it is now, it > fails if that file (which is in the ovirt-identify-node subdir) isn't > present in the current directory. Good catch! That should be testing for an expected-to-exist file somewhere in the hierarchy. My first iteration of autogen.sh was in the ovirt-identify-node subdir. Here's the fix (along with the tar-rule fix one from discussion with Dan) that I'm folding in: diff --git a/Makefile.am b/Makefile.am index 506dbd2..0ae494d 100644 --- a/Makefile.am +++ b/Makefile.am @@ -39,9 +39,5 @@ include release.mk pkg_name = ovirt-node .PHONY: tar tar: dist - tar xf $(distdir).tar.gz mkdir -p rpm-build/BUILDROOT - tar zcvf rpm-build/$(NV).tar.gz $(NV) - cp version rpm-build - chmod -R u+rwx $(NV) - rm -rf $(NV) + cp version $(distdir).tar.gz rpm-build diff --git a/autogen.sh b/autogen.sh index 77fe883..85352f0 100755 --- a/autogen.sh +++ b/autogen.sh @@ -35,7 +35,7 @@ THEDIR=`pwd` test $die = 1 && exit 1 - test -f ovirt-identify-node.h || { + test -f ovirt-node.spec || { echo "You must run this script in the top-level directory" exit 1 } > Other than that it looks good as far as I can tell; as after I applied > that patch and made the aforementioned change I was able to run > "autogen.sh" and "make" to produce the ovirt-node rpms. Thanks for the feedback and for testing. From bguthro at virtualiron.com Mon Sep 8 15:58:42 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Mon, 8 Sep 2008 11:58:42 -0400 Subject: [Ovirt-devel] root access required? Message-ID: Hello, In my endeavor to set up a build environment for our developers experimenting with oVirt / libvirt, I have come across a general dislike that the build of the ovirt managed node requires the user to be root. In looking into this we have found 2 areas that I am unable to work out a solution for: 1. livecd-tools must mount a filesystem image, requiring: (a) losetup /dev/loopX fs-image Where the user must have write access to /dev/loopX (which by default is writable only by root, readable by group 'disk'). Could be worked around by changing /dev/loopX permissions (once, as root). (b) mount /dev/loopX /mnt/point Also requires root. Can be worked around with /etc/fstab entry allowing user mount. 2. 'rpm --root ...' is used to build the image. --root must chroot to the specified directory to run the various RPM scripts. chroot can't run under 'fakeroot' (AFAIK). I don't know how to avoid or workaround this. So - Does anyone here have any suggestions/recommended practices on how to go about working around these so that root access is not required? Or - are we stuck with "that's just the way it is" for building the managed node image? Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From apevec at redhat.com Mon Sep 8 16:03:16 2008 From: apevec at redhat.com (Alan Pevec) Date: Mon, 08 Sep 2008 18:03:16 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] use fedora_url for fedora_tree_url In-Reply-To: <48C51B10.3060109@redhat.com> References: <1220785032-1049-1-git-send-email-apevec@redhat.com> <48C51B10.3060109@redhat.com> Message-ID: <48C54CC4.4000505@redhat.com> Perry N. Myers wrote: > This is fine, but shouldn't this patch be done in conjunction with > removing references to FEDORA_TREE_URL in the Makefiles? > > Perry committed with FEDORA_TREE_URL removal -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-use-fedora_url-in-fedora_tree_url.patch Type: text/x-patch Size: 1705 bytes Desc: not available URL: From pmyers at redhat.com Mon Sep 8 16:03:21 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 12:03:21 -0400 Subject: [Ovirt-devel] root access required? In-Reply-To: References: Message-ID: <48C54CC9.1080701@redhat.com> Ben Guthro wrote: > Hello, > > In my endeavor to set up a build environment for our developers > experimenting with oVirt / libvirt, I have come across a general dislike > that the build of the ovirt managed node requires the user to be root. > > In looking into this we have found 2 areas that I am unable to work out > a solution for: > > 1. livecd-tools must mount a filesystem image, requiring: > (a) losetup /dev/loopX fs-image > Where the user must have write access to /dev/loopX (which by > default is writable only by root, readable by group 'disk'). > Could be > worked around by changing /dev/loopX permissions (once, as root). > (b) mount /dev/loopX /mnt/point > Also requires root. Can be worked around with /etc/fstab entry > allowing user mount. > > 2. 'rpm --root ...' is used to build the image. > --root must chroot to the specified directory to run the various RPM > scripts. > chroot can't run under 'fakeroot' (AFAIK). > I don't know how to avoid or workaround this. > > So - > Does anyone here have any suggestions/recommended practices on how to go > about working around these so that root access is not required? > > Or - are we stuck with "that's just the way it is" for building the > managed node image? The dependency on needing root is inherited from livecd-tools. So for us to remove root as a requirement for building this needs to be changed upstream. I'd start by posting questions/requests to the livecd mailing lists and see if the developers there can easily fix this. Once root is not longer required for livecd-tools, we will be able to build everything in ovirt as non-root. We've been working on some refactoring of the ovirt repositories to help reduce the requirement to build as root. But it is still required specifically for building the oVirt Appliance and the oVirt Node. The remainder of the items can be built as non-root. Look for an email with details on this from me shortly. Perry From berrange at redhat.com Mon Sep 8 16:08:16 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 8 Sep 2008 17:08:16 +0100 Subject: [Ovirt-devel] root access required? In-Reply-To: References: Message-ID: <20080908160816.GX2315@redhat.com> On Mon, Sep 08, 2008 at 11:58:42AM -0400, Ben Guthro wrote: > Hello, > > In my endeavor to set up a build environment for our developers > experimenting with oVirt / libvirt, I have come across a general > dislike that the build of the ovirt managed node requires the user > to be root. Yep, I don't much like it building as root either :-( > In looking into this we have found 2 areas that I am unable to work out a solution for: > > 1. livecd-tools must mount a filesystem image, requiring: > (a) losetup /dev/loopX fs-image > Where the user must have write access to /dev/loopX (which by > default is writable only by root, readable by group 'disk'). Could be > worked around by changing /dev/loopX permissions (once, as root). > (b) mount /dev/loopX /mnt/point > Also requires root. Can be worked around with /etc/fstab entry > allowing user mount. > > 2. 'rpm --root ...' is used to build the image. > --root must chroot to the specified directory to run the various RPM scripts. > chroot can't run under 'fakeroot' (AFAIK). > I don't know how to avoid or workaround this. Those are basically the same two places where I get to a roadblock. > Does anyone here have any suggestions/recommended practices on how to go > about working around these so that root access is not required? > > Or - are we stuck with "that's just the way it is" for building the > managed node image? The 'mock' program gets around this by using a setuid helper todo the chroot/bind mount stuff it requires. So this lets you run it non-root, but you can't really claim it is secure against anything other than accidental user error. In the absence of other ideas that's the only option I see for the livecd tools. Its probably a fair bit of work todo this though. I'd recommend doing the builds inside a virtual machine to protect your real host from accidental/delibrate damage Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jim at meyering.net Mon Sep 8 16:43:48 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 18:43:48 +0200 Subject: [Ovirt-devel] [PATCH release] add "diff"; work with autoconfiscated subdirs Message-ID: <87vdx67fln.fsf@rho.meyering.net> Build in cleaned "node" dir fails due to missing Makefile. This also makes "make -f ovirt.mk status" and "make -f ovirt.mk diff" output more useful, so you can tell which parts belong to which subdirectories. >From 796ec90ac69a6c65cfdf65c74d1087987e0062ff Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Mon, 8 Sep 2008 18:39:49 +0200 Subject: [PATCH release] add "diff"; work with autoconfiscated subdirs * ovirt.mk (status): Add a "diff" target. Print module/dir name and a line of =========. (publish): Run autogen.sh and/or ./configure in directories like node, that have been autoconfiscated. --- ovirt.mk | 11 +++++++---- 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index e9bff32..8b97ef4 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -43,11 +43,12 @@ bumprelease: bumpversion: $(for_each_subdir) -status: +status diff: for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - (cd $$dir && git $@) || :; \ - fi ; \ + if test -d $$dir ; then \ + echo ===== $$dir =============================================== ;\ + (cd $$dir && git $@) || :; \ + fi ; \ done build: publish @@ -56,6 +57,8 @@ publish: if ! test -d $$dir ; then \ $(MAKE) $$dir || exit 1 ; \ fi ; \ + ( cd $$dir; test ! -f Makefile.in && ./autogen.sh ); \ + ( cd $$dir; test ! -f Makefile && ./configure ); \ $(MAKE) -C $$dir $@ || exit 1 ; \ done rm -f rpms -- 1.6.0.1.196.g01914 From dlively at virtualiron.com Mon Sep 8 17:19:44 2008 From: dlively at virtualiron.com (David Lively) Date: Mon, 08 Sep 2008 13:19:44 -0400 Subject: [Ovirt-devel] root access required? In-Reply-To: References: Message-ID: <1220894384.5971.11.camel@dlively2.katana-technology.com> I've always been a big fan of Debian's 'fakeroot' for making archives whose files have root ownership (without actually boosting the invoking users privileges -- so not a security hole). And now 'fakeroot' is available for Fedora (9, at least) via the official yum repos. But I found one (unsurprisingly) can't 'fakeroot chroot /dir', (where /dir (and children) are owned by the invoking user). But I just today (after Ben sent this) stumbled upon 'fakechroot': http://fakechroot.alioth.debian.org/ At first (very quick) glance, this would appear to do the trick, though I'm not sure whether we'll hit some of the limitations described on the man page: http://fakechroot.alioth.debian.org/index.cgi?ManFakechroot I'm also not sure what it would take to port this into a non-Debian environment, since I haven't yet pulled down the sources. Anyone have any experience with 'fakechroot'?? Dave On Mon, 2008-09-08 at 11:58 -0400, Ben Guthro wrote: > Hello, > > In my endeavor to set up a build environment for our developers > experimenting with oVirt / libvirt, I have come across a general > dislike that the build of the ovirt managed node requires the user to > be root. > > In looking into this we have found 2 areas that I am unable to work > out a solution for: > > 1. livecd-tools must mount a filesystem image, requiring: > (a) losetup /dev/loopX fs-image > Where the user must have write access to /dev/loopX (which by > default is writable only by root, readable by group 'disk'). > Could be > worked around by changing /dev/loopX permissions (once, as > root). > (b) mount /dev/loopX /mnt/point > Also requires root. Can be worked around with /etc/fstab entry > allowing user mount. > > 2. 'rpm --root ...' is used to build the image. > --root must chroot to the specified directory to run the various > RPM scripts. > chroot can't run under 'fakeroot' (AFAIK). > I don't know how to avoid or workaround this. > > So - > Does anyone here have any suggestions/recommended practices on how to > go about working around these so that root access is not required? > > Or - are we stuck with "that's just the way it is" for building the > managed node image? > > Ben > From pmyers at redhat.com Mon Sep 8 17:31:28 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 13:31:28 -0400 Subject: [Ovirt-devel] [PATCH release] add "diff"; work with autoconfiscated subdirs In-Reply-To: <87vdx67fln.fsf@rho.meyering.net> References: <87vdx67fln.fsf@rho.meyering.net> Message-ID: <48C56170.9000600@redhat.com> Jim Meyering wrote: > Build in cleaned "node" dir fails due to missing Makefile. > This also makes "make -f ovirt.mk status" and > "make -f ovirt.mk diff" output more useful, so you > can tell which parts belong to which subdirectories. Nice, ACK. Perry >>From 796ec90ac69a6c65cfdf65c74d1087987e0062ff Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Mon, 8 Sep 2008 18:39:49 +0200 > Subject: [PATCH release] add "diff"; work with autoconfiscated subdirs > > * ovirt.mk (status): Add a "diff" target. > Print module/dir name and a line of =========. > (publish): Run autogen.sh and/or ./configure in directories like > node, that have been autoconfiscated. > --- > ovirt.mk | 11 +++++++---- > 1 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/ovirt.mk b/ovirt.mk > index e9bff32..8b97ef4 100644 > --- a/ovirt.mk > +++ b/ovirt.mk > @@ -43,11 +43,12 @@ bumprelease: > bumpversion: > $(for_each_subdir) > > -status: > +status diff: > for dir in $(SUBDIRS); do \ > - if test -d $$dir ; then \ > - (cd $$dir && git $@) || :; \ > - fi ; \ > + if test -d $$dir ; then \ > + echo ===== $$dir =============================================== ;\ > + (cd $$dir && git $@) || :; \ > + fi ; \ > done > > build: publish > @@ -56,6 +57,8 @@ publish: > if ! test -d $$dir ; then \ > $(MAKE) $$dir || exit 1 ; \ > fi ; \ > + ( cd $$dir; test ! -f Makefile.in && ./autogen.sh ); \ > + ( cd $$dir; test ! -f Makefile && ./configure ); \ > $(MAKE) -C $$dir $@ || exit 1 ; \ > done > rm -f rpms > -- > 1.6.0.1.196.g01914 > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From jim at meyering.net Mon Sep 8 17:37:08 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 19:37:08 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] cleanup directory In-Reply-To: <1220784980-980-1-git-send-email-apevec@redhat.com> (Alan Pevec's message of "Sun, 7 Sep 2008 12:56:20 +0200") References: <1220784980-980-1-git-send-email-apevec@redhat.com> Message-ID: <87prne7d4r.fsf@rho.meyering.net> Alan Pevec wrote: > Signed-off-by: Alan Pevec > --- > Makefile | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/Makefile b/Makefile > index 58ae5e4..c51b04d 100644 > --- a/Makefile > +++ b/Makefile > @@ -25,7 +25,7 @@ RPM_FLAGS += --define "ovirt_url $(OVIRT_URL)" > endif > > clean: > - rm -f $(pkg_name)-* > + rm -rf $(pkg_name)-* > > distclean: clean > rm -rf tmp repos.ks rpm-build Clearly a necessary improvement, since Makefile does this: mkdir -p $(NV) and NV is defined (in release.mk) like this: NV = $(pkg_name)-$(VERSION) Hmm... As I write this, I wonder about removing $(NV) instead. That's a little more readable, since you don't have to go look up where the heck $(pkg_name)-* was created (finding the NV definition in a separate file). Then there's the question of whether you want to remove only this particular directory, or *all* with that prefix, including $(pkg_name)-precious that I carefully renamed for future reference ;-) When I put it that way, I do prefer the more conservative approach of dropping the wildcard and just using $(NV). Either way's ok though. ACK. From jim at meyering.net Mon Sep 8 17:39:16 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 19:39:16 +0200 Subject: [Ovirt-devel] [PATCH] ovirt-node-image: require livecd-tools from ovirt.org repo for F9 In-Reply-To: <1220782522-31363-1-git-send-email-apevec@redhat.com> (Alan Pevec's message of "Sun, 7 Sep 2008 12:15:22 +0200") References: <1220782522-31363-1-git-send-email-apevec@redhat.com> Message-ID: <87k5dm7d17.fsf@rho.meyering.net> Alan Pevec wrote: > Signed-off-by: Alan Pevec > --- > ovirt-node-image.spec | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec > index 297d711..9e47e54 100644 > --- a/ovirt-node-image.spec > +++ b/ovirt-node-image.spec > @@ -12,7 +12,7 @@ License: Fedora > Group: Applications/System > BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot > URL: http://ovirt.org/ > -BuildRequires: livecd-tools >= 017 > +BuildRequires: livecd-tools >= 017.1-2ovirt > BuildRequires: syslinux > > %define app_root %{_datadir}/%{name} Looks small and safe, but why? Maybe add a comment to the spec file or commit log explaining? From bguthro at virtualiron.com Mon Sep 8 17:42:47 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Mon, 08 Sep 2008 13:42:47 -0400 Subject: [Ovirt-devel] root access required? In-Reply-To: <1220894384.5971.11.camel@dlively2.katana-technology.com> References: <1220894384.5971.11.camel@dlively2.katana-technology.com> Message-ID: <48C56417.50306@virtualiron.com> > I'm also not sure what it would take to port this into a non-Debian > environment, since I haven't yet pulled down the sources. > not necessary to port. we just found this available on official yum repos... we'll look into seeing if this solves any of the problems mentioned before, and post any (positive) results. From jim at meyering.net Mon Sep 8 18:21:04 2008 From: jim at meyering.net (Jim Meyering) Date: Mon, 08 Sep 2008 20:21:04 +0200 Subject: [Ovirt-devel] [PATCH release] add "diff"; work with autoconfiscated subdirs In-Reply-To: <48C56170.9000600@redhat.com> (Perry N. Myers's message of "Mon, 08 Sep 2008 13:31:28 -0400") References: <87vdx67fln.fsf@rho.meyering.net> <48C56170.9000600@redhat.com> Message-ID: <87ej3u7b3j.fsf@rho.meyering.net> "Perry N. Myers" wrote: > Jim Meyering wrote: >> Build in cleaned "node" dir fails due to missing Makefile. >> This also makes "make -f ovirt.mk status" and >> "make -f ovirt.mk diff" output more useful, so you >> can tell which parts belong to which subdirectories. > > Nice, ACK. Thanks. Pushed. From apevec at redhat.com Mon Sep 8 19:00:47 2008 From: apevec at redhat.com (Alan Pevec) Date: Mon, 08 Sep 2008 21:00:47 +0200 Subject: [Ovirt-devel] [PATCH] ovirt-node-image: require livecd-tools from ovirt.org repo for F9 In-Reply-To: <87k5dm7d17.fsf@rho.meyering.net> References: <1220782522-31363-1-git-send-email-apevec@redhat.com> <87k5dm7d17.fsf@rho.meyering.net> Message-ID: <48C5765F.2060103@redhat.com> Jim Meyering wrote: >> -BuildRequires: livecd-tools >= 017 >> +BuildRequires: livecd-tools >= 017.1-2ovirt > Looks small and safe, but why? > Maybe add a comment to the spec file or commit log explaining? right, from livecd-tools-017.1-2ovirt1.fc9 changelog: * Thu Aug 14 2008 Alan Pevec 017.1-2ovirt1 - patches from livecd f9-branch after 017.1 tag + bootloader --append fix All those fixes are in 018 in rawhide, and for F9 I'll need to file a BZ and ask maintainer for a bugfix update. From dpierce at redhat.com Mon Sep 8 19:40:10 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Mon, 8 Sep 2008 15:40:10 -0400 Subject: [Ovirt-devel] Re: NIC bonding and failover... In-Reply-To: <50d9f33a0809070210t3d79d813l2adaccbe9a8147d2@mail.gmail.com> References: <50d9f33a0809070210t3d79d813l2adaccbe9a8147d2@mail.gmail.com> Message-ID: <20080908194010.GC4520@redhat.com> +++ Neil Wilson [07/09/08 10:10 +0100]: >I would certainly suggest support for the Link Aggregation Control >Protocal - LACP (which is mode 4 on the binding driver IIRC) for those >cards and switches that support it. It makes the entire process >completely automatic, very standard and link efficient. > >Only if that trunking fails (such as when there is no miimon or no >LACP upstream switch) would I fall back to the more manual mechanisms. > >LACP is PXE for trunking and is supported on very cost effective >switches. (HP 1800 8G for example). Good suggestion. I've added that as a fourth option for how to bond the interfaces, so it currently has: Load Balanced (mode=2) Failover (mode=1) Broadcasting (mode=3) Link Aggregation (mode=4) The mode is used by the future configuration controller when specifying how to load the kernel model. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From pmyers at redhat.com Mon Sep 8 19:40:28 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 08 Sep 2008 15:40:28 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring Message-ID: <48C57FAC.2030909@redhat.com> oVirt is composed of several components that have well defined interfaces and are able to be used in isolation from each other. Our code repository did not reflect this since it was a single monolithic repository for all of oVirt. We've refactored the repositories into the following: ovirt-server : RPMs that provide oVirt Server Suite functionality ovirt-node : RPMs that provide oVirt node functionality ovirt-node-image: RPM that contains LiveCD ISO image and PXE images of the oVirt Node which uses the ovirt-node RPM ovirt-appliance : RPM that contains a Fedora appliance OS with ovirt-server and ovirt-node-image RPMs installed and configured ovirt-release : RPM that contains yum repo configuration file for ovirt.org repositories and developer convenience scripts ovirt-docs : RPMs that contain documentation for the oVirt project The build-all.sh script that was used to build all of the sub-projects of oVirt has been replaced with a top level makefile (ovirt.mk) from the ovirt-release repository and RPM. The old ovirt repo will continue to be hosted on git.et.redhat.org indefinitely, since it corresponds to version 0.92-1 and below of oVirt. The next release of oVirt will use the new refactored repositories. In addition to the repo refactoring and change from build-all.sh to ovirt.mk, we've also tried to reduce the dependency on root access for building. The only sections of the build that still require root are the RPM builds of ovirt-appliance and ovirt-node-image, as these RPMs use livecd-creator which requires root. Because of this, the user running the ovirt.mk makefile should have passwordless sudo as root access. Sudo is used inside of the appliance and node-image spec files to allow livecd-creator to work properly. Developers wishing to take a look at what is currently in development for the next release can do the following on a Fedora 9 host. Install the latest ovirt-release RPM from ovirt.org: $ sudo rpm -ivh http://ovirt.org/repos/ovirt/9/ovirt-release-0.92-1.fc9.noarch.rpm This will add: /etc/yum.repos.d/ovirt.repo - Used for yum update/install of oVirt RPMs /usr/share/ovirt-release/ovirt.mk - Developer Makefile To get the rest of the repositories do the following: $ mkdir ~/ovirt $ cd ~/ovirt\ $ export OVIRT_BRANCH=next $ make -f /usr/share/ovirt-release/ovirt.mk update Replace ~/ovirt with any directory you would like (this is just an example) This will check out all 6 repos from the ovirt.org site. OVIRT_BRANCH is set to next to indicate that you want to work on the next branch instead of master in the git repos. To do a build (similar to build-all.sh in previous releases) do: $ make -f /usr/share/ovirt-release/ovirt.mk build This will build all of the RPMs and make the oVirt Node and Appliance. After that you can run: $ sudo create-ovirt-appliance to create the Appliance on your host. create-ovirt-appliance replaces create-wui-appliance and has the same command line parameters. So to bridge your appliance to eth1, you would use: $ sudo create-ovirt-appliance -e eth1 Give the new repositories and developer scripts a try and please report any problems encountered. Thanks, oVirt Development Team -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From slinabery at redhat.com Mon Sep 8 20:38:20 2008 From: slinabery at redhat.com (Steve Linabery) Date: Mon, 8 Sep 2008 15:38:20 -0500 Subject: [Ovirt-devel] Blocked on flex compilation of open-flash-chart Message-ID: <20080908203820.GC4096@redhat.com> As some of you know, I've been trying to get an open source graphing tool to work with oVirt. The project is called open flash chart, and it lives at http://teethgrinder.co.uk/open-flash-chart-2/ The problem I am blocked on is building the Open Flash Chart (hereafter OFC) project using mxmlc (the command line Action Script compiler that ships with the adobe flex SDK). The author of OFC uses an open source IDE called Flash Develop, but there is no linux port for this Windows-based project. His code relies on some classes provided by the Flash Develop IDE which are used to send debugging trace messages from the swf to the IDE. I have worked around this (temporarily and solely for the immediate purpose of getting *something* to build) by copying the source (.as) files for these classes into my build tree. The tougher nut to crack seems to be dealing with the way the author is using Embedded Fonts. In flex, in order to be able to display text as rotated and have it remain legible, one needs to embed the font definition in the swf. Typically this is done using an "Embed" metadata tag, e.g. [Embed(source="pathToFont", fontFamily="fontName")] private var className:Class;** The author, however, has embedded the Windows Arial font in this manner: [Embed(systemFont='Arial', fontName='spArial', mimeType='application/x-font')] public static var ArialFont:Class; I can get the project to compile if I change the above to: [Embed(systemFont='Nimbus Sans L', fontName='spArial', mimeType='application/x-font')] public static var ArialFont:Class; but then, at runtime, I get the error: "Verify error#1014 Class mx.core::FontAsset could not be found". So at this point, I am faced with some problems whose solutions aren't obvious to me, all of which relate to getting possible changes back into the upstream project. 0) The workaround for the Flash Develop IDE debugging classes: Do I try to persuade the author to include the source for these classes in his project source? Or perhaps point the mxmlc compiler to a different set of source files for these classes that merely imitate the debugging classes by implementing their various methods, but which do nothing (i.e. change "someMethod() { doSomething(); }" to "someMethod() { //do nothing }"...in other words, create "stub" classes that allow the project to compile. 1) I can try re-implementing the Embed metadata tags using linux system fonts in the style at ** above, but I presume the Windows-based project author prefers to continue using the windows fonts. 2) Since I don't really know Action Script or flex development (except what I've picked up from this experience so far), I don't know whether I'm wasting effort on this. It might be more efficient to learn Action Script and roll our own! I would appreciate some help and/or guidance in deciding what path to take at this point. Thanks, Steve From apevec at redhat.com Tue Sep 9 00:21:02 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:21:02 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node] Allow the appliance to manage the hardware it is running on - part 1 In-Reply-To: <1220601430-12218-1-git-send-email-clalance@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> Message-ID: <1220919664-21440-1-git-send-email-apevec@redhat.com> From: Chris Lalancette Add ovirt-listen-awake daemon. This is a very small daemon that oVirt appliance can communicate with to send simple messages to the host it is running on. It's used so that the appliance can "manage" the hardware it is running on, removing the need for the fake oVirt Nodes. Signed-off-by: Chris Lalancette --- Makefile.am | 2 +- configure.ac | 2 +- ovirt-listen-awake/COPYING | 339 +++++++++++++++++++++++++++++++ ovirt-listen-awake/Makefile.am | 26 +++ ovirt-listen-awake/ovirt-listen-awake.c | 213 +++++++++++++++++++ ovirt-node.spec | 7 +- 6 files changed, 586 insertions(+), 3 deletions(-) create mode 100644 ovirt-listen-awake/COPYING create mode 100644 ovirt-listen-awake/Makefile.am create mode 100644 ovirt-listen-awake/ovirt-listen-awake.c diff --git a/Makefile.am b/Makefile.am index 0ae494d..fad3fb5 100644 --- a/Makefile.am +++ b/Makefile.am @@ -15,7 +15,7 @@ # MA 02110-1301, USA. A copy of the GNU General Public License is # also available at http://www.gnu.org/copyleft/gpl.html. -SUBDIRS = ovirt-identify-node +SUBDIRS = ovirt-identify-node ovirt-listen-awake EXTRA_DIST = \ .gitignore \ diff --git a/configure.ac b/configure.ac index 453d015..e6ba7e3 100644 --- a/configure.ac +++ b/configure.ac @@ -13,5 +13,5 @@ PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4]) test x"$ac_ct_CC:$CFLAGS" = 'xgcc:-g -O2' \ && CFLAGS="$CFLAGS -Wshadow -Wall -Werror" -AC_CONFIG_FILES([Makefile ovirt-identify-node/Makefile]) +AC_CONFIG_FILES([Makefile ovirt-identify-node/Makefile ovirt-listen-awake/Makefile]) AC_OUTPUT diff --git a/ovirt-listen-awake/COPYING b/ovirt-listen-awake/COPYING new file mode 100644 index 0000000..d511905 --- /dev/null +++ b/ovirt-listen-awake/COPYING @@ -0,0 +1,339 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Lesser General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License along + with this program; if not, write to the Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Lesser General +Public License instead of this License. diff --git a/ovirt-listen-awake/Makefile.am b/ovirt-listen-awake/Makefile.am new file mode 100644 index 0000000..1d4e870 --- /dev/null +++ b/ovirt-listen-awake/Makefile.am @@ -0,0 +1,20 @@ +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +bin_PROGRAMS = ovirt-listen-awake + +ovirt_listen_awake_SOURCES = ovirt-listen-awake.c diff --git a/ovirt-listen-awake/ovirt-listen-awake.c b/ovirt-listen-awake/ovirt-listen-awake.c new file mode 100644 index 0000000..ceb32dc --- /dev/null +++ b/ovirt-listen-awake/ovirt-listen-awake.c @@ -0,0 +1,213 @@ +/* ovirt-listen-awake: daemon to listen for and respond to AWAKE requests + * + * Copyright (C) 2008 Red Hat, Inc. + * Written by Chris Lalancette + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. A copy of the GNU General Public License is + * also available at http://www.gnu.org/copyleft/gpl.html. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +// We only ever expect to receive the strings "AWAKE" or "IDENTIFY", so +// 20 bytes is more than enough +#define BUFLEN 20 +#define LOGFILE "/var/log/ovirt-host.log" + +static int streq(char *first, char *second) +{ + int first_len, second_len; + + first_len = strlen(first); + second_len = strlen(second); + + if (first_len == second_len && strncmp(first, second, first_len) == 0) + return 1; + return 0; +} + +static void strip_space(char *buffer) +{ + int i; + + i = 0; + while (buffer[i] != '\0') { + if (isspace(buffer[i])) { + // once we see the first whitespace character, we are done + buffer[i] ='\0'; + break; + } + i++; + } +} + +static int listenSocket(int listen_port) +{ + struct sockaddr_in a; + int s,yes; + + if (listen_port < 0) { + fprintf(stderr, "Invalid listen_port %d\n", listen_port); + return -1; + } + + s = socket(AF_INET, SOCK_STREAM, 0); + if (s < 0) { + fprintf(stderr, "Failed creating socket: %s\n", strerror(errno)); + return -1; + } + yes = 1; + if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,(char *)&yes, sizeof (yes)) < 0) { + fprintf(stderr, "Failed setsockopt: %s\n", strerror(errno)); + close(s); + return -1; + } + memset (&a, 0, sizeof (a)); + a.sin_port = htons (listen_port); + a.sin_family = AF_INET; + if (bind(s, (struct sockaddr *) &a, sizeof (a)) < 0) { + fprintf(stderr, "Error binding to port %d: %s\n", listen_port, + strerror(errno)); + close(s); + return -1; + } + listen(s, 10); + return s; +} + +static void usage(void) +{ + printf("Usage: host-startup [OPTIONS]\n"); + printf("OPTIONS:\n"); + printf(" -h\tShow this help message\n"); + printf(" -n\tDo not daemonize (useful for debugging\n"); + exit(1); +} + +int main(int argc, char *argv[]) +{ + int listen_socket, conn; + struct sockaddr_in client_address; + unsigned int addrlen; + FILE *conn_stream; + FILE *logfile; + char buffer[BUFLEN]; + int c; + int do_daemon; + + do_daemon = 1; + + while ((c=getopt(argc, argv, ":hn")) != -1) { + switch(c) { + case 'h': + usage(); + break; + case 'n': + do_daemon = 0; + break; + default: + usage(); + } + } + + if ((argc-optind) != 0) + usage(); + + listen_socket = listenSocket(7777); + if (listen_socket < 0) + return 2; + + if (do_daemon) { + logfile = fopen(LOGFILE,"a+"); + if (logfile == NULL) { + fprintf(stderr, "Error opening logfile %s: %s\n", + LOGFILE, strerror(errno)); + return 3; + } + + // NOTE: this closes stdout and stderr + daemon(0, 0); + + // so re-open them to the logfile here + dup2(fileno(logfile), STDOUT_FILENO); + dup2(fileno(logfile), STDERR_FILENO); + } + + while (1) { + addrlen = sizeof(client_address); + memset(&client_address, 0, addrlen); + memset(buffer, 0, BUFLEN); + conn = accept(listen_socket, (struct sockaddr *)&client_address, &addrlen); + if (conn < 0) { + fprintf(stderr, "Error accepting socket: %s\n", strerror(errno)); + continue; + } + + conn_stream = fdopen(conn, "r"); + if (conn_stream == NULL) { + fprintf(stderr, "Error converting fd to stream: %s\n", strerror(errno)); + close(conn); + continue; + } + + if (fgets(buffer, BUFLEN, conn_stream) == NULL) { + fprintf(stderr, "Error receiving data: %s\n", strerror(errno)); + fclose(conn_stream); + continue; + } + + strip_space(buffer); + + if (streq(buffer, "IDENTIFY")) { + // run ovirt-identify-node against 192.168.50.2 (the WUI node) + fprintf(stderr, "Doing identify\n"); + // FIXME: it would be best to call the "find_srv" shell script here to + // find out where we should contact. However, we would still have to + // hardcode which DNS server to use (192.168.50.2), and which domain + // name to use "priv.ovirt.org" to get this to work. I don't have + // a good idea how to solve this at the moment. + system("ovirt-identify-node -s 192.168.50.2 -p 12120"); + } + else if (streq(buffer, "AWAKE")) { + // run ovirt-awake against 192.168.50.2 + fprintf(stderr, "Doing awake\n"); + // FIXME: I hate to duplicate this stuff here, but I can't use the + // ovirt init scripts as-is; they depend too much on the environment + // (in particular, which DNS server to use to resolve, and which + // domainname). Until I come up with a good solution for that, I'll + // have to leave this as-is. + system("wget -q http://192.168.50.2:80/ipa/config/krb5.ini -O /etc/krb5.conf"); + system("ovirt-awake start 192.168.50.2 12120 /etc/libvirt/krb5.tab"); + } + else { + fprintf(stderr, "Unknown command %s\n", buffer); + } + + fclose(conn_stream); + } + + close(listen_socket); + fclose(logfile); + + return 0; +} diff --git a/ovirt-node.spec b/ovirt-node.spec index 5c092b4..736338d 100644 --- a/ovirt-node.spec +++ b/ovirt-node.spec @@ -43,6 +43,7 @@ make %{__install} -p -m0755 scripts/ovirt-awake %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-identify-node/ovirt-identify-node %{buildroot}%{_sbindir} +%{__install} -p -m0755 ovirt-listen-awake/ovirt-listen-awake %{buildroot}%{_sbindir} %{__install} -p -m0644 scripts/ovirt-functions %{buildroot}%{_initrddir} %{__install} -p -m0755 scripts/ovirt-early %{buildroot}%{_initrddir} @@ -130,6 +131,7 @@ fi %defattr(-,root,root,0755) %{_sbindir}/ovirt-awake %{_sbindir}/ovirt-identify-node +%{_sbindir}/ovirt-listen-awake %{_initrddir}/ovirt-early %{_initrddir}/ovirt %{_initrddir}/ovirt-post @@ -147,9 +149,12 @@ fi %doc ovirt-identify-node/COPYING %changelog -* Mon Sep 8 2008 Jim Meyering - 0.92 0.4 +* Mon Sep 8 2008 Jim Meyering - 0.92 0.6 - Update ovirt-identify-node's build rule. +* Fri Aug 22 2008 Chris Lalancette - 0.92 0.5 +- Add the ovirt-listen-awake daemon to the RPM + * Fri Aug 22 2008 Chris Lalancette - 0.92 0.4 - Re-arrange the directory layout, in preparation for ovirt-listen-awake -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 00:21:03 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:21:03 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node] Allow the appliance to manage the hardware it is running on - part 2 In-Reply-To: <1220919664-21440-1-git-send-email-apevec@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919664-21440-1-git-send-email-apevec@redhat.com> Message-ID: <1220919664-21440-2-git-send-email-apevec@redhat.com> From: Chris Lalancette A rather large re-write of the ovirt-node.spec file. The reason for this is so that we can introduce the concept of the "stateful" oVirt node; that is, one which is already installed and running with an OS. To accomplish this, we add two subpackages: ovirt-node-stateless, and ovirt-node-stateful. They both depend on ovirt-node, which holds most of the necessary binaries. The two subpackages have subtly different %post scripts, since you don't necessarily want to do all of the stuff from stateless on a stateful box. There is also a minor change to common-pkgs to require ovirt-node-stateless, the addition of an init script for ovirt-node-stateful, and the addition of two helper scripts for the stateful case to let you turn your machine into an oVirt node. Signed-off-by: Chris Lalancette --- ovirt-listen-awake/ovirt-convert-host | 51 +++++++++++++++++ ovirt-listen-awake/ovirt-listen-awake.init | 49 ++++++++++++++++ ovirt-listen-awake/ovirt-unconvert-host | 30 ++++++++++ ovirt-node.spec | 85 ++++++++++++++++----------- scripts/ovirt-functions | 25 ++++++++ 5 files changed, 205 insertions(+), 35 deletions(-) create mode 100755 ovirt-listen-awake/ovirt-convert-host create mode 100644 ovirt-listen-awake/ovirt-listen-awake.init create mode 100755 ovirt-listen-awake/ovirt-unconvert-host diff --git a/ovirt-listen-awake/ovirt-convert-host b/ovirt-listen-awake/ovirt-convert-host new file mode 100755 index 0000000..0ef374d --- /dev/null +++ b/ovirt-listen-awake/ovirt-convert-host @@ -0,0 +1,51 @@ +#!/bin/bash + +. /etc/init.d/ovirt-functions + +if [ $# -ne 0 ]; then + echo "Usage: ovirt-convert-host" + exit 1 +fi + +backup_file() { + dir=$(dirname $1) + mkdir -p $OVIRT_BACKUP_DIR/${dir:1} + cp -pf $1 $OVIRT_BACKUP_DIR/${dir:1} +} + +echo "This script will make a number of changes to your system to enable it to" +echo "work as an oVirt node. You can later undo these changes by" +echo "running /usr/sbin/ovirt-unconvert-host. Do you want to proceed? [y/N]?" +read yesno + +if [ "$yesno" != "y" -a "$yesno" != "Y" ]; then + exit 2 +fi + +mkdir -p $OVIRT_BACKUP_DIR + +backup_file /etc/sysconfig/network +sed -i -e 's/^HOSTNAME=.*/HOSTNAME=physical.priv.ovirt.org/' /etc/sysconfig/network + +backup_file /etc/hosts +if [ $( grep -c "physical.priv.ovirt.org" /etc/hosts ) -eq 0 ]; then + echo "192.168.50.1 physical.priv.ovirt.org" >> /etc/hosts +fi +if [ $( grep -c "management.priv.ovirt.org" /etc/hosts ) -eq 0 ]; then + echo "192.168.50.2 management.priv.ovirt.org" >> /etc/hosts +fi + +/sbin/chkconfig ovirt-listen-awake on +/sbin/chkconfig collectd on + +backup_file /etc/sysconfig/libvirtd +backup_file /etc/libvirt/qemu.conf +backup_file /etc/libvirt/libvirtd.conf +backup_file /etc/sasl2/libvirt.conf +ovirt_setup_libvirtd + +backup_file /etc/sysconfig/iptables +/usr/sbin/lokkit -n -t ovirtbr + +echo "Setup complete. To make the changes take effect, shut down any running +guests and reboot the host" diff --git a/ovirt-listen-awake/ovirt-listen-awake.init b/ovirt-listen-awake/ovirt-listen-awake.init new file mode 100644 index 0000000..a6bb78a --- /dev/null +++ b/ovirt-listen-awake/ovirt-listen-awake.init @@ -0,0 +1,49 @@ +#!/bin/bash +# +# +# ovirt-listen-awake startup script for ovirt-listen-awake +# +# chkconfig: - 97 03 +# description: ovirt-listen-awake is a daemon to listen for requests from +# the ovirt VM manager. When it receives one, it contacts the machine +# back with details so that it is added to the ovirt host pool. + +DAEMON=/usr/sbin/ovirt-listen-awake + +. /etc/init.d/functions + +start() { + echo -n "Starting ovirt-listen-awake: " + daemon $DAEMON + RETVAL=$? + echo +} + +stop() { + echo -n "Shutting down ovirt-listen-awake: " + killproc ovirt-listen-awake + RETVAL=$? + echo +} + +case "$1" in + start) + start + ;; + stop) + stop + ;; + restart) + stop + start + ;; + status) + status $DAEMON + RETVAL=$? + ;; + *) + echo "Usage: ovirt-listen-awake {start|stop|restart|status}" + exit 1 + ;; +esac +exit $RETVAL diff --git a/ovirt-listen-awake/ovirt-unconvert-host b/ovirt-listen-awake/ovirt-unconvert-host new file mode 100755 index 0000000..cfaa51d --- /dev/null +++ b/ovirt-listen-awake/ovirt-unconvert-host @@ -0,0 +1,30 @@ +#!/bin/bash + +. /etc/init.d/ovirt-functions + +if [ $# -ne 0 ]; then + echo "Usage: ovirt-unconvert-host" + exit 1 +fi + +if [ ! -d $OVIRT_BACKUP_DIR ]; then + echo "The oVirt backup directory $OVIRT_BACKUP_DIR doesn't exist; can't" + echo "unconvert the host" + exit 2 +fi + +unbackup_file() { + # note that $1 will have a / on the front, so we don't need to add our own + cp -pf $OVIRT_BACKUP_DIR$1 $1 +} + +/sbin/chkconfig ovirt-listen-awake off +/sbin/chkconfig collectd off + +unbackup_file /etc/sysconfig/network +unbackup_file /etc/hosts +unbackup_file /etc/sysconfig/libvirtd +unbackup_file /etc/libvirt/qemu.conf +unbackup_file /etc/libvirt/libvirtd.conf +unbackup_file /etc/sasl2/libvirt.conf +unbackup_file /etc/sysconfig/iptables diff --git a/ovirt-node.spec b/ovirt-node.spec index 736338d..d0a699c 100644 --- a/ovirt-node.spec +++ b/ovirt-node.spec @@ -15,6 +15,8 @@ BuildRequires: libvirt-devel BuildRequires: dbus-devel hal-devel Requires: libvirt Requires: hal +Requires: collectd +Requires: cyrus-sasl-gssapi ExclusiveArch: %{ix86} x86_64 %define app_root %{_datadir}/%{name} @@ -23,6 +25,20 @@ ExclusiveArch: %{ix86} x86_64 Provides a series of daemons and support utilities to allow an oVirt Node to interact with the oVirt server. +%package stateless +Summary: The oVirt Node scripts for stateless +Group: Applications/System +Requires: %{name} = %{version}-%{release} +%description stateless +This package does configuration for a stateless oVirt Node. + +%package stateful +Summary: The oVirt node scripts for existing machines +Group: Applications/System +Requires: %{name} = %{version}-%{release} +%description stateful +This package does configuration for a stateful oVirt node. + %prep %setup -q @@ -44,6 +60,9 @@ make %{__install} -p -m0755 scripts/ovirt-awake %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-identify-node/ovirt-identify-node %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-listen-awake/ovirt-listen-awake %{buildroot}%{_sbindir} +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-listen-awake.init %{buildroot}%{_initrddir}/ovirt-listen-awake +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-convert-host %{buildroot}%{_sbindir} +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-unconvert-host %{buildroot}%{_sbindir} %{__install} -p -m0644 scripts/ovirt-functions %{buildroot}%{_initrddir} %{__install} -p -m0755 scripts/ovirt-early %{buildroot}%{_initrddir} @@ -52,8 +71,6 @@ make %{__install} -p -m0644 scripts/collectd %{buildroot}%{_sysconfdir}/chkconfig.d %{__install} -p -m0644 scripts/collectd.conf.in %{buildroot}%{_sysconfdir} -%{__install} -p -m0755 scripts/kvm-ifup %{buildroot}%{_sysconfdir} -%{__install} -p -m0755 scripts/dhclient-exit-hooks %{buildroot}%{_sysconfdir} %{__install} -p -m0755 logrotate/ovirt-logrotate %{buildroot}%{_sysconfdir}/cron.hourly %{__install} -p -m0644 logrotate/ovirt-logrotate.conf %{buildroot}%{_sysconfdir}/logrotate.d @@ -63,40 +80,25 @@ echo "oVirt Node release %{version}-%{release}" > %{buildroot}%{_sysconfdir}/ovi %clean %{__rm} -rf %{buildroot} -%post +%post stateful +/sbin/chkconfig --add ovirt-listen-awake +# this is ugly; we need collectd to start *after* libvirtd, so we own the +# /etc/chkconfig.d/collectd file, and then have to re-define collectd here +/sbin/chkconfig --add collectd + +%post stateless /sbin/chkconfig --add ovirt-early /sbin/chkconfig ovirt-early on /sbin/chkconfig --add ovirt /sbin/chkconfig ovirt on /sbin/chkconfig --add ovirt-post /sbin/chkconfig ovirt-post on -/sbin/chkconfig --add collectd -/sbin/chkconfig collectd on - -# just to get a boot warning to shut up -touch /etc/resolv.conf - -# make libvirtd listen on the external interfaces -sed -i -e "s/^#\(LIBVIRTD_ARGS=\"--listen\"\).*/\1/" /etc/sysconfig/libvirtd -# set up qemu daemon to allow outside VNC connections -sed -i -e "s/^[[:space:]]*#[[:space:]]*\(vnc_listen = \"0.0.0.0\"\).*/\1/" \ - /etc/libvirt/qemu.conf - -# set up libvirtd to listen on TCP (for kerberos) -sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ - -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ - /etc/libvirt/libvirtd.conf +. /etc/init.d/ovirt-functions ; ovirt_setup_libvirtd # make sure we don't autostart virbr0 on libvirtd startup rm -f /etc/libvirt/qemu/networks/autostart/default.xml -# with the new libvirt (0.4.0), make sure we we setup gssapi in the mech_list -if [ `egrep -c "^mech_list: gssapi" /etc/sasl2/libvirt.conf` -eq 0 ]; then - sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" /etc/sasl2/libvirt.conf - echo "mech_list: gssapi" >> /etc/sasl2/libvirt.conf -fi - # remove the /etc/krb5.conf file; it will be fetched on bootup rm -f /etc/krb5.conf @@ -120,25 +122,22 @@ cat < /etc/issue EOF cp -p /etc/issue /etc/issue.net -%preun +%preun stateless if [ "$1" = 0 ] ; then /sbin/chkconfig --del ovirt-early /sbin/chkconfig --del ovirt /sbin/chkconfig --del ovirt-post fi +%preun stateful +if [ "$1" = 0 ] ; then + /sbin/chkconfig --del ovirt-listen-awake +fi + %files %defattr(-,root,root,0755) %{_sbindir}/ovirt-awake %{_sbindir}/ovirt-identify-node -%{_sbindir}/ovirt-listen-awake -%{_initrddir}/ovirt-early -%{_initrddir}/ovirt -%{_initrddir}/ovirt-post -%{_sysconfdir}/kvm-ifup -%{_sysconfdir}/dhclient-exit-hooks -%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf -%config %{_sysconfdir}/cron.hourly/ovirt-logrotate %defattr(-,root,root,0644) %{_initrddir}/ovirt-functions %{_sysconfdir}/collectd.conf.in @@ -148,10 +147,26 @@ fi %doc ovirt-identify-node/AUTHOR ovirt-identify-node/ChangeLog %doc ovirt-identify-node/COPYING +%files stateful +%{_initrddir}/ovirt-listen-awake +%{_sbindir}/ovirt-listen-awake +%{_sbindir}/ovirt-convert-host +%{_sbindir}/ovirt-unconvert-host + +%files stateless +%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf +%config %{_sysconfdir}/cron.hourly/ovirt-logrotate +%{_initrddir}/ovirt-early +%{_initrddir}/ovirt +%{_initrddir}/ovirt-post + %changelog -* Mon Sep 8 2008 Jim Meyering - 0.92 0.6 +* Mon Sep 8 2008 Jim Meyering - 0.92 0.7 - Update ovirt-identify-node's build rule. +* Thu Aug 28 2008 Chris Lalancette - 0.92 0.6 +- Rewrite the whole spec to make sub-packages for stateless vs. stateful + * Fri Aug 22 2008 Chris Lalancette - 0.92 0.5 - Add the ovirt-listen-awake daemon to the RPM diff --git a/scripts/ovirt-functions b/scripts/ovirt-functions index 083e13d..24a28df 100644 --- a/scripts/ovirt-functions +++ b/scripts/ovirt-functions @@ -5,6 +5,8 @@ OVIRT_LOGFILE=/var/log/ovirt.log # label of the oVirt partition OVIRT_LABEL=OVIRT +OVIRT_BACKUP_DIR=/var/lib/ovirt-backup + find_srv() { local dnsreply @@ -21,3 +23,26 @@ die() { echo "$@" 1>&2; failure; echo 1>&2; exit 1 } + +ovirt_setup_libvirtd() { + # just to get a boot warning to shut up + touch /etc/resolv.conf + + # make libvirtd listen on the external interfaces + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ + /etc/sysconfig/libvirtd + + # set up qemu daemon to allow outside VNC connections + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ + /etc/libvirt/qemu.conf + # set up libvirtd to listen on TCP (for kerberos) + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ + /etc/libvirt/libvirtd.conf + + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list + if [ `egrep -c "^mech_list: gssapi" /etc/sasl2/libvirt.conf` -eq 0 ]; then + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" /etc/sasl2/libvirt.conf + echo "mech_list: gssapi" >> /etc/sasl2/libvirt.conf + fi +} -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 00:21:04 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:21:04 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node] Allow the appliance to manage the hardware it is running on - part 3 In-Reply-To: <1220919664-21440-2-git-send-email-apevec@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919664-21440-1-git-send-email-apevec@redhat.com> <1220919664-21440-2-git-send-email-apevec@redhat.com> Message-ID: <1220919664-21440-3-git-send-email-apevec@redhat.com> From: Chris Lalancette Since we are currently hardcoding ovirtbr0 in taskomatic, we have to call the bridge on the host ovirtbr0 to allow guests to start. This limitation should go away fairly soon with Darryl's network discovery work, but we need it for now. Signed-off-by: Chris Lalancette --- ovirt-listen-awake/ovirt-convert-host | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ovirt-listen-awake/ovirt-convert-host b/ovirt-listen-awake/ovirt-convert-host index 0ef374d..aa9e282 100755 --- a/ovirt-listen-awake/ovirt-convert-host +++ b/ovirt-listen-awake/ovirt-convert-host @@ -45,7 +45,7 @@ backup_file /etc/sasl2/libvirt.conf ovirt_setup_libvirtd backup_file /etc/sysconfig/iptables -/usr/sbin/lokkit -n -t ovirtbr +/usr/sbin/lokkit -n -t ovirtbr0 echo "Setup complete. To make the changes take effect, shut down any running guests and reboot the host" -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 00:22:09 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:22:09 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node-image] fix ovirt-node-image.spec In-Reply-To: <1220601430-12218-1-git-send-email-clalance@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> Message-ID: <1220919730-21474-1-git-send-email-apevec@redhat.com> From: Chris Lalancette 1) Removed a redundant BuildRequires line. 2) More importantly, added a %post script for the pxe RPM to run cobbler sync iff cobbler exists. With this in place, running "rpm -Uvh" with a new ovirt-managed-node-pxe RPM will actually cause managed nodes to pick up the new image instead of the old one. Signed-off-by: Chris Lalancette --- ovirt-node-image.spec | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec index 9e47e54..ebe674d 100644 --- a/ovirt-node-image.spec +++ b/ovirt-node-image.spec @@ -28,7 +28,6 @@ At the moment, this RPM just packages prebuilt ISO. %package pxe Summary: oVirt Node boot PXE image Group: Applications/System -BuildRequires: livecd-tools >= 017 %description pxe The PXE boot image for oVirt Node network boot from oVirt Server. @@ -82,6 +81,9 @@ mkdir %{buildroot} %clean %{__rm} -rf %{buildroot} +%post pxe +[ -x /usr/bin/cobbler ] && /usr/bin/cobbler sync + %files %defattr(-,root,root,0644) %{app_root}/%{name}.iso -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 00:22:10 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:22:10 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node-image] Allow the appliance to manage the hardware it is running on In-Reply-To: <1220919730-21474-1-git-send-email-apevec@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919730-21474-1-git-send-email-apevec@redhat.com> Message-ID: <1220919730-21474-2-git-send-email-apevec@redhat.com> From: Chris Lalancette change common-pkgs to require ovirt-node-stateless Signed-off-by: Chris Lalancette --- common-pkgs.ks | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common-pkgs.ks b/common-pkgs.ks index 70707fc..e88d6d8 100644 --- a/common-pkgs.ks +++ b/common-pkgs.ks @@ -28,7 +28,7 @@ bind-utils syslinux cronie hal -ovirt-node +ovirt-node-stateless -policycoreutils -audit-libs-python -hdparm -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 00:22:59 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:22:59 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] Allow the appliance to manage the hardware it is running on - part 1 In-Reply-To: <1220601430-12218-1-git-send-email-clalance@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> Message-ID: <1220919781-21508-1-git-send-email-apevec@redhat.com> From: Chris Lalancette In the rc.local, attempt to contact the host we are running on. If we succeed, great, we can manage it with the rest of the nodes. If we fail, no big deal, it just won't be available. Note that we can't do this in the ovirt-wui-dev initscript because it happens too early in boot (we need at least host-browser up for this to have a chance of working). Signed-off-by: Chris Lalancette --- ovirt-appliance.ks | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/ovirt-appliance.ks b/ovirt-appliance.ks index 4c4c96e..faa0bd4 100644 --- a/ovirt-appliance.ks +++ b/ovirt-appliance.ks @@ -25,9 +25,22 @@ set /files/etc/sysconfig/network-scripts/ifcfg-eth1/DNS1 192.168.50.2 save EOF +# the code to contact the host we are running on and make it configure itself +# note that this has to be done in rc.local (as opposed to ovirt-wui-dev) +# because when ovirt-wui-dev starts, the host-browser is not yet running +cat >> /etc/rc.d/rc.local << \EOF +# Try to contact the host we are running on; if we succeed, we'll use it as +# one of the managed nodes; if not, no big deal +exec 3<> /dev/tcp/192.168.50.1/7777 +echo "AWAKE" 1>&3 +exec 3<> /dev/tcp/192.168.50.1/7777 +echo "IDENTIFY" 1>&3 +EOF + # make sure to update the /etc/hosts with the list of all possible DHCP # addresses we can hand out; dnsmasq uses this sed -i -e 's/management\.priv\.ovirt\.org//' /etc/hosts +echo "192.168.50.1 physical.priv.ovirt.org" >> /etc/hosts echo "192.168.50.2 management.priv.ovirt.org" >> /etc/hosts for i in `seq 3 252` ; do echo "192.168.50.$i node$i.priv.ovirt.org" >> /etc/hosts -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 00:23:00 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:23:00 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] Allow the appliance to manage the hardware it is running on - part 2 In-Reply-To: <1220919781-21508-1-git-send-email-apevec@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919781-21508-1-git-send-email-apevec@redhat.com> Message-ID: <1220919781-21508-2-git-send-email-apevec@redhat.com> From: Chris Lalancette Fix up the awk script to *exactly* match the bridge we are looking for. This is an issue if you happen to have multiple bridges up, like ovirtbr0, ovirtbr1 and now the script basically scribbles over them when looking for things. Signed-off-by: Chris Lalancette --- create-ovirt-appliance | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/create-ovirt-appliance b/create-ovirt-appliance index 035dce7..d3800e7 100755 --- a/create-ovirt-appliance +++ b/create-ovirt-appliance @@ -220,7 +220,7 @@ fi # Remove old bridge device if it exists sed -i "/# $BRIDGENAME/d" /etc/rc.d/rc.local old_bridge=$(brctl show \ - | awk -v BRIDGENAME=$BRIDGENAME '$1~BRIDGENAME {print $4}') + | awk -v BRIDGENAME=$BRIDGENAME '$1==BRIDGENAME {print $4}') if [ -n "$old_bridge" ]; then echo "Removing old bridge $old_bridge" ifconfig $old_bridge down -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 00:23:01 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 02:23:01 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] Allow the appliance to manage the hardware it is running on - part 3 In-Reply-To: <1220919781-21508-2-git-send-email-apevec@redhat.com> References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919781-21508-1-git-send-email-apevec@redhat.com> <1220919781-21508-2-git-send-email-apevec@redhat.com> Message-ID: <1220919781-21508-3-git-send-email-apevec@redhat.com> From: Chris Lalancette Since we are currently hardcoding ovirtbr0 in taskomatic, we have to call the bridge on the host ovirtbr0 to allow guests to start. This limitation should go away fairly soon with Darryl's network discovery work, but we need it for now. Signed-off-by: Chris Lalancette --- create-ovirt-appliance | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/create-ovirt-appliance b/create-ovirt-appliance index d3800e7..57883e0 100755 --- a/create-ovirt-appliance +++ b/create-ovirt-appliance @@ -10,7 +10,7 @@ RAM=768 IMGDIR_DEFAULT=/var/lib/libvirt/images NAME_DEFAULT=ovirt-appliance NET_SCRIPTS=/etc/sysconfig/network-scripts -BRIDGENAME=ovirtbr +BRIDGENAME=ovirtbr0 imgdir=$IMGDIR_DEFAULT name=$NAME_DEFAULT -- 1.5.5.1 From jim at meyering.net Tue Sep 9 06:55:58 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 09 Sep 2008 08:55:58 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node-image] fix ovirt-node-image.spec In-Reply-To: <1220919730-21474-1-git-send-email-apevec@redhat.com> (Alan Pevec's message of "Tue, 9 Sep 2008 02:22:09 +0200") References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919730-21474-1-git-send-email-apevec@redhat.com> Message-ID: <871vzt7qpt.fsf@rho.meyering.net> Alan Pevec wrote: > From: Chris Lalancette > > 1) Removed a redundant BuildRequires line. > 2) More importantly, added a %post script for the pxe RPM to run cobbler > sync iff cobbler exists. With this in place, running "rpm -Uvh" with a new > ovirt-managed-node-pxe RPM will actually cause managed nodes to pick up the > new image instead of the old one. > > Signed-off-by: Chris Lalancette > --- > ovirt-node-image.spec | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec > index 9e47e54..ebe674d 100644 > --- a/ovirt-node-image.spec > +++ b/ovirt-node-image.spec > @@ -28,7 +28,6 @@ At the moment, this RPM just packages prebuilt ISO. > %package pxe > Summary: oVirt Node boot PXE image > Group: Applications/System > -BuildRequires: livecd-tools >= 017 > > %description pxe > The PXE boot image for oVirt Node network boot from oVirt Server. > @@ -82,6 +81,9 @@ mkdir %{buildroot} > %clean > %{__rm} -rf %{buildroot} > > +%post pxe > +[ -x /usr/bin/cobbler ] && /usr/bin/cobbler sync Good idea! How about this (functionally equivalent code) instead? (cobbler --help) > /dev/null 2>&1 && cobbler sync It's good to avoid absolute names[*], and guaranteed to be ok in this case, since livecd-creator (also in /usr/bin) is used above with no dir prefix. Jim [*] What if cobbler moves to /bin or /usr/sbin some day? From jim at meyering.net Tue Sep 9 07:59:15 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 09 Sep 2008 09:59:15 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node] Allow the appliance to manage the hardware it is running on - part 1 In-Reply-To: <1220919664-21440-1-git-send-email-apevec@redhat.com> (Alan Pevec's message of "Tue, 9 Sep 2008 02:21:02 +0200") References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919664-21440-1-git-send-email-apevec@redhat.com> Message-ID: <87vdx5697w.fsf@rho.meyering.net> Alan Pevec wrote: > From: Chris Lalancette > > Add ovirt-listen-awake daemon. This is a very small daemon that oVirt > appliance can communicate with to send simple messages to the host it is > running on. It's used so that the appliance can "manage" the hardware > it is running on, removing the need for the fake oVirt Nodes. Hi Chris, I haven't built or tested, but did go through and write some suggestions: > diff --git a/ovirt-listen-awake/ovirt-listen-awake.c b/ovirt-listen-awake/ovirt-listen-awake.c > +// We only ever expect to receive the strings "AWAKE" or "IDENTIFY", so > +// 20 bytes is more than enough > +#define BUFLEN 20 > +#define LOGFILE "/var/log/ovirt-host.log" > + > +static int streq(char *first, char *second) > +{ > + int first_len, second_len; > + > + first_len = strlen(first); > + second_len = strlen(second); > + > + if (first_len == second_len && strncmp(first, second, first_len) == 0) > + return 1; > + return 0; > +} Just looking at the function name, I wondered if this was stripping trailing or leading spaces. In fact, it does neither. If you add a comment something like this, others won't wonder ;-) /* Truncate the NUL-terminated string, BUFFER, at the first white space byte. */ > +static void strip_space(char *buffer) > +{ > + int i; > + > + i = 0; > + while (buffer[i] != '\0') { > + if (isspace(buffer[i])) { > + // once we see the first whitespace character, we are done > + buffer[i] ='\0'; > + break; > + } > + i++; > + } > +} > + > +static int listenSocket(int listen_port) > +{ > + struct sockaddr_in a; > + int s,yes; > + > + if (listen_port < 0) { > + fprintf(stderr, "Invalid listen_port %d\n", listen_port); Please include "argv[0]: " at the beginning of each diagnostic. That is recommended practice, because it easier to figure out which program produces that error message buried in thousands of lines from many different programs. Easiest might be to do this (note no trailing "\n"): [first #include , of course] error(0, 0, "Invalid listen_port %d", listen_port); Don't worry about the portability of "error". If it becomes an issue, we can use gnulib. > + return -1; > + } > + > + s = socket(AF_INET, SOCK_STREAM, 0); > + if (s < 0) { > + fprintf(stderr, "Failed creating socket: %s\n", strerror(errno)); error(0, errno, "Failed creating socket"); > + return -1; > + } > + yes = 1; > + if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,(char *)&yes, sizeof (yes)) < 0) { > + fprintf(stderr, "Failed setsockopt: %s\n", strerror(errno)); error(0, errno, "Failed setsockopt"); > + close(s); > + return -1; > + } > + memset (&a, 0, sizeof (a)); > + a.sin_port = htons (listen_port); > + a.sin_family = AF_INET; > + if (bind(s, (struct sockaddr *) &a, sizeof (a)) < 0) { > + fprintf(stderr, "Error binding to port %d: %s\n", listen_port, > + strerror(errno)); Likewise. You can probably replace all fprintf(stderr,... uses. > + close(s); > + return -1; > + } > + listen(s, 10); Don't you want to diagnose listen failure? It looks like at least EADDRINUSE can occur. > + return s; > +} > + > +static void usage(void) > +{ > + printf("Usage: host-startup [OPTIONS]\n"); host-startup? must be an old name. I like to set a global "program_name = argv[0];" in main, then use that from the usage function. > + printf("OPTIONS:\n"); > + printf(" -h\tShow this help message\n"); > + printf(" -n\tDo not daemonize (useful for debugging\n"); Sometimes it's important not to exit(1), e.g. for --help, so either move the "exit" out to each caller or make the exit status a parameter. > + exit(1); > +} > + > +int main(int argc, char *argv[]) > +{ > + int listen_socket, conn; > + struct sockaddr_in client_address; > + unsigned int addrlen; > + FILE *conn_stream; > + FILE *logfile; > + char buffer[BUFLEN]; > + int c; > + int do_daemon; > + > + do_daemon = 1; > + > + while ((c=getopt(argc, argv, ":hn")) != -1) { > + switch(c) { > + case 'h': > + usage(); > + break; > + case 'n': > + do_daemon = 0; > + break; > + default: > + usage(); > + } > + } > + > + if ((argc-optind) != 0) > + usage(); I know this is just a tiny helper program, but it's nice to diagnose this with e.g., ovirt-listen-awake: extra operand "FOO" rather than just printing help output. E.g., $ who am i j who: extra operand `j' Try `who --help' for more information. [Exit 1] > + listen_socket = listenSocket(7777); > + if (listen_socket < 0) > + return 2; > + > + if (do_daemon) { > + logfile = fopen(LOGFILE,"a+"); > + if (logfile == NULL) { > + fprintf(stderr, "Error opening logfile %s: %s\n", > + LOGFILE, strerror(errno)); > + return 3; > + } > + > + // NOTE: this closes stdout and stderr > + daemon(0, 0); Upon failure (i.e., to fork), diagnose and exit: if (daemon(0, 0) < 0) error(EXIT_FAILURE, errno, "Failed do daemonize"); > + // so re-open them to the logfile here > + dup2(fileno(logfile), STDOUT_FILENO); > + dup2(fileno(logfile), STDERR_FILENO); > + } > + > + while (1) { > + addrlen = sizeof(client_address); > + memset(&client_address, 0, addrlen); > + memset(buffer, 0, BUFLEN); This memset looks unnecessary. > + conn = accept(listen_socket, (struct sockaddr *)&client_address, &addrlen); > + if (conn < 0) { > + fprintf(stderr, "Error accepting socket: %s\n", strerror(errno)); > + continue; > + } > + > + conn_stream = fdopen(conn, "r"); > + if (conn_stream == NULL) { > + fprintf(stderr, "Error converting fd to stream: %s\n", strerror(errno)); > + close(conn); > + continue; > + } > + > + if (fgets(buffer, BUFLEN, conn_stream) == NULL) { You may want a separate test to detect EOF. Otherwise, errno is not defined in that case. > + fprintf(stderr, "Error receiving data: %s\n", strerror(errno)); > + fclose(conn_stream); > + continue; > + } > + > + strip_space(buffer); > + > + if (streq(buffer, "IDENTIFY")) { > + // run ovirt-identify-node against 192.168.50.2 (the WUI node) > + fprintf(stderr, "Doing identify\n"); > + // FIXME: it would be best to call the "find_srv" shell script here to > + // find out where we should contact. However, we would still have to > + // hardcode which DNS server to use (192.168.50.2), and which domain > + // name to use "priv.ovirt.org" to get this to work. I don't have > + // a good idea how to solve this at the moment. > + system("ovirt-identify-node -s 192.168.50.2 -p 12120"); > + } > + else if (streq(buffer, "AWAKE")) { > + // run ovirt-awake against 192.168.50.2 > + fprintf(stderr, "Doing awake\n"); > + // FIXME: I hate to duplicate this stuff here, but I can't use the > + // ovirt init scripts as-is; they depend too much on the environment > + // (in particular, which DNS server to use to resolve, and which > + // domainname). Until I come up with a good solution for that, I'll > + // have to leave this as-is. > + system("wget -q http://192.168.50.2:80/ipa/config/krb5.ini -O /etc/krb5.conf"); > + system("ovirt-awake start 192.168.50.2 12120 /etc/libvirt/krb5.tab"); > + } > + else { > + fprintf(stderr, "Unknown command %s\n", buffer); > + } > + > + fclose(conn_stream); > + } > + > + close(listen_socket); > + fclose(logfile); Might be nice to exit nonzero upon fclose failure (i.e., write failure). > + return 0; > +} From neil at brightbox.co.uk Tue Sep 9 07:59:11 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 9 Sep 2008 08:59:11 +0100 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C57FAC.2030909@redhat.com> References: <48C57FAC.2030909@redhat.com> Message-ID: <50d9f33a0809090059ue2cb030l2e08f894a55494ac@mail.gmail.com> 2008/9/8 Perry N. Myers : > To do a build (similar to build-all.sh in previous releases) do: > $ make -f /usr/share/ovirt-release/ovirt.mk build > My base install Fedora server complains about the lack of rpmbuild with this command. Is there a missing dependency on the devtools? -- Neil Wilson From neil at brightbox.co.uk Tue Sep 9 08:06:46 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 9 Sep 2008 09:06:46 +0100 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C57FAC.2030909@redhat.com> References: <48C57FAC.2030909@redhat.com> Message-ID: <50d9f33a0809090106m1811cdb6i18d2b70a11ad3cf3@mail.gmail.com> 2008/9/8 Perry N. Myers : > To do a build (similar to build-all.sh in previous releases) do: > $ make -f /usr/share/ovirt-release/ovirt.mk build Doesn't seem to run the autogen in the node branch, so no Makefile. make[1]: Leaving directory `/root/ovirt/server' make[1]: Entering directory `/root/ovirt/node' make[1]: *** No rule to make target `publish'. Stop. make[1]: Leaving directory `/root/ovirt/node' make: *** [publish] Error 1 -- Neil Wilson From neil at brightbox.co.uk Tue Sep 9 08:27:35 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 9 Sep 2008 09:27:35 +0100 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <50d9f33a0809090059ue2cb030l2e08f894a55494ac@mail.gmail.com> References: <48C57FAC.2030909@redhat.com> <50d9f33a0809090059ue2cb030l2e08f894a55494ac@mail.gmail.com> Message-ID: <50d9f33a0809090127t493e18aeg63b374bdc5f34f52@mail.gmail.com> 2008/9/9 Neil Wilson : > 2008/9/8 Perry N. Myers : >> To do a build (similar to build-all.sh in previous releases) do: >> $ make -f /usr/share/ovirt-release/ovirt.mk build >> > > My base install Fedora server complains about the lack of rpmbuild > with this command. Is there a missing dependency on the devtools? Similarly with libtool, automake and autoconf for the autogen.sh After that configure falls over with a pkg-config check error on libvirt. There doesn't appear to be a libvirt.pc file anywhere. (I have 0.4.4-2ovirt2 installed according to yum). I'll leave it there for now. -- Neil Wilson From berrange at redhat.com Tue Sep 9 08:41:44 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 9 Sep 2008 09:41:44 +0100 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <50d9f33a0809090127t493e18aeg63b374bdc5f34f52@mail.gmail.com> References: <48C57FAC.2030909@redhat.com> <50d9f33a0809090059ue2cb030l2e08f894a55494ac@mail.gmail.com> <50d9f33a0809090127t493e18aeg63b374bdc5f34f52@mail.gmail.com> Message-ID: <20080909084144.GA18300@redhat.com> On Tue, Sep 09, 2008 at 09:27:35AM +0100, Neil Wilson wrote: > 2008/9/9 Neil Wilson : > > 2008/9/8 Perry N. Myers : > >> To do a build (similar to build-all.sh in previous releases) do: > >> $ make -f /usr/share/ovirt-release/ovirt.mk build > >> > > > > My base install Fedora server complains about the lack of rpmbuild > > with this command. Is there a missing dependency on the devtools? > > Similarly with libtool, automake and autoconf for the autogen.sh > > After that configure falls over with a pkg-config check error on > libvirt. There doesn't appear to be a libvirt.pc file anywhere. (I > have 0.4.4-2ovirt2 installed according to yum). You are missing the entire development toolchain by the sounds of it. Based of your messages here you neeed to install at least libtool automake autoconf rpm-build libvirt-devel Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From neil at brightbox.co.uk Tue Sep 9 08:53:11 2008 From: neil at brightbox.co.uk (Neil Wilson) Date: Tue, 9 Sep 2008 09:53:11 +0100 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <20080909084144.GA18300@redhat.com> References: <48C57FAC.2030909@redhat.com> <50d9f33a0809090059ue2cb030l2e08f894a55494ac@mail.gmail.com> <50d9f33a0809090127t493e18aeg63b374bdc5f34f52@mail.gmail.com> <20080909084144.GA18300@redhat.com> Message-ID: <50d9f33a0809090153n796fd990q6d60bfac2a42c0fb@mail.gmail.com> 2008/9/9 Daniel P. Berrange : > You are missing the entire development toolchain by the sounds of it. Based > of your messages here you neeed to install at least > > libtool automake autoconf rpm-build libvirt-devel > No doubt. In which case do the dependencies in the documentation need changing where somebody is going to build the system? Or did I just miss them completely? -- Neil Wilson From jim at meyering.net Tue Sep 9 09:50:16 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 09 Sep 2008 11:50:16 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node] Allow the appliance to manage the hardware it is running on - part 2 In-Reply-To: <1220919664-21440-2-git-send-email-apevec@redhat.com> (Alan Pevec's message of "Tue, 9 Sep 2008 02:21:03 +0200") References: <1220601430-12218-1-git-send-email-clalance@redhat.com> <1220919664-21440-1-git-send-email-apevec@redhat.com> <1220919664-21440-2-git-send-email-apevec@redhat.com> Message-ID: <87k5dl642v.fsf@rho.meyering.net> > From: Chris Lalancette > > A rather large re-write of the ovirt-node.spec file. The reason > for this is so that we can introduce the concept of the "stateful" oVirt > node; that is, one which is already installed and running with an OS. > To accomplish this, we add two subpackages: ovirt-node-stateless, > and ovirt-node-stateful. They both depend on ovirt-node, > which holds most of the necessary binaries. The two subpackages have > subtly different %post scripts, since you don't necessarily want to do all > of the stuff from stateless on a stateful box. There is also a minor change > to common-pkgs to require ovirt-node-stateless, the addition of > an init script for ovirt-node-stateful, and the addition of two > helper scripts for the stateful case to let you turn your machine into > an oVirt node. ... Substance looks fine, so... > diff --git a/ovirt-listen-awake/ovirt-convert-host b/ovirt-listen-awake/ovirt-convert-host > new file mode 100755 > index 0000000..0ef374d > --- /dev/null > +++ b/ovirt-listen-awake/ovirt-convert-host > @@ -0,0 +1,51 @@ > +#!/bin/bash > + What do you think about sourcing /etc/init.d/functions here? Then you could remove all the /sbin/ and /usr/sbin/ prefixes below and invoke e.g., "chkconfig" rather than "/sbin/chkconfig". > +. /etc/init.d/ovirt-functions > + > +if [ $# -ne 0 ]; then > + echo "Usage: ovirt-convert-host" > + exit 1 > +fi > + > +backup_file() { > + dir=$(dirname $1) > + mkdir -p $OVIRT_BACKUP_DIR/${dir:1} > + cp -pf $1 $OVIRT_BACKUP_DIR/${dir:1} How about this? (removing the :1, which I had to look up, and adding double quotes, just in case. No use of backup_file requires double quotes around $1, but better to add them now, in case the function is used differently later. dir=$(dirname "$1") mkdir -p "$OVIRT_BACKUP_DIR$dir" cp -pf "$1" "$OVIRT_BACKUP_DIR$dir" $dir always starts with "/", but it would be prudent to insert the equivalent of assert(dir[0] == '/'); before the mkdir, i.e., case $dir in /*);; *) die "unexpected non-absolute dir: $dir";; esac ... > +backup_file /etc/hosts > +if [ $( grep -c "physical.priv.ovirt.org" /etc/hosts ) -eq 0 ]; then > + echo "192.168.50.1 physical.priv.ovirt.org" >> /etc/hosts > +fi If you tighten up this regexp, it won't match commented-out or slightly different lines. You can also remove the use of "test" (aka '['): grep -qE '^[0-9.]+[[:space:]]+physical\.priv\.ovirt\.org' /etc/hosts \ || echo "192.168.50.1 physical.priv.ovirt.org" >> /etc/hosts Hmm... I guess officially the regexp should start with ^[[:space:]]*. And I prefer to use single quotes so I don't have to worry about embedded backslashes or '$' signs. Even in the following 'echo', using single quotes is nicer, since then you know right away that the string won't be shell-interpolated. grep -qE \ '^[[:space:]]*[0-9.]+[[:space:]]+physical\.priv\.ovirt\.org' /etc/hosts \ || echo '192.168.50.1 physical.priv.ovirt.org' >> /etc/hosts Rats, it's going to wrap. to avoid matching the bogus 192.168.50.1 physical.priv.ovirt.organophosphate.com you'd add a little more. And with all this added obfuscation (this is where I miss the likes of \d \S and \s), it'd be good to add a comment: # Add an IP->hostname entry for "physical" if it's not already there. grep -qE \ '^[[:space:]]*[0-9.]+[[:space:]]+physical\.priv\.ovirt\.org($|#|[[:space:]])'\ /etc/hosts \ || echo '192.168.50.1 physical.priv.ovirt.org' >> /etc/hosts Man, that horse is dead. I hope. > +if [ $( grep -c "management.priv.ovirt.org" /etc/hosts ) -eq 0 ]; then > + echo "192.168.50.2 management.priv.ovirt.org" >> /etc/hosts > +fi Same here. > +/sbin/chkconfig ovirt-listen-awake on > +/sbin/chkconfig collectd on > + > +backup_file /etc/sysconfig/libvirtd > +backup_file /etc/libvirt/qemu.conf > +backup_file /etc/libvirt/libvirtd.conf > +backup_file /etc/sasl2/libvirt.conf > +ovirt_setup_libvirtd > + > +backup_file /etc/sysconfig/iptables > +/usr/sbin/lokkit -n -t ovirtbr > + > +echo "Setup complete. To make the changes take effect, shut down any running > +guests and reboot the host" > diff --git a/ovirt-listen-awake/ovirt-unconvert-host b/ovirt-listen-awake/ovirt-unconvert-host > new file mode 100755 > index 0000000..cfaa51d > --- /dev/null > +++ b/ovirt-listen-awake/ovirt-unconvert-host > @@ -0,0 +1,30 @@ > +#!/bin/bash > + > +. /etc/init.d/ovirt-functions > + > +if [ $# -ne 0 ]; then > + echo "Usage: ovirt-unconvert-host" > + exit 1 > +fi > + > +if [ ! -d $OVIRT_BACKUP_DIR ]; then > + echo "The oVirt backup directory $OVIRT_BACKUP_DIR doesn't exist; can't" > + echo "unconvert the host" > + exit 2 > +fi > + > +unbackup_file() { > + # note that $1 will have a / on the front, so we don't need to add our own > + cp -pf $OVIRT_BACKUP_DIR$1 $1 Who knows what $OVIRT_BACKUP_DIR might contain ;-) cp -pf "$OVIRT_BACKUP_DIR$1" "$1" ... > diff --git a/ovirt-node.spec b/ovirt-node.spec ... > +%post stateless > /sbin/chkconfig --add ovirt-early > /sbin/chkconfig ovirt-early on > /sbin/chkconfig --add ovirt > /sbin/chkconfig ovirt on > /sbin/chkconfig --add ovirt-post > /sbin/chkconfig ovirt-post on ... > +. /etc/init.d/ovirt-functions ; ovirt_setup_libvirtd Using two separate lines would be more readable. Otherwise, it's easy to miss the latter stmt. ... > diff --git a/scripts/ovirt-functions b/scripts/ovirt-functions > index 083e13d..24a28df 100644 > --- a/scripts/ovirt-functions > +++ b/scripts/ovirt-functions > @@ -5,6 +5,8 @@ OVIRT_LOGFILE=/var/log/ovirt.log > # label of the oVirt partition > OVIRT_LABEL=OVIRT > > +OVIRT_BACKUP_DIR=/var/lib/ovirt-backup > + > find_srv() > { > local dnsreply > @@ -21,3 +23,26 @@ die() > { > echo "$@" 1>&2; failure; echo 1>&2; exit 1 > } > + > +ovirt_setup_libvirtd() { > + # just to get a boot warning to shut up > + touch /etc/resolv.conf > + > + # make libvirtd listen on the external interfaces > + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ > + /etc/sysconfig/libvirtd > + > + # set up qemu daemon to allow outside VNC connections > + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ > + /etc/libvirt/qemu.conf > + # set up libvirtd to listen on TCP (for kerberos) > + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ > + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ > + /etc/libvirt/libvirtd.conf > + > + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list > + if [ `egrep -c "^mech_list: gssapi" /etc/sasl2/libvirt.conf` -eq 0 ]; then > + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" /etc/sasl2/libvirt.conf > + echo "mech_list: gssapi" >> /etc/sasl2/libvirt.conf > + fi > +} This is probably just moved code, but you can avoid a "test" and a `` subshell. Plus, it's better not to use "egrep". grep -E is more standard and portable. If you don't like the -q option (some non-POSIX systems lack it), and the output would be a problem, just redirect stdout to /dev/null. Finally, with three uses of "/etc/sasl2/libvirt.conf", it's worthwhile to factor it out: sasl_libvirt_conf=/etc/sasl2/libvirt.conf if ! grep -qE '^mech_list: gssapi' $sasl_libvirt_conf; then sed -i 's/^\([[:space:]]*mech_list.*\)/#\1/' $sasl_libvirt_conf echo 'mech_list: gssapi' >> $sasl_libvirt_conf fi From apevec at redhat.com Tue Sep 9 09:52:31 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 09 Sep 2008 11:52:31 +0200 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <50d9f33a0809090153n796fd990q6d60bfac2a42c0fb@mail.gmail.com> References: <48C57FAC.2030909@redhat.com> <50d9f33a0809090059ue2cb030l2e08f894a55494ac@mail.gmail.com> <50d9f33a0809090127t493e18aeg63b374bdc5f34f52@mail.gmail.com> <20080909084144.GA18300@redhat.com> <50d9f33a0809090153n796fd990q6d60bfac2a42c0fb@mail.gmail.com> Message-ID: <48C6475F.7050203@redhat.com> Neil Wilson wrote: > 2008/9/9 Daniel P. Berrange : >> You are missing the entire development toolchain by the sounds of it. Based >> of your messages here you neeed to install at least >> >> libtool automake autoconf rpm-build libvirt-devel >> > > No doubt. > > In which case do the dependencies in the documentation need changing > where somebody is going to build the system? Or did I just miss them > completely? Docs on ovirt.org are for the last release, i.e. old single ovirt.git repo. We'll add to the site 'devel' docs, updated to reflect the new repo layout. Re missing BRs: I guess we could add ovirt-devel RPM containing ovirt.mk and all build requirements as its deps. From apevec at redhat.com Tue Sep 9 10:38:28 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 09 Sep 2008 12:38:28 +0200 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <50d9f33a0809090106m1811cdb6i18d2b70a11ad3cf3@mail.gmail.com> References: <48C57FAC.2030909@redhat.com> <50d9f33a0809090106m1811cdb6i18d2b70a11ad3cf3@mail.gmail.com> Message-ID: <48C65224.8050707@redhat.com> Neil Wilson wrote: > 2008/9/8 Perry N. Myers : >> To do a build (similar to build-all.sh in previous releases) do: >> $ make -f /usr/share/ovirt-release/ovirt.mk build > > Doesn't seem to run the autogen in the node branch, so no Makefile. > > make[1]: Leaving directory `/root/ovirt/server' > make[1]: Entering directory `/root/ovirt/node' > make[1]: *** No rule to make target `publish'. Stop. > make[1]: Leaving directory `/root/ovirt/node' > make: *** [publish] Error 1 rpm -Uvh http://ovirt.org/repos/ovirt/9/ovirt-release-0.92-2.fc9.noarch.rpm I've just updated ovirt-release RPM on ovirt.org to include http://git.et.redhat.com/?p=ovirt-release.git;a=commit;h=796ec90ac69a6c65cfdf65c74d1087987e0062ff "add "diff"; work with autoconfiscated subdirs" From jim at meyering.net Tue Sep 9 10:39:27 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 09 Sep 2008 12:39:27 +0200 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <50d9f33a0809090106m1811cdb6i18d2b70a11ad3cf3@mail.gmail.com> (Neil Wilson's message of "Tue, 9 Sep 2008 09:06:46 +0100") References: <48C57FAC.2030909@redhat.com> <50d9f33a0809090106m1811cdb6i18d2b70a11ad3cf3@mail.gmail.com> Message-ID: <87ej3t61sw.fsf@rho.meyering.net> "Neil Wilson" wrote: > 2008/9/8 Perry N. Myers : >> To do a build (similar to build-all.sh in previous releases) do: >> $ make -f /usr/share/ovirt-release/ovirt.mk build > > Doesn't seem to run the autogen in the node branch, so no Makefile. > > make[1]: Leaving directory `/root/ovirt/server' > make[1]: Entering directory `/root/ovirt/node' > make[1]: *** No rule to make target `publish'. Stop. > make[1]: Leaving directory `/root/ovirt/node' > make: *** [publish] Error 1 Sounds like you need to update the release/ subdir ("next" branch), which will pull in a modified ovirt.mk file. Then the top level build command _will_ run autogen.sh in node/. From apevec at redhat.com Tue Sep 9 11:42:23 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 13:42:23 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] add %{ovirt_local_repo} rpm macro Message-ID: <1220960543-20157-1-git-send-email-apevec@redhat.com> so that autobuild can override it default is file://%{ovirt_cache_dir}/ovirt Signed-off-by: Alan Pevec --- ovirt-appliance.spec | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index bbc0e77..feec956 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -1,4 +1,5 @@ %{!?ovirt_cache_dir: %define ovirt_cache_dir /var/tmp/ovirt-cache} +%{!?ovirt_local_repo: %define ovirt_local_repo file://%{ovirt_cache_dir}/ovirt} %{!?ovirt_url: %define ovirt_url http://ovirt.org/repos/ovirt} %if %{fedora_url} %define fedora_tree_url %{fedora_url}/releases/%{fedora}/Fedora/%{_arch}/os @@ -47,7 +48,7 @@ fi cat >> repos.ks << EOF repo --name=ovirt-org --baseurl=%{ovirt_url}/%{fedora}/%{_arch} -repo --name=ovirt-cache --baseurl=file://%{ovirt_cache_dir}/ovirt +repo --name=ovirt-local --baseurl=%{ovirt_local_repo} EOF mkdir -p %{ovirt_cache_dir}/appliance-tmp/tree -- 1.5.5.1 From apevec at redhat.com Tue Sep 9 11:42:58 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 9 Sep 2008 13:42:58 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node-image] add %{ovirt_local_repo} rpm macro Message-ID: <1220960578-20211-1-git-send-email-apevec@redhat.com> so that autobuild can override it default is file://%{ovirt_cache_dir}/ovirt Signed-off-by: Alan Pevec --- ovirt-node-image.spec | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec index ebe674d..5885fd9 100644 --- a/ovirt-node-image.spec +++ b/ovirt-node-image.spec @@ -1,4 +1,5 @@ %{!?ovirt_cache_dir: %define ovirt_cache_dir /var/tmp/ovirt-cache} +%{!?ovirt_local_repo: %define ovirt_local_repo file://%{ovirt_cache_dir}/ovirt} %{!?ovirt_url: %define ovirt_url http://ovirt.org/repos/ovirt} %define fedora_mirror http://mirrors.fedoraproject.org/mirrorlist @@ -50,7 +51,7 @@ fi cat >> repos.ks << EOF repo --name=ovirt-org --baseurl=%{ovirt_url}/%{fedora}/%{_arch} -repo --name=ovirt-cache --baseurl=file://%{ovirt_cache_dir}/ovirt +repo --name=ovirt-local --baseurl=%{ovirt_local_repo} EOF mkdir -p %{ovirt_cache_dir}/node-image-tmp -- 1.5.5.1 From bguthro at virtualiron.com Tue Sep 9 12:42:13 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Tue, 09 Sep 2008 08:42:13 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C57FAC.2030909@redhat.com> References: <48C57FAC.2030909@redhat.com> Message-ID: <48C66F25.3020000@virtualiron.com> I'm having some issues building after the refactoring, and I was hoping someone might be able to point me in the right direction... I am only interested in building the managed node pxe images, at this point. As I understand this restructuring, this means I need the following repos to build: ovirt-release ovirt-node ovirt-node-image I should be able to do without the other subcomponents that I am not interested in, correct? To build I execute make overriding the following environment variables: FEDORA_URL Use a local yum mirror OVIRT_CACHE_DIR Override location to make this behave as before, and put it in a local dir to the build area SUBDIRS="node node-image" Only build what I care about. OVIRT_BRANCH build on the "next" branch However, it would seem that something in the automake magic is picking up the SUBDIRS override, because it seems to be using it incorrectly when it tries to make the "node" dir. (see make output below) Am I doing something wrong here? Is this a supported operation? [bguthro at bguthro ovirt]$ ls node node-image release [bguthro at bguthro ovirt]$ make FEDORA_URL=http://install/fedora/yum OVIRT_CACHE_DIR=/home/bguthro/dev/trivo/ovirt/ovirt-cache SUBDIRS="node node-image" -f release/ovirt.mk build for dir in node node-image; do \ if ! test -d $dir ; then \ make $dir || exit 1 ; \ fi ; \ ( cd $dir; test ! -f Makefile.in && ./autogen.sh ); \ ( cd $dir; test ! -f Makefile && ./configure ); \ make -C $dir publish || exit 1 ; \ done I am going to run ./configure with no arguments - if you wish to pass any to it, please specify them on the ./autogen.sh command line. configure.ac:3: installing `./install-sh' configure.ac:3: installing `./missing' ovirt-identify-node/Makefile.am: installing `./depcomp' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for DBUS... yes checking for HAL... yes checking for VIRT... yes configure: creating ./config.status config.status: creating Makefile config.status: creating ovirt-identify-node/Makefile config.status: creating config.h config.status: executing depfiles commands make[1]: Entering directory `/home/bguthro/dev/trivo/ovirt/node' { test ! -d ovirt-node-0.92 || { find ovirt-node-0.92 -type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr ovirt-node-0.92; }; } test -d ovirt-node-0.92 || mkdir ovirt-node-0.92 list='node node-image'; for subdir in $list; do \ if test "$subdir" = .; then :; else \ test -d "ovirt-node-0.92/$subdir" \ || /bin/mkdir -p "ovirt-node-0.92/$subdir" \ || exit 1; \ distdir=`CDPATH="${ZSH_VERSION+.}:" && cd ovirt-node-0.92 && pwd`; \ top_distdir=`CDPATH="${ZSH_VERSION+.}:" && cd ovirt-node-0.92 && pwd`; \ (cd $subdir && \ make \ top_distdir="$top_distdir" \ distdir="$distdir/$subdir" \ am__remove_distdir=: \ am__skip_length_check=: \ distdir) \ || exit 1; \ fi; \ done /bin/sh: line 7: cd: node: No such file or directory make[1]: *** [distdir] Error 1 make[1]: Leaving directory `/home/bguthro/dev/trivo/ovirt/node' make: *** [publish] Error 1 Perry N. Myers wrote on 09/08/2008 03:40 PM: > oVirt is composed of several components that have well defined interfaces > and are able to be used in isolation from each other. Our code > repository > did not reflect this since it was a single monolithic repository for all > of oVirt. > > We've refactored the repositories into the following: > > ovirt-server : RPMs that provide oVirt Server Suite functionality > ovirt-node : RPMs that provide oVirt node functionality > ovirt-node-image: RPM that contains LiveCD ISO image and PXE images of > the oVirt Node which uses the ovirt-node RPM > ovirt-appliance : RPM that contains a Fedora appliance OS with > ovirt-server and ovirt-node-image RPMs installed and > configured > ovirt-release : RPM that contains yum repo configuration file for > ovirt.org repositories and developer convenience > scripts > ovirt-docs : RPMs that contain documentation for the oVirt project > > The build-all.sh script that was used to build all of the sub-projects of > oVirt has been replaced with a top level makefile (ovirt.mk) from the > ovirt-release repository and RPM. > > The old ovirt repo will continue to be hosted on git.et.redhat.org > indefinitely, since it corresponds to version 0.92-1 and below of oVirt. > The next release of oVirt will use the new refactored repositories. > > In addition to the repo refactoring and change from build-all.sh to > ovirt.mk, we've also tried to reduce the dependency on root access for > building. The only sections of the build that still require root are the > RPM builds of ovirt-appliance and ovirt-node-image, as these RPMs use > livecd-creator which requires root. > > Because of this, the user running the ovirt.mk makefile should have > passwordless sudo as root access. Sudo is used inside of the appliance > and node-image spec files to allow livecd-creator to work properly. > > Developers wishing to take a look at what is currently in development for > the next release can do the following on a Fedora 9 host. > > Install the latest ovirt-release RPM from ovirt.org: > > $ sudo rpm -ivh > http://ovirt.org/repos/ovirt/9/ovirt-release-0.92-1.fc9.noarch.rpm > > This will add: > /etc/yum.repos.d/ovirt.repo - Used for yum update/install of oVirt RPMs > /usr/share/ovirt-release/ovirt.mk - Developer Makefile > > To get the rest of the repositories do the following: > $ mkdir ~/ovirt > $ cd ~/ovirt\ > $ export OVIRT_BRANCH=next > $ make -f /usr/share/ovirt-release/ovirt.mk update > > Replace ~/ovirt with any directory you would like (this is just an > example) This will check out all 6 repos from the ovirt.org site. > > OVIRT_BRANCH is set to next to indicate that you want to work on the next > branch instead of master in the git repos. > > To do a build (similar to build-all.sh in previous releases) do: > $ make -f /usr/share/ovirt-release/ovirt.mk build > > This will build all of the RPMs and make the oVirt Node and Appliance. > After that you can run: > > $ sudo create-ovirt-appliance > > to create the Appliance on your host. create-ovirt-appliance replaces > create-wui-appliance and has the same command line parameters. So to > bridge your appliance to eth1, you would use: > > $ sudo create-ovirt-appliance -e eth1 > > Give the new repositories and developer scripts a try and please report > any problems encountered. > > Thanks, > > oVirt Development Team > From pmyers at redhat.com Tue Sep 9 12:55:45 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 09 Sep 2008 08:55:45 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <50d9f33a0809090057i158702cbi6e42710b578337c1@mail.gmail.com> References: <48C57FAC.2030909@redhat.com> <50d9f33a0809090057i158702cbi6e42710b578337c1@mail.gmail.com> Message-ID: <48C67251.5010804@redhat.com> Neil Wilson wrote: > 2008/9/8 Perry N. Myers : >> To do a build (similar to build-all.sh in previous releases) do: >> $ make -f /usr/share/ovirt-release/ovirt.mk build >> > > My base install Fedora server complains about the lack of rpmbuild > with this command. Is there a missing dependency on the devtools? > Neil, Sending to ovirt-devel, in case other people have the same question... From: http://ovirt.org/install-instructions.html Building the appliance from source 2. There are a handful of packages required to build the appliance. Some of these RPMs are located in the oVirt repository so make sure to follow the instructions above on installing the ovirt-release RPM first. Install them with: # yum install ruby ruby-devel ruby-gettext-package rubygem-rake avahi-devel rpm-build libvirt-devel hal-devel dbus-devel createrepo appliance-tools gcc Switching to ovirt.mk from build-all.sh didn't remove the requirement to have all of the above packages installed for the build. Most of these dependencies are encoded as BuildRequires in the RPM spec files, however rpmbuild itself can't be a BuildRequire in a spec file. Thanks, Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From bguthro at virtualiron.com Tue Sep 9 13:22:11 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Tue, 09 Sep 2008 09:22:11 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C66F25.3020000@virtualiron.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> Message-ID: <48C67883.4020507@virtualiron.com> please disregard (operator error) I was specifying the environment variables incorrectly on the build line. apologies for the noise. Ben Guthro wrote on 09/09/2008 08:42 AM: > I'm having some issues building after the refactoring, and I was > hoping someone might be able to point me in the right direction... > > I am only interested in building the managed node pxe images, at this > point. > As I understand this restructuring, this means I need the following > repos to build: > ovirt-release > ovirt-node > ovirt-node-image > > I should be able to do without the other subcomponents that I am not > interested in, correct? > > To build I execute make overriding the following environment variables: > FEDORA_URL Use a local yum mirror > OVIRT_CACHE_DIR Override location to make this behave as > before, and put it in a > local dir to the build area > SUBDIRS="node node-image" Only build what I care about. > OVIRT_BRANCH build on the "next" branch > > However, it would seem that something in the automake magic is picking > up the SUBDIRS override, because it seems to be using it incorrectly > when it tries to make the "node" dir. (see make output below) > > Am I doing something wrong here? Is this a supported operation? > > > > > > [bguthro at bguthro ovirt]$ ls > node node-image release > [bguthro at bguthro ovirt]$ make FEDORA_URL=http://install/fedora/yum > OVIRT_CACHE_DIR=/home/bguthro/dev/trivo/ovirt/ovirt-cache > SUBDIRS="node node-image" -f release/ovirt.mk build > for dir in node node-image; do \ > if ! test -d $dir ; then \ > make $dir || exit 1 ; \ > fi ; \ > ( cd $dir; test ! -f Makefile.in && ./autogen.sh ); \ > ( cd $dir; test ! -f Makefile && ./configure ); \ > make -C $dir publish || exit 1 ; \ > done > I am going to run ./configure with no arguments - if you wish > to pass any to it, please specify them on the ./autogen.sh command line. > configure.ac:3: installing `./install-sh' > configure.ac:3: installing `./missing' > ovirt-identify-node/Makefile.am: installing `./depcomp' > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of gcc... gcc3 > checking for pkg-config... /usr/bin/pkg-config > checking pkg-config is at least version 0.9.0... yes > checking for DBUS... yes > checking for HAL... yes > checking for VIRT... yes > configure: creating ./config.status > config.status: creating Makefile > config.status: creating ovirt-identify-node/Makefile > config.status: creating config.h > config.status: executing depfiles commands > make[1]: Entering directory `/home/bguthro/dev/trivo/ovirt/node' > { test ! -d ovirt-node-0.92 || { find ovirt-node-0.92 -type d ! -perm > -200 -exec chmod u+w {} ';' && rm -fr ovirt-node-0.92; }; } > test -d ovirt-node-0.92 || mkdir ovirt-node-0.92 > list='node node-image'; for subdir in $list; do \ > if test "$subdir" = .; then :; else \ > test -d "ovirt-node-0.92/$subdir" \ > || /bin/mkdir -p "ovirt-node-0.92/$subdir" \ > || exit 1; \ > distdir=`CDPATH="${ZSH_VERSION+.}:" && cd ovirt-node-0.92 > && pwd`; \ > top_distdir=`CDPATH="${ZSH_VERSION+.}:" && cd > ovirt-node-0.92 && pwd`; \ > (cd $subdir && \ > make \ > top_distdir="$top_distdir" \ > distdir="$distdir/$subdir" \ > am__remove_distdir=: \ > am__skip_length_check=: \ > distdir) \ > || exit 1; \ > fi; \ > done > /bin/sh: line 7: cd: node: No such file or directory > make[1]: *** [distdir] Error 1 > make[1]: Leaving directory `/home/bguthro/dev/trivo/ovirt/node' > make: *** [publish] Error 1 > > > > > Perry N. Myers wrote on 09/08/2008 03:40 PM: >> oVirt is composed of several components that have well defined >> interfaces >> and are able to be used in isolation from each other. Our code >> repository >> did not reflect this since it was a single monolithic repository for all >> of oVirt. >> >> We've refactored the repositories into the following: >> >> ovirt-server : RPMs that provide oVirt Server Suite functionality >> ovirt-node : RPMs that provide oVirt node functionality >> ovirt-node-image: RPM that contains LiveCD ISO image and PXE images of >> the oVirt Node which uses the ovirt-node RPM >> ovirt-appliance : RPM that contains a Fedora appliance OS with >> ovirt-server and ovirt-node-image RPMs installed and >> configured >> ovirt-release : RPM that contains yum repo configuration file for >> ovirt.org repositories and developer convenience >> scripts >> ovirt-docs : RPMs that contain documentation for the oVirt project >> >> The build-all.sh script that was used to build all of the >> sub-projects of >> oVirt has been replaced with a top level makefile (ovirt.mk) from the >> ovirt-release repository and RPM. >> >> The old ovirt repo will continue to be hosted on git.et.redhat.org >> indefinitely, since it corresponds to version 0.92-1 and below of oVirt. >> The next release of oVirt will use the new refactored repositories. >> >> In addition to the repo refactoring and change from build-all.sh to >> ovirt.mk, we've also tried to reduce the dependency on root access for >> building. The only sections of the build that still require root are >> the >> RPM builds of ovirt-appliance and ovirt-node-image, as these RPMs use >> livecd-creator which requires root. >> >> Because of this, the user running the ovirt.mk makefile should have >> passwordless sudo as root access. Sudo is used inside of the appliance >> and node-image spec files to allow livecd-creator to work properly. >> >> Developers wishing to take a look at what is currently in development >> for >> the next release can do the following on a Fedora 9 host. >> >> Install the latest ovirt-release RPM from ovirt.org: >> >> $ sudo rpm -ivh >> http://ovirt.org/repos/ovirt/9/ovirt-release-0.92-1.fc9.noarch.rpm >> >> This will add: >> /etc/yum.repos.d/ovirt.repo - Used for yum update/install of oVirt RPMs >> /usr/share/ovirt-release/ovirt.mk - Developer Makefile >> >> To get the rest of the repositories do the following: >> $ mkdir ~/ovirt >> $ cd ~/ovirt\ >> $ export OVIRT_BRANCH=next >> $ make -f /usr/share/ovirt-release/ovirt.mk update >> >> Replace ~/ovirt with any directory you would like (this is just an >> example) This will check out all 6 repos from the ovirt.org site. >> >> OVIRT_BRANCH is set to next to indicate that you want to work on the >> next >> branch instead of master in the git repos. >> >> To do a build (similar to build-all.sh in previous releases) do: >> $ make -f /usr/share/ovirt-release/ovirt.mk build >> >> This will build all of the RPMs and make the oVirt Node and Appliance. >> After that you can run: >> >> $ sudo create-ovirt-appliance >> >> to create the Appliance on your host. create-ovirt-appliance replaces >> create-wui-appliance and has the same command line parameters. So to >> bridge your appliance to eth1, you would use: >> >> $ sudo create-ovirt-appliance -e eth1 >> >> Give the new repositories and developer scripts a try and please report >> any problems encountered. >> >> Thanks, >> >> oVirt Development Team >> > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From mmorsi at redhat.com Tue Sep 9 13:32:05 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Tue, 09 Sep 2008 09:32:05 -0400 Subject: [Ovirt-devel] [PATCH ovirt-appliance] add %{ovirt_local_repo} rpm macro In-Reply-To: <1220960543-20157-1-git-send-email-apevec@redhat.com> References: <1220960543-20157-1-git-send-email-apevec@redhat.com> Message-ID: <48C67AD5.9000802@redhat.com> Alan Pevec wrote: > so that autobuild can override it > default is file://%{ovirt_cache_dir}/ovirt > > Signed-off-by: Alan Pevec > --- > ovirt-appliance.spec | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec > index bbc0e77..feec956 100644 > --- a/ovirt-appliance.spec > +++ b/ovirt-appliance.spec > @@ -1,4 +1,5 @@ > %{!?ovirt_cache_dir: %define ovirt_cache_dir /var/tmp/ovirt-cache} > +%{!?ovirt_local_repo: %define ovirt_local_repo file://%{ovirt_cache_dir}/ovirt} > %{!?ovirt_url: %define ovirt_url http://ovirt.org/repos/ovirt} > %if %{fedora_url} > %define fedora_tree_url %{fedora_url}/releases/%{fedora}/Fedora/%{_arch}/os > @@ -47,7 +48,7 @@ fi > > cat >> repos.ks << EOF > repo --name=ovirt-org --baseurl=%{ovirt_url}/%{fedora}/%{_arch} > -repo --name=ovirt-cache --baseurl=file://%{ovirt_cache_dir}/ovirt > +repo --name=ovirt-local --baseurl=%{ovirt_local_repo} > EOF > > mkdir -p %{ovirt_cache_dir}/appliance-tmp/tree > ACK. Works for me. -Mo From mmorsi at redhat.com Tue Sep 9 13:32:19 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Tue, 09 Sep 2008 09:32:19 -0400 Subject: [Ovirt-devel] [PATCH ovirt-node-image] add %{ovirt_local_repo} rpm macro In-Reply-To: <1220960578-20211-1-git-send-email-apevec@redhat.com> References: <1220960578-20211-1-git-send-email-apevec@redhat.com> Message-ID: <48C67AE3.4070106@redhat.com> Alan Pevec wrote: > so that autobuild can override it > default is file://%{ovirt_cache_dir}/ovirt > > Signed-off-by: Alan Pevec > --- > ovirt-node-image.spec | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec > index ebe674d..5885fd9 100644 > --- a/ovirt-node-image.spec > +++ b/ovirt-node-image.spec > @@ -1,4 +1,5 @@ > %{!?ovirt_cache_dir: %define ovirt_cache_dir /var/tmp/ovirt-cache} > +%{!?ovirt_local_repo: %define ovirt_local_repo file://%{ovirt_cache_dir}/ovirt} > %{!?ovirt_url: %define ovirt_url http://ovirt.org/repos/ovirt} > %define fedora_mirror http://mirrors.fedoraproject.org/mirrorlist > > @@ -50,7 +51,7 @@ fi > > cat >> repos.ks << EOF > repo --name=ovirt-org --baseurl=%{ovirt_url}/%{fedora}/%{_arch} > -repo --name=ovirt-cache --baseurl=file://%{ovirt_cache_dir}/ovirt > +repo --name=ovirt-local --baseurl=%{ovirt_local_repo} > EOF > > mkdir -p %{ovirt_cache_dir}/node-image-tmp > ACK. Works for me. -Mo From pmyers at redhat.com Tue Sep 9 13:36:39 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 09 Sep 2008 09:36:39 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C67883.4020507@virtualiron.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> <48C67883.4020507@virtualiron.com> Message-ID: <48C67BE7.1070804@redhat.com> Ben Guthro wrote: > please disregard (operator error) > I was specifying the environment variables incorrectly on the build line. > > apologies for the noise. No worries.... So did just building the node and node-image by overriding SUBDIRS work then? I ask because the ability to do what you are doing was partially the point of the repo reorg, so I just want to make sure it's working as expected :) Perry From bguthro at virtualiron.com Tue Sep 9 13:46:30 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Tue, 09 Sep 2008 09:46:30 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C67BE7.1070804@redhat.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> <48C67883.4020507@virtualiron.com> <48C67BE7.1070804@redhat.com> Message-ID: <48C67E36.4090703@virtualiron.com> yes, it does work as advertised. I was doing make SUBDIRS="..." foo instead of SUBDIRS="..." make foo It would seem to make a difference. Thanks! Ben Perry N. Myers wrote on 09/09/2008 09:36 AM: > Ben Guthro wrote: >> please disregard (operator error) >> I was specifying the environment variables incorrectly on the build >> line. >> >> apologies for the noise. > > No worries.... So did just building the node and node-image by > overriding SUBDIRS work then? I ask because the ability to do what > you are doing was partially the point of the repo reorg, so I just > want to make sure it's working as expected :) > > Perry From rjones at redhat.com Tue Sep 9 14:22:32 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Sep 2008 15:22:32 +0100 Subject: [Ovirt-devel] root access required? In-Reply-To: <48C54CC9.1080701@redhat.com> References: <48C54CC9.1080701@redhat.com> Message-ID: <20080909142232.GA25270@amd.home.annexia.org> On Mon, Sep 08, 2008 at 12:03:21PM -0400, Perry N. Myers wrote: > Ben Guthro wrote: >> In my endeavor to set up a build environment for our developers >> experimenting with oVirt / libvirt, I have come across a general >> dislike that the build of the ovirt managed node requires the user to >> be root. [...] > The dependency on needing root is inherited from livecd-tools. So for us > to remove root as a requirement for building this needs to be changed > upstream. I'd start by posting questions/requests to the livecd mailing > lists and see if the developers there can easily fix this. > > Once root is not longer required for livecd-tools, we will be able to > build everything in ovirt as non-root. I would also LOVE to see livecd-creator not needing root. Has anyone talked to the livecd developers about this (email CC'd)? I can't find any recent discussion on their mailing list about it though. Mock does this by having a C helper program called, creatively, 'mock-helper' which does all the SUID operations needed on behalf of mock. The result is obviously very successful for them. Here is the source for mock-helper: http://annexia.org/tmp/mock-helper.c.txt Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Tue Sep 9 14:24:49 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Sep 2008 15:24:49 +0100 Subject: [Ovirt-devel] root access required? In-Reply-To: <1220894384.5971.11.camel@dlively2.katana-technology.com> References: <1220894384.5971.11.camel@dlively2.katana-technology.com> Message-ID: <20080909142449.GB25270@amd.home.annexia.org> On Mon, Sep 08, 2008 at 01:19:44PM -0400, David Lively wrote: > I've always been a big fan of Debian's 'fakeroot' for making archives > whose files have root ownership (without actually boosting the invoking > users privileges -- so not a security hole). And now 'fakeroot' is > available for Fedora (9, at least) via the official yum repos. One cool thing about fakeroot for those not familiar with it, is that it doesn't just fake root operations, eg. chowning a file, but it also remembers the faked state of file ownership/permissions etc. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From katzj at redhat.com Tue Sep 9 15:34:03 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 09 Sep 2008 11:34:03 -0400 Subject: [Fedora-livecd-list] Re: [Ovirt-devel] root access required? In-Reply-To: <20080909142232.GA25270@amd.home.annexia.org> References: <48C54CC9.1080701@redhat.com> <20080909142232.GA25270@amd.home.annexia.org> Message-ID: <1220974443.5554.172.camel@aglarond.local> On Tue, 2008-09-09 at 15:22 +0100, Richard W.M. Jones wrote: > On Mon, Sep 08, 2008 at 12:03:21PM -0400, Perry N. Myers wrote: > > Ben Guthro wrote: > >> In my endeavor to set up a build environment for our developers > >> experimenting with oVirt / libvirt, I have come across a general > >> dislike that the build of the ovirt managed node requires the user to > >> be root. > [...] > > The dependency on needing root is inherited from livecd-tools. So for us > > to remove root as a requirement for building this needs to be changed > > upstream. I'd start by posting questions/requests to the livecd mailing > > lists and see if the developers there can easily fix this. > > > > Once root is not longer required for livecd-tools, we will be able to > > build everything in ovirt as non-root. > > I would also LOVE to see livecd-creator not needing root. Has anyone > talked to the livecd developers about this (email CC'd)? I can't find > any recent discussion on their mailing list about it though. > > Mock does this by having a C helper program called, creatively, > 'mock-helper' which does all the SUID operations needed on behalf of > mock. The result is obviously very successful for them. > > Here is the source for mock-helper: > > http://annexia.org/tmp/mock-helper.c.txt Given that you're installing arbitrary packages and then running scripts for livecd-tools, just use sudo. And doing something like fakeroot doesn't work because just "remembering" the changed owners isn't good enough -- they actually need to be changed on the filesystem so that the resulting filesystem (that you boot and use as a normal system) has the correct ownership, selinux xattrs and permissions. Jeremy From pmyers at redhat.com Tue Sep 9 16:45:32 2008 From: pmyers at redhat.com (Perry Myers) Date: Tue, 9 Sep 2008 12:45:32 -0400 Subject: [Ovirt-devel] [PATCH] Added ovirt-build subpackage to store developer tools Message-ID: <1220978732-17239-1-git-send-email-pmyers@redhat.com> Signed-off-by: Perry Myers --- ovirt-release.spec | 19 ++++++++++++++++--- 1 files changed, 16 insertions(+), 3 deletions(-) diff --git a/ovirt-release.spec b/ovirt-release.spec index d348352..b9a1d5d 100644 --- a/ovirt-release.spec +++ b/ovirt-release.spec @@ -12,11 +12,19 @@ BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) BuildArch: noarch %define app_root %{_datadir}/%{name} +%define app_build_root %{_datadir}/ovirt-build %description ovirt.org Repository contains packages and fixes required for oVirt which are not yet in Fedora. +%package -n ovirt-build +Summary: oVirt Build Scripts for developers +Group: Applications/System +%description -n ovirt-build +Developer makefile and scripts to help automate the building of +oVirt from source repositories. + %prep %setup -c -T @@ -27,17 +35,22 @@ which are not yet in Fedora. install -dm 755 %{buildroot}%{_sysconfdir}/yum.repos.d install -pm 644 %{SOURCE0} %{buildroot}%{_sysconfdir}/yum.repos.d -install -dm 755 %{buildroot}%{app_root} -install -pm 644 %{SOURCE2} %{buildroot}%{app_root} +install -dm 755 %{buildroot}%{app_build_root} +install -pm 644 %{SOURCE2} %{buildroot}%{app_build_root} %clean %{__rm} -rf %{buildroot} %files %defattr(-,root,root,0644) -%{app_root}/ovirt.mk %config %{_sysconfdir}/yum.repos.d/* +%files -n ovirt-build +%defattr(-,root,root,0644) +%{app_build_root}/ovirt.mk + %changelog +* Tue Sep 09 2008 Perry Myers 0.92-1 +- Added ovirt-build subpackage for developer tools * Tue Jul 29 2008 Alan Pevec 0.91-1 - Initial build. -- 1.5.5.1 From bguthro at virtualiron.com Tue Sep 9 18:04:03 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Tue, 09 Sep 2008 14:04:03 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C67E36.4090703@virtualiron.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> <48C67883.4020507@virtualiron.com> <48C67BE7.1070804@redhat.com> <48C67E36.4090703@virtualiron.com> Message-ID: <48C6BA93.1050200@virtualiron.com> I am curious about one new quirk, however... It seems that my /dev/loopX is being left mounted at the end of the build. Is that intentional, or an oversight? Ben Guthro wrote on 09/09/2008 09:46 AM: > yes, it does work as advertised. > > I was doing > make SUBDIRS="..." foo > instead of > SUBDIRS="..." make foo > > It would seem to make a difference. > > Thanks! > > Ben > > Perry N. Myers wrote on 09/09/2008 09:36 AM: >> Ben Guthro wrote: >>> please disregard (operator error) >>> I was specifying the environment variables incorrectly on the build >>> line. >>> >>> apologies for the noise. >> >> No worries.... So did just building the node and node-image by >> overriding SUBDIRS work then? I ask because the ability to do what >> you are doing was partially the point of the repo reorg, so I just >> want to make sure it's working as expected :) >> >> Perry > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From pmyers at redhat.com Tue Sep 9 18:17:51 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 09 Sep 2008 14:17:51 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C6BA93.1050200@virtualiron.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> <48C67883.4020507@virtualiron.com> <48C67BE7.1070804@redhat.com> <48C67E36.4090703@virtualiron.com> <48C6BA93.1050200@virtualiron.com> Message-ID: <48C6BDCF.608@redhat.com> Ben Guthro wrote: > I am curious about one new quirk, however... > > It seems that my /dev/loopX is being left mounted at the end of the build. > Is that intentional, or an oversight? That is a bug in livecd-tools that I have seen but have never been able to track down... What should happen is when livecd-tools finishes making a livecd image it should tear down all of the loop filesystems and return the system to normal. But sometimes it doesn't do that, and I've yet to figure out why. One thing that I *think* causes it is if you abort a livecd creation in the middle. But that's just speculation. I do believe there is an open bug against this behavior, btw. cc'ing Jeremy on this in case he has any insights. Perry From pmyers at redhat.com Tue Sep 9 19:03:34 2008 From: pmyers at redhat.com (Perry Myers) Date: Tue, 9 Sep 2008 15:03:34 -0400 Subject: [Ovirt-devel] [PATCH] Cleanup of output in ovirt.mk file as well as fixing autoconf problems Message-ID: <1220987014-1142-1-git-send-email-pmyers@redhat.com> --- ovirt.mk | 24 +++++++++++++++--------- 1 files changed, 15 insertions(+), 9 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index 8b97ef4..126502c 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -8,11 +8,16 @@ OVIRT_BRANCH ?= master SUBDIRS ?= release server node node-image appliance docs +SUBDIR_SEP = ============================================================ + export OVIRT_CACHE_DIR ?= $(HOME)/ovirt-cache define for_each_subdir +for dir in $(SUBDIRS); do \ if test -d $$dir ; then \ + echo $(SUBDIR_SEP) $$dir ; \ + (cd $$dir && test ! -f Makefile.in && test -f autogen.sh && ./autogen.sh ) || :; \ + (cd $$dir && test ! -f Makefile && test -f configure && ./configure ) || :; \ $(MAKE) -C $$dir $@ || exit 1 ; \ fi ; \ done @@ -29,24 +34,24 @@ $(SUBDIRS): cd $@ && git pull -v && git checkout $(OVIRT_BRANCH) clean: - $(for_each_subdir) + @$(for_each_subdir) distclean: - $(for_each_subdir) + @$(for_each_subdir) bumpgit: - $(for_each_subdir) + @$(for_each_subdir) bumprelease: - $(for_each_subdir) + @$(for_each_subdir) bumpversion: - $(for_each_subdir) + @$(for_each_subdir) status diff: - for dir in $(SUBDIRS); do \ + @for dir in $(SUBDIRS); do \ if test -d $$dir ; then \ - echo ===== $$dir =============================================== ;\ + echo $(SUBDIR_SEP) $$dir ; \ (cd $$dir && git $@) || :; \ fi ; \ done @@ -57,8 +62,9 @@ publish: if ! test -d $$dir ; then \ $(MAKE) $$dir || exit 1 ; \ fi ; \ - ( cd $$dir; test ! -f Makefile.in && ./autogen.sh ); \ - ( cd $$dir; test ! -f Makefile && ./configure ); \ + echo $(SUBDIR_SEP) $$dir ; \ + (cd $$dir && test ! -f Makefile.in && test -f autogen.sh && ./autogen.sh ) || :; \ + (cd $$dir && test ! -f Makefile && test -f configure && ./configure ) || :; \ $(MAKE) -C $$dir $@ || exit 1 ; \ done rm -f rpms -- 1.5.5.1 From jim at meyering.net Tue Sep 9 19:54:37 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 09 Sep 2008 21:54:37 +0200 Subject: [Ovirt-devel] [PATCH node] autogen.sh: don't say we're about to run configure, Message-ID: <87bpyx14ea.fsf@rho.meyering.net> since this script no longer does that. --- autogen.sh | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/autogen.sh b/autogen.sh index 85352f0..df09187 100755 --- a/autogen.sh +++ b/autogen.sh @@ -40,11 +40,6 @@ THEDIR=`pwd` exit 1 } - if test -z "$*"; then - echo "I am going to run ./configure with no arguments - if you wish " - echo "to pass any to it, please specify them on the $0 command line." - fi - aclocal autoheader automake --add-missing -- 1.6.0.1.196.g01914 From apevec at redhat.com Tue Sep 9 20:03:08 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 09 Sep 2008 22:03:08 +0200 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C6BA93.1050200@virtualiron.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> <48C67883.4020507@virtualiron.com> <48C67BE7.1070804@redhat.com> <48C67E36.4090703@virtualiron.com> <48C6BA93.1050200@virtualiron.com> Message-ID: <48C6D67C.7000809@redhat.com> Ben Guthro wrote: > I am curious about one new quirk, however... > > It seems that my /dev/loopX is being left mounted at the end of the build. > Is that intentional, or an oversight? If all finished cleanly, loop device should be detached by livecd cleanup. Please email me the build log when that happened, if you have it captured. From jim at meyering.net Tue Sep 9 20:13:30 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 09 Sep 2008 22:13:30 +0200 Subject: [Ovirt-devel] [PATCH] Cleanup of output in ovirt.mk file as well as fixing autoconf problems In-Reply-To: <1220987014-1142-1-git-send-email-pmyers@redhat.com> (Perry Myers's message of "Tue, 9 Sep 2008 15:03:34 -0400") References: <1220987014-1142-1-git-send-email-pmyers@redhat.com> Message-ID: <8763p513it.fsf@rho.meyering.net> Perry Myers wrote: > --- > ovirt.mk | 24 +++++++++++++++--------- > 1 files changed, 15 insertions(+), 9 deletions(-) > > diff --git a/ovirt.mk b/ovirt.mk > index 8b97ef4..126502c 100644 > --- a/ovirt.mk > +++ b/ovirt.mk > @@ -8,11 +8,16 @@ OVIRT_BRANCH ?= master > > SUBDIRS ?= release server node node-image appliance docs > > +SUBDIR_SEP = ============================================================ > + > export OVIRT_CACHE_DIR ?= $(HOME)/ovirt-cache > > define for_each_subdir > +for dir in $(SUBDIRS); do \ > if test -d $$dir ; then \ > + echo $(SUBDIR_SEP) $$dir ; \ > + (cd $$dir && test ! -f Makefile.in && test -f autogen.sh && ./autogen.sh ) || :; \ > + (cd $$dir && test ! -f Makefile && test -f configure && ./configure ) || :; \ > $(MAKE) -C $$dir $@ || exit 1 ; \ > fi ; \ > done > @@ -29,24 +34,24 @@ $(SUBDIRS): > cd $@ && git pull -v && git checkout $(OVIRT_BRANCH) > > clean: > - $(for_each_subdir) > + @$(for_each_subdir) > > distclean: > - $(for_each_subdir) > + @$(for_each_subdir) > > bumpgit: > - $(for_each_subdir) > + @$(for_each_subdir) > > bumprelease: > - $(for_each_subdir) > + @$(for_each_subdir) > > bumpversion: > - $(for_each_subdir) > + @$(for_each_subdir) > > status diff: > - for dir in $(SUBDIRS); do \ > + @for dir in $(SUBDIRS); do \ > if test -d $$dir ; then \ > - echo ===== $$dir =============================================== ;\ > + echo $(SUBDIR_SEP) $$dir ; \ > (cd $$dir && git $@) || :; \ > fi ; \ > done > @@ -57,8 +62,9 @@ publish: > if ! test -d $$dir ; then \ > $(MAKE) $$dir || exit 1 ; \ > fi ; \ > - ( cd $$dir; test ! -f Makefile.in && ./autogen.sh ); \ > - ( cd $$dir; test ! -f Makefile && ./configure ); \ > + echo $(SUBDIR_SEP) $$dir ; \ > + (cd $$dir && test ! -f Makefile.in && test -f autogen.sh && ./autogen.sh ) || :; \ > + (cd $$dir && test ! -f Makefile && test -f configure && ./configure ) || :; \ > $(MAKE) -C $$dir $@ || exit 1 ; \ > done > rm -f rpms That works, but you shouldn't have had to make the same change to 5 identical lines, and I want to avoid some duplication and long lines, so how about these additional changes? >From 7362ec4f2d6a74566ad2fe735a7be7d47faaa131 Mon Sep 17 00:00:00 2001 From: Perry Myers Date: Tue, 9 Sep 2008 15:03:34 -0400 Subject: [PATCH release] ovirt.mk: factor+cleanup; make rules work also in autoconfiscated subdir (clean, distclean, bumpgit, bumprelease, bumpversion): Consolidate. (subdir_gen_and_make): New "command", factored out of... (for_each_subdir): ...here, and (status diff): ...here. --- ovirt.mk | 59 ++++++++++++++++++++++++++++------------------------------- 1 files changed, 28 insertions(+), 31 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index 8b97ef4..7f7d143 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -8,14 +8,25 @@ OVIRT_BRANCH ?= master SUBDIRS ?= release server node node-image appliance docs +SUBDIR_SEP = ============================================================ + export OVIRT_CACHE_DIR ?= $(HOME)/ovirt-cache +define subdir_gen_and_make + echo $(SUBDIR_SEP) $$dir; \ + (cd $$dir && test ! -f Makefile.in && test -f autogen.sh && ./autogen.sh) \ + || :; \ + (cd $$dir && test ! -f Makefile && test -f configure && ./configure ) \ + || :; \ + $(MAKE) -C $$dir $@ || exit 1 +endef + define for_each_subdir - +for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - $(MAKE) -C $$dir $@ || exit 1 ; \ - fi ; \ - done + +for dir in $(SUBDIRS); do \ + if test -d $$dir ; then \ + $(subdir_gen_and_make); \ + fi; \ + done endef all: dev-build @@ -28,38 +39,24 @@ $(SUBDIRS): git config remote.origin.fetch +$(OVIRT_BRANCH):$(OVIRT_BRANCH) ; } cd $@ && git pull -v && git checkout $(OVIRT_BRANCH) -clean: - $(for_each_subdir) - -distclean: - $(for_each_subdir) - -bumpgit: - $(for_each_subdir) - -bumprelease: - $(for_each_subdir) - -bumpversion: - $(for_each_subdir) +clean distclean bumpgit bumprelease bumpversion: + @$(for_each_subdir) status diff: - for dir in $(SUBDIRS); do \ - if test -d $$dir ; then \ - echo ===== $$dir =============================================== ;\ - (cd $$dir && git $@) || :; \ - fi ; \ + @for dir in $(SUBDIRS); do \ + if test -d $$dir ; then \ + echo $(SUBDIR_SEP) $$dir ; \ + (cd $$dir && git $@) || :; \ + fi ; \ done build: publish publish: - for dir in $(SUBDIRS); do \ - if ! test -d $$dir ; then \ - $(MAKE) $$dir || exit 1 ; \ - fi ; \ - ( cd $$dir; test ! -f Makefile.in && ./autogen.sh ); \ - ( cd $$dir; test ! -f Makefile && ./configure ); \ - $(MAKE) -C $$dir $@ || exit 1 ; \ + for dir in $(SUBDIRS); do \ + if ! test -d $$dir ; then \ + $(MAKE) $$dir || exit 1 ; \ + fi ; \ + $(subdir_gen_and_make); \ done rm -f rpms ln -s $(OVIRT_CACHE_DIR)/ovirt rpms -- 1.6.0.1.196.g01914 From bguthro at virtualiron.com Tue Sep 9 20:41:22 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Tue, 09 Sep 2008 16:41:22 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C6D67C.7000809@redhat.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> <48C67883.4020507@virtualiron.com> <48C67BE7.1070804@redhat.com> <48C67E36.4090703@virtualiron.com> <48C6BA93.1050200@virtualiron.com> <48C6D67C.7000809@redhat.com> Message-ID: <48C6DF72.1020900@virtualiron.com> Hmm... I have not seen it clean up properly yet, since the repo split. However - it was at that time I started to execute this not as root, but as a user with sudo access, and no password. After every build, I have to do a sudo umount /dev/loop0 losetup -d /dev/loop0 to clean up log attached (excerpt from a larger build) Alan Pevec wrote on 09/09/2008 04:03 PM: > Ben Guthro wrote: >> I am curious about one new quirk, however... >> >> It seems that my /dev/loopX is being left mounted at the end of the >> build. >> Is that intentional, or an oversight? > > If all finished cleanly, loop device should be detached by livecd > cleanup. > Please email me the build log when that happened, if you have it > captured. > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: build.ovirt.log URL: From bguthro at virtualiron.com Tue Sep 9 20:58:52 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Tue, 09 Sep 2008 16:58:52 -0400 Subject: [Ovirt-devel] oVirt Source Repository Refactoring In-Reply-To: <48C6DF72.1020900@virtualiron.com> References: <48C57FAC.2030909@redhat.com> <48C66F25.3020000@virtualiron.com> <48C67883.4020507@virtualiron.com> <48C67BE7.1070804@redhat.com> <48C67E36.4090703@virtualiron.com> <48C6BA93.1050200@virtualiron.com> <48C6D67C.7000809@redhat.com> <48C6DF72.1020900@virtualiron.com> Message-ID: <48C6E38C.8060800@virtualiron.com> It would seem this has nothing to do with root vs non-root - as I get the same behaviour either way. Am I missing a build step? Ben Guthro wrote on 09/09/2008 04:41 PM: > Hmm... I have not seen it clean up properly yet, since the repo split. > > However - it was at that time I started to execute this not as root, > but as a user with sudo access, and no password. > > After every build, I have to do a > sudo umount /dev/loop0 > losetup -d /dev/loop0 > to clean up > > log attached (excerpt from a larger build) > > > Alan Pevec wrote on 09/09/2008 04:03 PM: >> Ben Guthro wrote: >>> I am curious about one new quirk, however... >>> >>> It seems that my /dev/loopX is being left mounted at the end of the >>> build. >>> Is that intentional, or an oversight? >> >> If all finished cleanly, loop device should be detached by livecd >> cleanup. >> Please email me the build log when that happened, if you have it >> captured. >> >> > ------------------------------------------------------------------------ > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at meyering.net Tue Sep 9 21:10:52 2008 From: jim at meyering.net (Jim Meyering) Date: Tue, 09 Sep 2008 23:10:52 +0200 Subject: [Ovirt-devel] [PATCH] Cleanup of output in ovirt.mk file as well as fixing autoconf problems In-Reply-To: <8763p513it.fsf@rho.meyering.net> (Jim Meyering's message of "Tue, 09 Sep 2008 22:13:30 +0200") References: <1220987014-1142-1-git-send-email-pmyers@redhat.com> <8763p513it.fsf@rho.meyering.net> Message-ID: <87wshlyqhv.fsf@rho.meyering.net> Jim Meyering wrote: > Perry Myers wrote: >> --- >> ovirt.mk | 24 +++++++++++++++--------- ... > That works, but you shouldn't have had to make the same change to > 5 identical lines, and I want to avoid some duplication and long lines, > so how about these additional changes? > >>From 7362ec4f2d6a74566ad2fe735a7be7d47faaa131 Mon Sep 17 00:00:00 2001 > From: Perry Myers > Date: Tue, 9 Sep 2008 15:03:34 -0400 > Subject: [PATCH release] ovirt.mk: factor+cleanup; make rules work also in autoconfiscated subdir > > (clean, distclean, bumpgit, bumprelease, bumpversion): Consolidate. > (subdir_gen_and_make): New "command", factored out of... > (for_each_subdir): ...here, and > (status diff): ...here. Perry ACK'd it, so I've just pushed the updated patch. From clalance at redhat.com Wed Sep 10 06:39:44 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:39:44 +0200 Subject: [Ovirt-devel] [PATCH-appliance 0/3]: Allow the WUI to manage the hardware it is running on Message-ID: <1221028787-15886-1-git-send-email-clalance@redhat.com> Appliance patches for allowing the WUI to manage the hardware it is running on. From clalance at redhat.com Wed Sep 10 06:39:45 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:39:45 +0200 Subject: [Ovirt-devel] [PATCH-appliance 1/3] In the rc.local, attempt to contact the host we are running In-Reply-To: <1221028787-15886-1-git-send-email-clalance@redhat.com> References: <1221028787-15886-1-git-send-email-clalance@redhat.com> Message-ID: <1221028787-15886-2-git-send-email-clalance@redhat.com> Signed-off-by: Chris Lalancette --- :100644 100644 4c4c96e... faa0bd4... M ovirt-appliance.ks ovirt-appliance.ks | 13 +++++++++++++ 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/ovirt-appliance.ks b/ovirt-appliance.ks index 4c4c96e..faa0bd4 100644 --- a/ovirt-appliance.ks +++ b/ovirt-appliance.ks @@ -25,9 +25,22 @@ set /files/etc/sysconfig/network-scripts/ifcfg-eth1/DNS1 192.168.50.2 save EOF +# the code to contact the host we are running on and make it configure itself +# note that this has to be done in rc.local (as opposed to ovirt-wui-dev) +# because when ovirt-wui-dev starts, the host-browser is not yet running +cat >> /etc/rc.d/rc.local << \EOF +# Try to contact the host we are running on; if we succeed, we'll use it as +# one of the managed nodes; if not, no big deal +exec 3<> /dev/tcp/192.168.50.1/7777 +echo "AWAKE" 1>&3 +exec 3<> /dev/tcp/192.168.50.1/7777 +echo "IDENTIFY" 1>&3 +EOF + # make sure to update the /etc/hosts with the list of all possible DHCP # addresses we can hand out; dnsmasq uses this sed -i -e 's/management\.priv\.ovirt\.org//' /etc/hosts +echo "192.168.50.1 physical.priv.ovirt.org" >> /etc/hosts echo "192.168.50.2 management.priv.ovirt.org" >> /etc/hosts for i in `seq 3 252` ; do echo "192.168.50.$i node$i.priv.ovirt.org" >> /etc/hosts -- 1.5.4.1 From clalance at redhat.com Wed Sep 10 06:39:46 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:39:46 +0200 Subject: [Ovirt-devel] [PATCH-appliance 2/3] Fix up the awk script to *exactly* match the bridge we are looking for. In-Reply-To: <1221028787-15886-1-git-send-email-clalance@redhat.com> References: <1221028787-15886-1-git-send-email-clalance@redhat.com> Message-ID: <1221028787-15886-3-git-send-email-clalance@redhat.com> Signed-off-by: Chris Lalancette --- :100755 100755 035dce7... d3800e7... M create-ovirt-appliance create-ovirt-appliance | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/create-ovirt-appliance b/create-ovirt-appliance index 035dce7..d3800e7 100755 --- a/create-ovirt-appliance +++ b/create-ovirt-appliance @@ -220,7 +220,7 @@ fi # Remove old bridge device if it exists sed -i "/# $BRIDGENAME/d" /etc/rc.d/rc.local old_bridge=$(brctl show \ - | awk -v BRIDGENAME=$BRIDGENAME '$1~BRIDGENAME {print $4}') + | awk -v BRIDGENAME=$BRIDGENAME '$1==BRIDGENAME {print $4}') if [ -n "$old_bridge" ]; then echo "Removing old bridge $old_bridge" ifconfig $old_bridge down -- 1.5.4.1 From clalance at redhat.com Wed Sep 10 06:39:47 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:39:47 +0200 Subject: [Ovirt-devel] [PATCH-appliance 3/3] Since we are currently hardcoding ovirtbr0 in taskomatic, In-Reply-To: <1221028787-15886-1-git-send-email-clalance@redhat.com> References: <1221028787-15886-1-git-send-email-clalance@redhat.com> Message-ID: <1221028787-15886-4-git-send-email-clalance@redhat.com> Signed-off-by: Chris Lalancette --- :100755 100755 d3800e7... 57883e0... M create-ovirt-appliance create-ovirt-appliance | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/create-ovirt-appliance b/create-ovirt-appliance index d3800e7..57883e0 100755 --- a/create-ovirt-appliance +++ b/create-ovirt-appliance @@ -10,7 +10,7 @@ RAM=768 IMGDIR_DEFAULT=/var/lib/libvirt/images NAME_DEFAULT=ovirt-appliance NET_SCRIPTS=/etc/sysconfig/network-scripts -BRIDGENAME=ovirtbr +BRIDGENAME=ovirtbr0 imgdir=$IMGDIR_DEFAULT name=$NAME_DEFAULT -- 1.5.4.1 From clalance at redhat.com Wed Sep 10 06:41:13 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:41:13 +0200 Subject: [Ovirt-devel] [PATCH-node-image 0/2]: Allow the WUI to manage the hardware it is running on Message-ID: <1221028875-15992-1-git-send-email-clalance@redhat.com> Node-image patches for allowing the WUI to manage the hardware it is running on. From clalance at redhat.com Wed Sep 10 06:41:15 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:41:15 +0200 Subject: [Ovirt-devel] [PATCH-node-image 2/2] change common-pkgs to require ovirt-node-stateless In-Reply-To: <1221028875-15992-1-git-send-email-clalance@redhat.com> References: <1221028875-15992-1-git-send-email-clalance@redhat.com> Message-ID: <1221028875-15992-3-git-send-email-clalance@redhat.com> Signed-off-by: Chris Lalancette --- :100644 100644 70707fc... e88d6d8... M common-pkgs.ks common-pkgs.ks | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common-pkgs.ks b/common-pkgs.ks index 70707fc..e88d6d8 100644 --- a/common-pkgs.ks +++ b/common-pkgs.ks @@ -28,7 +28,7 @@ bind-utils syslinux cronie hal -ovirt-node +ovirt-node-stateless -policycoreutils -audit-libs-python -hdparm -- 1.5.4.1 From clalance at redhat.com Wed Sep 10 06:41:14 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:41:14 +0200 Subject: [Ovirt-devel] [PATCH-node-image 1/2] 1) Removed a redundant BuildRequires line. In-Reply-To: <1221028875-15992-1-git-send-email-clalance@redhat.com> References: <1221028875-15992-1-git-send-email-clalance@redhat.com> Message-ID: <1221028875-15992-2-git-send-email-clalance@redhat.com> Signed-off-by: Chris Lalancette --- :100644 100644 1615f4f... 5885fd9... M ovirt-node-image.spec ovirt-node-image.spec | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec index 1615f4f..5885fd9 100644 --- a/ovirt-node-image.spec +++ b/ovirt-node-image.spec @@ -29,7 +29,6 @@ At the moment, this RPM just packages prebuilt ISO. %package pxe Summary: oVirt Node boot PXE image Group: Applications/System -BuildRequires: livecd-tools >= 017 %description pxe The PXE boot image for oVirt Node network boot from oVirt Server. @@ -83,6 +82,9 @@ mkdir %{buildroot} %clean %{__rm} -rf %{buildroot} +%post pxe +[ -x /usr/bin/cobbler ] && /usr/bin/cobbler sync + %files %defattr(-,root,root,0644) %{app_root}/%{name}.iso -- 1.5.4.1 From clalance at redhat.com Wed Sep 10 06:42:12 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:42:12 +0200 Subject: [Ovirt-devel] [PATCH-node 1/2] Add ovirt-listen-awake daemon. This is a very small daemon that oVirt In-Reply-To: <1221028933-16058-1-git-send-email-clalance@redhat.com> References: <1221028933-16058-1-git-send-email-clalance@redhat.com> Message-ID: <1221028933-16058-2-git-send-email-clalance@redhat.com> Signed-off-by: Chris Lalancette --- :100644 100644 0ae494d... fad3fb5... M Makefile.am :100644 100644 453d015... e6ba7e3... M configure.ac :000000 100644 0000000... d511905... A ovirt-listen-awake/COPYING :000000 100644 0000000... b7f299c... A ovirt-listen-awake/Makefile.am :000000 100644 0000000... 7ecd0a7... A ovirt-listen-awake/ovirt-listen-awake.c :100644 100644 5c092b4... 736338d... M ovirt-node.spec Makefile.am | 2 +- configure.ac | 2 +- ovirt-listen-awake/COPYING | 339 +++++++++++++++++++++++++++++++ ovirt-listen-awake/Makefile.am | 22 ++ ovirt-listen-awake/ovirt-listen-awake.c | 225 ++++++++++++++++++++ ovirt-node.spec | 7 +- 6 files changed, 594 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index 0ae494d..fad3fb5 100644 --- a/Makefile.am +++ b/Makefile.am @@ -15,7 +15,7 @@ # MA 02110-1301, USA. A copy of the GNU General Public License is # also available at http://www.gnu.org/copyleft/gpl.html. -SUBDIRS = ovirt-identify-node +SUBDIRS = ovirt-identify-node ovirt-listen-awake EXTRA_DIST = \ .gitignore \ diff --git a/configure.ac b/configure.ac index 453d015..e6ba7e3 100644 --- a/configure.ac +++ b/configure.ac @@ -13,5 +13,5 @@ PKG_CHECK_MODULES([VIRT], [libvirt >= 0.4.4]) test x"$ac_ct_CC:$CFLAGS" = 'xgcc:-g -O2' \ && CFLAGS="$CFLAGS -Wshadow -Wall -Werror" -AC_CONFIG_FILES([Makefile ovirt-identify-node/Makefile]) +AC_CONFIG_FILES([Makefile ovirt-identify-node/Makefile ovirt-listen-awake/Makefile]) AC_OUTPUT diff --git a/ovirt-listen-awake/COPYING b/ovirt-listen-awake/COPYING new file mode 100644 index 0000000..d511905 --- /dev/null +++ b/ovirt-listen-awake/COPYING @@ -0,0 +1,339 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Lesser General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License along + with this program; if not, write to the Free Software Foundation, Inc., + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Lesser General +Public License instead of this License. diff --git a/ovirt-listen-awake/Makefile.am b/ovirt-listen-awake/Makefile.am new file mode 100644 index 0000000..b7f299c --- /dev/null +++ b/ovirt-listen-awake/Makefile.am @@ -0,0 +1,22 @@ +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +bin_PROGRAMS = ovirt-listen-awake + +EXTRA_DIST = ovirt-listen-awake.init ovirt-convert-host ovirt-unconvert-host + +ovirt_listen_awake_SOURCES = ovirt-listen-awake.c diff --git a/ovirt-listen-awake/ovirt-listen-awake.c b/ovirt-listen-awake/ovirt-listen-awake.c new file mode 100644 index 0000000..7ecd0a7 --- /dev/null +++ b/ovirt-listen-awake/ovirt-listen-awake.c @@ -0,0 +1,225 @@ +/* ovirt-listen-awake: daemon to listen for and respond to AWAKE requests + * + * Copyright (C) 2008 Red Hat, Inc. + * Written by Chris Lalancette + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, + * MA 02110-1301, USA. A copy of the GNU General Public License is + * also available at http://www.gnu.org/copyleft/gpl.html. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +// We only ever expect to receive the strings "AWAKE" or "IDENTIFY", so +// 20 bytes is more than enough +#define BUFLEN 20 +#define LOGFILE "/var/log/ovirt-host.log" + +static int streq(char *first, char *second) +{ + int first_len, second_len; + + first_len = strlen(first); + second_len = strlen(second); + + if (first_len == second_len && strncmp(first, second, first_len) == 0) + return 1; + return 0; +} + +// Given a buffer, find the first whitespace character, replace it with \0, +// and return +static void find_first_whitespace(char *buffer) +{ + int i; + + i = 0; + while (buffer[i] != '\0') { + if (isspace(buffer[i])) { + // once we see the first whitespace character, we are done + buffer[i] ='\0'; + break; + } + i++; + } +} + +static int listenSocket(int listen_port) +{ + struct sockaddr_in a; + int s,yes; + + if (listen_port < 0) { + error(0, 0, "Invalid listen_port %d", listen_port); + return -1; + } + + s = socket(AF_INET, SOCK_STREAM, 0); + if (s < 0) { + error(0, errno, "Failed creating socket"); + return -1; + } + + yes = 1; + if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR,(char *)&yes, sizeof (yes)) < 0) { + error(0, errno, "Failed setsockopt"); + close(s); + return -1; + } + + memset (&a, 0, sizeof (a)); + a.sin_port = htons (listen_port); + a.sin_family = AF_INET; + if (bind(s, (struct sockaddr *) &a, sizeof (a)) < 0) { + error(0, errno, "Error binding to port %d", listen_port); + close(s); + return -1; + } + + if (listen(s, 10) < 0) { + error(0, errno, "Error listening on port %d", listen_port); + close(s); + return -1; + } + return s; +} + +static void usage(int exitcode) +{ + printf("Usage: ovirt-listen-awake [OPTIONS]\n"); + printf("OPTIONS:\n"); + printf(" -h\t\tShow this help message\n"); + printf(" -n\t\tDo not daemonize (useful for debugging)\n"); + exit(exitcode); +} + +int main(int argc, char *argv[]) +{ + int listen_socket, conn; + struct sockaddr_in client_address; + unsigned int addrlen; + FILE *conn_stream; + FILE *logfile; + char buffer[BUFLEN]; + int c; + int do_daemon; + int i; + + do_daemon = 1; + + while ((c=getopt(argc, argv, ":hn")) != -1) { + switch(c) { + case 'h': + usage(0); + break; + case 'n': + do_daemon = 0; + break; + default: + usage(1); + } + } + + if ((argc-optind) != 0) { + for (i = optind; i < argc ; i ++) { + fprintf(stderr, "Extra operand %s\n", argv[i]); + } + error(1, 0, "Try --help for more information"); + } + + listen_socket = listenSocket(7777); + if (listen_socket < 0) + return 2; + + if (do_daemon) { + logfile = fopen(LOGFILE,"a+"); + if (logfile == NULL) + error(3, errno, "Error opening logfile %s", LOGFILE); + + // NOTE: this closes stdout and stderr + if (daemon(0, 0) < 0) + error(4, errno, "Error daemonizing"); + + // so re-open them to the logfile here + dup2(fileno(logfile), STDOUT_FILENO); + dup2(fileno(logfile), STDERR_FILENO); + } + + while (1) { + addrlen = sizeof(client_address); + memset(&client_address, 0, addrlen); + memset(buffer, 0, BUFLEN); + conn = accept(listen_socket, (struct sockaddr *)&client_address, &addrlen); + if (conn < 0) { + error(0, errno, "Error accepting socket"); + continue; + } + + conn_stream = fdopen(conn, "r"); + if (conn_stream == NULL) { + error(0, errno, "Error converting fd to stream"); + close(conn); + continue; + } + + if (fgets(buffer, BUFLEN, conn_stream) == NULL) { + error(0, errno, "Error receiving data"); + fclose(conn_stream); + continue; + } + + find_first_whitespace(buffer); + + if (streq(buffer, "IDENTIFY")) { + // run ovirt-identify-node against 192.168.50.2 (the WUI node) + fprintf(stderr, "Doing identify\n"); + // FIXME: it would be best to call the "find_srv" shell script here to + // find out where we should contact. However, we would still have to + // hardcode which DNS server to use (192.168.50.2), and which domain + // name to use "priv.ovirt.org" to get this to work. I don't have + // a good idea how to solve this at the moment. + system("ovirt-identify-node -s 192.168.50.2 -p 12120"); + } + else if (streq(buffer, "AWAKE")) { + // run ovirt-awake against 192.168.50.2 + fprintf(stderr, "Doing awake\n"); + // FIXME: I hate to duplicate this stuff here, but I can't use the + // ovirt init scripts as-is; they depend too much on the environment + // (in particular, which DNS server to use to resolve, and which + // domainname). Until I come up with a good solution for that, I'll + // have to leave this as-is. + system("wget -q http://192.168.50.2:80/ipa/config/krb5.ini -O /etc/krb5.conf"); + system("ovirt-awake start 192.168.50.2 12120 /etc/libvirt/krb5.tab"); + } + else { + error(0, 0, "Unknown command %s", buffer); + } + + fclose(conn_stream); + } + + close(listen_socket); + fclose(logfile); + + return 0; +} diff --git a/ovirt-node.spec b/ovirt-node.spec index 5c092b4..736338d 100644 --- a/ovirt-node.spec +++ b/ovirt-node.spec @@ -43,6 +43,7 @@ make %{__install} -p -m0755 scripts/ovirt-awake %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-identify-node/ovirt-identify-node %{buildroot}%{_sbindir} +%{__install} -p -m0755 ovirt-listen-awake/ovirt-listen-awake %{buildroot}%{_sbindir} %{__install} -p -m0644 scripts/ovirt-functions %{buildroot}%{_initrddir} %{__install} -p -m0755 scripts/ovirt-early %{buildroot}%{_initrddir} @@ -130,6 +131,7 @@ fi %defattr(-,root,root,0755) %{_sbindir}/ovirt-awake %{_sbindir}/ovirt-identify-node +%{_sbindir}/ovirt-listen-awake %{_initrddir}/ovirt-early %{_initrddir}/ovirt %{_initrddir}/ovirt-post @@ -147,9 +149,12 @@ fi %doc ovirt-identify-node/COPYING %changelog -* Mon Sep 8 2008 Jim Meyering - 0.92 0.4 +* Mon Sep 8 2008 Jim Meyering - 0.92 0.6 - Update ovirt-identify-node's build rule. +* Fri Aug 22 2008 Chris Lalancette - 0.92 0.5 +- Add the ovirt-listen-awake daemon to the RPM + * Fri Aug 22 2008 Chris Lalancette - 0.92 0.4 - Re-arrange the directory layout, in preparation for ovirt-listen-awake -- 1.5.4.1 From clalance at redhat.com Wed Sep 10 06:42:11 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:42:11 +0200 Subject: [Ovirt-devel] [PATCH-node 0/2]: Allow the WUI to manage the hardware it is running on Message-ID: <1221028933-16058-1-git-send-email-clalance@redhat.com> Node patches for allowing the WUI to manage the hardware it is running on. From clalance at redhat.com Wed Sep 10 06:42:13 2008 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 10 Sep 2008 08:42:13 +0200 Subject: [Ovirt-devel] [PATCH-node 2/2] A rather large re-write of the ovirt-node.spec file. The reason In-Reply-To: <1221028933-16058-1-git-send-email-clalance@redhat.com> References: <1221028933-16058-1-git-send-email-clalance@redhat.com> Message-ID: <1221028933-16058-3-git-send-email-clalance@redhat.com> Signed-off-by: Chris Lalancette --- :000000 100644 0000000... 584291a... A ovirt-listen-awake/ovirt-convert-host :000000 100644 0000000... a6bb78a... A ovirt-listen-awake/ovirt-listen-awake.init :000000 100644 0000000... 4f0b02d... A ovirt-listen-awake/ovirt-unconvert-host :100644 100644 736338d... 3274a3f... M ovirt-node.spec :100644 100644 083e13d... 6ea034a... M scripts/ovirt-functions ovirt-listen-awake/ovirt-convert-host | 58 +++++++++++++++++++ ovirt-listen-awake/ovirt-listen-awake.init | 49 ++++++++++++++++ ovirt-listen-awake/ovirt-unconvert-host | 32 ++++++++++ ovirt-node.spec | 86 ++++++++++++++++----------- scripts/ovirt-functions | 26 ++++++++ 5 files changed, 216 insertions(+), 35 deletions(-) diff --git a/ovirt-listen-awake/ovirt-convert-host b/ovirt-listen-awake/ovirt-convert-host new file mode 100644 index 0000000..584291a --- /dev/null +++ b/ovirt-listen-awake/ovirt-convert-host @@ -0,0 +1,58 @@ +#!/bin/bash + +. /etc/init.d/ovirt-functions + +PATH=$PATH:/sbin:/usr/sbin + +if [ $# -ne 0 ]; then + echo "Usage: ovirt-convert-host" + exit 1 +fi + +backup_file() { + dir=$(dirname "$1") + case $dir in /*);; *) die "unexpected non-absolute dir: $dir";; esac + mkdir -p "$OVIRT_BACKUP_DIR/${dir:1}" + cp -pf "$1" "$OVIRT_BACKUP_DIR/${dir:1}" +} + +add_if_not_exist() { + string="$1" + file="$2" + + grep -qE "^[[:space:]]*$string($|#|[[:space:]])" "$file" \ + || echo "$string" >> "$file" +} + +echo "This script will make a number of changes to your system to enable it to" +echo "work as an oVirt node. You can later undo these changes by" +echo "running /usr/sbin/ovirt-unconvert-host. Do you want to proceed? [y/N]?" +read yesno + +if [ "$yesno" != "y" -a "$yesno" != "Y" ]; then + exit 2 +fi + +mkdir -p $OVIRT_BACKUP_DIR + +backup_file /etc/sysconfig/network +sed -i -e 's/^HOSTNAME=.*/HOSTNAME=physical.priv.ovirt.org/' /etc/sysconfig/network + +backup_file /etc/hosts +add_if_not_exist "192.168.50.1 physical.priv.ovirt.org" /etc/hosts +add_if_not_exist "192.168.50.2 management.priv.ovirt.org" /etc/hosts + +chkconfig ovirt-listen-awake on +chkconfig collectd on + +backup_file /etc/sysconfig/libvirtd +backup_file /etc/libvirt/qemu.conf +backup_file /etc/libvirt/libvirtd.conf +backup_file /etc/sasl2/libvirt.conf +ovirt_setup_libvirtd + +backup_file /etc/sysconfig/iptables +lokkit -n -t ovirtbr0 + +echo "Setup complete. To make the changes take effect, shut down any running +guests and reboot the host" diff --git a/ovirt-listen-awake/ovirt-listen-awake.init b/ovirt-listen-awake/ovirt-listen-awake.init new file mode 100644 index 0000000..a6bb78a --- /dev/null +++ b/ovirt-listen-awake/ovirt-listen-awake.init @@ -0,0 +1,49 @@ +#!/bin/bash +# +# +# ovirt-listen-awake startup script for ovirt-listen-awake +# +# chkconfig: - 97 03 +# description: ovirt-listen-awake is a daemon to listen for requests from +# the ovirt VM manager. When it receives one, it contacts the machine +# back with details so that it is added to the ovirt host pool. + +DAEMON=/usr/sbin/ovirt-listen-awake + +. /etc/init.d/functions + +start() { + echo -n "Starting ovirt-listen-awake: " + daemon $DAEMON + RETVAL=$? + echo +} + +stop() { + echo -n "Shutting down ovirt-listen-awake: " + killproc ovirt-listen-awake + RETVAL=$? + echo +} + +case "$1" in + start) + start + ;; + stop) + stop + ;; + restart) + stop + start + ;; + status) + status $DAEMON + RETVAL=$? + ;; + *) + echo "Usage: ovirt-listen-awake {start|stop|restart|status}" + exit 1 + ;; +esac +exit $RETVAL diff --git a/ovirt-listen-awake/ovirt-unconvert-host b/ovirt-listen-awake/ovirt-unconvert-host new file mode 100644 index 0000000..4f0b02d --- /dev/null +++ b/ovirt-listen-awake/ovirt-unconvert-host @@ -0,0 +1,32 @@ +#!/bin/bash + +. /etc/init.d/ovirt-functions + +PATH=$PATH:/sbin:/usr/sbin + +if [ $# -ne 0 ]; then + echo "Usage: ovirt-unconvert-host" + exit 1 +fi + +if [ ! -d $OVIRT_BACKUP_DIR ]; then + echo "The oVirt backup directory $OVIRT_BACKUP_DIR doesn't exist; can't" + echo "unconvert the host" + exit 2 +fi + +unbackup_file() { + # note that $1 will have a / on the front, so we don't need to add our own + cp -pf "$OVIRT_BACKUP_DIR$1" "$1" +} + +chkconfig ovirt-listen-awake off +chkconfig collectd off + +unbackup_file /etc/sysconfig/network +unbackup_file /etc/hosts +unbackup_file /etc/sysconfig/libvirtd +unbackup_file /etc/libvirt/qemu.conf +unbackup_file /etc/libvirt/libvirtd.conf +unbackup_file /etc/sasl2/libvirt.conf +unbackup_file /etc/sysconfig/iptables diff --git a/ovirt-node.spec b/ovirt-node.spec index 736338d..3274a3f 100644 --- a/ovirt-node.spec +++ b/ovirt-node.spec @@ -15,6 +15,8 @@ BuildRequires: libvirt-devel BuildRequires: dbus-devel hal-devel Requires: libvirt Requires: hal +Requires: collectd +Requires: cyrus-sasl-gssapi ExclusiveArch: %{ix86} x86_64 %define app_root %{_datadir}/%{name} @@ -23,6 +25,20 @@ ExclusiveArch: %{ix86} x86_64 Provides a series of daemons and support utilities to allow an oVirt Node to interact with the oVirt server. +%package stateless +Summary: The oVirt Node scripts for stateless +Group: Applications/System +Requires: %{name} = %{version}-%{release} +%description stateless +This package does configuration for a stateless oVirt Node. + +%package stateful +Summary: The oVirt node scripts for existing machines +Group: Applications/System +Requires: %{name} = %{version}-%{release} +%description stateful +This package does configuration for a stateful oVirt node. + %prep %setup -q @@ -44,6 +60,9 @@ make %{__install} -p -m0755 scripts/ovirt-awake %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-identify-node/ovirt-identify-node %{buildroot}%{_sbindir} %{__install} -p -m0755 ovirt-listen-awake/ovirt-listen-awake %{buildroot}%{_sbindir} +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-listen-awake.init %{buildroot}%{_initrddir}/ovirt-listen-awake +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-convert-host %{buildroot}%{_sbindir} +%{__install} -Dp -m0755 ovirt-listen-awake/ovirt-unconvert-host %{buildroot}%{_sbindir} %{__install} -p -m0644 scripts/ovirt-functions %{buildroot}%{_initrddir} %{__install} -p -m0755 scripts/ovirt-early %{buildroot}%{_initrddir} @@ -52,8 +71,6 @@ make %{__install} -p -m0644 scripts/collectd %{buildroot}%{_sysconfdir}/chkconfig.d %{__install} -p -m0644 scripts/collectd.conf.in %{buildroot}%{_sysconfdir} -%{__install} -p -m0755 scripts/kvm-ifup %{buildroot}%{_sysconfdir} -%{__install} -p -m0755 scripts/dhclient-exit-hooks %{buildroot}%{_sysconfdir} %{__install} -p -m0755 logrotate/ovirt-logrotate %{buildroot}%{_sysconfdir}/cron.hourly %{__install} -p -m0644 logrotate/ovirt-logrotate.conf %{buildroot}%{_sysconfdir}/logrotate.d @@ -63,40 +80,26 @@ echo "oVirt Node release %{version}-%{release}" > %{buildroot}%{_sysconfdir}/ovi %clean %{__rm} -rf %{buildroot} -%post +%post stateful +/sbin/chkconfig --add ovirt-listen-awake +# this is ugly; we need collectd to start *after* libvirtd, so we own the +# /etc/chkconfig.d/collectd file, and then have to re-define collectd here +/sbin/chkconfig --add collectd + +%post stateless /sbin/chkconfig --add ovirt-early /sbin/chkconfig ovirt-early on /sbin/chkconfig --add ovirt /sbin/chkconfig ovirt on /sbin/chkconfig --add ovirt-post /sbin/chkconfig ovirt-post on -/sbin/chkconfig --add collectd -/sbin/chkconfig collectd on - -# just to get a boot warning to shut up -touch /etc/resolv.conf - -# make libvirtd listen on the external interfaces -sed -i -e "s/^#\(LIBVIRTD_ARGS=\"--listen\"\).*/\1/" /etc/sysconfig/libvirtd -# set up qemu daemon to allow outside VNC connections -sed -i -e "s/^[[:space:]]*#[[:space:]]*\(vnc_listen = \"0.0.0.0\"\).*/\1/" \ - /etc/libvirt/qemu.conf - -# set up libvirtd to listen on TCP (for kerberos) -sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ - -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ - /etc/libvirt/libvirtd.conf +. /etc/init.d/ovirt-functions +ovirt_setup_libvirtd # make sure we don't autostart virbr0 on libvirtd startup rm -f /etc/libvirt/qemu/networks/autostart/default.xml -# with the new libvirt (0.4.0), make sure we we setup gssapi in the mech_list -if [ `egrep -c "^mech_list: gssapi" /etc/sasl2/libvirt.conf` -eq 0 ]; then - sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" /etc/sasl2/libvirt.conf - echo "mech_list: gssapi" >> /etc/sasl2/libvirt.conf -fi - # remove the /etc/krb5.conf file; it will be fetched on bootup rm -f /etc/krb5.conf @@ -120,25 +123,22 @@ cat < /etc/issue EOF cp -p /etc/issue /etc/issue.net -%preun +%preun stateless if [ "$1" = 0 ] ; then /sbin/chkconfig --del ovirt-early /sbin/chkconfig --del ovirt /sbin/chkconfig --del ovirt-post fi +%preun stateful +if [ "$1" = 0 ] ; then + /sbin/chkconfig --del ovirt-listen-awake +fi + %files %defattr(-,root,root,0755) %{_sbindir}/ovirt-awake %{_sbindir}/ovirt-identify-node -%{_sbindir}/ovirt-listen-awake -%{_initrddir}/ovirt-early -%{_initrddir}/ovirt -%{_initrddir}/ovirt-post -%{_sysconfdir}/kvm-ifup -%{_sysconfdir}/dhclient-exit-hooks -%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf -%config %{_sysconfdir}/cron.hourly/ovirt-logrotate %defattr(-,root,root,0644) %{_initrddir}/ovirt-functions %{_sysconfdir}/collectd.conf.in @@ -148,10 +148,26 @@ fi %doc ovirt-identify-node/AUTHOR ovirt-identify-node/ChangeLog %doc ovirt-identify-node/COPYING +%files stateful +%{_initrddir}/ovirt-listen-awake +%{_sbindir}/ovirt-listen-awake +%{_sbindir}/ovirt-convert-host +%{_sbindir}/ovirt-unconvert-host + +%files stateless +%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf +%config %{_sysconfdir}/cron.hourly/ovirt-logrotate +%{_initrddir}/ovirt-early +%{_initrddir}/ovirt +%{_initrddir}/ovirt-post + %changelog -* Mon Sep 8 2008 Jim Meyering - 0.92 0.6 +* Mon Sep 8 2008 Jim Meyering - 0.92 0.7 - Update ovirt-identify-node's build rule. +* Thu Aug 28 2008 Chris Lalancette - 0.92 0.6 +- Rewrite the whole spec to make sub-packages for stateless vs. stateful + * Fri Aug 22 2008 Chris Lalancette - 0.92 0.5 - Add the ovirt-listen-awake daemon to the RPM diff --git a/scripts/ovirt-functions b/scripts/ovirt-functions index 083e13d..6ea034a 100644 --- a/scripts/ovirt-functions +++ b/scripts/ovirt-functions @@ -5,6 +5,8 @@ OVIRT_LOGFILE=/var/log/ovirt.log # label of the oVirt partition OVIRT_LABEL=OVIRT +OVIRT_BACKUP_DIR=/var/lib/ovirt-backup + find_srv() { local dnsreply @@ -21,3 +23,27 @@ die() { echo "$@" 1>&2; failure; echo 1>&2; exit 1 } + +ovirt_setup_libvirtd() { + # just to get a boot warning to shut up + touch /etc/resolv.conf + + # make libvirtd listen on the external interfaces + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ + /etc/sysconfig/libvirtd + + # set up qemu daemon to allow outside VNC connections + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ + /etc/libvirt/qemu.conf + # set up libvirtd to listen on TCP (for kerberos) + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ + /etc/libvirt/libvirtd.conf + + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list + sasl_conf=/etc/sasl2/libvirt.conf + if ! grep -qE "^mech_list: gssapi" $sasl_conf ; then + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" $sasl_conf + echo "mech_list: gssapi" >> $sasl_conf + fi +} -- 1.5.4.1 From apevec at redhat.com Wed Sep 10 08:29:15 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 10 Sep 2008 10:29:15 +0200 Subject: [Ovirt-devel] [PATCH ovirt-appliance] add updates-newkey repo Message-ID: <1221035355-8211-1-git-send-email-apevec@redhat.com> Signed-off-by: Alan Pevec --- ovirt-appliance.spec | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index 0b15b30..2eebee8 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -36,11 +36,13 @@ if [ -n "%{?fedora_url}" ]; then cat > repos.ks << EOF repo --name=f%{fedora} --baseurl=%{fedora_url}/releases/%{fedora}/Everything/%{_arch}/os repo --name=f%{fedora}-updates --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch} +repo --name=f%{fedora}-updates-newkey --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch}.newkey EOF else cat > repos.ks << EOF repo --name=f%{fedora} --mirrorlist=%{fedora_mirror}?repo=fedora-%{fedora}&arch=%{_arch} repo --name=f%{fedora}-updates --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}&arch=%{_arch} +repo --name=f%{fedora}-updates-newkey --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}.newkey&arch=%{_arch} EOF fi -- 1.5.5.1 From apevec at redhat.com Wed Sep 10 08:30:23 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 10 Sep 2008 10:30:23 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node-image] add updates-newkey repo Message-ID: <1221035423-8870-1-git-send-email-apevec@redhat.com> Signed-off-by: Alan Pevec --- ovirt-node-image.spec | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec index 1615f4f..ba63b2a 100644 --- a/ovirt-node-image.spec +++ b/ovirt-node-image.spec @@ -42,11 +42,13 @@ if [ -n "%{?fedora_url}" ]; then cat > repos.ks << EOF repo --name=f%{fedora} --baseurl=%{fedora_url}/releases/%{fedora}/Everything/%{_arch}/os repo --name=f%{fedora}-updates --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch} +repo --name=f%{fedora}-updates-newkey --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch}.newkey EOF else cat > repos.ks << EOF repo --name=f%{fedora} --mirrorlist=%{fedora_mirror}?repo=fedora-%{fedora}&arch=%{_arch} repo --name=f%{fedora}-updates --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}&arch=%{_arch} +repo --name=f%{fedora}-updates-newkey --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}.newkey&arch=%{_arch} EOF fi -- 1.5.5.1 From mmorsi at redhat.com Wed Sep 10 11:04:02 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 07:04:02 -0400 Subject: [Ovirt-devel] [PATCH ovirt-node-image] add updates-newkey repo In-Reply-To: <1221035423-8870-1-git-send-email-apevec@redhat.com> References: <1221035423-8870-1-git-send-email-apevec@redhat.com> Message-ID: <48C7A9A2.6060605@redhat.com> Alan Pevec wrote: > Signed-off-by: Alan Pevec > --- > ovirt-node-image.spec | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec > index 1615f4f..ba63b2a 100644 > --- a/ovirt-node-image.spec > +++ b/ovirt-node-image.spec > @@ -42,11 +42,13 @@ if [ -n "%{?fedora_url}" ]; then > cat > repos.ks << EOF > repo --name=f%{fedora} --baseurl=%{fedora_url}/releases/%{fedora}/Everything/%{_arch}/os > repo --name=f%{fedora}-updates --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch} > +repo --name=f%{fedora}-updates-newkey --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch}.newkey > EOF > else > cat > repos.ks << EOF > repo --name=f%{fedora} --mirrorlist=%{fedora_mirror}?repo=fedora-%{fedora}&arch=%{_arch} > repo --name=f%{fedora}-updates --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}&arch=%{_arch} > +repo --name=f%{fedora}-updates-newkey --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}.newkey&arch=%{_arch} > EOF > fi > > Looks good, ACK. -Mo From mmorsi at redhat.com Wed Sep 10 11:04:06 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 07:04:06 -0400 Subject: [Ovirt-devel] [PATCH ovirt-appliance] add updates-newkey repo In-Reply-To: <1221035355-8211-1-git-send-email-apevec@redhat.com> References: <1221035355-8211-1-git-send-email-apevec@redhat.com> Message-ID: <48C7A9A6.3040608@redhat.com> Alan Pevec wrote: > Signed-off-by: Alan Pevec > --- > ovirt-appliance.spec | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec > index 0b15b30..2eebee8 100644 > --- a/ovirt-appliance.spec > +++ b/ovirt-appliance.spec > @@ -36,11 +36,13 @@ if [ -n "%{?fedora_url}" ]; then > cat > repos.ks << EOF > repo --name=f%{fedora} --baseurl=%{fedora_url}/releases/%{fedora}/Everything/%{_arch}/os > repo --name=f%{fedora}-updates --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch} > +repo --name=f%{fedora}-updates-newkey --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch}.newkey > EOF > else > cat > repos.ks << EOF > repo --name=f%{fedora} --mirrorlist=%{fedora_mirror}?repo=fedora-%{fedora}&arch=%{_arch} > repo --name=f%{fedora}-updates --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}&arch=%{_arch} > +repo --name=f%{fedora}-updates-newkey --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}.newkey&arch=%{_arch} > EOF > fi > > Looks good, ACK. -Mo From bguthro at virtualiron.com Wed Sep 10 12:06:46 2008 From: bguthro at virtualiron.com (Ben Guthro) Date: Wed, 10 Sep 2008 08:06:46 -0400 Subject: [Ovirt-devel] updates-newkey repo Message-ID: <48C7B856.8040609@virtualiron.com> I noticed that a changeset went in adding the "newkey" repos: http://git.et.redhat.com/?p=ovirt-node-image.git;a=commitdiff;h=60f8bd80b73af31cd9cbdbe757f7f17d04dd4aeb http://download.fedora.redhat.com/pub/fedora/linux/updates/9/ I'm wondering - what is the difference between these rsync dirs? We were syncing up against the x86_64 dir - do we need to sync up against both now to get the build to work when specifying FEDORA_URL as a fedora mirror? Ben From berrange at redhat.com Wed Sep 10 12:10:01 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Sep 2008 13:10:01 +0100 Subject: [Ovirt-devel] updates-newkey repo In-Reply-To: <48C7B856.8040609@virtualiron.com> References: <48C7B856.8040609@virtualiron.com> Message-ID: <20080910121001.GL2662@redhat.com> On Wed, Sep 10, 2008 at 08:06:46AM -0400, Ben Guthro wrote: > I noticed that a changeset went in adding the "newkey" repos: > http://git.et.redhat.com/?p=ovirt-node-image.git;a=commitdiff;h=60f8bd80b73af31cd9cbdbe757f7f17d04dd4aeb > > http://download.fedora.redhat.com/pub/fedora/linux/updates/9/ > > I'm wondering - what is the difference between these rsync dirs? > We were syncing up against the x86_64 dir - do we need to sync up > against both now to get the build to work when specifying FEDORA_URL as > a fedora mirror? This is related to the new Fedora updates repos following the security breach a few weeks back http://www.redhat.com/archives/fedora-announce-list/2008-September/msg00007.html Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From apevec at redhat.com Wed Sep 10 12:13:13 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 10 Sep 2008 14:13:13 +0200 Subject: [Ovirt-devel] Re: updates-newkey repo In-Reply-To: <48C7B856.8040609@virtualiron.com> References: <48C7B856.8040609@virtualiron.com> Message-ID: <48C7B9D9.70008@redhat.com> Ben Guthro wrote: > I noticed that a changeset went in adding the "newkey" repos: > http://git.et.redhat.com/?p=ovirt-node-image.git;a=commitdiff;h=60f8bd80b73af31cd9cbdbe757f7f17d04dd4aeb > > > http://download.fedora.redhat.com/pub/fedora/linux/updates/9/ > > I'm wondering - what is the difference between these rsync dirs? > We were syncing up against the x86_64 dir - do we need to sync up > against both now to get the build to work when specifying FEDORA_URL as > a fedora mirror? see https://www.redhat.com/archives/fedora-announce-list/2008-September/msg00007.html All Fedora packages were just resigned, so rsync against new repos should be fast, if package itself didn't change. From apevec at redhat.com Wed Sep 10 12:20:33 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 10 Sep 2008 14:20:33 +0200 Subject: [Ovirt-devel] Re: updates-newkey repo In-Reply-To: <48C7B9D9.70008@redhat.com> References: <48C7B856.8040609@virtualiron.com> <48C7B9D9.70008@redhat.com> Message-ID: <48C7BB91.6090407@redhat.com> Alan Pevec wrote: > All Fedora packages were just resigned, so rsync against new repos > should be fast, if package itself didn't change. To clarify: copy old updates RPMs to the new location and then start rsync against newkey repo From mmorsi at redhat.com Wed Sep 10 12:44:05 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 08:44:05 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-server] autobuild.sh In-Reply-To: <1221050645-17529-4-git-send-email-mmorsi@redhat.com> References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> <1221050645-17529-2-git-send-email-mmorsi@redhat.com> <1221050645-17529-3-git-send-email-mmorsi@redhat.com> <1221050645-17529-4-git-send-email-mmorsi@redhat.com> Message-ID: <1221050645-17529-5-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..259c82a --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,27 @@ +#!/bin/sh +#oVirt server autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +set -e +set -v + +echo "Running oVirt server Autobuild" +make publish + +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm -- 1.5.4.1 From mmorsi at redhat.com Wed Sep 10 12:44:04 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 08:44:04 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-release] autobuild.sh In-Reply-To: <1221050645-17529-3-git-send-email-mmorsi@redhat.com> References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> <1221050645-17529-2-git-send-email-mmorsi@redhat.com> <1221050645-17529-3-git-send-email-mmorsi@redhat.com> Message-ID: <1221050645-17529-4-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..e90c9d0 --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,27 @@ +#!/bin/sh +#oVirt release autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +set -e +set -v + +echo "Running oVirt Release Autobuild" +make publish + +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm -- 1.5.4.1 From mmorsi at redhat.com Wed Sep 10 12:44:03 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 08:44:03 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-node-image] autobuild.sh In-Reply-To: <1221050645-17529-2-git-send-email-mmorsi@redhat.com> References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> <1221050645-17529-2-git-send-email-mmorsi@redhat.com> Message-ID: <1221050645-17529-3-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..0f8cd40 --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,27 @@ +#!/bin/sh +#oVirt node image autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +set -e +set -v + +echo "Running oVirt node image Autobuild" +make publish + +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm -- 1.5.4.1 From mmorsi at redhat.com Wed Sep 10 12:44:01 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 08:44:01 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-appliance] autobuild.sh Message-ID: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 101 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 101 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..0228fde --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,101 @@ +#!/bin/sh +#oVirt appliance autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +set -e +set -v + +ME=$(basename "$0") +warn() { printf "$ME: $@\n" >&2; } +die() { warn "$@"; exit 1; } + +test -n "$1" && RESULTS=$1 || RESULTS=results.log + +SSHKEY=~/.ssh/id_autobuild +remote_target="root at 192.168.50.2" +ssh_cmd="ssh -i $SSHKEY -o StrictHostKeyChecking=no \ + -o UserKnownHostsFile=/dev/null $remote_target" +scp_cmd="scp -i $SSHKEY -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" + +# implant Autobuild SSH key into appliance +if [ ! -r $SSHKEY ]; then + mkdir -p $(dirname "$SSHKEY") + ssh-keygen -q -t rsa -N "" -f $SSHKEY +fi + +cat >> common-post.ks << KS +mkdir -p /root/.ssh +chmod 700 /root/.ssh +cat > /root/.ssh/authorized_keys << \EOF +$(ssh-keygen -y -f $SSHKEY) +EOF +chmod 600 /root/.ssh/authorized_keys +KS + +# move sshd to start last (after ovirt*first-run scripts) +cat >> common-post.ks << \KS +mkdir -p /etc/chkconfig.d +cat > /etc/chkconfig.d/sshd << \EOF +# chkconfig: 2345 99 01 +EOF +chkconfig --override sshd +KS + +echo "Running oVirt Appliance Autobuild" +make publish + +# make resulting rpms publically available +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm + +# install the rpm, create appliance, and start the appliance / node3 +rpm -qi ovirt-appliance +if [ "$?" -eq 0 ]; then + rpm -e ovirt-appliance +fi +rpm -ivh rpm-build/ovirt-appliance-0.92-1.fc9.x86_64.rpm +/usr/sbin/create-ovirt-appliance +virsh start node3 \ + || die "virsh start failed, node3 not started" +virsh start ovirt-appliance \ + || die "virsh start failed, appliance not started" + +# wait until started +for i in $(seq 1 60); do + $ssh_cmd exit && break + sleep 10 +done + +SELENIUM_RB=/var/selenium/selenium.rb +if [ -f $SELENIUM_RB ]; then + $scp_cmd $SELENIUM_RB $remote_target:/usr/share/ovirt-server/test/ +else + echo "$SELENIUM_RB not found, will not run interface tests" +fi + +echo "Running the server tests" +$ssh_cmd \ + "sed -i \"s/#RAILS_ENV=production/RAILS_ENV=test/g\" /etc/sysconfig/ovirt-rails && \ + sed -i \"s/development/test/\" /usr/share/ovirt-server/dutils/active_record_env.rb && \ + service ovirt-taskomatic restart && \ + service ovirt-mongrel-rails restart && \ + service httpd restart && \ + curl -i http://management.priv.ovirt.org/ovirt/ | \ + grep 'HTTP/1.1 200 OK' && \ + cd /usr/share/ovirt-server && rake test" > "$RESULTS" 2>&1 \ + || die "server tests failed" -- 1.5.4.1 From mmorsi at redhat.com Wed Sep 10 12:44:02 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 08:44:02 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh In-Reply-To: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> Message-ID: <1221050645-17529-2-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 29 +++++++++++++++++++++++++++++ 1 files changed, 29 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..835212e --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,29 @@ +#!/bin/sh +#oVirt node autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +set -e +set -v + +echo "Running oVirt Node Autobuild" +./autogen.sh --prefix=$AUTOBUILD_INSTALL_ROOT +./configure +make publish + +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm -- 1.5.4.1 From berrange at redhat.com Wed Sep 10 12:54:57 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Sep 2008 13:54:57 +0100 Subject: [Ovirt-devel] [PATCH] [ovirt-release] autobuild.sh In-Reply-To: <1221050645-17529-4-git-send-email-mmorsi@redhat.com> References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> <1221050645-17529-2-git-send-email-mmorsi@redhat.com> <1221050645-17529-3-git-send-email-mmorsi@redhat.com> <1221050645-17529-4-git-send-email-mmorsi@redhat.com> Message-ID: <20080910125457.GM2662@redhat.com> On Wed, Sep 10, 2008 at 08:44:04AM -0400, Mohammed Morsi wrote: > --- > autobuild.sh | 27 +++++++++++++++++++++++++++ > 1 files changed, 27 insertions(+), 0 deletions(-) > create mode 100755 autobuild.sh > > diff --git a/autobuild.sh b/autobuild.sh > new file mode 100755 > index 0000000..e90c9d0 > --- /dev/null > +++ b/autobuild.sh > @@ -0,0 +1,27 @@ > +#!/bin/sh > +#oVirt release autobuild script > +# > +# Copyright (C) 2008 Red Hat, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301, USA. A copy of the GNU General Public License is > +# also available at http://www.gnu.org/copyleft/gpl.html. > + > +set -e > +set -v > + > +echo "Running oVirt Release Autobuild" > +make publish > + > +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm This is wrong. 'make publish' creates a YUM repo which is not what we want. Autobuild takes care of that. All you should be doing is building the RPM and putting it into $AUTOBUILD_PACKAGE_ROOT. Furthermore if you it shoudln't call 'make rpms' either - invoke rpmbuild directly and ensure the autobuild user account has a .rpmmacros pointing to the $AUTOBUILD_PACKAGE_ROOT. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Sep 10 12:55:23 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Sep 2008 13:55:23 +0100 Subject: [Ovirt-devel] [PATCH] [ovirt-server] autobuild.sh In-Reply-To: <1221050645-17529-5-git-send-email-mmorsi@redhat.com> References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> <1221050645-17529-2-git-send-email-mmorsi@redhat.com> <1221050645-17529-3-git-send-email-mmorsi@redhat.com> <1221050645-17529-4-git-send-email-mmorsi@redhat.com> <1221050645-17529-5-git-send-email-mmorsi@redhat.com> Message-ID: <20080910125523.GN2662@redhat.com> On Wed, Sep 10, 2008 at 08:44:05AM -0400, Mohammed Morsi wrote: > --- > autobuild.sh | 27 +++++++++++++++++++++++++++ > 1 files changed, 27 insertions(+), 0 deletions(-) > create mode 100755 autobuild.sh > > diff --git a/autobuild.sh b/autobuild.sh > new file mode 100755 > index 0000000..259c82a > --- /dev/null > +++ b/autobuild.sh > @@ -0,0 +1,27 @@ > +#!/bin/sh > +#oVirt server autobuild script > +# > +# Copyright (C) 2008 Red Hat, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301, USA. A copy of the GNU General Public License is > +# also available at http://www.gnu.org/copyleft/gpl.html. > + > +set -e > +set -v > + > +echo "Running oVirt server Autobuild" > +make publish > + > +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm Same comments as other similar autobuild.sh. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Sep 10 12:59:03 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Sep 2008 13:59:03 +0100 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh In-Reply-To: <1221050645-17529-2-git-send-email-mmorsi@redhat.com> References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> <1221050645-17529-2-git-send-email-mmorsi@redhat.com> Message-ID: <20080910125903.GO2662@redhat.com> On Wed, Sep 10, 2008 at 08:44:02AM -0400, Mohammed Morsi wrote: > --- > autobuild.sh | 29 +++++++++++++++++++++++++++++ > 1 files changed, 29 insertions(+), 0 deletions(-) > create mode 100755 autobuild.sh > > diff --git a/autobuild.sh b/autobuild.sh > new file mode 100755 > index 0000000..835212e > --- /dev/null > +++ b/autobuild.sh > @@ -0,0 +1,29 @@ > +#!/bin/sh > +#oVirt node autobuild script > +# > +# Copyright (C) 2008 Red Hat, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301, USA. A copy of the GNU General Public License is > +# also available at http://www.gnu.org/copyleft/gpl.html. > + > +set -e > +set -v > + > +echo "Running oVirt Node Autobuild" > +./autogen.sh --prefix=$AUTOBUILD_INSTALL_ROOT > +./configure autogen.sh will run configure - running it again is blowing away the --prefix you set a line earlier. You should also 'make', (possibly 'make test') and 'make install' > +make publish > + > +ln -f rpm-build/*.rpm $AUTOBUILD_PACKAGE_ROOT/rpm Same comments as per other modules Basically I expect that autobuild.sh for any autotools based app should look pretty much like this: http://gtk-vnc.codemonkey.ws/hg/outgoing.hg/file/f1d5c8fae2e9/autobuild.sh Add in a 'make test' command before 'make install' if the app has a test suite Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jim at meyering.net Wed Sep 10 13:59:42 2008 From: jim at meyering.net (Jim Meyering) Date: Wed, 10 Sep 2008 15:59:42 +0200 Subject: [Ovirt-devel] [PATCH-node 2/2] A rather large re-write of the ovirt-node.spec file. The reason In-Reply-To: <1221028933-16058-3-git-send-email-clalance@redhat.com> (Chris Lalancette's message of "Wed, 10 Sep 2008 08:42:13 +0200") References: <1221028933-16058-1-git-send-email-clalance@redhat.com> <1221028933-16058-3-git-send-email-clalance@redhat.com> Message-ID: <87prncxfsh.fsf@rho.meyering.net> Chris Lalancette wrote: > diff --git a/ovirt-listen-awake/ovirt-convert-host b/ovirt-listen-awake/ovirt-convert-host > new file mode 100644 > index 0000000..584291a > --- /dev/null > +++ b/ovirt-listen-awake/ovirt-convert-host > @@ -0,0 +1,58 @@ > +#!/bin/bash > + > +. /etc/init.d/ovirt-functions > + > +PATH=$PATH:/sbin:/usr/sbin > + > +if [ $# -ne 0 ]; then > + echo "Usage: ovirt-convert-host" > + exit 1 > +fi > + > +backup_file() { > + dir=$(dirname "$1") > + case $dir in /*);; *) die "unexpected non-absolute dir: $dir";; esac > + mkdir -p "$OVIRT_BACKUP_DIR/${dir:1}" > + cp -pf "$1" "$OVIRT_BACKUP_DIR/${dir:1}" Now that you ensure $dir starts with "/", you can replace each of the /${dir:1} with $dir. Not only is that more readable (I don't have to look up ${VAR:1} syntax in the bash manual ;-), but you avoid the bash-ism. > +} > + > +add_if_not_exist() { > + string="$1" > + file="$2" > + > + grep -qE "^[[:space:]]*$string($|#|[[:space:]])" "$file" \ > + || echo "$string" >> "$file" > +} Good idea to make this into a function! However, regexp-special characters (like ".", "*", etc.) in $string must be escaped for use as the grep regexp. In the existing uses, only "." needs to be escaped, but might as well escape them all, in case someone copies the code to use elsewhere. I think the sed command below will do it (please double check!). Also, using printf is slightly safer that echo, in case someone ever applies this function to strings containing a \c sequence that's interpreted by echo: Note the new function name and no double quotes needed on assignment with a simple RHS: add_if_missing() { string=$1 file=$2 # backslash-escape regexp-special characters in the string string_re=$(printf %s "$string"|sed 's,\([][|?{}\.+()*]\),\\\1,g') grep -qE "^[[:space:]]*$string_re($|#|[[:space:]])" "$file" \ || printf '%s\n' "$string" >> "$file" } > +echo "This script will make a number of changes to your system to enable it to" > +echo "work as an oVirt node. You can later undo these changes by" > +echo "running /usr/sbin/ovirt-unconvert-host. Do you want to proceed? [y/N]?" > +read yesno ... > diff --git a/scripts/ovirt-functions b/scripts/ovirt-functions > index 083e13d..6ea034a 100644 > --- a/scripts/ovirt-functions > +++ b/scripts/ovirt-functions > @@ -5,6 +5,8 @@ OVIRT_LOGFILE=/var/log/ovirt.log > # label of the oVirt partition > OVIRT_LABEL=OVIRT > > +OVIRT_BACKUP_DIR=/var/lib/ovirt-backup > + > find_srv() > { > local dnsreply > @@ -21,3 +23,27 @@ die() > { > echo "$@" 1>&2; failure; echo 1>&2; exit 1 > } > + > +ovirt_setup_libvirtd() { > + # just to get a boot warning to shut up > + touch /etc/resolv.conf > + > + # make libvirtd listen on the external interfaces > + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ > + /etc/sysconfig/libvirtd > + > + # set up qemu daemon to allow outside VNC connections > + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ > + /etc/libvirt/qemu.conf > + # set up libvirtd to listen on TCP (for kerberos) > + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ > + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ > + /etc/libvirt/libvirtd.conf > + > + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list > + sasl_conf=/etc/sasl2/libvirt.conf > + if ! grep -qE "^mech_list: gssapi" $sasl_conf ; then > + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" $sasl_conf > + echo "mech_list: gssapi" >> $sasl_conf > + fi Everything else looks ok, though using double quotes above in echo and sed is unnecessary and a little bit fragile -- and not consistent with use of single quotes in the two prior sed commands... From jim at meyering.net Wed Sep 10 14:17:30 2008 From: jim at meyering.net (Jim Meyering) Date: Wed, 10 Sep 2008 16:17:30 +0200 Subject: [Ovirt-devel] [PATCH-node 1/2] Add ovirt-listen-awake daemon. This is a very small daemon that oVirt In-Reply-To: <1221028933-16058-2-git-send-email-clalance@redhat.com> (Chris Lalancette's message of "Wed, 10 Sep 2008 08:42:12 +0200") References: <1221028933-16058-1-git-send-email-clalance@redhat.com> <1221028933-16058-2-git-send-email-clalance@redhat.com> Message-ID: <87k5dkxeyt.fsf@rho.meyering.net> Chris Lalancette wrote: ... > diff --git a/ovirt-listen-awake/ovirt-listen-awake.c b/ovirt-listen-awake/ovirt-listen-awake.c ... > +static void usage(int exitcode) > +{ > + printf("Usage: ovirt-listen-awake [OPTIONS]\n"); > + printf("OPTIONS:\n"); > + printf(" -h\t\tShow this help message\n"); > + printf(" -n\t\tDo not daemonize (useful for debugging)\n"); > + exit(exitcode); > +} > + > +int main(int argc, char *argv[]) > +{ > + int listen_socket, conn; > + struct sockaddr_in client_address; > + unsigned int addrlen; > + FILE *conn_stream; > + FILE *logfile; > + char buffer[BUFLEN]; > + int c; > + int do_daemon; > + int i; > + > + do_daemon = 1; > + > + while ((c=getopt(argc, argv, ":hn")) != -1) { > + switch(c) { > + case 'h': > + usage(0); > + break; > + case 'n': > + do_daemon = 0; > + break; > + default: > + usage(1); > + } > + } > + > + if ((argc-optind) != 0) { > + for (i = optind; i < argc ; i ++) { > + fprintf(stderr, "Extra operand %s\n", argv[i]); > + } > + error(1, 0, "Try --help for more information"); s/--help/-h/ (or overkill: switch to getopt_long and accept --help) > + } > + > + listen_socket = listenSocket(7777); > + if (listen_socket < 0) > + return 2; > + > + if (do_daemon) { > + logfile = fopen(LOGFILE,"a+"); > + if (logfile == NULL) > + error(3, errno, "Error opening logfile %s", LOGFILE); > + > + // NOTE: this closes stdout and stderr > + if (daemon(0, 0) < 0) > + error(4, errno, "Error daemonizing"); > + > + // so re-open them to the logfile here > + dup2(fileno(logfile), STDOUT_FILENO); > + dup2(fileno(logfile), STDERR_FILENO); Oops. I missed this the first time around. Each of these dup2 calls can fail, so best to check for that. > + } > + > + while (1) { > + addrlen = sizeof(client_address); > + memset(&client_address, 0, addrlen); > + memset(buffer, 0, BUFLEN); This use of memset still looks unnecessary. ... > + } > + > + close(listen_socket); > + fclose(logfile); How about detecting write failure (e.g., disk full): if (fclose (logfile) != 0) return 1; > + return 0; > +} > diff --git a/ovirt-node.spec b/ovirt-node.spec ... From mmorsi at redhat.com Wed Sep 10 18:30:47 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 14:30:47 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh Message-ID: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 43 +++++++++++++++++++++++++++++++++++++++++++ autogen.sh | 1 + 2 files changed, 44 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..a1a1fd0 --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,43 @@ +#!/bin/sh +#oVirt node autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +echo "Running oVirt Node Autobuild" + +set -e +set -v + +test -f Makefile && make -k distclean || : + +./autogen.sh --prefix=$AUTOBUILD_INSTALL_ROOT +make +make install + +rm -f *.tar.gz +make dist + +if [ -f /usr/bin/rpmbuild ]; then + if [ -n "$AUTOBUILD_COUNTER" ]; then + EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER" + else + NOW=`date +"%s"` + EXTRA_RELEASE=".$USER$NOW" + fi + rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" -ta --clean *.tar.gz +fi diff --git a/autogen.sh b/autogen.sh index 85352f0..b8828fe 100755 --- a/autogen.sh +++ b/autogen.sh @@ -49,6 +49,7 @@ THEDIR=`pwd` autoheader automake --add-missing autoconf + ./configure "$@" ) if test "x$OBJ_DIR" != x; then -- 1.5.4.1 From mmorsi at redhat.com Wed Sep 10 18:30:48 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 14:30:48 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-release] autobuild.sh In-Reply-To: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> References: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> Message-ID: <1221071449-3173-2-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 42 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..b8290a0 --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,42 @@ +#!/bin/sh +#oVirt release autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +echo "Running oVirt Release Autobuild" + +set -e +set -v + +test -f Makefile && make -k distclean || : + +if [ -f /usr/bin/rpmbuild ]; then + if [ -n "$AUTOBUILD_COUNTER" ]; then + EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER" + else + NOW=`date +"%s"` + EXTRA_RELEASE=".$USER$NOW" + fi + # manually copy files over until we have an autotools + # generated tarball to base rpmbuild on + cp version $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ + cp ovirt.repo $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ + cp ovirt.mk $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ + + rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" -ba --clean ovirt-release.spec +fi -- 1.5.4.1 From mmorsi at redhat.com Wed Sep 10 18:30:49 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Wed, 10 Sep 2008 14:30:49 -0400 Subject: [Ovirt-devel] [PATCH] [ovirt-server] autobuild.sh In-Reply-To: <1221071449-3173-2-git-send-email-mmorsi@redhat.com> References: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> <1221071449-3173-2-git-send-email-mmorsi@redhat.com> Message-ID: <1221071449-3173-3-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 43 insertions(+), 0 deletions(-) create mode 100755 autobuild.sh diff --git a/autobuild.sh b/autobuild.sh new file mode 100755 index 0000000..eaaf5f4 --- /dev/null +++ b/autobuild.sh @@ -0,0 +1,43 @@ +#!/bin/sh +#oVirt server autobuild script +# +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +echo "Running oVirt server Autobuild" + +set -e +set -v + +test -f Makefile && make -k distclean || : + +make tar + +if [ -f /usr/bin/rpmbuild ]; then + if [ -n "$AUTOBUILD_COUNTER" ]; then + EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER" + else + NOW=`date +"%s"` + EXTRA_RELEASE=".$USER$NOW" + fi + # manually copy files over until we have an autotools + # generated tarball to base rpmbuild on + cp version $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ + cp rpm-build/ovirt-server-0.92.tar.gz $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ + + rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" -ba --clean ovirt-server.spec +fi -- 1.5.4.1 From lutter at redhat.com Wed Sep 10 20:11:57 2008 From: lutter at redhat.com (David Lutterkort) Date: Wed, 10 Sep 2008 13:11:57 -0700 Subject: [Ovirt-devel] [PATCH-node 2/2] A rather large re-write of the ovirt-node.spec file. The reason In-Reply-To: <1221028933-16058-3-git-send-email-clalance@redhat.com> References: <1221028933-16058-1-git-send-email-clalance@redhat.com> <1221028933-16058-3-git-send-email-clalance@redhat.com> Message-ID: <1221077517.12330.84.camel@localhost.localdomain> On Wed, 2008-09-10 at 08:42 +0200, Chris Lalancette wrote: > + > +ovirt_setup_libvirtd() { > + # just to get a boot warning to shut up > + touch /etc/resolv.conf > + > + # make libvirtd listen on the external interfaces > + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ > + /etc/sysconfig/libvirtd > + > + # set up qemu daemon to allow outside VNC connections > + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ > + /etc/libvirt/qemu.conf > + # set up libvirtd to listen on TCP (for kerberos) > + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ > + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ > + /etc/libvirt/libvirtd.conf > + > + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list > + sasl_conf=/etc/sasl2/libvirt.conf > + if ! grep -qE "^mech_list: gssapi" $sasl_conf ; then > + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" $sasl_conf > + echo "mech_list: gssapi" >> $sasl_conf > + fi > +} Why not just augtool < References: <1221028933-16058-1-git-send-email-clalance@redhat.com> <1221028933-16058-3-git-send-email-clalance@redhat.com> <1221077517.12330.84.camel@localhost.localdomain> Message-ID: <20080910202429.GB6249@redhat.com> On Wed, Sep 10, 2008 at 01:11:57PM -0700, David Lutterkort wrote: > On Wed, 2008-09-10 at 08:42 +0200, Chris Lalancette wrote: > > + > > +ovirt_setup_libvirtd() { > > + # just to get a boot warning to shut up > > + touch /etc/resolv.conf > > + > > + # make libvirtd listen on the external interfaces > > + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ > > + /etc/sysconfig/libvirtd > > + > > + # set up qemu daemon to allow outside VNC connections > > + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ > > + /etc/libvirt/qemu.conf > > + # set up libvirtd to listen on TCP (for kerberos) > > + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ > > + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ > > + /etc/libvirt/libvirtd.conf > > + > > + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list > > + sasl_conf=/etc/sasl2/libvirt.conf > > + if ! grep -qE "^mech_list: gssapi" $sasl_conf ; then > > + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" $sasl_conf > > + echo "mech_list: gssapi" >> $sasl_conf > > + fi > > +} > > Why not just > > augtool < set /files/etc/sysconfig/libvirtd/LIBVIRTD_ARGS --listen > set /files/etc/libvirt/qemu.conf/vnc_listen 0.0.0.0 > set /files/etc/libvirt/libvirtd.conf/listen_tcp 1 > set /files/etc/libvirt/libvirtd.conf/listen_tls 0 > set /files/etc/sasl2/libvirt.conf/mech_list gssapi > save > EOF > > It'll actually need some minor love in Augeas to make that work, but if > you want to go that route, I can add that very easily. Yes, if you update to libvirt 0.4.5 the augeas definitions are all there as standard for both qemu.conf and libvirtd.conf. I think augeas has generic handling for sysconfig files ? If not it'd be trivial to add the libvirtd sysconfig file too. Not sure about sasl configs ? Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From lutter at redhat.com Wed Sep 10 20:31:54 2008 From: lutter at redhat.com (David Lutterkort) Date: Wed, 10 Sep 2008 13:31:54 -0700 Subject: [Ovirt-devel] [PATCH-node 2/2] A rather large re-write of the ovirt-node.spec file. The reason In-Reply-To: <20080910202429.GB6249@redhat.com> References: <1221028933-16058-1-git-send-email-clalance@redhat.com> <1221028933-16058-3-git-send-email-clalance@redhat.com> <1221077517.12330.84.camel@localhost.localdomain> <20080910202429.GB6249@redhat.com> Message-ID: <1221078714.12330.85.camel@localhost.localdomain> On Wed, 2008-09-10 at 21:24 +0100, Daniel P. Berrange wrote: > On Wed, Sep 10, 2008 at 01:11:57PM -0700, David Lutterkort wrote: > > Why not just > > > > augtool < > set /files/etc/sysconfig/libvirtd/LIBVIRTD_ARGS --listen > > set /files/etc/libvirt/qemu.conf/vnc_listen 0.0.0.0 > > set /files/etc/libvirt/libvirtd.conf/listen_tcp 1 > > set /files/etc/libvirt/libvirtd.conf/listen_tls 0 > > set /files/etc/sasl2/libvirt.conf/mech_list gssapi > > save > > EOF > > > > It'll actually need some minor love in Augeas to make that work, but if > > you want to go that route, I can add that very easily. > > Yes, if you update to libvirt 0.4.5 the augeas definitions are all > there as standard for both qemu.conf and libvirtd.conf. I think augeas > has generic handling for sysconfig files ? If not it'd be trivial to > add the libvirtd sysconfig file too. Not sure about sasl configs ? The sysconfig file is there, the 'minor love' is the sasl config. David From clalance at redhat.com Thu Sep 11 07:56:49 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 11 Sep 2008 09:56:49 +0200 Subject: [Ovirt-devel] [PATCH-node 2/2] A rather large re-write of the ovirt-node.spec file. The reason In-Reply-To: <1221077517.12330.84.camel@localhost.localdomain> References: <1221028933-16058-1-git-send-email-clalance@redhat.com> <1221028933-16058-3-git-send-email-clalance@redhat.com> <1221077517.12330.84.camel@localhost.localdomain> Message-ID: <48C8CF41.5010501@redhat.com> David Lutterkort wrote: > On Wed, 2008-09-10 at 08:42 +0200, Chris Lalancette wrote: >> + >> +ovirt_setup_libvirtd() { >> + # just to get a boot warning to shut up >> + touch /etc/resolv.conf >> + >> + # make libvirtd listen on the external interfaces >> + sed -i -e 's/^#\(LIBVIRTD_ARGS="--listen"\).*/\1/' \ >> + /etc/sysconfig/libvirtd >> + >> + # set up qemu daemon to allow outside VNC connections >> + sed -i -e 's/^[[:space:]]*#[[:space:]]*\(vnc_listen = "0.0.0.0"\).*/\1/' \ >> + /etc/libvirt/qemu.conf >> + # set up libvirtd to listen on TCP (for kerberos) >> + sed -i -e "s/^[[:space:]]*#[[:space:]]*\(listen_tcp\)\>.*/\1 = 1/" \ >> + -e "s/^[[:space:]]*#[[:space:]]*\(listen_tls\)\>.*/\1 = 0/" \ >> + /etc/libvirt/libvirtd.conf >> + >> + # with libvirt (0.4.0), make sure we we setup gssapi in the mech_list >> + sasl_conf=/etc/sasl2/libvirt.conf >> + if ! grep -qE "^mech_list: gssapi" $sasl_conf ; then >> + sed -i -e "s/^\([[:space:]]*mech_list.*\)/#\1/" $sasl_conf >> + echo "mech_list: gssapi" >> $sasl_conf >> + fi >> +} > > Why not just > > augtool < set /files/etc/sysconfig/libvirtd/LIBVIRTD_ARGS --listen > set /files/etc/libvirt/qemu.conf/vnc_listen 0.0.0.0 > set /files/etc/libvirt/libvirtd.conf/listen_tcp 1 > set /files/etc/libvirt/libvirtd.conf/listen_tls 0 > set /files/etc/sasl2/libvirt.conf/mech_list gssapi > save > EOF > > It'll actually need some minor love in Augeas to make that work, but if > you want to go that route, I can add that very easily. That's totally fine with me, assuming the relevant code is in the ovirt repositories or in F-9. If not, I'm fine with doing this long term, but for the moment I would prefer to not have to carry more custom packages then we already are. -- Chris Lalancette From clalance at redhat.com Thu Sep 11 09:21:45 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 11 Sep 2008 11:21:45 +0200 Subject: [Ovirt-devel] Allow WUI to manage itself mostly committed Message-ID: <48C8E329.5010703@redhat.com> All, I've committed most of the parts of the "WUI manage itself" patch series, just so I don't keep carrying them out of tree. Two parts are still missing: 1) I didn't address *all* of Jim's comments about ovirt-listen-awake. I'll get to that probably later today. 2) I haven't changed the ovirt-node spec file to have separate scripts for stateful vs. stateless. I'll also do that today. I'll post patches for the above two once they are done. -- Chris Lalancette From clalance at redhat.com Thu Sep 11 09:29:19 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 11 Sep 2008 11:29:19 +0200 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh In-Reply-To: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> References: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> Message-ID: <48C8E4EF.8090202@redhat.com> Mohammed Morsi wrote: > diff --git a/autogen.sh b/autogen.sh > index 85352f0..b8828fe 100755 > --- a/autogen.sh > +++ b/autogen.sh > @@ -49,6 +49,7 @@ THEDIR=`pwd` > autoheader > automake --add-missing > autoconf > + ./configure "$@" > ) Dunno anything about autobuild.sh, so I'll skip that for now. For autogen.sh, we might want to follow the pattern of libvirt; the reason (I believe) is so that you can build into a different subdirectory. The pattern is basically: srcdir=`dirname $0` test -z "$srcdir" && srcdir=. THEDIR=`pwd` cd $srcdir ... automake autoconf cd $THEDIR $srcdir/configure "$@" && { echo echo "Now type 'make' to compile libvirt." I'll ACK a patch that does essentially that. -- Chris Lalancette From jim at meyering.net Thu Sep 11 09:35:04 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 11:35:04 +0200 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh In-Reply-To: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> (Mohammed Morsi's message of "Wed, 10 Sep 2008 14:30:47 -0400") References: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> Message-ID: <87iqt3m3ef.fsf@rho.meyering.net> Mohammed Morsi wrote: > --- > autobuild.sh | 43 +++++++++++++++++++++++++++++++++++++++++++ > autogen.sh | 1 + > 2 files changed, 44 insertions(+), 0 deletions(-) > create mode 100755 autobuild.sh > > diff --git a/autobuild.sh b/autobuild.sh > new file mode 100755 > index 0000000..a1a1fd0 > --- /dev/null > +++ b/autobuild.sh > @@ -0,0 +1,43 @@ > +#!/bin/sh > +#oVirt node autobuild script > +# > +# Copyright (C) 2008 Red Hat, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301, USA. A copy of the GNU General Public License is > +# also available at http://www.gnu.org/copyleft/gpl.html. > + > +echo "Running oVirt Node Autobuild" > + > +set -e > +set -v > + > +test -f Makefile && make -k distclean || : > + > +./autogen.sh --prefix=$AUTOBUILD_INSTALL_ROOT > +make > +make install > + > +rm -f *.tar.gz > +make dist > + > +if [ -f /usr/bin/rpmbuild ]; then > + if [ -n "$AUTOBUILD_COUNTER" ]; then > + EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER" > + else > + NOW=`date +"%s"` > + EXTRA_RELEASE=".$USER$NOW" > + fi > + rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" -ta --clean *.tar.gz > +fi > diff --git a/autogen.sh b/autogen.sh > index 85352f0..b8828fe 100755 > --- a/autogen.sh > +++ b/autogen.sh > @@ -49,6 +49,7 @@ THEDIR=`pwd` > autoheader > automake --add-missing > autoconf > + ./configure "$@" > ) > > if test "x$OBJ_DIR" != x; then ACK In fact, all three of these new autobuild.sh files look fine. The only thing is that they're so alike. Eventually (once a few more packages have been autoconfiscated), I expect we'll want them to be identical, no? Thanks for adding the ./configure. From berrange at redhat.com Thu Sep 11 09:41:51 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 11 Sep 2008 10:41:51 +0100 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh In-Reply-To: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> References: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> Message-ID: <20080911094151.GC29353@redhat.com> On Wed, Sep 10, 2008 at 02:30:47PM -0400, Mohammed Morsi wrote: > --- > autobuild.sh | 43 +++++++++++++++++++++++++++++++++++++++++++ > autogen.sh | 1 + > 2 files changed, 44 insertions(+), 0 deletions(-) > create mode 100755 autobuild.sh > > diff --git a/autobuild.sh b/autobuild.sh > new file mode 100755 > index 0000000..a1a1fd0 > --- /dev/null > +++ b/autobuild.sh > @@ -0,0 +1,43 @@ > +#!/bin/sh > +#oVirt node autobuild script > +# > +# Copyright (C) 2008 Red Hat, Inc. > +# > +# This program is free software; you can redistribute it and/or modify > +# it under the terms of the GNU General Public License as published by > +# the Free Software Foundation; version 2 of the License. > +# > +# This program is distributed in the hope that it will be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write to the Free Software > +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, > +# MA 02110-1301, USA. A copy of the GNU General Public License is > +# also available at http://www.gnu.org/copyleft/gpl.html. > + > +echo "Running oVirt Node Autobuild" > + > +set -e > +set -v > + > +test -f Makefile && make -k distclean || : > + > +./autogen.sh --prefix=$AUTOBUILD_INSTALL_ROOT > +make > +make install > + > +rm -f *.tar.gz > +make dist > + > +if [ -f /usr/bin/rpmbuild ]; then > + if [ -n "$AUTOBUILD_COUNTER" ]; then > + EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER" > + else > + NOW=`date +"%s"` > + EXTRA_RELEASE=".$USER$NOW" > + fi > + rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" -ta --clean *.tar.gz You're missing the corresponding change in the specfile to actually do something with the extra_release, eg change Release: %(echo `awk '{ print $2 }' %{SOURCE1}`)%{?dist} to Release: %(echo `awk '{ print $2 }' %{SOURCE1}`)%{?dist}%{?extra_release} ACK to all these autobuild.sh files though. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Thu Sep 11 09:43:41 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 11 Sep 2008 10:43:41 +0100 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh In-Reply-To: <87iqt3m3ef.fsf@rho.meyering.net> References: <1221071449-3173-1-git-send-email-mmorsi@redhat.com> <87iqt3m3ef.fsf@rho.meyering.net> Message-ID: <20080911094341.GD29353@redhat.com> On Thu, Sep 11, 2008 at 11:35:04AM +0200, Jim Meyering wrote: > Mohammed Morsi wrote: > > > ACK > In fact, all three of these new autobuild.sh files look fine. > The only thing is that they're so alike. > Eventually (once a few more packages have been autoconfiscated), > I expect we'll want them to be identical, no? I intend to address this need in autobuild itself, but adding a concept of generic control file templates. So you'll just declare what 'features' your app's build system has, and autobiuld will 'do the right thing'. So as an example you'll say features = autotools, rpm And it'll generate a control file to do standard autotools based build and test, and also invoke an RPM build cycle. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jim at meyering.net Thu Sep 11 09:46:30 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 11:46:30 +0200 Subject: [Ovirt-devel] [PATCH] [ovirt-node] autobuild.sh In-Reply-To: <20080910125903.GO2662@redhat.com> (Daniel P. Berrange's message of "Wed, 10 Sep 2008 13:59:03 +0100") References: <1221050645-17529-1-git-send-email-mmorsi@redhat.com> <1221050645-17529-2-git-send-email-mmorsi@redhat.com> <20080910125903.GO2662@redhat.com> Message-ID: <87d4jbm2vd.fsf@rho.meyering.net> "Daniel P. Berrange" wrote: ... > Basically I expect that autobuild.sh for any autotools based app should > look pretty much like this: > > http://gtk-vnc.codemonkey.ws/hg/outgoing.hg/file/f1d5c8fae2e9/autobuild.sh > > Add in a 'make test' command before 'make install' if the app has a test > suite Good idea. For autoconfiscated packages, you'd add "make check". From clalance at redhat.com Thu Sep 11 11:59:33 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 11 Sep 2008 13:59:33 +0200 Subject: [Ovirt-devel] [PATCH-node]: Re-arrange the node spec file to use scripts Message-ID: <48C90825.9010504@redhat.com> -- Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-rearrange-node-spec.patch Type: text/x-patch Size: 14158 bytes Desc: not available URL: From clalance at redhat.com Thu Sep 11 12:00:08 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 11 Sep 2008 14:00:08 +0200 Subject: [Ovirt-devel] [PATCH-node-image]: Make sure to call the ovirt-install-host script in %post Message-ID: <48C90848.2080602@redhat.com> -- Chris Lalancette -------------- next part -------------- A non-text attachment was scrubbed... Name: ovirt-node-image-call-stateless.patch Type: text/x-patch Size: 793 bytes Desc: not available URL: From jim at meyering.net Thu Sep 11 12:16:29 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 14:16:29 +0200 Subject: [Ovirt-devel] [PATCH appliance] ovirt-appliance.spec (Buildrequires): Add wget. Message-ID: <878wtylvxe.fsf@rho.meyering.net> --- This missing build-requirement caused a build failure on a just-installed (from liveCD) F9 system. This is one part of the fix. The next is to append "wget" to the appliance "yum install ..." line in http://ovirt.org/build-instructions.html ovirt-appliance.spec | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index 2eebee8..6b495cc 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -19,6 +19,7 @@ BuildRequires: appliance-tools BuildRequires: livecd-tools >= 017 BuildRequires: syslinux BuildRequires: qemu-img +BuildRequires: wget %define app_root %{_datadir}/%{name} @@ -89,5 +90,3 @@ mkdir %{buildroot} %changelog * Fri Sep 05 2008 Perry Myers 0.92-1 - Initial build. - - -- 1.6.0.1.308.gede4c From jim at meyering.net Thu Sep 11 12:32:35 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 14:32:35 +0200 Subject: [Ovirt-devel] [PATCH-node]: Re-arrange the node spec file to use scripts In-Reply-To: <48C90825.9010504@redhat.com> (Chris Lalancette's message of "Thu, 11 Sep 2008 13:59:33 +0200") References: <48C90825.9010504@redhat.com> Message-ID: <87y71ykgm4.fsf@rho.meyering.net> Chris Lalancette wrote: > commit 56f847792a30f26891940d21fe7bb10df8c2abd9 > Author: Chris Lalancette > Date: Thu Sep 11 13:43:25 2008 +0200 > > A rewrite of the ovirt-node.spec script, which cascaded into a bunch of > other files. The impetus for doing this is that we want to have an ... > diff --git a/ovirt-listen-awake/ovirt-install-host b/ovirt-listen-awake/ovirt-install-host ... > \ No newline at end of file > diff --git a/ovirt-listen-awake/ovirt-uninstall-host b/ovirt-listen-awake/ovirt-uninstall-host ... > \ No newline at end of file All looks fine, though you'll want to add a newline at the end of each of those files. From pmyers at redhat.com Thu Sep 11 12:51:29 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 11 Sep 2008 08:51:29 -0400 Subject: [Ovirt-devel] [PATCH appliance] ovirt-appliance.spec (Buildrequires): Add wget. In-Reply-To: <878wtylvxe.fsf@rho.meyering.net> References: <878wtylvxe.fsf@rho.meyering.net> Message-ID: <48C91451.1050806@redhat.com> Jim Meyering wrote: > --- > This missing build-requirement caused a build failure on a > just-installed (from liveCD) F9 system. > > This is one part of the fix. The next is to append > "wget" to the appliance "yum install ..." line in > http://ovirt.org/build-instructions.html ACK > ovirt-appliance.spec | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec > index 2eebee8..6b495cc 100644 > --- a/ovirt-appliance.spec > +++ b/ovirt-appliance.spec > @@ -19,6 +19,7 @@ BuildRequires: appliance-tools > BuildRequires: livecd-tools >= 017 > BuildRequires: syslinux > BuildRequires: qemu-img > +BuildRequires: wget > > %define app_root %{_datadir}/%{name} > > @@ -89,5 +90,3 @@ mkdir %{buildroot} > %changelog > * Fri Sep 05 2008 Perry Myers 0.92-1 > - Initial build. > - > - > -- > 1.6.0.1.308.gede4c > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From mmorsi at redhat.com Thu Sep 11 13:33:29 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Thu, 11 Sep 2008 09:33:29 -0400 Subject: [Ovirt-devel] [PATCH] fixed static version in autobuild.sh Message-ID: <1221140009-19998-1-git-send-email-mmorsi@redhat.com> --- autobuild.sh | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/autobuild.sh b/autobuild.sh index eaaf5f4..b189546 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -27,6 +27,8 @@ test -f Makefile && make -k distclean || : make tar +version=`sed s/\ .*$// version` + if [ -f /usr/bin/rpmbuild ]; then if [ -n "$AUTOBUILD_COUNTER" ]; then EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER" @@ -37,7 +39,7 @@ if [ -f /usr/bin/rpmbuild ]; then # manually copy files over until we have an autotools # generated tarball to base rpmbuild on cp version $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ - cp rpm-build/ovirt-server-0.92.tar.gz $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ + cp rpm-build/ovirt-server-$version.tar.gz $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" -ba --clean ovirt-server.spec fi -- 1.5.4.1 From jim at meyering.net Thu Sep 11 13:46:38 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 15:46:38 +0200 Subject: [Ovirt-devel] [PATCH appliance] autoconfiscate Message-ID: <87sks6kd6p.fsf@rho.meyering.net> release.mk: Copy from ../node autogen.sh: Likewise. Makefile.am: New file. List distributed files. configure.ac: Set package name. --- Tested via "make -f ... build" on F9. .gitignore | 21 ++++++++++++++++++--- Makefile | 38 -------------------------------------- Makefile.am | 37 +++++++++++++++++++++++++++++++++++++ autogen.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ configure.ac | 6 ++++++ release.mk | 9 +++++---- 6 files changed, 124 insertions(+), 45 deletions(-) delete mode 100644 Makefile create mode 100644 Makefile.am create mode 100755 autogen.sh create mode 100644 configure.ac diff --git a/.gitignore b/.gitignore index a2ea3e5..cd5ff32 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,19 @@ -repos.ks -ovirt-appliance.xml -ovirt-appliance-sda.raw +*~ +INSTALL +Makefile +Makefile.in +aclocal.m4 +autom4te.cache/ +config.h +config.h.in +config.log +config.status +configure +install-sh +missing +ovirt-appliance-*.tar.gz ovirt-appliance-sda.qcow +ovirt-appliance-sda.raw +ovirt-appliance.xml +repos.ks +stamp-h1 diff --git a/Makefile b/Makefile deleted file mode 100644 index a743d29..0000000 --- a/Makefile +++ /dev/null @@ -1,38 +0,0 @@ -# FEDORA_URL env var can be set to the root of a fedora mirror -# OVIRT_URL env var can be set to the root of an ovirt.org mirror -# SKIP_COMPRESS_IMAGE env var an be set to 1 to skip qcow compression -# that contains the install tree -pkg_name = ovirt-appliance - -all: rpms -include release.mk - -ifdef SKIP_COMPRESS_IMAGE -RPM_FLAGS += --define "skip_compress_image 1" -endif - -ifdef FEDORA_URL -RPM_FLAGS += --define "fedora_url $(FEDORA_URL)" -endif - -ifdef OVIRT_URL -RPM_FLAGS += --define "ovirt_url $(OVIRT_URL)" -endif - -clean: - rm -rf $(pkg_name)-* - -distclean: clean - rm -rf tmp repos.ks rpm-build - -tar: clean common-install.ks common-pkgs.ks common-post.ks ovirt-appliance.ks repos.ks.in - mkdir -p $(NV) - cp -a common-install.ks common-pkgs.ks common-post.ks COPYING \ - create-$(pkg_name) gettree.sh Makefile $(pkg_name).ks \ - $(pkg_name).spec release.mk repos.ks.in $(NV) - mkdir -p rpm-build - tar zcvf rpm-build/$(NV).tar $(NV) - cp version rpm-build/ - rm -rf $(NV) - -.PHONY: clean distclean all tar diff --git a/Makefile.am b/Makefile.am new file mode 100644 index 0000000..b59086a --- /dev/null +++ b/Makefile.am @@ -0,0 +1,37 @@ +# Copyright (C) 2008 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. + +EXTRA_DIST = \ + .gitignore \ + common-install.ks \ + common-pkgs.ks \ + common-post.ks \ + create-ovirt-appliance \ + gettree.sh \ + ovirt-appliance.ks \ + ovirt-appliance.spec \ + release.mk \ + repos.ks.in \ + version + +include release.mk + +pkg_name = $(PACKAGE_NAME) +.PHONY: tar +tar: dist + mkdir -p rpm-build/BUILDROOT + cp version $(distdir).tar.gz rpm-build diff --git a/autogen.sh b/autogen.sh new file mode 100755 index 0000000..0d2c99c --- /dev/null +++ b/autogen.sh @@ -0,0 +1,58 @@ +#!/bin/sh +# Run this to generate configure and Makefile + +srcdir=`dirname $0` +test -z "$srcdir" && srcdir=. + +THEDIR=`pwd` +( + cd $srcdir + die=0 + + (autoconf --version) < /dev/null > /dev/null 2>&1 || { + echo + echo "You must have autoconf installed." + echo "Download the appropriate package for your distribution," + echo "or see http://www.gnu.org/software/autoconf" + die=1 + } + + (libtool --version) < /dev/null > /dev/null 2>&1 || { + echo + echo "You must have libtool installed." + echo "Download the appropriate package for your distribution," + echo "or see http://www.gnu.org/software/libtool" + die=1 + } + + (automake --version) < /dev/null > /dev/null 2>&1 || { + echo + die=1 + echo "You must have automake installed." + echo "Download the appropriate package for your distribution," + echo "or see http://www.gnu.org/software/automake" + } + + test $die = 1 && exit 1 + + test -f ovirt-appliance.spec || { + echo "You must run this script in the top-level directory" + exit 1 + } + + if test -z "$*"; then + echo "I am going to run ./configure with no arguments - if you wish " + echo "to pass any to it, please specify them on the $0 command line." + fi + + aclocal + autoheader + automake --add-missing + autoconf + ./configure "$@" +) + +if test "x$OBJ_DIR" != x; then + mkdir -p "$OBJ_DIR" + cd "$OBJ_DIR" +fi diff --git a/configure.ac b/configure.ac new file mode 100644 index 0000000..3f0fa6e --- /dev/null +++ b/configure.ac @@ -0,0 +1,6 @@ +# note: the version number here is overridden by the one in release.mk +AC_INIT([ovirt-appliance], [0.1], [ovirt-devel at redhat.com]) +AM_INIT_AUTOMAKE([-Wall -Werror foreign]) + +AC_CONFIG_FILES([Makefile]) +AC_OUTPUT diff --git a/release.mk b/release.mk index b89bd86..7d9ddd0 100644 --- a/release.mk +++ b/release.mk @@ -2,13 +2,14 @@ # It expects the including Makefile to define the "pkg_name" # variable, as well as a file named "version" in the current directory. -ARCH := $(shell uname -i) -VERSION := $(shell awk '{ print $$1 }' version) -RELEASE := $(shell awk '{ print $$2 }' version) +srcdir ?= . +ARCH = $(shell uname -i) +VERSION = $(shell awk '{ print $$1 }' $(srcdir)/version) +RELEASE = $(shell awk '{ print $$2 }' $(srcdir)/version) NEWVERSION = $$(awk 'BEGIN { printf "%.2f", $(VERSION) + .01 }') NEWRELEASE = $$(($(RELEASE) + 1)) X = $$(awk '{ split($$2,r,"."); \ - printf("%d.%d\n", r[1], r[2]+1) }' version) + printf("%d.%d\n", r[1], r[2]+1) }' $(srcdir)/version) git_head = $$(git log -1 --pretty=format:%h) GITRELEASE = $(X).$$(date --utc +%Y%m%d%H%M)git$(git_head) DIST = $$(rpm --eval '%{dist}') -- 1.6.0.1.308.gede4c From jim at meyering.net Thu Sep 11 13:50:28 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 15:50:28 +0200 Subject: [Ovirt-devel] [PATCH node] Makefile.am (pkg_name): define to $(PACKAGE_NAME), Message-ID: <87myiekd0b.fsf@rho.meyering.net> which is set via autoconf and automake rather than hard-coding --- full disclosure: not tested separately, since the same code was already tested in the just-run test of my appliance patch. Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.am b/Makefile.am index fad3fb5..a41c9ad 100644 --- a/Makefile.am +++ b/Makefile.am @@ -36,7 +36,7 @@ EXTRA_DIST = \ include release.mk -pkg_name = ovirt-node +pkg_name = $(PACKAGE_NAME) .PHONY: tar tar: dist mkdir -p rpm-build/BUILDROOT -- 1.6.0.1.308.gede4c From berrange at redhat.com Thu Sep 11 13:51:07 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 11 Sep 2008 14:51:07 +0100 Subject: [Ovirt-devel] [PATCH appliance] autoconfiscate In-Reply-To: <87sks6kd6p.fsf@rho.meyering.net> References: <87sks6kd6p.fsf@rho.meyering.net> Message-ID: <20080911135107.GB15043@redhat.com> On Thu, Sep 11, 2008 at 03:46:38PM +0200, Jim Meyering wrote: > > release.mk: Copy from ../node > autogen.sh: Likewise. > Makefile.am: New file. List distributed files. > configure.ac: Set package name. ACK, this is a good start. I'd like to it an add on though that removes all the junk from the RPM %install section and puts it into the Makefile, you can just do 'make install'. RPM build scripts should be for distro integration only, not a core part of the generic application build & install process. I notice the ovirt-node suffers from the same problem Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jim at meyering.net Thu Sep 11 13:55:41 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 15:55:41 +0200 Subject: [Ovirt-devel] [PATCH appliance] autoconfiscate In-Reply-To: <20080911135107.GB15043@redhat.com> (Daniel P. Berrange's message of "Thu, 11 Sep 2008 14:51:07 +0100") References: <87sks6kd6p.fsf@rho.meyering.net> <20080911135107.GB15043@redhat.com> Message-ID: <87hc8mkcrm.fsf@rho.meyering.net> "Daniel P. Berrange" wrote: > On Thu, Sep 11, 2008 at 03:46:38PM +0200, Jim Meyering wrote: >> >> release.mk: Copy from ../node >> autogen.sh: Likewise. >> Makefile.am: New file. List distributed files. >> configure.ac: Set package name. > > ACK, this is a good start. I'd like to it an add on though > that removes all the junk from the RPM %install section > and puts it into the Makefile, you can just do 'make install'. > RPM build scripts should be for distro integration only, > not a core part of the generic application build & install > process. I notice the ovirt-node suffers from the same problem I agree. I'm taking small steps and didn't have a lot of time for this today. Now that I have usable hardware+F9, I'm looking at SElinux. How about if I push this for now, and save the further (and required, "proper") integration for later. From berrange at redhat.com Thu Sep 11 13:56:34 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 11 Sep 2008 14:56:34 +0100 Subject: [Ovirt-devel] [PATCH appliance] autoconfiscate In-Reply-To: <87hc8mkcrm.fsf@rho.meyering.net> References: <87sks6kd6p.fsf@rho.meyering.net> <20080911135107.GB15043@redhat.com> <87hc8mkcrm.fsf@rho.meyering.net> Message-ID: <20080911135634.GC15043@redhat.com> On Thu, Sep 11, 2008 at 03:55:41PM +0200, Jim Meyering wrote: > "Daniel P. Berrange" wrote: > > On Thu, Sep 11, 2008 at 03:46:38PM +0200, Jim Meyering wrote: > >> > >> release.mk: Copy from ../node > >> autogen.sh: Likewise. > >> Makefile.am: New file. List distributed files. > >> configure.ac: Set package name. > > > > ACK, this is a good start. I'd like to it an add on though > > that removes all the junk from the RPM %install section > > and puts it into the Makefile, you can just do 'make install'. > > RPM build scripts should be for distro integration only, > > not a core part of the generic application build & install > > process. I notice the ovirt-node suffers from the same problem > > I agree. > I'm taking small steps and didn't have a lot of time for this today. > Now that I have usable hardware+F9, I'm looking at SElinux. > How about if I push this for now, and save the further > (and required, "proper") integration for later. Yes - no problem - any step in the right direction is worthwhile change to apply. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Thu Sep 11 14:01:40 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 11 Sep 2008 10:01:40 -0400 Subject: [Ovirt-devel] [PATCH-node-image]: Make sure to call the ovirt-install-host script in %post In-Reply-To: <48C90848.2080602@redhat.com> References: <48C90848.2080602@redhat.com> Message-ID: <48C924C4.8010104@redhat.com> One comment... Maybe we should call the install script ovirt-install-node instead of ovirt-install-host to be consistent with the terminology we're using on the website. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From apevec at redhat.com Thu Sep 11 14:14:00 2008 From: apevec at redhat.com (Alan Pevec) Date: Thu, 11 Sep 2008 16:14:00 +0200 Subject: [Ovirt-devel] [PATCH appliance] autoconfiscate In-Reply-To: <20080911135107.GB15043@redhat.com> References: <87sks6kd6p.fsf@rho.meyering.net> <20080911135107.GB15043@redhat.com> Message-ID: <48C927A8.1030300@redhat.com> Daniel P. Berrange wrote: > ACK, this is a good start. I'd like to it an add on though > that removes all the junk from the RPM %install section > and puts it into the Makefile, you can just do 'make install'. > RPM build scripts should be for distro integration only, > not a core part of the generic application build & install > process. I notice the ovirt-node suffers from the same problem ok, but ovirt-appliance is distro integration exercise: it's basically Fedora installation with oVirt packages added and configured From pmyers at redhat.com Thu Sep 11 14:15:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Thu, 11 Sep 2008 10:15:20 -0400 Subject: [Ovirt-devel] [PATCH-node]: Re-arrange the node spec file to use scripts In-Reply-To: <48C90825.9010504@redhat.com> References: <48C90825.9010504@redhat.com> Message-ID: <48C927F8.8020205@redhat.com> Just some general comments... Comment on naming of the script (ovirt-install-node) from your other patch applies here as well. Otherwise this looks fine as a first pass. A few things to keep in mind (stuff to work on later) This patch is specific to solving the problem of letting the oVirt Server Suite running as an appliance manage VMs running on its own host. This is a good idea, but we should be able to further generalize this patch to support installing the ovirt-node RPM on any random F9 box to turn that box into a node that can be managed by oVirt. Some of the hardcoded values in the stateful section (like the IP address and DNS information) would prevent this from working properly, so we might need to tweak things there. Also, it seems to me that the ovirt-listen-awake might not be applicable to the general case... Not sure how that would fit in. But overall, this is a good first cut in the right direction, so ACK (assuming it's been reasonably tested :) Perry From dpierce at redhat.com Thu Sep 11 14:30:25 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 11 Sep 2008 10:30:25 -0400 Subject: [Ovirt-devel] NIC Bonding and Failover Message-ID: <20080911143025.GB7156@redhat.com> In order to make this happen, the following flow occurs during the node's bootup: 1. the node submits its hardware details, including the list of NICs 2. the server updates the database, deleting any records for NICs that weren't reported, and saving records for new NICs reported 3. the node makes a request to the new managed node controller, asking for the configuration file a. previously this was a hard-coded file, now it's a generated file b. the node submits the list of mac addresses mapped to the interface names for the system c. the returned configuration will contain at most two sections: 1. a pre-augtool script 2. an augtool file 4. the configuration file is saved to /var/tmp/node-config 5. the configuration file is then passed to bash for execution, to extract the two files 6. if the file /var/tmp/pre-config-script exists, it is executed a. this segment loads the bonding kernel module with the correct bonding mode 7. if the file /var/tmp/node-augtool exists, then it is passed to augtool 8. the network service is then restarted and the bonding is available. To configure a node for bonding/failover/load balancing on the server, the admin has to set a bonding type for the node. The choices are: 1. Load Balancing 2. Failover 3. Broadcast 4. Link Aggregation Only one type can be set per-node. Optionally the user will be able to set an arp ping address and ping interval. However, at this time those features won't be surfaced. The user will then be able to select two or more NICs on that node and enslave them to a bonded interface. To do that, they will: 1. create a bonded interface and give it a name and an interface name 2. select two or more NICs and associate them with the bonded interface The next time the node boots, it will load the bonding module and pass in the appropriate mode for the bonding type selected. Questions? -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From berrange at redhat.com Thu Sep 11 14:53:23 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 11 Sep 2008 15:53:23 +0100 Subject: [Ovirt-devel] NIC Bonding and Failover In-Reply-To: <20080911143025.GB7156@redhat.com> References: <20080911143025.GB7156@redhat.com> Message-ID: <20080911145323.GE15043@redhat.com> On Thu, Sep 11, 2008 at 10:30:25AM -0400, Darryl L. Pierce wrote: > In order to make this happen, the following flow occurs during the node's > bootup: > > 1. the node submits its hardware details, including the list of NICs > 2. the server updates the database, deleting any records for NICs that > weren't reported, and saving records for new NICs reported > 3. the node makes a request to the new managed node controller, asking for > the configuration file > a. previously this was a hard-coded file, now it's a generated file > b. the node submits the list of mac addresses mapped to the interface > names for the system > c. the returned configuration will contain at most two sections: > 1. a pre-augtool script > 2. an augtool file > 4. the configuration file is saved to /var/tmp/node-config > 5. the configuration file is then passed to bash for execution, to extract > the two files > 6. if the file /var/tmp/pre-config-script exists, it is executed > a. this segment loads the bonding kernel module with the correct > bonding mode > 7. if the file /var/tmp/node-augtool exists, then it is passed to augtool > 8. the network service is then restarted and the bonding is available. > > To configure a node for bonding/failover/load balancing on the server, the > admin has to set a bonding type for the node. The choices are: > > 1. Load Balancing > 2. Failover > 3. Broadcast > 4. Link Aggregation > > Only one type can be set per-node. Is that a limitation of the linux bonding driver, or an explicit design choice ? If I have a system with lots of NICs I could imagine that the storage LAN might want a different bonding config from the guest LAN, from the management LAN. Then again you could argue that in that case you can just set 2 pairs for each LAN all in Link Aggregation, which effectively gives you load balancing/failover upon failure anyway. > The user will then be able to select two or more NICs on that node and > enslave them to a bonded interface. To do that, they will: > > 1. create a bonded interface and give it a name and an interface name > 2. select two or more NICs and associate them with the bonded interface > > The next time the node boots, it will load the bonding module and pass in > the > appropriate mode for the bonding type selected. > > Questions? Don't forget that we need to add briding ontop of that if the bonded pair is to be used for the guest LAN. Potentially also bridges ontop of VLANs ontop of bonds. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From dpierce at redhat.com Thu Sep 11 15:11:32 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 11 Sep 2008 11:11:32 -0400 Subject: [Ovirt-devel] Re: NIC Bonding and Failover In-Reply-To: <20080911145323.GE15043@redhat.com> References: <20080911143025.GB7156@redhat.com> <20080911145323.GE15043@redhat.com> Message-ID: <20080911151132.GC7156@redhat.com> +++ Daniel P. Berrange [11/09/08 15:53 +0100]: >> To configure a node for bonding/failover/load balancing on the server, the >> admin has to set a bonding type for the node. The choices are: >> >> 1. Load Balancing >> 2. Failover >> 3. Broadcast >> 4. Link Aggregation >> >> Only one type can be set per-node. > >Is that a limitation of the linux bonding driver, or an explicit design >choice ? > >If I have a system with lots of NICs I could imagine that the storage >LAN might want a different bonding config from the guest LAN, from >the management LAN. Then again you could argue that in that case >you can just set 2 pairs for each LAN all in Link Aggregation, which >effectively gives you load balancing/failover upon failure anyway. It was a design choice on my part to keep things simple initially. The way things are configured currently we a single relationship of a host to a bonding strategy. But it wouldn't be difficult to enhance that down the road to allow multiple bonding strategies. >> The user will then be able to select two or more NICs on that node and >> enslave them to a bonded interface. To do that, they will: >> >> 1. create a bonded interface and give it a name and an interface name >> 2. select two or more NICs and associate them with the bonded interface >> >> The next time the node boots, it will load the bonding module and pass in >> the >> appropriate mode for the bonding type selected. >> >> Questions? > >Don't forget that we need to add briding ontop of that if the bonded pair >is to be used for the guest LAN. Potentially also bridges ontop of VLANs >ontop of bonds. Good point. That's still in the nics model, so when the augtool portion is generated and there's a nic with a bridge then it's included. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From clalance at redhat.com Thu Sep 11 15:15:52 2008 From: clalance at redhat.com (Chris Lalancette) Date: Thu, 11 Sep 2008 17:15:52 +0200 Subject: [Ovirt-devel] NIC Bonding and Failover In-Reply-To: <20080911145323.GE15043@redhat.com> References: <20080911143025.GB7156@redhat.com> <20080911145323.GE15043@redhat.com> Message-ID: <48C93628.20008@redhat.com> Daniel P. Berrange wrote: > On Thu, Sep 11, 2008 at 10:30:25AM -0400, Darryl L. Pierce wrote: >> In order to make this happen, the following flow occurs during the node's >> bootup: >> >> 1. the node submits its hardware details, including the list of NICs >> 2. the server updates the database, deleting any records for NICs that >> weren't reported, and saving records for new NICs reported >> 3. the node makes a request to the new managed node controller, asking for >> the configuration file >> a. previously this was a hard-coded file, now it's a generated file >> b. the node submits the list of mac addresses mapped to the interface >> names for the system >> c. the returned configuration will contain at most two sections: >> 1. a pre-augtool script >> 2. an augtool file >> 4. the configuration file is saved to /var/tmp/node-config >> 5. the configuration file is then passed to bash for execution, to extract >> the two files >> 6. if the file /var/tmp/pre-config-script exists, it is executed >> a. this segment loads the bonding kernel module with the correct >> bonding mode >> 7. if the file /var/tmp/node-augtool exists, then it is passed to augtool >> 8. the network service is then restarted and the bonding is available. >> >> To configure a node for bonding/failover/load balancing on the server, the >> admin has to set a bonding type for the node. The choices are: >> >> 1. Load Balancing >> 2. Failover >> 3. Broadcast >> 4. Link Aggregation >> >> Only one type can be set per-node. > > Is that a limitation of the linux bonding driver, or an explicit design > choice ? > > If I have a system with lots of NICs I could imagine that the storage > LAN might want a different bonding config from the guest LAN, from > the management LAN. Then again you could argue that in that case > you can just set 2 pairs for each LAN all in Link Aggregation, which > effectively gives you load balancing/failover upon failure anyway. I'm pretty sure modern Linux allows you to have more than one type of bond active at a time. I have no idea how to do it, though, so you'll have to research it. I'm fine if this is going to be a temporary limitation, but as danpb points out, you might want to bond differently on machines with lots of NICs. > >> The user will then be able to select two or more NICs on that node and >> enslave them to a bonded interface. To do that, they will: >> >> 1. create a bonded interface and give it a name and an interface name >> 2. select two or more NICs and associate them with the bonded interface >> >> The next time the node boots, it will load the bonding module and pass in >> the >> appropriate mode for the bonding type selected. >> >> Questions? > > Don't forget that we need to add briding ontop of that if the bonded pair > is to be used for the guest LAN. Potentially also bridges ontop of VLANs > ontop of bonds. Yes, this question is very appropriate too. Again, I'm not saying we have to support this right now, but we need to be conscious of it. There are 3 pieces at work here (bridges, VLAN's, and bonds), which means there are 9 ways you could do things: VLAN's on top of bonds on top of bridges, bridges on top of bonds on top of VLAN's, etc. We have to figure out which combinations are completely insane, which are valid and make sense, and then make sure we can handle those. Yes, this is complicated :(. -- Chris Lalancette From berrange at redhat.com Thu Sep 11 15:22:36 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 11 Sep 2008 16:22:36 +0100 Subject: [Ovirt-devel] NIC Bonding and Failover In-Reply-To: <48C93628.20008@redhat.com> References: <20080911143025.GB7156@redhat.com> <20080911145323.GE15043@redhat.com> <48C93628.20008@redhat.com> Message-ID: <20080911152236.GF15043@redhat.com> On Thu, Sep 11, 2008 at 05:15:52PM +0200, Chris Lalancette wrote: > > On Thu, Sep 11, 2008 at 10:30:25AM -0400, Darryl L. Pierce wrote:> > Yes, this question is very appropriate too. Again, I'm not saying we have to > support this right now, but we need to be conscious of it. There are 3 pieces > at work here (bridges, VLAN's, and bonds), which means there are 9 ways you > could do things: VLAN's on top of bonds on top of bridges, bridges on top of > bonds on top of VLAN's, etc. We have to figure out which combinations are > completely insane, which are valid and make sense, and then make sure we can > handle those. Yes, this is complicated :(. bonding has to be done at the physical level, so that cuts out one variable. Conceptually briding is just a way to 'share' an interface with the guests, so that only makes sense at the top level. Which leaves VLANs in the middle. So you get a hierarchy like: n * Physical nic -> bond device -> n * vlan -> bridge Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jim at meyering.net Thu Sep 11 15:26:07 2008 From: jim at meyering.net (Jim Meyering) Date: Thu, 11 Sep 2008 17:26:07 +0200 Subject: [Ovirt-devel] [PATCH appliance] autoconfiscate In-Reply-To: <20080911135634.GC15043@redhat.com> (Daniel P. Berrange's message of "Thu, 11 Sep 2008 14:56:34 +0100") References: <87sks6kd6p.fsf@rho.meyering.net> <20080911135107.GB15043@redhat.com> <87hc8mkcrm.fsf@rho.meyering.net> <20080911135634.GC15043@redhat.com> Message-ID: <87zlmeiu0g.fsf@rho.meyering.net> "Daniel P. Berrange" wrote: > On Thu, Sep 11, 2008 at 03:55:41PM +0200, Jim Meyering wrote: >> "Daniel P. Berrange" wrote: >> > On Thu, Sep 11, 2008 at 03:46:38PM +0200, Jim Meyering wrote: >> >> >> >> release.mk: Copy from ../node >> >> autogen.sh: Likewise. >> >> Makefile.am: New file. List distributed files. >> >> configure.ac: Set package name. >> > >> > ACK, this is a good start. I'd like to it an add on though >> > that removes all the junk from the RPM %install section >> > and puts it into the Makefile, you can just do 'make install'. >> > RPM build scripts should be for distro integration only, >> > not a core part of the generic application build & install >> > process. I notice the ovirt-node suffers from the same problem >> >> I agree. >> I'm taking small steps and didn't have a lot of time for this today. >> Now that I have usable hardware+F9, I'm looking at SElinux. >> How about if I push this for now, and save the further >> (and required, "proper") integration for later. > > Yes - no problem - any step in the right direction is worthwhile change > to apply. Pushed it. From dpierce at redhat.com Thu Sep 11 15:42:08 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Thu, 11 Sep 2008 11:42:08 -0400 Subject: [Ovirt-devel] Re: NIC Bonding and Failover In-Reply-To: <48C93628.20008@redhat.com> References: <20080911143025.GB7156@redhat.com> <20080911145323.GE15043@redhat.com> <48C93628.20008@redhat.com> Message-ID: <20080911154207.GD7156@redhat.com> +++ Chris Lalancette [11/09/08 17:15 +0200]: >I'm pretty sure modern Linux allows you to have more than one type of bond >active at a time. I have no idea how to do it, though, so you'll have to >research it. I'm fine if this is going to be a temporary limitation, but as >danpb points out, you might want to bond differently on machines with lots of NICs. You should be able to alias each of the bonding types: alias storage0 bonding alias virtnet0 bonding option storage0 mode=2 option virtnet0 mode=4 This, I believe, will give us the two bonded interfaces with the different bonding strategies. >Yes, this question is very appropriate too. Again, I'm not saying we have to >support this right now, but we need to be conscious of it. There are 3 pieces >at work here (bridges, VLAN's, and bonds), which means there are 9 ways you >could do things: VLAN's on top of bonds on top of bridges, bridges on top of >bonds on top of VLAN's, etc. We have to figure out which combinations are >completely insane, which are valid and make sense, and then make sure we can >handle those. Yes, this is complicated :(. Oh, now you tell me. :D -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From clalance at redhat.com Fri Sep 12 09:02:09 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 12 Sep 2008 11:02:09 +0200 Subject: [Ovirt-devel] [PATCH-node]: Re-arrange the node spec file to use scripts In-Reply-To: <48C90825.9010504@redhat.com> References: <48C90825.9010504@redhat.com> Message-ID: <48CA3011.9010209@redhat.com> Pushed, after addressing the name change from ovirt-install-host to ovirt-install-node and ovirt-uninstall-host to ovirt-uninstall-node. -- Chris Lalancette From clalance at redhat.com Fri Sep 12 09:02:24 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 12 Sep 2008 11:02:24 +0200 Subject: [Ovirt-devel] [PATCH-node-image]: Make sure to call the ovirt-install-host script in %post In-Reply-To: <48C90848.2080602@redhat.com> References: <48C90848.2080602@redhat.com> Message-ID: <48CA3020.1070400@redhat.com> Also pushed, with rename. -- Chris Lalancette From mmorsi at redhat.com Fri Sep 12 12:36:39 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Fri, 12 Sep 2008 08:36:39 -0400 Subject: [Ovirt-devel] Appliance Building using thincrust In-Reply-To: <1219416455-18149-1-git-send-email-bkearney@redhat.com> References: <1219416455-18149-1-git-send-email-bkearney@redhat.com> Message-ID: <48CA6257.8050302@redhat.com> bkearney at redhat.com wrote: > Two patches. The first pulls in the appliance recipe from thincrust. The second modifies the kickstart file to use hte new rpms from the first. Note that most "flat files" from the kickstart files are now acutal files in the first patch. > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel > Hey Brian, I started reviewing these patches this morning. Obviously with the repo refactoring some changes will need to be made, as well as some terminology updates ('wui' should probably be renamed to 'server' in a few locations), but for the most part this all looks good. Other than some directory layout tweaks due to the repo refactoring, a few things I noticed that need to be changed is the removal of the firefox profile from the appliance (firefox is no longer installed on the appliance since we now support password-based / simple kerb auth); as well as the removal of the build-all script (this functionality is mostly handled via make / rpmbuild). Other than that, this looks to be good to go (though I won't know for sure until I can apply the patch against a ovirt-appliance checkout and test it). In the meantime, just to make sure I'm understanding how this all works, you are removing all the cruft from the ovirt-appliance kickstart, besides the bare essentials; eg. setting up the necessary host resolution, iSCSI / NFS disc configuration, the ovirtAppliance package to be installed (which I'm assuming will be in the oVirt repo when this is all committed), and starting the ace init service on startup. On the ovirtAppliance rpm side you've moved most of the configuration previously in the kickstart to the /usr/share/ace/appliances/ovirt directory which will be loaded and used by ace when the service is started. Overall it all makes sense and looks great. One last thing I'm trying to figure out is the best way to add some minor changes to configure the appliance to run in a test / demo mode, for example when autobuild is going through the build process and setting up the appliance. These changes include implanting the host's public ssh key onto the appliance, delaying sshd to start as one of the last services, and setting the rails environment to 'test'. Looking at your patches, perhaps one approach (feel free to suggest an easier and/or better one) would be to create a 'ovirt-test' ace configuration, residing in /usr/share/ace/appliances/ovirt-test, which would be identical to the 'ovirt' one save the aformentioned changes, and use the autobuild.sh script in the ovirt-appliance repo to sed ovirt-appliance.ks (previously wui-appliance/wui-devel.ks) to change "echo ovirt >> /etc/sysconfig/ace/appliancename" to "echo ovirt-test >> /etc/sysconfig/ace/appliancename". Since it has to do w/ autobuild I can take care of this last part once your changes are in, but wanted to get your feedback on the best approach. -Mo From jim at meyering.net Fri Sep 12 13:53:37 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 12 Sep 2008 15:53:37 +0200 Subject: [Ovirt-devel] RFC: make "next" the default branch Message-ID: <87k5dhfp26.fsf@rho.meyering.net> Since most activity happens on "next" these days, we're considering making that the default branch upon clone. That would simplify several common scenarios. On the positive side, it will let us simplify both documentation and build procedures (there have been more than a few misunderstandings due to development proceeding on "next" and that not being the default). On the down side, it's slightly nonstandard. Thoughts? objections? From sseago at redhat.com Fri Sep 12 14:37:36 2008 From: sseago at redhat.com (Scott Seago) Date: Fri, 12 Sep 2008 10:37:36 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> Message-ID: <48CA7EB0.5070506@redhat.com> Mohammed Morsi wrote: > --- > wui/src/app/controllers/vm_controller.rb | 73 +++++++++++++++++++++++++----- > wui/src/app/views/vm/_form.rhtml | 6 ++- > 2 files changed, 65 insertions(+), 14 deletions(-) > > > This all looks good so far, but I think there's still something missing. >From what I see here, I don't think the cobbler system is being created in the reprovisioning case. Right the cobbler system is created in taskomatic in the create_vm action, but this won't be run in the reprovisioning case. It's not completely obvious how we'd resolve this, but we need to create and/or modify the cobbler system before restarting the VM. Darryl -- from the cobbler point of view, what action is required when a cobbler profile is changed for a system -- do we just edit the cobbler system? i.e. retrieve it by name (UUID), and modify, or do we have to delete it and recreate one? In any case, we'll need an explicit taskomatic task to be run before restarting the VM -- and this needs to happen any time the provisioning information is changed -- but it should probably not happen when we're not reprovisioning. Scott From mmorsi at redhat.com Fri Sep 12 15:04:48 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Fri, 12 Sep 2008 11:04:48 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CA7EB0.5070506@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> Message-ID: <48CA8510.6030408@redhat.com> Scott Seago wrote: > Mohammed Morsi wrote: >> --- >> wui/src/app/controllers/vm_controller.rb | 73 >> +++++++++++++++++++++++++----- >> wui/src/app/views/vm/_form.rhtml | 6 ++- >> 2 files changed, 65 insertions(+), 14 deletions(-) >> >> >> > This all looks good so far, but I think there's still something > missing. From what I see here, I don't think the cobbler system is > being created in the reprovisioning case. In the patch, the very first line added (to VmController.update) is a call to _setup_vm_provision(params), a method I added below to update the cobbler system if found, else create it. If I am misunderstanding something, please clarify. > Right the cobbler system is created in taskomatic in the create_vm > action, but this won't be run in the reprovisioning case. You bring up a good point here about an inconsistency, in the create vm case, taskomatic handles creating the vm, where as in the edit case which I added with this patch, the vm controller takes care of it. Will probably work, but as mentioned it is not consistent and probably should be taken care of by one component. Right now we could probably easily add a call to my new _setup_vm_provision(params) method in VmController.create > It's not completely obvious how we'd resolve this, but we need to > create and/or modify the cobbler system before restarting the VM. > > Darryl -- from the cobbler point of view, what action is required when > a cobbler profile is changed for a system -- do we just edit the > cobbler system? i.e. retrieve it by name (UUID), and modify, or do we > have to delete it and recreate one? > > In any case, we'll need an explicit taskomatic task to be run before > restarting the VM -- and this needs to happen any time the > provisioning information is changed -- but it should probably not > happen when we're not reprovisioning. Is there a definitive reason for making taskomatic handle the cobbler update as opposed to the rails application? -Mo From mmorsi at redhat.com Fri Sep 12 15:47:36 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Fri, 12 Sep 2008 11:47:36 -0400 Subject: [Ovirt-devel] [PATCH] autobuild fixes / improvements Message-ID: <1221234456-25674-1-git-send-email-mmorsi@redhat.com> * remove static version * use extra_release in spec * define ovirt_local_repo so as not to rely on .rpmmacros --- autobuild.sh | 8 ++++++-- ovirt-server.spec | 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/autobuild.sh b/autobuild.sh index eaaf5f4..f5ebd54 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -27,6 +27,8 @@ test -f Makefile && make -k distclean || : make tar +version=`sed s/\ .*$// version` + if [ -f /usr/bin/rpmbuild ]; then if [ -n "$AUTOBUILD_COUNTER" ]; then EXTRA_RELEASE=".auto$AUTOBUILD_COUNTER" @@ -37,7 +39,9 @@ if [ -f /usr/bin/rpmbuild ]; then # manually copy files over until we have an autotools # generated tarball to base rpmbuild on cp version $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ - cp rpm-build/ovirt-server-0.92.tar.gz $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ + cp rpm-build/ovirt-server-$version.tar.gz $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ - rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" -ba --clean ovirt-server.spec + rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" \ + --define "ovirt_local_repo $AUTOBUILD_PACKAGE_ROOT/rpm/RPMS" \ + -ba --clean ovirt-server.spec fi diff --git a/ovirt-server.spec b/ovirt-server.spec index 79cfffb..2f6ae48 100644 --- a/ovirt-server.spec +++ b/ovirt-server.spec @@ -5,7 +5,7 @@ Summary: oVirt Server Suite Name: ovirt-server Source1: version Version: %(echo `awk '{ print $1 }' %{SOURCE1}`) -Release: %(echo `awk '{ print $2 }' %{SOURCE1}`)%{?dist} +Release: %(echo `awk '{ print $2 }' %{SOURCE1}`)%{?dist}%{?extra_release} Source0: %{name}-%{version}.tar.gz #Entire source code is GPL except for vendor/plugins/will_paginate and #vendor/plugins/betternestedset, which are MIT, and -- 1.5.4.1 From sseago at redhat.com Fri Sep 12 15:47:51 2008 From: sseago at redhat.com (Scott Seago) Date: Fri, 12 Sep 2008 11:47:51 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CA8510.6030408@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> <48CA8510.6030408@redhat.com> Message-ID: <48CA8F27.6080301@redhat.com> Mohammed Morsi wrote: > Scott Seago wrote: > >> Mohammed Morsi wrote: >> >>> --- >>> wui/src/app/controllers/vm_controller.rb | 73 >>> +++++++++++++++++++++++++----- >>> wui/src/app/views/vm/_form.rhtml | 6 ++- >>> 2 files changed, 65 insertions(+), 14 deletions(-) >>> >>> >>> >>> >> This all looks good so far, but I think there's still something >> missing. From what I see here, I don't think the cobbler system is >> being created in the reprovisioning case. >> > In the patch, the very first line added (to VmController.update) is a > call to _setup_vm_provision(params), a method I added below to update > the cobbler system if found, else create it. If I am misunderstanding > something, please clarify. > > Ugh. not enough coffee today -- somehow I glossed right over that new bit. > >> Right the cobbler system is created in taskomatic in the create_vm >> action, but this won't be run in the reprovisioning case. >> > You bring up a good point here about an inconsistency, in the create vm > case, taskomatic handles creating the vm, where as in the edit case > which I added with this patch, the vm controller takes care of it. Will > probably work, but as mentioned it is not consistent and probably should > be taken care of by one component. Right now we could probably easily > add a call to my new _setup_vm_provision(params) method in > VmController.create > > Yeah -- we need to do them in the same place. As it is with this patch, there's a bit of a race condition if you edit a vm right after creating (but before taskomatic executes create_vm). Originally I'd made the decision to put the system create in taskomatic, since that's where all the other action-oriented bits that call out to external servers are handled. It's probably not that big a deal either way though, as we're already making cobbler calls from the WUI to get the profile list. But yes, we need to either put both of these calls in taskomatic or gut create_vm and put both in the WUI. My original preference here was for taskomatic to handle it, but the reprovision case makes that much more complex (since we'd need a new task type, etc), so maybe it makes more sense to do it all in the WUI. Any other opinions on this? >> happen when we're not reprovisioning. >> > Is there a definitive reason for making taskomatic handle the cobbler > update as opposed to the rails application? > > > The original reason was to pull anything that's not instantaneous into taskomatic -- although the cobbler calls should be fairly quick, so it may be no big deal either way -- as long as we do both new and reprovisioning bits the same way. Scott > -Mo > From jim at meyering.net Fri Sep 12 16:00:19 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 12 Sep 2008 18:00:19 +0200 Subject: [Ovirt-devel] [PATCH appliance] restore envvar-controlled RPM_FLAGS additions Message-ID: <87ej3pfj70.fsf@rho.meyering.net> * Makefile.am: Restore the code to append to RPM_FLAGS. These were mistakenly removed by the previous commit. --- Thanks to Perry Myers for spotting this. Testing it now... Makefile.am | 17 +++++++++++++++++ 1 files changed, 17 insertions(+), 0 deletions(-) diff --git a/Makefile.am b/Makefile.am index b59086a..8fbba56 100644 --- a/Makefile.am +++ b/Makefile.am @@ -35,3 +35,20 @@ pkg_name = $(PACKAGE_NAME) tar: dist mkdir -p rpm-build/BUILDROOT cp version $(distdir).tar.gz rpm-build + +# FEDORA_URL env var can be set to the root of a fedora mirror +# OVIRT_URL env var can be set to the root of an ovirt.org mirror +# SKIP_COMPRESS_IMAGE env var an be set to 1 to skip qcow compression +# that contains the install tree + +ifdef SKIP_COMPRESS_IMAGE +RPM_FLAGS += --define "skip_compress_image 1" +endif + +ifdef FEDORA_URL +RPM_FLAGS += --define "fedora_url $(FEDORA_URL)" +endif + +ifdef OVIRT_URL +RPM_FLAGS += --define "ovirt_url $(OVIRT_URL)" +endif -- 1.6.0.1.308.gede4c From clalance at redhat.com Fri Sep 12 16:05:54 2008 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 12 Sep 2008 18:05:54 +0200 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CA8F27.6080301@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> <48CA8510.6030408@redhat.com> <48CA8F27.6080301@redhat.com> Message-ID: <48CA9362.2010005@redhat.com> Scott Seago wrote: > Yeah -- we need to do them in the same place. As it is with this patch, > there's a bit of a race condition if you edit a vm right after creating > (but before taskomatic executes create_vm). Originally I'd made the > decision to put the system create in taskomatic, since that's where all > the other action-oriented bits that call out to external servers are > handled. It's probably not that big a deal either way though, as we're > already making cobbler calls from the WUI to get the profile list. > > But yes, we need to either put both of these calls in taskomatic or gut > create_vm and put both in the WUI. My original preference here was for > taskomatic to handle it, but the reprovision case makes that much more > complex (since we'd need a new task type, etc), so maybe it makes more > sense to do it all in the WUI. > > Any other opinions on this? Not an opinion (since I don't really care where it's done, as long as it is consistent), but a fact: in theory the cobbler stuff could hang up the WUI if there are network issues. If you do something like: iptables -A INPUT -p tcp --dport -j DROP on the cobbler server to simulate a network outage, then try to connect to it remotely, you will hang up for quite a while TCP attempts to connect. It's one reason to slightly prefer taskomatic to do it, but it may not be compelling enough. I just thought I would point it out. -- Chris Lalancette From lutter at redhat.com Fri Sep 12 16:33:28 2008 From: lutter at redhat.com (David Lutterkort) Date: Fri, 12 Sep 2008 09:33:28 -0700 Subject: [Ovirt-devel] [PATCH] Added the appliance-recipe code from the acex repo In-Reply-To: <1219416455-18149-2-git-send-email-bkearney@redhat.com> References: <1219416455-18149-1-git-send-email-bkearney@redhat.com> <1219416455-18149-2-git-send-email-bkearney@redhat.com> Message-ID: <1221237208.30184.10.camel@localhost.localdomain> On Fri, 2008-08-22 at 10:47 -0400, bkearney at redhat.com wrote: > From: root I haven't tried this out, just read through it, and only have some minor comments that could also be taken care of post commit. > diff --git a/appliance-recipe/README.rdoc b/appliance-recipe/README.rdoc > new file mode 100644 > index 0000000..7b981ac > --- /dev/null > +++ b/appliance-recipe/README.rdoc > @@ -0,0 +1,17 @@ > += Pligg Recipe > +This example will help to build a Pligg Appliance > +In order to do this, please do the following: > + > +* Download Pligg Beta 9.9.0 from www.pligg.com. Put it into the > +sources directory > +* execute rake pligg_rpm. This will build an RPM from the > +distribuition. > +* exeucte rake appliance_rpm. This will build an rpm for the recipe We should mention OVirt here, not Pligg ;) > diff --git a/appliance-recipe/appliances/ovirt/files/ovirt-wui-dev b/appliance-recipe/appliances/ovirt/files/ovirt-wui-dev > new file mode 100644 > index 0000000..54970bb > --- /dev/null > +++ b/appliance-recipe/appliances/ovirt/files/ovirt-wui-dev > +start() { > + echo -n "Starting ovirt-wui-dev: " > + dnsmasq -i eth1 -F 192.168.50.6,192.168.50.252 \ > + -G 00:16:3e:12:34:57,192.168.50.3 -G 00:16:3e:12:34:58,192.168.50.4 \ > + -G 00:16:3e:12:34:59,192.168.50.5 \ > + -s priv.ovirt.org \ > + -W _ovirt._tcp,management.priv.ovirt.org,80 \ > + -W _ipa._tcp,management.priv.ovirt.org,80 \ > + -W _ldap._tcp,management.priv.ovirt.org,389 \ > + -W _collectd._tcp,management.priv.ovirt.org,25826 \ > + -W _identify._tcp,management.priv.ovirt.org,12120 \ > + --enable-tftp --tftp-root=/var/lib/tftpboot -M pxelinux.0 \ > + -O option:router,192.168.50.2 -O option:ntp-server,192.168.50.2 \ > + --dhcp-option=12 \ > + -R --local /priv.ovirt.org/ --server 192.168.122.1 Not directly related to appliance building, but this should go into its own config file, so that it can be adapted locally; makes deployment of the appliance much more flexible. > diff --git a/appliance-recipe/appliances/ovirt/files/ovirt.repo b/appliance-recipe/appliances/ovirt/files/ovirt.repo > new file mode 100644 > index 0000000..c5d60cd > --- /dev/null > +++ b/appliance-recipe/appliances/ovirt/files/ovirt.repo > @@ -0,0 +1,5 @@ > +[ovirt] > +name=ovirt > +baseurl=http://ovirt.org/repos/ovirt/9/$basearch/ > +enabled=1 > +gpgcheck=0 This _could_ go into a yumrepo resource in the puppet manifest. > diff --git a/appliance-recipe/appliances/ovirt/ovirt.pp b/appliance-recipe/appliances/ovirt/ovirt.pp > new file mode 100644 > index 0000000..6c8a3f4 > --- /dev/null > +++ b/appliance-recipe/appliances/ovirt/ovirt.pp > @@ -0,0 +1,154 @@ > +# Information about our appliance > +$appliance_name = "OVirt Web UI" > +$appliance_version = "0.0.1" > +$ff_profile_dir = "uxssq4qb.ovirtadmin" > +$principal = "ovirtadmin" > +$realm = "PRIV.OVIRT.ORG" > +$password = "ovirt" > +$cron_file = "/etc/cron.hourly/ovirtadmin.cron" > +$ktab_file = "/usr/share/ovirt-wui/ovirtadmin.tab" Tab issues ? > +file_replacement{"nat_forwarding" : > + file => "/etc/sysctl.conf", > + pattern => "^net.ipv4.ip_forward = .*", > + replacement => "net.ipv4.ip_forward = 1", > + notify => Service[network] , > +} Augeas 0.3.1 supports sysctl.conf :) David From sseago at redhat.com Fri Sep 12 16:36:46 2008 From: sseago at redhat.com (Scott Seago) Date: Fri, 12 Sep 2008 12:36:46 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CA9362.2010005@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> <48CA8510.6030408@redhat.com> <48CA8F27.6080301@redhat.com> <48CA9362.2010005@redhat.com> Message-ID: <48CA9A9E.3060603@redhat.com> Chris Lalancette wrote: > Scott Seago wrote: > >> Yeah -- we need to do them in the same place. As it is with this patch, >> there's a bit of a race condition if you edit a vm right after creating >> (but before taskomatic executes create_vm). Originally I'd made the >> decision to put the system create in taskomatic, since that's where all >> the other action-oriented bits that call out to external servers are >> handled. It's probably not that big a deal either way though, as we're >> already making cobbler calls from the WUI to get the profile list. >> >> But yes, we need to either put both of these calls in taskomatic or gut >> create_vm and put both in the WUI. My original preference here was for >> taskomatic to handle it, but the reprovision case makes that much more >> complex (since we'd need a new task type, etc), so maybe it makes more >> sense to do it all in the WUI. >> >> Any other opinions on this? >> > > Not an opinion (since I don't really care where it's done, as long as it is > consistent), but a fact: in theory the cobbler stuff could hang up the WUI if > there are network issues. If you do something like: > > iptables -A INPUT -p tcp --dport -j DROP > > on the cobbler server to simulate a network outage, then try to connect to it > remotely, you will hang up for quite a while TCP attempts to connect. It's one > reason to slightly prefer taskomatic to do it, but it may not be compelling > enough. I just thought I would point it out. > > On the other hand, we're already getting the profile list on the WUI -- the above problem will affect the WUI anyway unless we also generate the cobbler profile list on the back end. Now we may eventually have to do this anyway if we ever want to define per-profile access control -- but as things stand now, just doing the cobbler system bit in taskomatic doesn't completely eliminate the cobbler connectivity issue for the WUI. Scott From dpierce at redhat.com Fri Sep 12 18:24:20 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 12 Sep 2008 14:24:20 -0400 Subject: [Ovirt-devel] Configuration NICs Message-ID: <20080912182420.GA15733@redhat.com> In order to configure a NIC and also use bonding/fail-over, we need a way to: 1. associate one or more BondingType objects to the Host via the Bonding class. 2. associate which of the Host's Nic objects will be a part of each Bonding object. 3. set the ip address, netmask, etc. for a Nic that's not enslaved. Here's a crude ASCII of what I"m thinking. [ Select a bonding type v ] [ Add ] Bonded interface alias: _bond0_____________________ [ Remove ]_ Bonded interface name: _ovbond0____________________ Network Interfaces: 00:11:22 [ ] Enslave to ovbond0 IP Address: _______ Netmask: ____ | 11:22:33 [X] Enslaved to ovbond0 22:33:44 [X] Enslaved to ovbond0 [ Save Changes ] 1. The user selects a bonding type and clicks "Add". The bonded interface fields are displayed. 2. The user clicks "Remove" to destroy the interface. When that happens, any enslaved Nic is released but not destroyed. 3. If the user clicks the checkbox to enslave an interface then the IP address and netmask fields go away. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From hbrock at redhat.com Fri Sep 12 18:47:24 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Fri, 12 Sep 2008 14:47:24 -0400 Subject: [Ovirt-devel] RFC: make "next" the default branch In-Reply-To: <87k5dhfp26.fsf@rho.meyering.net> References: <87k5dhfp26.fsf@rho.meyering.net> Message-ID: <20080912184723.GM10338@redhat.com> On Fri, Sep 12, 2008 at 03:53:37PM +0200, Jim Meyering wrote: > Since most activity happens on "next" these days, > we're considering making that the default branch upon clone. > That would simplify several common scenarios. > > On the positive side, it will let us simplify both > documentation and build procedures (there have been more than > a few misunderstandings due to development proceeding on "next" > and that not being the default). > > On the down side, it's slightly nonstandard. > > Thoughts? objections? I can't think of any reason not to do this -- the branch people can commit on should really be the default branch I think. --Hugh From jim at meyering.net Fri Sep 12 18:50:53 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 12 Sep 2008 20:50:53 +0200 Subject: [Ovirt-devel] RFC: make "next" the default branch In-Reply-To: <20080912184723.GM10338@redhat.com> (Hugh O. Brock's message of "Fri, 12 Sep 2008 14:47:24 -0400") References: <87k5dhfp26.fsf@rho.meyering.net> <20080912184723.GM10338@redhat.com> Message-ID: <87ljxxdwqa.fsf@rho.meyering.net> "Hugh O. Brock" wrote: > On Fri, Sep 12, 2008 at 03:53:37PM +0200, Jim Meyering wrote: >> Since most activity happens on "next" these days, >> we're considering making that the default branch upon clone. >> That would simplify several common scenarios. >> >> On the positive side, it will let us simplify both >> documentation and build procedures (there have been more than >> a few misunderstandings due to development proceeding on "next" >> and that not being the default). >> >> On the down side, it's slightly nonstandard. >> >> Thoughts? objections? > > I can't think of any reason not to do this -- the branch people can > commit on should really be the default branch I think. Ok. Barring objections, Monday I'll detail what exactly will have to change. From pmyers at redhat.com Fri Sep 12 18:56:51 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 12 Sep 2008 14:56:51 -0400 Subject: [Ovirt-devel] Configuration NICs In-Reply-To: <20080912182420.GA15733@redhat.com> References: <20080912182420.GA15733@redhat.com> Message-ID: <48CABB73.70102@redhat.com> Darryl L. Pierce wrote: > In order to configure a NIC and also use bonding/fail-over, we need a > way to: > > 1. associate one or more BondingType objects to the Host via the Bonding > class. Should we model this by associating a BondingType to a set of NICs rather than a Host? I know initially we're only going to support on BondingType per Host as to simplify things, but it might make sense to structure the data model to make it easier to transition to the more flexible approach. For the time being we can make the restriction that once you're created one set of bonded interfaces and have selected Type X for those interfaces that all other interfaces on the Host can only use type X. That's a simple restriction in the UI that doesn't affect the data model. > 2. associate which of the Host's Nic objects will be a part of each Bonding > object. > 3. set the ip address, netmask, etc. for a Nic that's not enslaved. Or allow DHCP, right? > Here's a crude ASCII of what I"m thinking. > > > [ Select a bonding type v ] [ Add ] > > Bonded interface alias: _bond0_____________________ [ Remove ]_ > Bonded interface name: _ovbond0____________________ > > Network Interfaces: > 00:11:22 [ ] > Enslave to ovbond0 IP Address: _______ Netmask: ____ | > 11:22:33 [X] Enslaved to ovbond0 > 22:33:44 [X] Enslaved to ovbond0 > > [ Save Changes ] > > > 1. The user selects a bonding type and clicks "Add". The bonded interface > fields are displayed. > 2. The user clicks "Remove" to destroy the interface. When that happens, > any > enslaved Nic is released but not destroyed. > 3. If the user clicks the checkbox to enslave an interface then the IP > address and netmask fields go away. So is this a UI that appears on an 'Edit Node' page? How does the user get to this page? And how would it look if there were multiple Bond objects? (i.e. is Bonded Interface Alias a drop down list?) What about configuring the IP addresses statically for interfaces that are not bonded? As an aside, we should probably allow interfaces to be 'labeled'. i.e. For each Interface object associate a label that can be used by a hardware Admin to know what physical network that interface is attached to. Interface with MAC 11:22:33:44:55:66 is on "LAN A" Or something like that. Bonded interfaces all need to be on the same physical network (so have the same label) and the Label associated with a set of bonded interfaces is the same as the underlying interfaces. Perry From jim at meyering.net Fri Sep 12 19:01:17 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 12 Sep 2008 21:01:17 +0200 Subject: [Ovirt-devel] [PATCH docs] Initial commit of Using Ovirt Admin UI Message-ID: <87fxo5dw8y.fsf@rho.meyering.net> FYI, here's a patch from Susan Burgess that I pushed several hours ago: I'm omitting all the binary parts, of course. >From 4a87b5217e90225c81e64c90f0711d92fc5d07d0 Mon Sep 17 00:00:00 2001 From: Susan Burgess Subject: [PATCH docs] Initial commit of Using Ovirt Admin UI Date: Fri, 12 Sep 2008 16:49:21 +1000 --- Using_the_oVirt_Admin_UI/Makefile | 14 + Using_the_oVirt_Admin_UI/en-US/Appendix-B.xml | 42 + Using_the_oVirt_Admin_UI/en-US/Appendix.xml | 14 + Using_the_oVirt_Admin_UI/en-US/Author_Group.xml | 15 + Using_the_oVirt_Admin_UI/en-US/Book_Info.xml | 30 + Using_the_oVirt_Admin_UI/en-US/Chapter.xml | 25 + Using_the_oVirt_Admin_UI/en-US/Getting-Started.xml | 259 ++ Using_the_oVirt_Admin_UI/en-US/Glossary.xml | 390 ++ .../en-US/Installing-the-Admin-UI.xml | 405 ++ .../en-US/Introduction-to-oVirt.xml | 145 + .../en-US/Managing-User-Permissions.xml | 181 + Using_the_oVirt_Admin_UI/en-US/Managing-VMs.xml | 306 ++ .../en-US/Managing-the-Hardware.xml | 720 ++++ Using_the_oVirt_Admin_UI/en-US/Preface.xml | 91 + Using_the_oVirt_Admin_UI/en-US/Quick-Start.xml | 171 + .../en-US/Revision_History.xml | 42 + .../en-US/Sample-oVirt-Scenarios.xml | 393 ++ Using_the_oVirt_Admin_UI/en-US/Troubleshooting.xml | 14 + Using_the_oVirt_Admin_UI/en-US/Using_oVirt.ent | 4 + Using_the_oVirt_Admin_UI/en-US/Using_oVirt.xml | 22 + Using_the_oVirt_Admin_UI/en-US/images/AddHost.png | Bin 0 -> 31515 bytes .../en-US/images/AddNewHWPool.png | Bin 0 -> 26731 bytes .../en-US/images/AddNewStorageServer.png | Bin 0 -> 27810 bytes .../en-US/images/AddNewStorageServerView.png | Bin 0 -> 37395 bytes .../en-US/images/AddNewUser.png | Bin 0 -> 35798 bytes .../en-US/images/AddNewVMPool.png | Bin 0 -> 25993 bytes .../en-US/images/AddStorage.png | Bin 0 -> 57297 bytes .../en-US/images/AddStorageView.png | Bin 0 -> 38595 bytes Using_the_oVirt_Admin_UI/en-US/images/AddVM.png | Bin 0 -> 42446 bytes .../en-US/images/Add_StorageSever2.jpg | Bin 0 -> 159949 bytes .../en-US/images/DeleteVM1.png | Bin 0 -> 38045 bytes .../en-US/images/DeleteVM2.png | Bin 0 -> 32769 bytes .../en-US/images/HWresourceMenu.png | Bin 0 -> 17825 bytes .../en-US/images/HostTab.jpg.svg | 60 + .../en-US/images/IconHWPool.png | Bin 0 -> 1070 bytes .../en-US/images/IconVMPool.png | Bin 0 -> 685 bytes Using_the_oVirt_Admin_UI/en-US/images/MoveHost.png | Bin 0 -> 27347 bytes .../en-US/images/MoveHostNewPool.png | Bin 0 -> 26758 bytes .../en-US/images/MoveStorageNewPool.png | Bin 0 -> 32241 bytes .../en-US/images/MoveStorageNewPoolView.png | Bin 0 -> 35569 bytes .../en-US/images/MoveStorageNewPoolView1.png | Bin 0 -> 35100 bytes .../en-US/images/MoveStorageServer.png | Bin 0 -> 37076 bytes .../en-US/images/MoveStorageServer1.png | Bin 0 -> 36189 bytes .../en-US/images/MoveStorageServerView.png | Bin 0 -> 38208 bytes .../en-US/images/QS1-SummaryTab.jpg | Bin 0 -> 23858 bytes .../en-US/images/QS1-SummaryTab.png | Bin 0 -> 86225 bytes .../en-US/images/StorageTab.png | Bin 0 -> 21656 bytes .../en-US/images/UserAccessTab.png | Bin 0 -> 19384 bytes .../en-US/images/UserAccessTab_roleMenu.png | Bin 0 -> 50512 bytes .../en-US/images/UserChangeRole.png | Bin 0 -> 29874 bytes .../en-US/images/VMActions1.png | Bin 0 -> 27317 bytes .../en-US/images/VMActions2.png | Bin 0 -> 27088 bytes .../en-US/images/VMProperties.png | Bin 0 -> 66173 bytes Using_the_oVirt_Admin_UI/en-US/images/VMTab.png | Bin 0 -> 29447 bytes .../en-US/images/VPool_SummaryTab.jpg | Bin 0 -> 242345 bytes .../en-US/images/VPool_SummaryTab.png | Bin 0 -> 50970 bytes .../en-US/images/VPool_VMTab.png | Bin 0 -> 56846 bytes Using_the_oVirt_Admin_UI/en-US/images/VRMenu.png | Bin 0 -> 22650 bytes .../en-US/images/ViewHWResources.png | Bin 0 -> 75606 bytes .../en-US/images/ViewHosts.png | Bin 0 -> 33208 bytes .../en-US/images/ViewVMPool.png | Bin 0 -> 34258 bytes .../en-US/images/ViewVMResources.png | Bin 0 -> 51420 bytes .../en-US/images/amyadmin5.png | Bin 0 -> 108462 bytes .../en-US/images/helpbutton.png | Bin 0 -> 17253 bytes Using_the_oVirt_Admin_UI/en-US/images/icon.svg | 3936 ++++++++++++++++++++ .../en-US/images/logical_arch2.gif | Bin 0 -> 20208 bytes .../en-US/images/navpanel-addhwresource.png | Bin 0 -> 1171 bytes .../en-US/images/navpanel-addvmresource.png | Bin 0 -> 821 bytes .../en-US/images/navpanel-delete.png | Bin 0 -> 539 bytes .../en-US/images/navpanelicons.png | Bin 0 -> 2151 bytes .../en-US/images/oVirtInterface.png | Bin 0 -> 58844 bytes .../en-US/images/whatisovirtNEW.png | Bin 0 -> 31892 bytes 72 files changed, 7279 insertions(+), 0 deletions(-) create mode 100644 Using_the_oVirt_Admin_UI/Makefile create mode 100644 Using_the_oVirt_Admin_UI/en-US/Appendix-B.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Appendix.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Author_Group.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Book_Info.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Chapter.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Getting-Started.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Glossary.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Installing-the-Admin-UI.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Introduction-to-oVirt.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Managing-User-Permissions.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Managing-VMs.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Managing-the-Hardware.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Preface.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Quick-Start.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Revision_History.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Sample-oVirt-Scenarios.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Troubleshooting.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/Using_oVirt.ent create mode 100644 Using_the_oVirt_Admin_UI/en-US/Using_oVirt.xml create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddHost.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddNewHWPool.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddNewStorageServer.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddNewStorageServerView.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddNewUser.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddNewVMPool.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddStorage.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddStorageView.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/AddVM.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/Add_StorageSever2.jpg create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/DeleteVM1.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/DeleteVM2.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/HWresourceMenu.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/HostTab.jpg.svg create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/IconHWPool.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/IconVMPool.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveHost.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveHostNewPool.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveStorageNewPool.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveStorageNewPoolView.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveStorageNewPoolView1.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveStorageServer.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveStorageServer1.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/MoveStorageServerView.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/QS1-SummaryTab.jpg create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/QS1-SummaryTab.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/StorageTab.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/UserAccessTab.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/UserAccessTab_roleMenu.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/UserChangeRole.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VMActions1.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VMActions2.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VMProperties.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VMTab.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VPool_SummaryTab.jpg create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VPool_SummaryTab.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VPool_VMTab.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/VRMenu.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/ViewHWResources.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/ViewHosts.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/ViewVMPool.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/ViewVMResources.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/amyadmin5.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/helpbutton.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/icon.svg create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/logical_arch2.gif create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/navpanel-addhwresource.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/navpanel-addvmresource.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/navpanel-delete.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/navpanelicons.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/oVirtInterface.png create mode 100644 Using_the_oVirt_Admin_UI/en-US/images/whatisovirtNEW.png diff --git a/Using_the_oVirt_Admin_UI/Makefile b/Using_the_oVirt_Admin_UI/Makefile new file mode 100644 index 0000000..963d546 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/Makefile @@ -0,0 +1,14 @@ +#Makefile for Using_oVirt + +XML_LANG = en-US +BRAND = oVirt + +#OTHER_LANGS = as-IN bn-IN de-DE es-ES fr-FR gu-IN hi-IN it-IT ja-JP kn-IN ko-KR ml-IN mr-IN or-IN pa-IN pt-BR ru-RU si-LK ta-IN te-IN zh-CN zh-TW +TRANSLATIONS = $(XML_LANG) $(OTHER_LANGS) + +#CHUNK_FIRST = 0 +#CHUNK_SECTION_DEPTH = 1 + +COMMON_CONFIG = /usr/share/publican +include $(COMMON_CONFIG)/make/Makefile.common + diff --git a/Using_the_oVirt_Admin_UI/en-US/Appendix-B.xml b/Using_the_oVirt_Admin_UI/en-US/Appendix-B.xml new file mode 100644 index 0000000..18af05b --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Appendix-B.xml @@ -0,0 +1,42 @@ + + + + + + oVirt Parts and Connections + This document provides a high-level view of oVirt's moving parts. + + oVirt consists of the following bits + + + + A stripped-down Fedora build that installs and runs off a CD, a usb key, or a ramdisk (over PXE) on a physical host. The build contains all the necessary pieces to support hosting and managing virtual machines on the host. + + A web-based management UI application for oVirt hosts, users, and vms + The FreeIPA ldap/kerberos identity, policy, and audit application + + This is how the parts work together: + + + The FreeIPA application handles kerberos administration, authentication, and authorization for the entire app. + + + An oVirt host image is provided with the application. On boot (via cdrom, flash drive, or PXE), the host image loads its keytab and kerberos configuration from the oVirt management application and announces itself. + + + The oVirt management application authenticates with FreeIPA and can then communicate with the libvirtd running on each oVirt host via an encrypted SASL connection using the libvirt SASL infrastructure. + + + An iSCSI target, running on any machine reachable from the oVirt host, provides disk storage for oVirt guests. The oVirt host will automatically make the storage targets on the iSCSI server it is configured for available for oVirt guest installs. + + + + + + + + + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Appendix.xml b/Using_the_oVirt_Admin_UI/en-US/Appendix.xml new file mode 100644 index 0000000..39ac1e4 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Appendix.xml @@ -0,0 +1,14 @@ + + + + + + + + Revision History + + Empty para tags are not allowed (they break translations), so this boilerplate text is here to keep place until actual text is added. (Note: the file is currently not included in built versions of this book: edit the appropriate xi:include in 'Using_oVirt.xml' to include this file.) + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Author_Group.xml b/Using_the_oVirt_Admin_UI/en-US/Author_Group.xml new file mode 100644 index 0000000..98def69 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Author_Group.xml @@ -0,0 +1,15 @@ + + + + + + Susan + Burgess + + Red Hat + Engineering Content Services + + sburgess at redhat.com + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Book_Info.xml b/Using_the_oVirt_Admin_UI/en-US/Book_Info.xml new file mode 100644 index 0000000..b15f225 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Book_Info.xml @@ -0,0 +1,30 @@ + + + + + Using oVirt + A Guide to the oVirt User Interface + 0.1 + 1 + oVirt + 0.6 + This online help describes how to use the oVirt Administration User Interface, a means of managing virtual machines and resources. + + + + + + Logo + + + + &YEAR; + &HOLDER; + + + + + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Chapter.xml b/Using_the_oVirt_Admin_UI/en-US/Chapter.xml new file mode 100644 index 0000000..db1ee48 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Chapter.xml @@ -0,0 +1,25 @@ + + + + + Test + + This is a test paragraph + +
        + Section 1 Test + + Test of a section + +
        + +
        + Section 2 Test + + Test of a section + +
        + +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Getting-Started.xml b/Using_the_oVirt_Admin_UI/en-US/Getting-Started.xml new file mode 100644 index 0000000..63c1bea --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Getting-Started.xml @@ -0,0 +1,259 @@ + + + + + Getting Started + + This section enables you to start using the oVirt Administration User Interface. The oVirt Administration User Interface is a graphical interface that enables you to easily manage hosts, storage, user permissions and virtual machines. The parts of the interface and how they work together are described in this section. The user interface provides visibility to your virtualized system at a glance, providing immediate information on loads, performance and usage. + + +
        + Logging on + oVirt relies on Kerberos for security. Log in using the kinit command: + + For example, +kinit ovirtadmin at PRIV.OVIRT.ORG + + Enter the password when prompted. + + + Note: + In the developer installation, described in this is not necessary since the developer appliance maintains a continuous kerberos ticket for the ovirtadmin user. + + + In the bundled installation, kinit as ovirtadmin. This is effectively logging in as the superuser. + + +
        + +
        + Using the Interface + The user interface enables you to control large or small numbers of managed nodes, create virtual machines and interact with them, and manage users. + + + + + + + +
        + About the Interface + + + + + + + + The ovirt Administration User Interface consists of the following components: + + + The Resource Navigator on the left-hand side of the page. The Resource Navigator contains: + + + A browser tree consisting of hardware and virtual machine pools. + + + + A toolbar with buttons to Add or Delete Hardware or Virtual Machine Pools. + + + + + + The Content Pane on the right-hand side of the page. The Content Pane displays the contents of a resource pool, and menus and toolbars that enable you to manage the resources. In some instances, there may also be descriptions and graphics that add meaning to the lists. It contains: + + + A menu bar across the top of the page that contains from left to right: + + + The Product Name + + + + Contextual Menu Options. There are two menus, the Hardware Resource menu and the Virtual Machines menu. + + + + Search + + + + Online Help + + + + + + The main contents pane that displays information about the selected resource or resource pool. The contents panel may contain lists, descriptions or graphic information, check boxes, action buttons and tabs depending on the context. + The contents panel of the Activity page presents a richness of contextual information that enables you to manage, monitor and view the virtualized universe at a glance. + + + + The Details pane is the lower part of the content pane. The Details pane displays information about the selected item in the main content pane. + + + + + + +
        +
        + Using the Navigator + The Navigator enables you to locate resources ( that is, hardware pools and virtual machine pools) easily and quickly, displaying the pools as nodes in their existing context. You can also use the Navigator to add or delete hardware pools or virtual machine pools. + The Navigator displays the hardware and virtual resources in a hierarchy. Hardware Pools can have several levels of hardware and virtual machine subpools. To view sub-pools, click the Expand button on the parent pool. + + Hardware Pools display as follows: + + + + + + + Virtual Machine Pools nodes display as follows: + + + + + + + To navigate to a resource: + + + Click on the hardware pool in the navigator. The Summary page and the Hardware resource menu display in the Content Pane. + + + + Click on the Expand icon to display the virtual machine pools, or hardware sub-pools attached to the hardware resource. + + + + Click on a Virtual Machine Pool in the Navigator. The Summary page and the Virtual Machines menu display in the Content Pane. + + + + + To manage resources from the Navigator, you can use the + Navigator menu at the bottom of the panel. + + + + + + From left to right the buttons are: + + Add Hardware Pool + Add Virtual Pool + Delete Selected Pool + + Navigate to the appropriate Hardware pool on the browser tree: + + + To add a hardware pool or sub-pool, click the Add Hardware button. The new hardware pool displays in the Navigator. + + + + To add a virtual machine pool, click the Add Virtual Machine Pool button. The new Virtual Machine pool displays below the selected node. + + + + To delete a pool, click the Delete Selected Pool button. The selected pool is removed from the browser tree. + + + + +
        +
        + Using the Content and Detail Panes + The Content Pane on the right-hand side of the oVirt Administration User Interface displays information on resources or resource collections, and enables management of the resources by means of menus, toolbars and buttons. It displays information and menus appropriate to the pool selected in the Navigator. For example: + + + If a hardware pool is selected in the Navigator, the Hardware Resources Menu and toolbar display in the Contents Pane. + + + If a virtual machine pool is selected in the Navigator, the Virtual Machines Pool menu and toolbar display in the Contents Pane. + + + + The Details pane on the lower part of the Content pane displays details on the item selected in the Content pane. +
        + The Menubar and Toolbar + The menubar and toolbar are part of the Content Pane that occupies the right panel of the OUI page. The menus available are: + + + Hardware Resource menu and toolbar + + + + + + + + + + + Virtual Resource menu and toolbar + + + + + + + + + + These menus are described fully in the following sections. +
        + +
        +
        + + +
        + Using Online Help + This online help can be accessed from the oVirt Administration User Interface. Click the Help button on the top right hand corner of the page. + + + + + +
        + + + + +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Glossary.xml b/Using_the_oVirt_Admin_UI/en-US/Glossary.xml new file mode 100644 index 0000000..320a0b6 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Glossary.xml @@ -0,0 +1,390 @@ + + + + + + This glossary is intended to define the terms used in the oVirt Administration User Interface Guide. + + + A + + test + + + No current entries. + + + + + + B + + Bare-metal + + + The term bare-metal refers to the underlying physical architecture of a computer. Running an operating system on bare-metal refers to dom0 (see) or a natively installed operating system. + + + + + + C + + test + + + No current entries. + + + + + + D + + dom0 + + + Also known as the or host operating system. + + + dom0 refers to the host instance of Red Hat Enterprise Linux running the which facilitates virtualization of guest operating systems. Dom0 runs on and manages the physical hardware and resource allocation for itself and the guest operating systems. + + + + + Domains + dom0 or domU + + + + and are both domains. Domains run on the . The term domains has a similar meaning to and the two are technically interchangeable. A domain is a Virtual Machine. + + + + + domU + + + domU refers to the guest operating system which run on the host system ( ). + + + + + + E + + test + + + No current entries. + + + + + + F + + Full Virtualization + + + You can deploy Red Hat Virtualization in one of two choices: full virtualization or paravirtualization. Full virtualization provides total abstraction of the underlying physical system ( ) and creates a new virtual system in which the guest operating systems can run. No modifications are needed in the guest OS or application (the guest OS or application is not aware of the virtualized environment and runs normally). Para-virtualization requires user modification of the guest operating systems that run on the virtual machines (these guest operating systems are aware that they are running on a virtual machine) and provide near-native performance. You can deploy both paravirtualization and full virtualization across your virtualization infrastructure. + + + + + Fully Virtualized + + + See . + + + + + + G + + Guest System + + + Also known as . + + + + + + H + + Hardware Virtual Machine + HVM + + + See + + + + + hypervisor + + + The hypervisor is the software layer that abstracts the hardware from the operating system permitting multiple operating systems to run on the same hardware. The hypervisor runs on the host system allowing virtual machines to run on the host's hardware as well. + + + + + Host + + + The host operating system, also known as . + + + The host environment runs the software for and guest systems. + + + + + + I + + test + + + No current entries. + + + + + + J + + test + + + No current entries. + + + + + + K + + Kernel-based Virtual Machine + KVM + + + KVM is a kernel module which will be incorporated into future releases of Red Hat Enterprise Linux. KVM is presently available in the fedora Liunx distribution and other Linux distributions. + + + + + Kerberos + + + + Kerberos is the name of a computer network authentication protocol, that allows individuals communicating over a non-secure network to prove their identity to one another in a secure manner. It is aimed primarily at a client-server model, and it provides mutual authentication ? both the user and the server verify each other's identity. Kerberos protocol messages are protected against eavesdropping and replay attacks. The protocol was named after the Greek mythological character Kerberos (or Cerberus), known in Greek mythology as being the monstrous three-headed guard dog of Hades. + + + + + + L + + LDAP + + The Lightweight Directory Access Protocol, or LDAP is an application protocol for querying and modifying directory services running over TCP/IP. + A directory is a set of objects with similar attributes organized in a logical and hierarchical manner. + + + + + + M + + Migration + + + See also + + + Migration refers to the process of moving a para-virtualized guest images from one Red Hat Virtualization server to another. This other server could be on the same server or a different server, including servers in other locations. + + + + + MAC Addresses + + + The Media Access Control Address is the hardware address for a Network Interface Controller. In the context of virtualization MAC addresses must be generated for virtual network interfaces with each MAC on your local domain being unique. + + + + + + N + + test + + + No current entries. + + + + + + O + + test + + + No current entries. + + + + + + P + + Para-virtualization + + + Para-virtualization uses a special kernel, sometimes referred to as the xen kernel or kernel-xen to virtualize another environment while using the hosts libraries and devices. A para-virtualized installation will have complete access to all devices on the system. Para-virtualization is significantly faster than full virtualization can can be effectively used for load balancing, provisioning, security and consolidation advantages. + + + As of Fedora 9 a special kernel will no longer be needed. Once this patch is accepted into the main Linux tree all linux kernels after that version will have para-virtualization enabled or available. + + + + + Para-virtualized drivers + + + Para-virtualized drivers are device drivers that operate on fully virtualized linux guests. These drivers greatly increase performance of network and block device I/O for fully virtualized guests. + + + + + + Q + + test + + + No current entries. + + + + + + R + + Relocation + + + Another term for usually used to describe moving a virtual machine image across geographic locations. + + + + + + S + + Single Sign-On + + Single sign-on (SSO) is a method of access control that enables a user to authenticate once and gain access to the resources of multiple software systems. Single sign-off is the reverse process whereby a single action of signing out terminates access to multiple software systems. + + + In a homogeneous IT infrastructure or at least where a single user entity authentication scheme exists or where a user database is centralized, single sign-on is a visible benefit. All users in this infrastructure would have a single set of authentication credentials; for example, in an organization which stores its user database in a LDAP database. All information processing systems can use such an LDAP database for user authentication and authorization, which in turn means single sign-on has been achieved organization-wide. + + + Benefits of single sign-on include reducing the amount of internal fraud by malicious employee contact, convenience of password access, security on all levels of entry/exit/access to systems, and centralized reporting for compliance adherence. + + + + + + T + + test + + + No current entries. + + + + + + U + + UUID + + Universally Unique Identifier is an identifier standard standardized by the Open Software Foundation (OSF) as part of the Distributed Computing Environment (DCE). The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve name conflicts. + + + + + + V + + Virtual cpu + vcpu + + + A system running Red Hat Virtualization has a number of virtual cpus, or vcpus. The number of vcpus is finite and represents the total number of vcpus that can be assigned to guest virtual machines. + + + + + Virtual Machines + vcpu + + + A virtual machine is a software implementation of a physical machine or programming language (for example the Java Runtime Environment or LISP). Virtual machines in the context of virtualization are operating systems running on virtualized hardware. + + + + + + W + + test + + + No current entries. + + + + + + X + + test + + + No current entries. + + + + + + Y + + test + + + No current entries. + + + + + + Z + + test + + + No current entries. + + + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Installing-the-Admin-UI.xml b/Using_the_oVirt_Admin_UI/en-US/Installing-the-Admin-UI.xml new file mode 100644 index 0000000..5ab492c --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Installing-the-Admin-UI.xml @@ -0,0 +1,405 @@ + + + + + Installing the oVirt Administration User Interface + + There are currently two ways to install oVirt. The developer version allows you to start using oVirt quickly with the minimal amount of hardware and configuration. The bundled version allows you to manage physical hardware. It requires a separately cabled network and a minimum of 2 machines to demonstrate the full power of oVirt. + + oVirt can also be installed and integrated manually with the services that come as part of the bundled install (including FreeIPA and postgres), however the manual method is not described in this document. + This guide, the oVirt Administration User Interface Online Help, distinguishes between commands to be run as root and commands to be run as a regular user. + + + Commands to be run as root are prefixed with a # symbol. + + + Commands to be run as a regular user are prefixed with a $ symbol. + + + + + + +
        + Installing oVirt Developer Version + + This section describes how to install the developer version of the oVirt Administration User Interface. Installing the developer version is the fastest way to get oVirt up and running and become familiar with the user interface. The developer version of the oVirt appliance cannot be used to manage physical hosts. To manage physical hosts, you must install the bundled version of the appliance, using the instructions in . + +
        + Prerequisites for the Development Version + + The developer version has the following prerequisites: + + + + + A machine that supports hardware virtualization. This machine is called a host machine throughout the rest of the document. + + + + Fedora 9 must be installed on the host machine with the latest versions of the following: + + + kernel version >= 2.6.24 + + + kvm version >= 60 + + + libvirt >= 0.4.1-3 + + + virt-manager + + + virt-viewer + + + + + + The Fedora 9 repository install tree or boot CD or DVD. + + + + +
        + Preparing to Install the Developer Version + + The following steps prepare your host machine for a successful installation of the oVirt Administration User Interface. + + + + Ensure that the host machine supports full hardware virtualization. If you have an Intel processor use this command: + +# cat /proc/cpuinfo | grep vmx + + or if you have an AMD processor use this command: + +# cat /proc/cpuinfo | grep svm + + + + Ensure that the correct bare metal kernel is available. + +# uname -r +2.6.24.14?107.fc9 + + + + Ensure that the kvm, libvirt and virt-manager packages are installed on the host machine. + + +# rpm -q libvirt kvm virt-manager + + + + Ensure that the host system has kvm, and kvm_intel or kvm_amd modules are loaded. For example, + +# lsmod | grep kvm + kvm_intel 29677 0 + kvm 88609 1 kvm_intel + + + + + +
        +
        + +
        + Installing the Appliance + This section describes how to install the developer version using the pre-built appliance provided on the oVirt website download page. + + + Note + You must be the root user to perform the installation. + + + + Download the appliance script onto the host machine. + + + + Uncompress the image to /var/lib/libvirt/images/ +# tar xf ovirt-developer-appliance-0.91-1-*.tar -C /var/lib/libvirt/images/ + + + + Run the create-wui-appliance.sh script to create the virtual machine: + +# cd /var/lib/libvirt/images/ovirt-developer-appliance-*; bash create-wui-appliance.sh -d "`pwd`" -v + + + + Remove the list of known hosts: + +#rm -Rf ~/.ssh/known_hosts + + + + + Start the virtual machine named developer. + +virsh start developer + + + + + Start up some fake managed nodes. These are additional KVM guests + on the same host machine, but they act as if they were separate + physical nodes. You can use up to 3 fake managed nodes, named + node3, node4, and node5. To start the + nodes: + +# virsh start node3 +# virsh start node4 +# virsh start node5 + + + + + Invoke the main oVirt page by running Firefox on the guest. + + +# ssh -fY root at 192.168.50.2 firefox -no-remote + + Enter the root password: ovirt + + A browser window opens displaying the oVirt User Administration Interface. + + + + + To connect to the console of a virtual machine running on a managed node: + +# ssh -fY root at 192.168.50.2 virt-viewer -c qemu+tcp://node3.priv.ovirt.org/system VM_NAME + + + + + + + Note + The kickstart can be copied to a local webserver + and modified so that the repos referenced in the kickstart point to local + mirrors. In this case, the command is: + +# create-wui-appliance.sh -t http://foo/f9-x86_64 -k http://foo/wui-rel-x86_64.ks -v + + + + +
        +
        +
        + Installing oVirt on a Physical Network + Set up the bundled oVirt appliance if you wish to manage physical hosts. This version allows you to manage physical hardware. It requires a minimum of 2 machines and a separately cabled network. + + + Note + You must be the root user to perform the installation. + +
        + Prerequisites + There are a number of prerequisites for the bundled install: + + + A machine that supports hardware virtualization. This machine is called a host machine throughout the rest of the document. + + + + The management host machine must have at least two network interfaces. + + + The managed nodes are one or more additional machines that support hardware virtualization. These machines are the physical machines on which VMs are run. + + + Fedora 9 must be installed on the host machine with the following: + + + kernel version >= 2.6.24 + + + kvm version >= 60 + + + libvirt >= 0.4.1-3 + + + virt-manager + + + virt-viewer + + + + + + The Fedora 9 repository install tree or boot CD or DVD. + + + +
        + Setting up the Hardware + This section describes how to set up the hardware for a simple bundled oVirt installation. + + + Set up the management node to enable it to run the management console as a KVM guest, and take over the second network card (for example, eth1) for a private oVirt network. + + + Set up the managed nodes. Connect the managed nodes to the same network as the second network interface on the management host. + + Set up the private network. This step is fully automated by create-wui-appliance.sh. + + Set up storage. + + +
        +
        +
        + Installing the Appliance + This section describes how to install the pre-built appliance from the oVirt website download page to manage physical hardware. Ensure that you have a free eth1 network interface so that the bridge works properly. + + + + + Download the appliance script onto the host machine. + + + + Uncompress the image to /var/lib/libvirt/images/ +# tar xf ovirt-developer-appliance-0.91-1-*.tar -C /var/lib/libvirt/images/ + + + + + Run the create-wui-appliance.sh script to create the virtual machine: +# cd /var/lib/libvirt/images/ovirt-developer-appliance-*; bash create-wui-appliance.sh -d "`pwd`" -b + + + + + Remove the list of known hosts: + +#rm -Rf ~/.ssh/known_hosts + + + + + Start the virtual machine. + +virsh start bundled + + + + + Start up some managed nodes. + +# virsh start node3 +# virsh start node4 + + + + + Invoke the main oVirt page by running Firefox on the guest. + +ssh -fY root at 192.168.50.2 firefox -no-remote + + Enter the root password: ovirt + + A browser window opens displaying the oVirt User Administration Interface. + + + To connect to the console of a virtual machine running on a managed node: + +# ssh -fY root at 192.168.50.2 virt-viewer -c qemu+tcp://node3.priv.ovirt.org/system VM_NAME + + + + + + + Note + The kickstart can be copied to a local webserver + and modified so that the repos referenced in the kickstart point to local + mirrors. In this case, the command is: + +# create-wui-appliance.sh -t http://foo/f9-x86_64 -k http://foo/wui-rel-x86_64.ks -b + + + +
        +
        + +
        + About create-wui-appliance.sh + create-wui-appliance is the pre-built appliance that is available from the oVirt website download page. Use this appliance to install either version of oVirt. + If you have not already done so, you can download the appliance onto the host machine, and follow the instructions in either or to install the appliance. + + + create-wui-appliance.sh Parameters + + Usage + + + + + create-wui-appliance.sh -i install_iso | -t install_tree [-d image_dir] [-a x86_64|i686] + + + + + + + + + + + Parameter + + Description + + + + + + -i + Location of installation ISO (required if -t not present) + + + -t + Location of installation tree (required if -i not present) + + + -k + URL of kickstart file for use with installation tree + + + -d + Directory to place virtual disk (default: /var/lib/libvirt/images) + + + -a + Architecture for the virtual machine (default: x86_64) + + + -v + Install in developer mode + + + -b + Install in bundled mode + + + -h + Display this help and exit + + + + +
        +
        +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Introduction-to-oVirt.xml b/Using_the_oVirt_Admin_UI/en-US/Introduction-to-oVirt.xml new file mode 100644 index 0000000..c905173 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Introduction-to-oVirt.xml @@ -0,0 +1,145 @@ + + + + + Introduction + + oVirt is the next step in Red Hat's Virtualization platform for any application, anywhere, anytime because it provides a simple yet powerful way to manage virtual machines. With the enormous flexibility and choice that the Red Hat Virtualization platform affords, you need an easy, visual way of managing virtual machines (VMs) that could be running thousands of software applications, deployed in a myriad ways, using different operating systems and hardware platforms. + + + + + + + + + From running a few VMs on a single host to managing thousands of VMs over hundreds of hosts on a network, oVirt makes virtualization easy and scales to meet your needs. The oVirt Administration User Interface runs on any platform with a web browser that can authenticate with a kerberos server. + +
        + Overview + + oVirt allows centralized management of your computing environment, reducing the costs of management of the infrastructure and allowing people to focus on their core tasks instead of the infrastructure itself. + + The oVirt host image is a small, stateless Fedora build that can run from a flash drive, a CDROM, or entirely in RAM via PXE. It enables users to manipulate virtual machines, provides a secure authenticated channel (GSSAPI/SASL2) for remote access and allows easy management and allocation of storage. + + + oVirt has several components: + + + + + + + + + A host browser and status update daemon that keeps the oVirt + database in sync with the available hosts and virtual machines on + the network, updating the oVirst database when new hosts appear, old hosts disappear, and VMs change their status; + + + + A task engine that reads a task queue from the oVirt database and + makes appropriate libvirt calls, updating the database on the + success or failure of those tasks; + + + + A monitoring agent that receives performance data from oVirt + hosts and stores it for display in the user interface; + + + An administration node that allows users to manage virtual + machines, view usage and performance, manage hosts and storage + servers, manage user permissions, and perform many other + management tasks. + + + + +
        + + +
        + Prerequisites + To use the oVirt Administration UI, the following is required: + + + An oVirt host image. On boot (via cdrom, flash drive, or PXE), the host image loads its keytab and kerberos configuration from the oVirt management application or from local storage and announces itself. + + + + A kerberos/LDAP server for authentication and authorization (oVirt ships with FreeIPA). + + + A database for storing oVirt data. oVirt comes bundled with Postgres. Future releases will support additional databases. + + DNS/DHCP services on the local LAN. If not available, oVirt can provide them for oVirt hosts over a private network if desired. + + + Network attached storage (NFS, iSCSI or Fibre Channel) for hosting oVirt Guests running on any machine reachable from the oVirt host. The oVirt host will automatically make the storage targets on the iSCSI server it is configured for available for oVirt guest installs. + + + + + +
        +
        + Types of Users + Understanding what kind of user you are will help you to quickly identify the features of oVirt that are of the most benefit to you, and the sections where you can find this information. There are two kinds of users, developers and users. Users can range from individuals, to small + businesses or labs to enterprise large-scale deployments. +
        + Open Source Developers + Red Hat supports open source developers and so we'd like ourselves and others to be able to use the oVirt system easily and effectively. Follow the instructions in + to quickly get a development system up and running. Once a system is up and running you can use the oVirt management interface to create new Virtual Machines to run on the managed node. + +
        +
        + Users + Medium to large scale enterprises who need to manage large numbers of virtual machines and physical hosts need a system that scales to their usage. oVirt is designed to scale from a small number of virtual machines and hosts to thousands of virtual machines and hosts. There are three different types of users in the enterprise: + + Hardware Administrators + + + Rack physical hosts and provision them with the oVirt managed node image + Create Virtual Pools for teams and assign hosts and storage to teams of users + Group hosts and storage in physical networks + Connect network attached storage (iSCSI, NFS) + Manage top-level user group membership + View usage and loading of resources, prepare hosts for downtime by migrating VMs + + + + + Team administrators + + + Manage user quotas, permissions, and subgroups for team hardware + + + Monitor physical hosts for resource issues, bottlenecks + + + Maintain available team VM install images/appliances + + + Define SLA for team hardware, in terms of: CPU availability; memory usage; network bandwidth + + + + oVirt Users + + + Connect to VMs from the browser interface with a console plug-in + Create, destroy, pause, resume, save, restore VMs on a team hardware collection + Configure VMs as virtual clusters + View current and historic performance information for VMs to determine SLA needs + + + + +
        +
        + +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Managing-User-Permissions.xml b/Using_the_oVirt_Admin_UI/en-US/Managing-User-Permissions.xml new file mode 100644 index 0000000..68c0328 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Managing-User-Permissions.xml @@ -0,0 +1,181 @@ + + + + + Managing User Access + oVirt's user access management is integrated with the Kerberos infrastructure that provides a single sign-on environment. oVirt is tightly integrated with the freeIPA project, so that administrators can authenticate, authorize, and audit their virtual resources across the enterprise. Permissions are defined by User Roles which allocate specific permissions to users in hardware or virtual pools. oVirt accesses the LDAP database for valid users, who can then be set up with permissions for oVirt resources. + Users must be logged in via Kerberos to access oVirt. oVirt user permissions determine the hardware and virtual pools that are accessible to the user. + + +
        + Assigning Permissions with User Roles + oVirt has four hierarchical permission levels that are reflected in four User Roles. The top-level role implies all lower levels and so on, with each role assuming all the permissions of the roles beneath it. Thus, the top-level role of Super Admin has its own permissions as well as all the permissions of all the roles beneath it. In contrast, because Monitor is the lowest role, it has only its own permissions. + Permission levels are attached to "pools", either hardware pools or VM resource + pools, and they are inherited by subpools of those pools. Individual VMs do not have permission levels. + +
        + How User Roles Work + oVirt's hierarchical permissions model means that user permissions are set by the hardware administrator at the top level, and the finer detail is added by the team administrator: + + Rather than specifying which box a particular application is running on, hardware administrators dedicate machines and storage to discrete groups, which then treat those resources generically. + Team administrators determine hardware and virtual resource usage based on software-defined resource limits and SLA definitions. + Users manage their own VMs, within their assigned quota/SLA, as required without requiring administrator attention. + +
        + User Roles in oVirt + Users are granted access in a particular role within a hardware or virtual pool. However users can be granted access to multiple pools, and can have different roles in different pools. + + User Roles are: + + User Admin or Super Admin + A User Admin or Super Admin user can grant permissions and + quota to other users, along with all other permissions. Typically the hardware administrator is the Super Admin, who can assign permissions to groups or teams, allowing access to resources and storage. + + Administrator + An Administrator can create and delete hardware + pools and virtual machine resource pools, and create, delete, and + manipulate the objects in those pools (hosts, storage servers, quota, + VMs,). + This includes the ability to create and delete + VMs in a VM resource pool. + Typically the team administrator is the Administrator. The Administrator must understand and determine the physical and virtual resource that a team requires for their work. + + + User + A user can access a VM page and do the following (with a VM in a VM resource pool): + + start + stop + suspend + resume + restore + + + + Typically, most users who need to use the VMs for their work will have this role. + + Monitor or View + A user with Monitor or View privileges can only view objects in the assigned VM pool. + + +
        +
        +
        + + +
        + Managing Users + + + The oVirt Administration User Interface provides the ability to manage users. Users are created within a hardware or virtual resource pool context, and cannot be moved between resource pools. However, user roles can be changed as necessary by the team or hardware administrator. + +
        + The User Access Page + Before you can assign user permissions, you must be logged into the oVirt Administration User Interface as the administrator. This gives you the requisite privileges. + + + kinit as the kerberos admin user. (If you are using the developer installation this is "ovirtadmin"). + Browse to the oVirt Administration User Interface. + Navigate either to top-level, or required resource or virtual pool and click User Access on the menubar. + The User Access page displays. The list of existing users, their roles and status display in the list. + + + + + + + + + You can add users from the LDAP database, change user roles within a pool and remove users for the selected pool. + + + +
        +
        + Adding Users to a Pool + To add a user to a hardware or virtual resource pool: + + Select the appropriate Hardware or Virtual Resource pool. + From the menu, select User Access. The User Access page displays. + + + + + + + Click Add User on the tool bar. The Add User dialog box displays. + + + + + + + Select the appropriate Role from: + + Super Admin + Administrator + User + Monitor + + + Select the User name from the Users listbox. + Click Add User. + The new user's User name displays in the list of existing users. + +
        +
        + Changing Users Roles + Users may need to change their roles as required by project requirements o or staff movement. For example, a team administrator may be required to take on the super admin role, or a person with monitor privileges may need user privileges. + To change a User role: + + Select the appropriate Hardware or Virtual Resource pool. + From the menu bar, select User Access. The User Access page displays a list of existing users. + Select the check box to the left of the user name. + + Click Change Role on the tool bar. The Change Role menu displays if at least one user was selected in the previous step. + + + + + + + + + Click the required role from the list: + + Super Administrator + Administrator + User + Monitor + + + The User name appears in the list of existing users on the page with the changed role. + + +
        +
        + Revoking User Permissions + You can revoke a user's permission to view or work in a hardware or virtual resource pool. + To revoke user permissions: + + Select the appropriate Hardware or Virtual Resource pool. + From the menu, select User Access. The User Access page displays with a list of existing users. + Select the check box to the left of the user name. + + Click Remove on the tool bar. A message displays prompting you to select at least one user if no user was selected in the previous step. + + + + A message prompts you to confirm. Click OK. + + + A message confirms the removal and the user name no longer appears in the list of existing users. + + +
        + +
        + +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Managing-VMs.xml b/Using_the_oVirt_Admin_UI/en-US/Managing-VMs.xml new file mode 100644 index 0000000..97fc154 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Managing-VMs.xml @@ -0,0 +1,306 @@ + + + + + Managing Virtual Resources + + Managing virtual resources is a simple task using oVirt's Administration User Interface. Virtual resources include virtual pools and virtual machines. Virtual machines run inside the Virtual Machine Pools. This section describes how to view, set up and manage virtual resources using the oVirt Administration User Interface. + Typically, hardware administrators or team administrators set up the virtual resources, users start and manage the virtual machines required for their work. + + +
        + Working with Virtual Machine Pools + Virtual Machines reside in virtual pools. While users can use and manage virtual machines according to their needs, team administrators would typically set up the virtual pools. Virtual pools are set up within a hardware resource pool, and once created cannot be moved to another hardware resource pool, so it is important to provide the virtual resource pool with the correct hardware resources. +
        + Viewing Virtual Pools + + The oVirt Administration UI page provides an overview of the resources, their availability, and current levels of load of the entire system. + + To view the resources of a specific Virtual Machine Pool: + + + Use the Navigator panel to select the Virtual Machine Pool node. + + + + Click the pool name and the Summary Page displays on the Virtual Contents Pane on the right-hand side of the oVirt Administration User Interface. + + + + + + + + + + + + + The Virtual Machine Pool page displays a list of the virtual machines and the following information about the pool quota: + + CPU - Usage and Availability + Memory - Usage and Availability + NICs - Usage and Availability + Number of Virtual Machines - Usage and Availability + Storage - Usage and Availability + + + + + To see details of the virtual machines, click Virtual Machines on the menu bar. The Virtual Machines page displays the Virtual Machine toolbar and the list of virtual machines, if any, in the resource pool. + + + + + + + + You can use the Virtual Machine toolbar to add, delete and manage the virtual machines within the pool. + + +
        + +
        + Creating Virtual Machine Pools + Creating a Virtual Machine Pool in which the virtual machines can run in an optimal fashion is crucial for system performance. For example, the hardware administrator might need to create a VM Resource Pool out of 5 physical nodes and a set of iSCSI targets. Once the hardware resources are set up the next step is to create the Virtual Machine Pools. + + + + To create a resource pool from the Navigator Panel + + Use the Navigator panel to select the Hardware Resource Pool node within which to create the Virtual Machine Pool. The Summary page and the Hardware Resource menu displays. + + + + + + + + + + + + The Navigator toolbar appears at the bottom on the panel. Click Add Virtual Machine Pool. The Add Virtual Machine Pool dialog box displays. + + + + + + + + + + + Enter the name of the new resource pool and click the Create Virtual Machine Pool button. A message indicates that the virtual machine resource pool was successfully created. Click OK + + + Note: + You must enter a name for the new Virtual Machine Resource Pool. oVirt validates the name field and prompts you to enter a name before the resource pool is created. + + + + You can now add virtual machines and users to the new Virtual Machine Pool. Click the appropriate option on the menubar. Adding virtual machines is described later in this section. + + + + Virtual Machine Pool Names + Names can be any combination of alphanumeric characters, spaces and special characters. Valid name lengths are 1-256 characters. It is recommended that you use meaningful names for the resource pools. + +
        +
        + Deleting Virtual Machine Pools + From time to time you will need to remove resource pools; for example, a project no longer requires a particular Virtual Machine Pool, or you need to optimise performance of the data center. Virtual Machine Pools are removed from the Navigator panel. + + Note + You can only remove a Virtual Machine Pool if there are no virtual machines in the pool. + + + To delete a resource pool: + + Use the Navigator panel to select the required Virtual Machine Pool node. The Summary page and the Virtual Resource menu displays. + + + + + + + + + + + + The Navigator toolbar appears at the bottom on the panel. Click Delete Selected Pool. A message appears prompting you to confirm that you wish to delete the selected resource. Click OK. + + + + The Virtual Machine Pool is removed and no longer displays in the Navigator Panel. + + + +
        +
        + +
        + Working with Virtual Machines + Virtual machines are created within Virtual Machine Pools. +
        + Viewing Virtual Machines + + Navigate to an existing Virtual Machine Pool and click the Virtual Machines tab to view, add or manage virtual machines. The Virtual Resource page and toolbar displays. The Virtual Machines toolbar enables you to add virtual machines (VMs), use the VMs and delete VMs. + + + + + + + + + The Virtual machines page displays a list of existing virtual machines. The following information is displayed for each virtual machine: + + Description - the name of the VM + UUID - the unique identifier + CPUs - the number of CPUs assigned to the VM + Memory - the amount of memory assigned to the VM + vNic Mac Address - + State - the status of the VM + Load - the current load + + +
        + +
        + Adding Virtual Machines + + Adding a virtual machine includes specifying the name and defining the resources and quotas that the VM can use. + + + To create a virtual machine, navigate to the appropriate virtual pool and select the Virtual Machines tab. + + + + + + + + + + + Click Add Virtual Machine from the Virtual Machine Pool toolbar. The Add a Virtual Machine dialog box displays. + + + + + + + + Enter the following information: + + Name of the Virtual Machine + Operating System + Select from + + Fedora 9 + Windows + + + CPUs - Enter the maximum number of CPUs the VM is permitted to use. + oVirt indicates the maximum that is permitted at start-up. Entering a value in this field is mandatory. + Memory (MB) - Enter the maximum amount of memory that the VM is permitted to use. + oVirt indicates the maximum that is permitted at start-up. Entering a value in this field is mandatory. + + Select the Storage Servers that the VM is permitted to use. The Storage table displays the Alias, Size and Type of Storage that is available. + The network VNIC is entered by default. You can change this if necessary. + The UUID is assigned by oVirt. You can change this if necessary. + Select the Start VM Now check box to start the VM immediately. The VM will start depending on the availability of resources. + + + Click Add Virtual Machine. A message indicates that the VM was successfully created. Click OK. + The VM appears in the list of VMs on the Virtual Machine Pool page. + + + + + + + + + +
        +
        + Using Virtual Machines + + + Navigate to an existing Virtual Machine Pool and click the Virtual Machines tab to view, add or manage virtual machines. + + + + + + + + + + + + + Select the check box of a virtual machine and click the Actions option on the toolbar. The Actions menu displays. + + + + + + + + + + From the Actions menu you can do the following to a virtual machine: + + Start + Shutdown + Suspend + Resume + Save + Restore + + + + A Virtual Machine Actions Result dialog box displays, indicating the result or results of the Action. + +
        +
        + Deleting Virtual Machines + + Deletion of a virtual machine is a permanent action that cannot be undone. + + + To delete a virtual machine, navigate to the appropriate virtual pool and select the Virtual Machines tab. + + + + + + + + + + Select the check box of the VM to be deleted. + Click Delete from the Virtual Machine Pool toolbar. A message prompts you to confirm the deletion. Click OK. + + A message indicates that the VM was successfully deleted. + The VM does not display in the list of VMs on the Virtual Machine Pool page. + + + + + + + + + + +
        + +
        +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Managing-the-Hardware.xml b/Using_the_oVirt_Admin_UI/en-US/Managing-the-Hardware.xml new file mode 100644 index 0000000..176c317 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Managing-the-Hardware.xml @@ -0,0 +1,720 @@ + + + + + Managing Hardware Resources + + This section describes how to set up and manage hardware resources. In a typical data center, a hardware administrator would need to: + + + + Create Hardware Pools + Create Virtual Pools for teams and assign hosts and storage to teams of users + Group hosts and storage in physical networks + Connect network attached storage (iSCSI, NFS) + Manage top-level user group membership + View usage and loading of resources, prepare hosts for downtime by migrating VMs + + + This section describes how a hardware administrator can perform the hardware related tasks of the above list in oVirt. +
        + Logging in as the Hardware Administrator + + Before you can manage any hardware resources, you must be logged into the oVirt Administration User Interface as the administrator. This gives you the requisite privileges. + + + + kinit as the kerberos admin user. (If you are using the developer installation, the password is is "ovirtadmin"). + Browse to oVirt Administration User Interface page. + The main page displays, with a summary of resources and lists of hardware pools, hosts and storage servers. On the left hand side of the page is the Navigator panel. Click the expand button on the default hardware pool. The resources display in a tree browser. On the right hand side is the Content Pane where details of the selected node and contextual menus display. + + + + + + + + + + Use the Navigator panel to navigate to a Hardware (or Virtual Machine Pool). You can also use the Navigator menu to add or delete hardware (and virtual machine pools). + + + + +
        + +
        + Working with Hardware Pools + Setting up, managing and monitoring the hardware resources is the key role of a hardware administrator. While this can be a complex task in any environment, it can become even more complex in a data centre with virtualized servers, hosts and storage. However, oVirt's Administration User Interface enables hardware administrators to manage a virtualized system effectively and efficiently. +
        + Viewing Hardware Resources + + The oVirt Administration UI page provides an overview of the resources, their availability, and current levels of load of the entire system. + + To view the resources of a specific hardware pool: + + + Use the Navigator panel to select the required hardware pool node. + + + + Click the pool name and the Summary Page displays on the Contents Pane on the right-hand side of the oVirt Administration UI. + + + + The numbers and amounts of used and available memory, storage and virtual resources appear in both a graphical and list form. Information on network traffic is also displayed. + + + + + + + + + + + + + + To see details on the physical host machines, click Hosts on the menu bar. The Hosts page displays the list of hosts in the resource pool. + + + + + + + + + + + + + To see details on the storage in the pool, click Storage on the menu bar. The Storage page displays the list of storage servers in the resource pool. + + + + + + + + +
        +
        + Creating and Deleting Hardware Pools + Creating and deleting Hardware Pools is a simple task using oVirt's Administration User Interface. + +
        + Creating Hardware Pools + Creating a hardware pool in which the virtual machines can run in an optimal fashion is crucial for system performance. For example, the hardware administrator might need to create a VM Resource Pool out of 5 physical nodes and a set of iSCSI targets. The resource pool would contain a + combined total of 10 processors, 20GB RAM, 100GB storage. The hardware administrator then assigns 3 users to this resource pool and assigns + constraints on those users, for example; + Each user may use 3 VCPUs, 30GB storage and 6GB RAM. However, the first step is to create the Hardware Pools. + + To do this you need to know the following: + + + The number of hosts required + The number of processors required + The amount of storage required + The amount of RAM required + The permissions and privileges of the users + + + + To create a resource pool from the Navigator Panel + + Use the Navigator panel to select the required hardware pool node. The Summary page and the Hardware Pool menu displays. + + + + + + + + + + + + The Navigator toolbar appears at the bottom on the panel. Click Add Hardware Pool. The Add Hardware Pool dialog box displays. + + + + + + + + + + + Enter the name of the new resource pool and click the Create Hardware Pool button. A message indicates that the hardware pool was successfully created. Click OK + + + Note: + You must enter a name for the new hardware pool. oVirt validates the name field and prompts you to enter a name before the resource pool is created. + + + + You can now add hosts, storage, virtual machines and users to the new hardware pool. Click the appropriate option on the menubar. Adding hosts, storage and virtual machines is described later in this section. + + + + Hardware Pool Names + Names can be any combination of alphanumeric characters, spaces and special characters. Valid name lengths are 1-256 characters. It is recommended that you use meaningful names for the resource pools. + +
        +
        + Deleting Hardware Pools + From time to time you will need to remove hardware pools; for example, a project no longer requires a particular hardware pool, or you need to optimise performance of the data center. Hardware Pools are removed from the Navigator panel. + + To do this you need to ensure the following: + + + There are no virtual machines in any sub-pools. + There are no virtual machine pools and virtual machine sub-pools in the pool or sub-pools. + There are no hardware resource sub-pools. + + + + To delete a resource pool: + + Use the Navigator panel to select the required hardware pool or sub-pool node. The Summary page and the Hardware Pool menu displays. + + + + + + + + + + + + The Navigator toolbar appears at the bottom on the panel. Click Delete Selected Pool. A message appears prompting you to confirm that you wish to delete the selected resource. Click OK. + + + + The hardware pool is removed and no longer displays in the Navigator Panel. + + + + Note + If there are any sub-pools or virtual machines in any node beneath the resource pool, the resource pool will not be deleted. + +
        +
        +
        + Adding and Removing Physical Hosts + Creating and deleting hosts is a simple task using oVirt's Administration User Interface. +
        + Adding Physical Hosts + As the hardware administrator you will frequently need to add physical hosts to new or existing resource pools. + + + + To add a host to an existing hardware pool: + Navigate to the hardware pool, click Hosts to view existing hosts. + + + + + + + + + From the Hosts toolbar, click Add Host. The Add Host dialog box displays. + + + + + + + + The Add Host dialog box displays the availability and usage statistics of the available hosts. + These include: + + Host Name - The name of the host + UUID - The unique identifier of the host + Hypervisor Type - the type of hypervisor + CPUs - the number of processors in the host + Speed - the speed of the processors + RAM - the size of the memory, and the percentage currently in use + + + + Select an available host. An available host is any host that the user has permissions on and does not have any VMs currently running on it. + Select the check box of the hosts that you wish to add to the hardware pool. At least one check box must be selected for the Add Host button to be enabled. + Click Add Host. The host displays on the Summary Page of the hardware pool. + To view all the hosts in the hardware pool, Click Hosts on the menubar. The new host displays in the list of hosts on the Hosts Page of the hardware pool. + +
        +
        + Removing Physical Hosts from a Hardware Pool + As the hardware administrator you will frequently need to remove physical hosts. Hosts are only removed from the specific hardware pool, they remain available for allocation to other pools, or to the same pool. + + + + To remove a host from an existing hardware pool: + Navigate to the hardware pool, click Hosts to view existing hosts. + + + + + + + + + Select the check box of the host that you wish to delete. + From the Hosts toolbar, click Remove. + + + A message displays indicating that the host was successfully moved. Click OK. + To view all the hosts in the hardware pool, Click Hosts on the menubar. The removed host does not display in the list of hosts on the Hosts Page of the hardware pool. + + Note + The host will still appear in the list of Hosts in the Add Hosts dialog box, and can be assigned to hardware pools as required. +
        +
        +
        + Moving Hosts between Hardware Pools + This process shows how to move hosts into new or existing Hardware Pools. For example, you may need to do this to balance the load, improve performance for particular applications, or if hosts are being replaced or retired. +
        + Move Hosts to Existing Hardware Pools + To move hosts to existing Hardware Pools: + + + + Use the Navigator panel to select the required hardware pool node. The Summary page and the Hardware Pool menu displays. + + + + + + + + + + + Click Hosts on the menu bar. The Hosts page displays the list of existing Hosts, and the Hosts toolbar displays. + + + + + + + + + + On the Hosts page, select the check box of the hosts to be moved. If no hosts are selected, you will be prompted to select at least one host before the Move Hosts dialog box displays. + + Click Move menu on the Hosts toolbar. The Move Hosts dialog box appears. + + + + + + + + + If necessary navigate to the destination resource pool node in the Move Hosts dialog box. + Click the destination resource pool node in the Move Hosts dialog box. + The selected host is removed from the current hardware pool, and the dialog box closes. + To view the hosts in the destination hardware pool, click the destination host node in the Navigator panel. The Summary page for the destination host resource pool displays. + + Click Hosts on the menu bar. The moved host displays in the list of hosts for the destination hardware pool. + +
        +
        + Move Hosts to a New Hardware Pool + You can use the Move Hosts dialog box to move hosts directly to a new hardware resource sub-pool. To move hosts to a new hardware resource sub-pool: + + + + In the Navigator panel, select the required hardware pool node. The Summary page and the Hardware Pool menu displays. + + + + + + + + + + + Click Hosts on the menu bar. The Hosts page displays the list of existing Hosts, and the Hosts toolbar displays. + + + + + + + + + + On the Hosts page, select the check box of the hosts to be moved. If no hosts are selected, you will be prompted to select at least one host before the Move Hosts dialog box displays. + + Click Move menu on the Hosts toolbar. The Move Hosts dialog box displays. + + + + + + + + + + Click the Move to new Hardware Pool button in the Move Hosts dialog box. The Add New Hardware Pool dialog box displays. + + + + + + + + + + Enter the name of the new resource pool and click the Create Hardware Pool button. + + Note: + You must enter a name for the new hardware pool. oVirt validates the name field and prompts you to enter a name before the resource pool is created. + + + The selected host is removed from the resource pool, and the dialog box closes. + To view the hosts in the destination hardware pool, click the destination host node in the Navigator panel. The Summary page for the destination host resource pool displays. + + Click Hosts on the menubar. The moved host displays in the list of hosts on the Hosts Page of the destination hardware pool. + + +
        +
        +
        +
        + Managing Storage Servers + Setting up, managing and monitoring the storage is the key role of a hardware administrator. While this can be a complex task in any environment, it can become even more complex in a data centre with virtualized storage. oVirt's Administration User Interface provides hardware administrators with tools to assign and manage virtualized storage effectively and efficiently. +
        + Adding Storage to the Resource Pool + + This process shows how to add an existing storage server to an existing hardware pool using the Storage Tab. The Storage toolbar allows you to add a storage server, create storage servers, move servers and delete storage. + + Note: + You can also add storage servers from the Summary page. + + + + + + In the Navigator panel, select the required hardware pool node. The Summary page and the Hardware Pool menu display. + + + + From the menu bar, click the Storage tab. The Storage page and toolbar display. + + + + + + + + + Click Add Storage Server from the toolbar. The Add Storage Server dialog box displays. + + + + + + + + + The Add Storage dialog box displays the alias, IP and Type of the available Storage Servers: + + Alias - The alias of the storage server + IP - The IP address of the storage server + Type - the type of hypervisor, either iSCSI or NFS + + + + Select the storage server is located. + Select the check box of the storage servers that you wish to add to the hardware pool. At least one storage server must be selected for the Add Selected Storage Pools button to be enabled. + Click Add Selected Storage Pools. The storage server displays on the Storage Page of the hardware pool. + + + + + + + + + +
        +
        + Creating Storage Servers + As the hardware administrator you may be required to provide additional storage servers to the system as more projects commence or grow to require more storage resources. + + + + To create a storage server: + + Use the Navigator panel to select the required hardware pool node. + + + + Click the pool name and the Summary Page displays on the Contents Pane on the right-hand side of the oVirt Administration UI. + + + + The numbers and amounts of used and available memory, storage and virtual resources appear in both a graphical and list form. + + + + + + + + + + To see details on the storage in the pool, click Storage on the menu bar. The Storage page displays the list of storage servers in the resource pool. + + + From the menu bar, click the Storage tab. The Storage page and toolbar display. + + + + + + + + + Click Create Storage Server from the toolbar. The Add New Storage Server dialog box displays. + + + + + + + + + Enter the following in the Add New Storage Pool dialog box + + Storage Type - iSCSI or NFS + IP Address + Port + Target + + + + Note + It is mandatory to provide details for each of the above fields. + + + Click Add Storage Server. The new storage server displays on the Storage Page of the hardware pool. + + + + + + + + + +
        +
        + Moving Storage Servers between Hardware Pools + This process shows how to move storage servers into new or existing Hardware Pools. For example, you may need to do this to balance the load, improve performance for particular applications, or if storage servers are being replaced or retired. +
        + Move Storage Servers to Existing Hardware Pools + To move storage to existing Hardware Pools: + + + + Use the Navigator panel to select the required hardware pool node. The Summary page and the Hardware Pool menu display. + + + + Click Storage on the menu bar. The Storage page displays the list of existing Storage Servers, and the Storage toolbar displays. + + + + + + + + + + On the Storage page, select the check box of the storage servers to be moved. If no storage servers are selected, you will be prompted to select at least one storage server before the Move Storage Server dialog box displays. + + Click Move on the Storage Server toolbar. The Move Storage Server dialog box displays. + + + + + + + + + Select the destination resource pool node in the Move Storage Server dialog box. + + + + + + + + + The selected storage server is removed from the current hardware pool, and the dialog box closes. + + + + + + + + + To view the storage server in the destination hardware pool, click the destination host node in the Navigator panel. The Summary page for the destination host resource pool displays. + + Click Storage on the menu bar. The moved storage server displays in the list of storage servers for the destination hardware pool. + +
        +
        + Move Storage Servers to a New Hardware Pool + You can also move a storage server directly to a new hardware resource sub-pool. To move a storage server to a new hardware resource sub-pool: + + + + In the Navigator panel, select the required hardware pool node. The Summary page and the Hardware Pool menu displays. + + + + Click Storage on the menu bar. The Storage page displays the list of existing storage servers, and the Storage toolbar displays. + + + + + + + + + + On the Storage page, select the check box of the storage server to be moved. If no Storage Server are selected, you will be prompted to select at least one host before the Move Storage Server dialog box displays. + + Click Move menu on the Storage Server toolbar. The Move Storage dialog box displays. + + + + + + + + + + Click the Move to New Hardware Pool button in the Move Storage dialog box. The Add New Hardware Pool dialog box displays. + + + + + + + + + + Enter the name of the new resource pool and click the Create Hardware Pool button. A message indicates that the new resource pool has been successfully created. Click OK. + + + Note: + You must enter a name for the new hardware pool. oVirt validates the name field and prompts you to enter a name before the resource pool is created. + + + The selected storage server is removed from the resource pool, and the dialog box closes. + + + + + + + + + To view the storage server in the destination hardware pool, click the destination host node in the Navigator panel. The Summary page for the destination host resource pool displays. + + + Click Storage on the menu bar. The moved storage server displays in the list on the Storage page of the destination hardware pool. + + + + + + + + + +
        +
        +
        + Deleting Storage Servers + This process shows how to remove storage servers. For example, you may need to do this if storage servers are being replaced or retired. There are two ways to do this, you can choose to remove a storage server from a particular hardware pool, or you may choose to delete it altogether. +
        + Removing Storage Servers from a Hardware Pool + Storage servers that are merely removed from a hardware pool remain available to be reassigned later, or assigned to other hardware pools. After removal they will still appear in the lists of assigned or unassigned storage servers, for example in the Add Storage Server dialog box. + To remove a storage server from a hardware pool: + + + + Use the Navigator panel to select the required hardware pool node. The Summary page and the Hardware Pool menu display. + + + + Click Storage on the menu bar. The Storage page displays the list of existing Storage Servers, and the Storage toolbar displays. + + + + + + + + + + + On the Storage page, select the check box of the storage servers to be removed. If no storage servers are selected, you will be prompted to select at least one storage server when you click Remove. + + Click Remove on the Storage Server toolbar. The storage server is removed and no longer appears on the page. + + Click Storage on the menu bar. The removed storage server no longer displays in the list of storage servers for the hardware pool. + + + Note + To check if the storage server is still available, use the Add Storage Server button on the Storage toolbar. Refer . + +
        +
        + Deleting Storage Servers from oVirt + Storage servers that are deleted from a hardware pool are also deleted from the system. After deletion they will no longer display in the lists of storage servers, for example in the Add Storage Server dialog box. + To delete a storage server from a hardware pool: + + + + Use the Navigator panel to select the required hardware pool node. The Summary page and the Hardware Pool menu display. + + + + Click Storage on the menu bar. The Storage page displays the list of existing Storage Servers, and the Storage toolbar displays. + + + + + + + + + + On the Storage page, select the check box of the storage servers to be deleted. If no storage servers are selected, you will be prompted to select at least one storage server when you click Delete. + + Click Delete on the Storage Server toolbar. + Click Storage on the menu bar. The deleted storage server no longer displays in the list of storage servers for the hardware pool. + + + Note + To check that the deleted storage server is no longer available, use the Add Storage Server button on the Storage toolbar. Refer . + +
        +
        +
        +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Preface.xml b/Using_the_oVirt_Admin_UI/en-US/Preface.xml new file mode 100644 index 0000000..0ef7989 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Preface.xml @@ -0,0 +1,91 @@ + + + + + Preface + oVirt is an open cross-platform virtualization management system. oVirt provides a small image that runs on a host and provides virtualization services to VMs, and a web-based management interface that lets you manage hosts and storage, install and remove virtual machines and level resources across a large group of machines. oVirt scales from a small group of users with little need for access control and quota management, all the way up to hundreds or even thousands of hosts with robust control over grouping, permissions, and quotas. + + + About &PRODUCT; Administration User Interface + + &PRODUCT; Administration User Interface is a web-based management UI application for oVirt hosts, users, and virtual machines. + + + + + About Using the &PRODUCT; Administration User Interface + The guide is provided as online help and as html pages. It describes how to perform a developer install of &PRODUCT; and how to use the interface to manage virtual hosts, users and virtual machines. + + + + + The &PRODUCT; Documentation Suite + &PRODUCT; documentation suite provides information on installation, development of applications, and all the latest changes. + + + + + + &PRODUCT; Release Notes - this document contains release specific information and known issues with the beta release. + + + + Online Help - this document describes how to use the &PRODUCT; Administration User Interface. + + + + Developer Installation Guide - this document describes how to install a developer version of &PRODUCT; correctly and quickly. + + + + Production Installation Guide - this document describes how to install &PRODUCT; correctly and quickly. A production install of &PRODUCT; allows a user to manage physical hosts. + + + + &PRODUCT; Configuration Guide - this document describes how to configure &PRODUCT; + + + + Appliance Development Kit User's Guide - this document describes the &PRODUCT; ADK. + + + + + + About the Audience + This documentation suite is intended for + + + Anyone who wants to manage virtual machines! oVirt is lightweight enough to work for a developer managing, say, a single host with four VMs, yet robust enough for a large organization managing tens of thousands of VMs. Although oVirt is developed using Fedora, oVirt is not tied to a particular platform. Solaris and Windows users can use the oVirt browser interface, and in the future the oVirt Administration Interface will run across platforms as well. + + + Open Source Developers + who are prototyping and experimenting with &PRODUCT;. Important aspects are an easy installation of the system and the ability to make changes in order to build a community of users and developers. + + + + + Users at the enterprise level: Hardware Administrators, team administrators and virtual machine users at large or small IT facilities. + + + Typically, hardware administrators can use oVirt to manage thousands of Virtual Machines running on thousands of Host systems, often with complex user roles involved. + + + + Team administrators manage user quotas, permissions, and subgroups for team hardware, Monitors physical hosts, Maintains available team VMs, install images/appliances + + + oVirt users create, destroy, and generally use VMs available to them after connecting to VMs from a browser interface. + + + + + + + + + + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Quick-Start.xml b/Using_the_oVirt_Admin_UI/en-US/Quick-Start.xml new file mode 100644 index 0000000..4b82532 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Quick-Start.xml @@ -0,0 +1,171 @@ + + + + + Quick Start + + This section is intended for users who wish to start using oVirt quickly without reading the online help from end to end. While it is recommended that you do read this document, this section gives you a high level look at how to apply the oVirt's functionality to typical virtualization tasks. + This section provides examples of how you can use oVirt to set up a number of managed nodes and how to set up a team environment. + +
        + Create a Hardware Pool + oVirt enables a development team to access hardware, storage and virtual machines for a new project in a quick, efficient and balanced way. A development team requires hardware resources, storage and a number of virtual machines to proceed with their project. In this exercise, the hardware administrator sets up the hardware resources, the team administrator assigns user permissions, and the developers can define, start or stop the VMs. + +
        + Scenario 1 + + The scenario is as follows, given five physical hosts and adequate networked storage: + + + Create a hardware pool for a team. + + + + + In the hardware pool, make a set of VMs with appropriate resource allocations and limits for three developers working on a project. + + + + Assign the developers appropriate permissions to use and manage their VMs. + + + + + This exercise demonstrates the following tasks + + Authentication/authorization as admin + Host/storage resource display + Pool creation + Adding resources to a pool + VM resource pool creation + Assign user group to pool/user-group-perms system + Define resource limits and resource guarantees for pool members + Authentication/authorization as non-privileged user + Define VMs + Start/stop VMs + Install available OS image in VMs + View VM console + Enforce resource limits and resource guarantees + +
        + +
        + Set up the Hardware Pool + This process shows the steps taken by the hardware administrator + + + + kinit as admin (ovirtadmin?) + Browse to oVirt UI + Navigate to top-level hardware pool, view available hosts and + storage + + + + + + + + + + Create team hardware pool + The Hardware Admin creates a VM Resource Pool out of 5 physical + nodes and a set of iSCSI targets. The resource pool contain a + combined total of 10 processors, 20GB RAM, 100GB storage. + + Move hosts and storage to team pool + Create VMResourcePool for the project + + + + Team Administrator + kinit as admin (ovirtadmin?) + + Browse to oVirt UI + + Navigate to team hardware pool, view available hosts and + storage + + Give team members access to the project. Assigns 3 users to this resource pool and assigns constraints on those users + + Give each team member appropriate resources to go with, or Each user may use 3 VCPUs, 30GB storage, 6GB RAM. + User A creates 6 VMs each using 5GB of disk, 2GB RAM and 1VCPU. Given his + resource constraints, he can only run 3 of them simultaneously, but + because he's got enough storage he is able to define 6, run 3 and leave 3 + offline. If he brings down a VM, he can then fire up a different one. + So the limit shouldn't be on the # of virtual machines that a user can + create, but it should be on their resource consumption in terms of + storage/processor/memory. + + + + + User - Team Member + kinit as team member + Log in as a team member, create VMs in the new pool using available OS images (that is, pull down a menu to choose the OS that cobbler will install via PXE when the VM starts). Start/stop VMs, see console (via console plugin link), etc. + Attempt to start a VM which goes over quota, show that quota limits are enforced. + + +
        +
        +
        + Create a team development box + Amy Admin is starting a project with 5 developers. The project requires a private network since it has a special authentication component. Amy needs to allocate and isolate 3 virtual machines to each developer, so that they can do network development that would otherwise be disruptive to the company network. + + + Amy logs into oVirt and selects a Group of hosts with several unallocated hosts. + + + + + + + + + + + She selects the under-utilized / unallocated hosts. + + + + + + + + + + + She moves the selected hosts to a new group. + + + + + + + + + OR she could create a new resource group first and then add hosts and storage + + + + + + + + + + The new group is created successfully + + + + + + + + + + +
        +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Revision_History.xml b/Using_the_oVirt_Admin_UI/en-US/Revision_History.xml new file mode 100644 index 0000000..f14cfd6 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Revision_History.xml @@ -0,0 +1,42 @@ + + + + + Revision History + + + + 1.0 + 3rd September 2008 + + Susan + Burgess + sburgess at redhat.com + + + + Updates + TBD + + + + + .6-1 + Wednesday June 18th 2008 + + Susan + Burgess + sburgess at redhat.com + + + + Resolves: #232215 + Need to have a BZ. Also, need a real bug# + + + + + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Sample-oVirt-Scenarios.xml b/Using_the_oVirt_Admin_UI/en-US/Sample-oVirt-Scenarios.xml new file mode 100644 index 0000000..60b9e9d --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Sample-oVirt-Scenarios.xml @@ -0,0 +1,393 @@ + + + + + Using oVirt - Sample Scenarios + + + This section provides a high level look at how to apply the oVirt's functionality to typical virtualization tasks. + This section provides a number of examples of how you can use oVirt in a virtualized environment. + +
        + Create a Hardware Pool + oVirt enables a development team to access hardware, storage and virtual machines for a new project in a quick, efficient and balanced way. A development team requires hardware resources, storage and a number of virtual machines to proceed with their project. In this exercise, the hardware administrator sets up the hardware resources, the team administrator assigns user permissions, and the developers can define, start or stop the VMs. + +
        + Scenario 1 + + The scenario is as follows, given five physical hosts and adequate networked storage: + + + Create a hardware pool for a team. + + + + + In the hardware pool, make a set of VMs with appropriate resource allocations and limits for three developers working on a project. + + + + Assign the developers appropriate permissions to use and manage their VMs. + + + + + This exercise demonstrates the following tasks + + Authentication/authorization as admin + Host/storage resource display + Pool creation + Adding resources to a pool + VM resource pool creation + Assign user group to pool/user-group-perms system + Define resource limits and resource guarantees for pool members + Authentication/authorization as non-privileged user + Define VMs + Start/stop VMs + Install available OS image in VMs + View VM console + Enforce resource limits and resource guarantees + +
        + +
        + Set up the Hardware Pool + This process shows the steps taken by the hardware administrator + + + + kinit as admin + Browse to the oVirt Administration User Interface + Navigate to top-level hardware pool, view available hosts and + storage + + + + + + + + + + Create team hardware pool + The Hardware Admin creates a VM Resource Pool out of 5 physical + nodes and a set of iSCSI targets. The resource pool contain a + combined total of 10 processors, 20GB RAM, 100GB storage. + + Move hosts and storage to team pool + Create VMResourcePool for the project + + + + + + + + + + + + + + Team Administrator + kinit as admin (ovirtadmin?) + + Browse to oVirt UI + + Navigate to team hardware pool, view available hosts and + storage + + Give team members access to the project. Assigns 3 users to this resource pool and assigns constraints on those users + + Give each team member appropriate resources to go with, or Each user may use 3 VCPUs, 30GB storage, 6GB RAM. + User A creates 6 VMs each using 5GB of disk, 2GB RAM and 1VCPU. Given his + resource constraints, he can only run 3 of them simultaneously, but + because he's got enough storage he is able to define 6, run 3 and leave 3 + offline. If he brings down a VM, he can then fire up a different one. + So the limit shouldn't be on the # of virtual machines that a user can + create, but it should be on their resource consumption in terms of + storage/processor/memory. + + + + + User - Team Member + kinit as team member + Log in as a team member, create VMs in the new pool using available OS images (that is, pull down a menu to choose the OS that cobbler will install via PXE when the VM starts). Start/stop VMs, see console (via console plugin link), etc. + Attempt to start a VM which goes over quota, show that quota limits are enforced. + + +
        +
        +
        + Create a team development box + Amy Admin is starting a project with 5 developers. The project requires a private network since it has a special authentication component. Amy needs to allocate and isolate 3 virtual machines to each developer, so that they can do network development that would otherwise be disruptive to the company network. + + + Amy logs into oVirt and selects a Group of hosts with several unallocated hosts. + + + + + + + + + + + She selects the under-utilized / unallocated hosts. + + + + + + + + + + + She moves the selected hosts to a new group. + + + + + + + + + OR she could create a new resource group first and then add hosts and storage + + + + + + + + + + The new group is created successfully + + + + + + + + + + +
        +
        + Manage Resource Loads + Given a pool of production hosts, examine load and resource + usage graphs to find VMs that need additional peak resources. Having + found one, migrate low-load VMs away from the resource-bound + machine. Alternatively, migrate the loaded VM to a larger, empty + machine. + + This sample demonstrates the following tasks in oVirt: + + + Authentication/authorization + + + Navigate to/view physical hosts + + + View performance graphs and statistics for physical hosts and VMs + + + Migrate VMs off loaded hosts to unloaded hosts + + + Change VM resource limits on the fly. + + + To manage the resource loads effectively in this scenario: + + kinit as admin (ovirtadmin?) + Browse to oVirt UI + Navigate to a pool of physical hosts. The physical hosts must have VMs running on them and some load history. + + + + + + + + + Show load graphs for physical hosts for the prior 24 hours. Identify one that is regularly overloaded. + Look at load graphs for VMs on the overloaded host. Identify one + that is regularly running out of resources/overloaded. + + + + + + + + + Migrate lightly loaded VMs off the overloaded host to make room. + Alternatively, migrate the loaded VM to a bigger host to make room. + Alternatively, lower resource limits of VMs to make more resources + available for the loaded VM + + +
        +
        + Setting up User Permissions + + Set a new user up with a virtual desktop. Given a + VM Resource Group for virtual desktop hosts, give the new user + permission to access the group, and resource allocations for a single + desktop host. Then create a VM for the user and install a desktop OS + in it. The user should be able to log in to the machine console and + use the VM. + This sample demonstrates the following tasks in oVirt. + + + Authentication/authorization + + + Navigate to hardware pools/resource pools + + + Grant permission + + + Allocate resources + + + Create VM for another user + + + Provision VM for another user + + + Navigate as non-privileged user to allowed VM + + + Viewing the VM console + + + The process is + + + kinit as admin (ovirtadmin?) + + + Browse to oVirt UI + + + Navigate to virtual-desktop VM Resource Group + + + Give new user permission on VM Resource Group + + + Give new user resource grants for a single desktop host + + + Create VM for user, install a desktop OS in it. + + + kinit as user + + + Navigate oVirt UI to VM console, launch console. + + +
        + +         + diff --git a/Using_the_oVirt_Admin_UI/en-US/Troubleshooting.xml b/Using_the_oVirt_Admin_UI/en-US/Troubleshooting.xml new file mode 100644 index 0000000..c6c3313 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Troubleshooting.xml @@ -0,0 +1,14 @@ + + + + + + + + Troubleshooting + + Empty para tags are not allowed (they break translations), so this boilerplate text is here to keep place until actual text is added. (Note: the file is currently not included in built versions of this book: edit the appropriate xi:include in 'Using_oVirt.xml' to include this file.) + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Using_oVirt.ent b/Using_the_oVirt_Admin_UI/en-US/Using_oVirt.ent new file mode 100644 index 0000000..7b9380a --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Using_oVirt.ent @@ -0,0 +1,4 @@ + + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/Using_oVirt.xml b/Using_the_oVirt_Admin_UI/en-US/Using_oVirt.xml new file mode 100644 index 0000000..8b8dd73 --- /dev/null +++ b/Using_the_oVirt_Admin_UI/en-US/Using_oVirt.xml @@ -0,0 +1,22 @@ + + + + + + + + + + + + + + + + + + + + + diff --git a/Using_the_oVirt_Admin_UI/en-US/images/AddHost.png b/Using_the_oVirt_Admin_UI/en-US/images/AddHost.png new file mode 100644 index 0000000000000000000000000000000000000000..16b9f0a27db85877537b42905411050302f5bc26 GIT binary patch From dpierce at redhat.com Fri Sep 12 19:06:43 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 12 Sep 2008 15:06:43 -0400 Subject: [Ovirt-devel] Re: Configuration NICs In-Reply-To: <48CABB73.70102@redhat.com> References: <20080912182420.GA15733@redhat.com> <48CABB73.70102@redhat.com> Message-ID: <20080912190643.GA3675@redhat.com> +++ Perry N. Myers [12/09/08 14:56 -0400]: > Darryl L. Pierce wrote: >> In order to configure a NIC and also use bonding/fail-over, we need a >> way to: >> >> 1. associate one or more BondingType objects to the Host via the Bonding >> class. > > Should we model this by associating a BondingType to a set of NICs rather > than a Host? I know initially we're only going to support on BondingType > per Host as to simplify things, but it might make sense to structure the > data model to make it easier to transition to the more flexible approach. The relationship between Host and Bonding is a one-to-many, so we're already able to do the multiple Bondings. I don't want to do the relationship from the Host to the Bonding through the Nic though 'cause that's not a natural way of thinking about it to me; i.e., the Bonding is an aspect of the Host so it should be hung there. > For the time being we can make the restriction that once you're created > one set of bonded interfaces and have selected Type X for those > interfaces that all other interfaces on the Host can only use type X. > That's a simple restriction in the UI that doesn't affect the data model. > >> 2. associate which of the Host's Nic objects will be a part of each Bonding >> object. >> 3. set the ip address, netmask, etc. for a Nic that's not enslaved. > > Or allow DHCP, right? Oops, forgot to mention that. If the IP address is nil then the configuration generator chooses DHCP for the boot protocol. > >> Here's a crude ASCII of what I"m thinking. >> >> >> [ Select a bonding type v ] [ Add ] >> >> Bonded interface alias: _bond0_____________________ [ Remove ]_ >> Bonded interface name: _ovbond0____________________ >> >> Network Interfaces: >> >> 00:11:22 [ ] Enslave to ovbond0 IP Address: _______ Netmask: ____ | >> 11:22:33 [X] Enslaved to ovbond0 >> 22:33:44 [X] Enslaved to ovbond0 >> >> [ Save Changes ] >> >> >> 1. The user selects a bonding type and clicks "Add". The bonded interface >> fields are displayed. >> 2. The user clicks "Remove" to destroy the interface. When that >> happens, any >> enslaved Nic is released but not destroyed. >> 3. If the user clicks the checkbox to enslave an interface then the IP >> address and netmask fields go away. > > So is this a UI that appears on an 'Edit Node' page? How does the user > get to this page? And how would it look if there were multiple Bond > objects? (i.e. is Bonded Interface Alias a drop down list?) These are the details that I was afraid to face initially without getting someone like Tim involved. I think that a dropdown listing the bondings would be the way to go when we support more than one bonding. > What about configuring the IP addresses statically for interfaces that > are not bonded? That's the example with mac 00:11:22 above: if the box isn't checked, then you can enter the ip address and netmask in the field next to the interface. > As an aside, we should probably allow interfaces to be 'labeled'. i.e. > For each Interface object associate a label that can be used by a > hardware Admin to know what physical network that interface is attached > to. > > Interface with MAC 11:22:33:44:55:66 is on "LAN A" > > Or something like that. Bonded interfaces all need to be on the same > physical network (so have the same label) and the Label associated with a > set of bonded interfaces is the same as the underlying interfaces. For the bondings that would be the alias. For the nics we could have a field next to each mac address where the admin could enter an alias for that and have it persisted. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From pmyers at redhat.com Fri Sep 12 19:28:32 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Fri, 12 Sep 2008 15:28:32 -0400 Subject: [Ovirt-devel] Re: Configuration NICs In-Reply-To: <20080912190643.GA3675@redhat.com> References: <20080912182420.GA15733@redhat.com> <48CABB73.70102@redhat.com> <20080912190643.GA3675@redhat.com> Message-ID: <48CAC2E0.2010906@redhat.com> Darryl L. Pierce wrote: > +++ Perry N. Myers [12/09/08 14:56 -0400]: >> Darryl L. Pierce wrote: >>> In order to configure a NIC and also use bonding/fail-over, we need >>> a way to: >>> >>> 1. associate one or more BondingType objects to the Host via the Bonding >>> class. >> >> Should we model this by associating a BondingType to a set of NICs >> rather than a Host? I know initially we're only going to support on >> BondingType per Host as to simplify things, but it might make sense to >> structure the data model to make it easier to transition to the more >> flexible approach. > > The relationship between Host and Bonding is a one-to-many, so we're > already > able to do the multiple Bondings. I don't want to do the relationship from > the Host to the Bonding through the Nic though 'cause that's not a natural > way of thinking about it to me; i.e., the Bonding is an aspect of the > Host so > it should be hung there. Ok. So initially a Host can have multiple Bondings and each Bonding on a Host must have the same BondingType. Eventually we'll support multiple Bondings on each host with independent BondingTypes. This right? >> For the time being we can make the restriction that once you're >> created one set of bonded interfaces and have selected Type X for >> those interfaces that all other interfaces on the Host can only use >> type X. That's a simple restriction in the UI that doesn't affect the >> data model. >> >>> 2. associate which of the Host's Nic objects will be a part of each >>> Bonding >>> object. >>> 3. set the ip address, netmask, etc. for a Nic that's not enslaved. >> >> Or allow DHCP, right? > > Oops, forgot to mention that. If the IP address is nil then the > configuration > generator chooses DHCP for the boot protocol. Ok. > >> >>> Here's a crude ASCII of what I"m thinking. >>> >>> >>> [ Select a bonding type v ] [ Add ] >>> >>> Bonded interface alias: _bond0_____________________ [ Remove ]_ >>> Bonded interface name: _ovbond0____________________ >>> >>> Network Interfaces: >>> 00:11:22 >>> [ ] Enslave to ovbond0 IP Address: _______ Netmask: ____ | >>> 11:22:33 [X] Enslaved to ovbond0 >>> 22:33:44 [X] Enslaved to ovbond0 >>> >>> [ Save Changes ] >>> >>> >>> 1. The user selects a bonding type and clicks "Add". The bonded >>> interface >>> fields are displayed. >>> 2. The user clicks "Remove" to destroy the interface. When that >>> happens, any >>> enslaved Nic is released but not destroyed. >>> 3. If the user clicks the checkbox to enslave an interface then the IP >>> address and netmask fields go away. >> >> So is this a UI that appears on an 'Edit Node' page? How does the >> user get to this page? And how would it look if there were multiple >> Bond objects? (i.e. is Bonded Interface Alias a drop down list?) > > These are the details that I was afraid to face initially without getting > someone like Tim involved. I think that a dropdown listing the bondings > would > be the way to go when we support more than one bonding. Tim, can you work with Darryl and Scott to do a mockup of what this should look like so we can implement it the right way :) >> What about configuring the IP addresses statically for interfaces that >> are not bonded? > > That's the example with mac 00:11:22 above: if the box isn't checked, then > you can enter the ip address and netmask in the field next to the > interface. Ok, the UI diagram above only assumes a single Bond per host... Yeah, we need to work out a UI where multiple Bonds are allowed... It gets more complex then. >> As an aside, we should probably allow interfaces to be 'labeled'. >> i.e. For each Interface object associate a label that can be used by >> a hardware Admin to know what physical network that interface is >> attached to. >> >> Interface with MAC 11:22:33:44:55:66 is on "LAN A" >> >> Or something like that. Bonded interfaces all need to be on the same >> physical network (so have the same label) and the Label associated >> with a set of bonded interfaces is the same as the underlying interfaces. > > For the bondings that would be the alias. For the nics we could have a > field > next to each mac address where the admin could enter an alias for that and > have it persisted. Well, the alias should be a rollup of the labels for the bonded interfaces. i.e. if you have 2 NICs bonded and each of them are labelled "LAN A" the alias for the bond should also be LAN A Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From dpierce at redhat.com Fri Sep 12 19:56:45 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 12 Sep 2008 15:56:45 -0400 Subject: [Ovirt-devel] Re: Configuration NICs In-Reply-To: <48CAC2E0.2010906@redhat.com> References: <20080912182420.GA15733@redhat.com> <48CABB73.70102@redhat.com> <20080912190643.GA3675@redhat.com> <48CAC2E0.2010906@redhat.com> Message-ID: <20080912195645.GA4649@redhat.com> +++ Perry N. Myers [12/09/08 15:28 -0400]: >> The relationship between Host and Bonding is a one-to-many, so we're >> already >> able to do the multiple Bondings. I don't want to do the relationship from >> the Host to the Bonding through the Nic though 'cause that's not a natural >> way of thinking about it to me; i.e., the Bonding is an aspect of the >> Host so >> it should be hung there. > > Ok. So initially a Host can have multiple Bondings and each Bonding on a > Host must have the same BondingType. Eventually we'll support multiple > Bondings on each host with independent BondingTypes. This right? We won't need to change the model at all: we support multiple bondings right now. The limitation is just in the user interface design. But if Tim can do a design taking those multiples into consideration, we won't need to change any of the backend code I've written for the server. >>> Or something like that. Bonded interfaces all need to be on the same >>> physical network (so have the same label) and the Label associated >>> with a set of bonded interfaces is the same as the underlying >>> interfaces. >> >> For the bondings that would be the alias. For the nics we could have a >> field >> next to each mac address where the admin could enter an alias for that and >> have it persisted. > > Well, the alias should be a rollup of the labels for the bonded > interfaces. i.e. if you have 2 NICs bonded and each of them are labelled > "LAN A" the alias for the bond should also be LAN A Ah, okay, I see what you're saying. Not a problem. We can get the alias from the Bonding pretty easily through the Nic. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jim at meyering.net Fri Sep 12 20:39:18 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 12 Sep 2008 22:39:18 +0200 Subject: [Ovirt-devel] [PATCH appliance] restore envvar-controlled RPM_FLAGS additions In-Reply-To: <87ej3pfj70.fsf@rho.meyering.net> (Jim Meyering's message of "Fri, 12 Sep 2008 18:00:19 +0200") References: <87ej3pfj70.fsf@rho.meyering.net> Message-ID: <87hc8lcd55.fsf@rho.meyering.net> Jim Meyering wrote: > * Makefile.am: Restore the code to append to RPM_FLAGS. > These were mistakenly removed by the previous commit. > --- > Thanks to Perry Myers for spotting this. > Testing it now... That test didn't work at all. GNU make-style "ifdef" doesn't work with automake. The following does it in equivalent shell code just prior to running rpmbuild. I verified that "make ... build" passes, but haven't tried setting any of those variables. >From 33840f85f5f739dcffa3b387951ee02fd501188b Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 12 Sep 2008 22:35:46 +0200 Subject: [PATCH appliance] restore envvar-controlled rpm option additions: FEDORA_URL, OVIRT_URL, SKIP_COMPRESS_IMAGE --- release.mk | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-) diff --git a/release.mk b/release.mk index 7d9ddd0..d63d53c 100644 --- a/release.mk +++ b/release.mk @@ -1,5 +1,5 @@ # Release/version-related Makefile variables and rules. -# It expects the including Makefile to define the "pkg_name" +# It expects the including Makefile to define the "pkg_name" # variable, as well as a file named "version" in the current directory. srcdir ?= . @@ -43,8 +43,20 @@ setversion: new-rpms: bumprelease rpms +# FEDORA_URL env var can be set to the root of a fedora mirror +# OVIRT_URL env var can be set to the root of an ovirt.org mirror +# SKIP_COMPRESS_IMAGE env var an be set to 1 to skip qcow compression +# that contains the install tree + rpms: tar - rpmbuild $(RPM_FLAGS) -ba $(SPEC_FILE) + v=; \ + test 'x$(SKIP_COMPRESS_IMAGE)' != x \ + && v="--define 'skip_compress_image 1'"; \ + test 'x$(FEDORA_URL)' != x \ + && v="$$v --define 'fedora_url $(FEDORA_URL)'"; \ + test 'x$(OVIRT_URL)' != x \ + && v="$$v --define 'ovirt_url $(OVIRT_URL)'"; \ + rpmbuild $(RPM_FLAGS) $$v -ba $(SPEC_FILE) publish: rpms rm -f $(OVIRT_CACHE_DIR)/ovirt/$(pkg_name)* -- 1.6.0.1.308.gede4c From dpierce at redhat.com Fri Sep 12 20:52:01 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 12 Sep 2008 16:52:01 -0400 Subject: [Ovirt-devel] [PATCH] Added additional fields to the nic table. Message-ID: <1221252721-12129-1-git-send-email-dpierce@redhat.com> The new fields are netmask and broadcast. You will need to run a migration with this patch. Signed-off-by: Darryl L. Pierce --- src/db/migrate/018_add_netmask_to_nics.rb | 11 +++++++++++ src/host-browser/host-browser.rb | 18 ++++++++++++++++-- 2 files changed, 27 insertions(+), 2 deletions(-) create mode 100644 src/db/migrate/018_add_netmask_to_nics.rb diff --git a/src/db/migrate/018_add_netmask_to_nics.rb b/src/db/migrate/018_add_netmask_to_nics.rb new file mode 100644 index 0000000..a006109 --- /dev/null +++ b/src/db/migrate/018_add_netmask_to_nics.rb @@ -0,0 +1,11 @@ +class AddNetmaskToNics < ActiveRecord::Migration + def self.up + add_column :nics, :netmask, :string, :limit => 16 + add_column :nics, :broadcast, :string, :limit => 16 + end + + def self.down + remove_column :nics, :netmask + remove_column :nics, :broadcast + end +end diff --git a/src/host-browser/host-browser.rb b/src/host-browser/host-browser.rb index a9fc9c7..debd78f 100755 --- a/src/host-browser/host-browser.rb +++ b/src/host-browser/host-browser.rb @@ -170,7 +170,7 @@ class HostBrowser break if info == "ENDNIC" - raise Exception.new("ERRINFO! Excepted key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]/ + raise Exception.new("ERRINFO! Excepted key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]*/ key, value = info.split("=") @@ -275,6 +275,17 @@ class HostBrowser # the received data to avoid creating a dupe later if detail['MAC'] == nic.mac nic_info.delete(detail) + + updated_nic = Nic.find_by_id(nic.id) + + updated_nic.bandwidth = detail['BANDWIDTH'] + updated_nic.ip_addr = detail['IP_ADDRESS'] + updated_nic.netmask = detail['NETMASK'] + updated_nic.broadcast = detail['BROADCAST'] + + updated_nic.save! + found=true + nic_info.delete detail end end @@ -292,7 +303,10 @@ class HostBrowser detail = Nic.new( 'mac' => nic['MAC'], 'bandwidth' => nic['BANDWIDTH'], - 'usage_type' => 1) + 'usage_type' => 1, + 'ip_addr' => nic['IP_ADDRESS'], + 'netmask' => nic['NETMASK'], + 'broadcast' => nic['BROADCAST']) host.nics << detail end -- 1.5.5.1 From dpierce at redhat.com Fri Sep 12 20:52:39 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Fri, 12 Sep 2008 16:52:39 -0400 Subject: [Ovirt-devel] [PATCH] The node sends the ip address, netmask and interface name during identification. Message-ID: <1221252759-12187-1-git-send-email-dpierce@redhat.com> This patch requires the associated patch for the server which includes the netmask and broadcast columns. Signed-off-by: Darryl L. Pierce --- ovirt-identify-node/gather.c | 37 ++++++++++++++++++++++++++-- ovirt-identify-node/ovirt-identify-node.h | 3 ++ ovirt-identify-node/protocol.c | 6 ++++- 3 files changed, 42 insertions(+), 4 deletions(-) diff --git a/ovirt-identify-node/gather.c b/ovirt-identify-node/gather.c index 4a664f7..7c6fa55 100644 --- a/ovirt-identify-node/gather.c +++ b/ovirt-identify-node/gather.c @@ -22,6 +22,10 @@ #include "ovirt-identify-node.h" +struct sockaddr_in sa; + +#define inaddrr(x) (*(struct in_addr *) &ifr.x[sizeof sa.sin_port]) + int init_gather(void) { @@ -205,6 +209,7 @@ get_nic_data(char *nic, nic_info_ptr nic_info_p) interface = libhal_device_get_property_string(hal_ctx, nic, "net.interface", &dbus_error); + snprintf(nic_info_p->iface_name, BUFFER_LENGTH, "%s", interface); bzero(&ifr, sizeof(struct ifreq)); sockfd = socket(AF_INET, SOCK_DGRAM, 0); @@ -212,12 +217,36 @@ get_nic_data(char *nic, nic_info_ptr nic_info_p) int bandwidth; ifr.ifr_addr.sa_family = AF_INET; - strncpy(ifr.ifr_name, interface, IFNAMSIZ - 1); + strncpy(ifr.ifr_name, interface, IFNAMSIZ - 1); + + if(!ioctl(sockfd,SIOCGIFADDR,&ifr)) { + + DEBUG("ip_address=%s\n",inet_ntoa(inaddrr(ifr_addr.sa_data))); + + snprintf(nic_info_p->ip_address, BUFFER_LENGTH, "%s", + inet_ntoa(inaddrr(ifr_addr.sa_data))); + } + + if(!ioctl(sockfd,SIOCGIFNETMASK,&ifr) && + strcmp("255.255.255.255", inet_ntoa(inaddrr(ifr_addr.sa_data)))) { + + DEBUG("netmask=%s",inet_ntoa(inaddrr(ifr_addr.sa_data))); + + snprintf(nic_info_p->netmask, BUFFER_LENGTH, "%s", + inet_ntoa(inaddrr(ifr_addr.sa_data))); + } + + if(!ioctl(sockfd,SIOCGIFBRDADDR,&ifr)) { + + DEBUG("broadcast=%s",inet_ntoa(inaddrr(ifr_addr.sa_data))); + + snprintf(nic_info_p->broadcast, BUFFER_LENGTH, "%s", + inet_ntoa(inaddrr(ifr_addr.sa_data))); + } ifr.ifr_data = (caddr_t)&ecmd; ioctl(sockfd, SIOCETHTOOL, &ifr); - close(sockfd); - + bandwidth = 10; if (ecmd.supported & SUPPORTED_10000baseT_Full) bandwidth = 10000; @@ -234,6 +263,8 @@ get_nic_data(char *nic, nic_info_ptr nic_info_p) bandwidth = 10; snprintf(nic_info_p->bandwidth, BUFFER_LENGTH, "%d", bandwidth); + + close(sockfd); } } diff --git a/ovirt-identify-node/ovirt-identify-node.h b/ovirt-identify-node/ovirt-identify-node.h index c595891..b8485fc 100644 --- a/ovirt-identify-node/ovirt-identify-node.h +++ b/ovirt-identify-node/ovirt-identify-node.h @@ -67,6 +67,9 @@ typedef struct _nic_info { char mac_address[BUFFER_LENGTH]; char bandwidth[BUFFER_LENGTH]; char ip_address[BUFFER_LENGTH]; + char netmask[BUFFER_LENGTH]; + char iface_name[BUFFER_LENGTH]; + char broadcast[BUFFER_LENGTH]; struct _nic_info* next; } t_nic_info; diff --git a/ovirt-identify-node/protocol.c b/ovirt-identify-node/protocol.c index 2a92edb..35bf651 100644 --- a/ovirt-identify-node/protocol.c +++ b/ovirt-identify-node/protocol.c @@ -181,7 +181,11 @@ send_nic_details(void) if (!(get_text("NICINFO?")) && (!send_value("MAC", current->mac_address)) && - (!send_value("BANDWIDTH", current->bandwidth))) { + (!send_value("BANDWIDTH", current->bandwidth)) && + (!send_value("IFACE_NAME", current->iface_name)) && + (!send_value("IP_ADDRESS", current->ip_address)) && + (!send_value("NETMASK", current->netmask)) && + (!send_value("BROADCAST", current->broadcast))) { send_text("ENDNIC"); result = get_text("ACK NIC"); } -- 1.5.5.1 From jim at meyering.net Fri Sep 12 21:00:54 2008 From: jim at meyering.net (Jim Meyering) Date: Fri, 12 Sep 2008 23:00:54 +0200 Subject: [Ovirt-devel] [PATCH appliance] restore envvar-controlled RPM_FLAGS additions In-Reply-To: <87hc8lcd55.fsf@rho.meyering.net> (Jim Meyering's message of "Fri, 12 Sep 2008 22:39:18 +0200") References: <87ej3pfj70.fsf@rho.meyering.net> <87hc8lcd55.fsf@rho.meyering.net> Message-ID: <87bpytcc55.fsf@rho.meyering.net> Jim Meyering wrote: > I verified that "make ... build" passes, > but haven't tried setting any of those variables. That change made modifications to release.mk that are best avoided, since they'd not be useful for the other projects that use release.mk, so here's one more iteration that pulls the appliance-specific bits out into Makefile.am: smoke test is in progress... >From 5947d7e7eae24d9f9b4af5a95e1cea6a8cef6d0c Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Fri, 12 Sep 2008 22:35:46 +0200 Subject: [PATCH appliance] restore envvar-controlled rpm option additions: This puts a new appliance-specific definition into Makefile.am, with only a small hook in the nominally-shared-between-all-ovirt-* projects release.mk file. --- Makefile.am | 13 +++++++++++++ release.mk | 5 +++-- 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/Makefile.am b/Makefile.am index b59086a..39f7d98 100644 --- a/Makefile.am +++ b/Makefile.am @@ -28,6 +28,19 @@ EXTRA_DIST = \ repos.ks.in \ version +# FEDORA_URL env var can be set to the root of a fedora mirror +# OVIRT_URL env var can be set to the root of an ovirt.org mirror +# SKIP_COMPRESS_IMAGE env var an be set to 1 to skip qcow compression +# that contains the install tree +# This variable is used in the rpmbuild-invoking rule in release.mk. +set_rpm_opts = \ + test 'x$(SKIP_COMPRESS_IMAGE)' != x \ + && v="--define 'skip_compress_image 1'"; \ + test 'x$(FEDORA_URL)' != x \ + && v="$$v --define 'fedora_url $(FEDORA_URL)'"; \ + test 'x$(OVIRT_URL)' != x \ + && v="$$v --define 'ovirt_url $(OVIRT_URL)'" + include release.mk pkg_name = $(PACKAGE_NAME) diff --git a/release.mk b/release.mk index 7d9ddd0..c63e44b 100644 --- a/release.mk +++ b/release.mk @@ -1,5 +1,5 @@ # Release/version-related Makefile variables and rules. -# It expects the including Makefile to define the "pkg_name" +# It expects the including Makefile to define the "pkg_name" # variable, as well as a file named "version" in the current directory. srcdir ?= . @@ -44,7 +44,8 @@ setversion: new-rpms: bumprelease rpms rpms: tar - rpmbuild $(RPM_FLAGS) -ba $(SPEC_FILE) + v=; $(set_rpm_opts); \ + rpmbuild $(RPM_FLAGS) $$v -ba $(SPEC_FILE) publish: rpms rm -f $(OVIRT_CACHE_DIR)/ovirt/$(pkg_name)* -- 1.6.0.1.308.gede4c From lutter at redhat.com Sat Sep 13 01:07:53 2008 From: lutter at redhat.com (David Lutterkort) Date: Fri, 12 Sep 2008 18:07:53 -0700 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CA9A9E.3060603@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> <48CA8510.6030408@redhat.com> <48CA8F27.6080301@redhat.com> <48CA9362.2010005@redhat.com> <48CA9A9E.3060603@redhat.com> Message-ID: <1221268073.30184.32.camel@localhost.localdomain> On Fri, 2008-09-12 at 12:36 -0400, Scott Seago wrote: > On the other hand, we're already getting the profile list on the WUI -- > the above problem will affect the WUI anyway unless we also generate the > cobbler profile list on the back end. Now we may eventually have to do > this anyway if we ever want to define per-profile access control -- but > as things stand now, just doing the cobbler system bit in taskomatic > doesn't completely eliminate the cobbler connectivity issue for the WUI. Another place to use QPid ;) ? I think eventually, we want to store as little transient information as possible in the WUIs DB and try to gather as much from data sources exposed through QPid/QMF - prime example is the state of individual VM's. But it's going to be a while before we get there. David From pmyers at redhat.com Sat Sep 13 15:09:24 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Sat, 13 Sep 2008 11:09:24 -0400 Subject: [Ovirt-devel] [PATCH] Added additional fields to the nic table. In-Reply-To: <1221252721-12129-1-git-send-email-dpierce@redhat.com> References: <1221252721-12129-1-git-send-email-dpierce@redhat.com> Message-ID: <48CBD7A4.5050503@redhat.com> Darryl L. Pierce wrote: > The new fields are netmask and broadcast. > > You will need to run a migration with this patch. I'm not the right one to give ACKs on object model changes in the DB, but this looks ok with one question... How does the administrator indicate that a given NIC should be configured via DHCP? Is this done by explicitly setting the IP_ADDRESS field? One of the things I'd like to get back from the host along with broadcast and netmask is the actual IP. In the case of a host that is statically configured this IP will be the same as the admin configured IP. But in the case of a NIC using DHCP this will be useful info for the administrator. If IP_ADDRESS is used to determine whether the NIC is DHCP or not, we can't just simply add IP_ADDRESS to the list of data that is sent back via the node identify process. Since that would overwrite the empty field and switch the NIC from DHCP to static. We either need a field in the NIC table that indicates what mode the NIC is in (DHCP, bootp, static) or we need a second IP_ADDRESS field that is the ACTUAL_IP_ADDRESS instead of the configured IP_ADDRESS. There is a field in the nics table right now called USAGE_TYPE. If that is the intent of this field, then just ignore my comments :) Perry > Signed-off-by: Darryl L. Pierce > --- > src/db/migrate/018_add_netmask_to_nics.rb | 11 +++++++++++ > src/host-browser/host-browser.rb | 18 ++++++++++++++++-- > 2 files changed, 27 insertions(+), 2 deletions(-) > create mode 100644 src/db/migrate/018_add_netmask_to_nics.rb > > diff --git a/src/db/migrate/018_add_netmask_to_nics.rb b/src/db/migrate/018_add_netmask_to_nics.rb > new file mode 100644 > index 0000000..a006109 > --- /dev/null > +++ b/src/db/migrate/018_add_netmask_to_nics.rb > @@ -0,0 +1,11 @@ > +class AddNetmaskToNics < ActiveRecord::Migration > + def self.up > + add_column :nics, :netmask, :string, :limit => 16 > + add_column :nics, :broadcast, :string, :limit => 16 > + end > + > + def self.down > + remove_column :nics, :netmask > + remove_column :nics, :broadcast > + end > +end > diff --git a/src/host-browser/host-browser.rb b/src/host-browser/host-browser.rb > index a9fc9c7..debd78f 100755 > --- a/src/host-browser/host-browser.rb > +++ b/src/host-browser/host-browser.rb > @@ -170,7 +170,7 @@ class HostBrowser > > break if info == "ENDNIC" > > - raise Exception.new("ERRINFO! Excepted key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]/ > + raise Exception.new("ERRINFO! Excepted key=value : #{info}\n") unless info =~ /[\w]+[\s]*=[\w]*/ > > key, value = info.split("=") > > @@ -275,6 +275,17 @@ class HostBrowser > # the received data to avoid creating a dupe later > if detail['MAC'] == nic.mac > nic_info.delete(detail) > + > + updated_nic = Nic.find_by_id(nic.id) > + > + updated_nic.bandwidth = detail['BANDWIDTH'] > + updated_nic.ip_addr = detail['IP_ADDRESS'] > + updated_nic.netmask = detail['NETMASK'] > + updated_nic.broadcast = detail['BROADCAST'] > + > + updated_nic.save! > + found=true > + nic_info.delete detail > end > end > > @@ -292,7 +303,10 @@ class HostBrowser > detail = Nic.new( > 'mac' => nic['MAC'], > 'bandwidth' => nic['BANDWIDTH'], > - 'usage_type' => 1) > + 'usage_type' => 1, > + 'ip_addr' => nic['IP_ADDRESS'], > + 'netmask' => nic['NETMASK'], > + 'broadcast' => nic['BROADCAST']) > > host.nics << detail > end -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Sat Sep 13 15:11:01 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Sat, 13 Sep 2008 11:11:01 -0400 Subject: [Ovirt-devel] [PATCH] The node sends the ip address, netmask and interface name during identification. In-Reply-To: <1221252759-12187-1-git-send-email-dpierce@redhat.com> References: <1221252759-12187-1-git-send-email-dpierce@redhat.com> Message-ID: <48CBD805.5040400@redhat.com> Darryl L. Pierce wrote: > This patch requires the associated patch for the server which includes the netmask and broadcast columns. See comments on the other patch in this series. Perry > Signed-off-by: Darryl L. Pierce > --- > ovirt-identify-node/gather.c | 37 ++++++++++++++++++++++++++-- > ovirt-identify-node/ovirt-identify-node.h | 3 ++ > ovirt-identify-node/protocol.c | 6 ++++- > 3 files changed, 42 insertions(+), 4 deletions(-) > > diff --git a/ovirt-identify-node/gather.c b/ovirt-identify-node/gather.c > index 4a664f7..7c6fa55 100644 > --- a/ovirt-identify-node/gather.c > +++ b/ovirt-identify-node/gather.c > @@ -22,6 +22,10 @@ > > #include "ovirt-identify-node.h" > > +struct sockaddr_in sa; > + > +#define inaddrr(x) (*(struct in_addr *) &ifr.x[sizeof sa.sin_port]) > + > int > init_gather(void) > { > @@ -205,6 +209,7 @@ get_nic_data(char *nic, nic_info_ptr nic_info_p) > interface = > libhal_device_get_property_string(hal_ctx, nic, "net.interface", > &dbus_error); > + snprintf(nic_info_p->iface_name, BUFFER_LENGTH, "%s", interface); > bzero(&ifr, sizeof(struct ifreq)); > > sockfd = socket(AF_INET, SOCK_DGRAM, 0); > @@ -212,12 +217,36 @@ get_nic_data(char *nic, nic_info_ptr nic_info_p) > int bandwidth; > > ifr.ifr_addr.sa_family = AF_INET; > - strncpy(ifr.ifr_name, interface, IFNAMSIZ - 1); > + strncpy(ifr.ifr_name, interface, IFNAMSIZ - 1); > + > + if(!ioctl(sockfd,SIOCGIFADDR,&ifr)) { > + > + DEBUG("ip_address=%s\n",inet_ntoa(inaddrr(ifr_addr.sa_data))); > + > + snprintf(nic_info_p->ip_address, BUFFER_LENGTH, "%s", > + inet_ntoa(inaddrr(ifr_addr.sa_data))); > + } > + > + if(!ioctl(sockfd,SIOCGIFNETMASK,&ifr) && > + strcmp("255.255.255.255", inet_ntoa(inaddrr(ifr_addr.sa_data)))) { > + > + DEBUG("netmask=%s",inet_ntoa(inaddrr(ifr_addr.sa_data))); > + > + snprintf(nic_info_p->netmask, BUFFER_LENGTH, "%s", > + inet_ntoa(inaddrr(ifr_addr.sa_data))); > + } > + > + if(!ioctl(sockfd,SIOCGIFBRDADDR,&ifr)) { > + > + DEBUG("broadcast=%s",inet_ntoa(inaddrr(ifr_addr.sa_data))); > + > + snprintf(nic_info_p->broadcast, BUFFER_LENGTH, "%s", > + inet_ntoa(inaddrr(ifr_addr.sa_data))); > + } > > ifr.ifr_data = (caddr_t)&ecmd; > ioctl(sockfd, SIOCETHTOOL, &ifr); > - close(sockfd); > - > + > bandwidth = 10; > if (ecmd.supported & SUPPORTED_10000baseT_Full) > bandwidth = 10000; > @@ -234,6 +263,8 @@ get_nic_data(char *nic, nic_info_ptr nic_info_p) > bandwidth = 10; > > snprintf(nic_info_p->bandwidth, BUFFER_LENGTH, "%d", bandwidth); > + > + close(sockfd); > } > } > > diff --git a/ovirt-identify-node/ovirt-identify-node.h b/ovirt-identify-node/ovirt-identify-node.h > index c595891..b8485fc 100644 > --- a/ovirt-identify-node/ovirt-identify-node.h > +++ b/ovirt-identify-node/ovirt-identify-node.h > @@ -67,6 +67,9 @@ typedef struct _nic_info { > char mac_address[BUFFER_LENGTH]; > char bandwidth[BUFFER_LENGTH]; > char ip_address[BUFFER_LENGTH]; > + char netmask[BUFFER_LENGTH]; > + char iface_name[BUFFER_LENGTH]; > + char broadcast[BUFFER_LENGTH]; > struct _nic_info* next; > } t_nic_info; > > diff --git a/ovirt-identify-node/protocol.c b/ovirt-identify-node/protocol.c > index 2a92edb..35bf651 100644 > --- a/ovirt-identify-node/protocol.c > +++ b/ovirt-identify-node/protocol.c > @@ -181,7 +181,11 @@ send_nic_details(void) > > if (!(get_text("NICINFO?")) && > (!send_value("MAC", current->mac_address)) && > - (!send_value("BANDWIDTH", current->bandwidth))) { > + (!send_value("BANDWIDTH", current->bandwidth)) && > + (!send_value("IFACE_NAME", current->iface_name)) && > + (!send_value("IP_ADDRESS", current->ip_address)) && > + (!send_value("NETMASK", current->netmask)) && > + (!send_value("BROADCAST", current->broadcast))) { > send_text("ENDNIC"); > result = get_text("ACK NIC"); > } -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Sat Sep 13 15:20:53 2008 From: pmyers at redhat.com (Perry Myers) Date: Sat, 13 Sep 2008 11:20:53 -0400 Subject: [Ovirt-devel] [PATCH appliance] Added in libvirt, chkconfig and kvm as Requires for the appliance Message-ID: <1221319253-25029-1-git-send-email-pmyers@redhat.com> The create-ovirt-appliance script requires libvirt and chkconfig to set up the appliance and network configurations. brctl is brought in as a dependency of libvirt And the appliance requires libvirt and kvm to actually run. Any version of chkconfig should work, but as of right now we require specific versions of libvirt and kvm from the ovirt repositories. So the version checks for those packages are somewhat more specific. This will change as we get the migration patches out of the ovirt repo and upstream. Signed-off-by: Perry Myers --- ovirt-appliance.spec | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index 9cb1984..f06b65e 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -20,6 +20,9 @@ BuildRequires: livecd-tools >= 017 BuildRequires: syslinux BuildRequires: qemu-img BuildRequires: wget +Requires: chkconfig +Requires: libvirt >= 0.4.4-2ovirt2 +Requires: kvm >= 72-3ovirt3 %define app_root %{_datadir}/%{name} -- 1.5.5.1 From pmyers at redhat.com Sat Sep 13 15:22:45 2008 From: pmyers at redhat.com (Perry Myers) Date: Sat, 13 Sep 2008 11:22:45 -0400 Subject: [Ovirt-devel] [PATCH release] Add subject prefix config to update target Message-ID: <1221319365-25083-1-git-send-email-pmyers@redhat.com> This allows git format-patch to generate subject prefixes that are specific to each of the oVirt repositories making it easier to see what repo a patch is intended for. i.e. [PATCH appliance] Signed-off-by: Perry Myers --- ovirt.mk | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index ea5d6fa..b72fbac 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -38,6 +38,7 @@ $(SUBDIRS): @test -d $@ && : || git clone $(OVIRT_GIT_SERVER)/ovirt-$@ $@ @cd $@ && { test "$(OVIRT_BRANCH)" = "master" || \ git config remote.origin.fetch +$(OVIRT_BRANCH):$(OVIRT_BRANCH) ; } + @cd $@ && git config format.subjectprefix "PATCH $@" @cd $@ && git pull -v && git checkout $(OVIRT_BRANCH) clean distclean bumpgit bumprelease bumpversion: -- 1.5.5.1 From sseago at redhat.com Sat Sep 13 16:08:59 2008 From: sseago at redhat.com (Scott Seago) Date: Sat, 13 Sep 2008 12:08:59 -0400 Subject: [Ovirt-devel] [PATCH] Added additional fields to the nic table. In-Reply-To: <48CBD7A4.5050503@redhat.com> References: <1221252721-12129-1-git-send-email-dpierce@redhat.com> <48CBD7A4.5050503@redhat.com> Message-ID: <48CBE59B.3040403@redhat.com> Perry N. Myers wrote: > Darryl L. Pierce wrote: >> The new fields are netmask and broadcast. >> >> You will need to run a migration with this patch. > > I'm not the right one to give ACKs on object model changes in the DB, > but this looks ok with one question... > > How does the administrator indicate that a given NIC should be > configured via DHCP? Is this done by explicitly setting the > IP_ADDRESS field? > > One of the things I'd like to get back from the host along with > broadcast and netmask is the actual IP. In the case of a host that is > statically configured this IP will be the same as the admin configured > IP. But in the case of a NIC using DHCP this will be useful info for > the administrator. > > If IP_ADDRESS is used to determine whether the NIC is DHCP or not, we > can't just simply add IP_ADDRESS to the list of data that is sent back > via the node identify process. Since that would overwrite the empty > field and switch the NIC from DHCP to static. > > We either need a field in the NIC table that indicates what mode the > NIC is in (DHCP, bootp, static) or we need a second IP_ADDRESS field > that is the ACTUAL_IP_ADDRESS instead of the configured IP_ADDRESS. > There is a field in the nics table right now called USAGE_TYPE. If > that is the intent of this field, then just ignore my comments :) > > Perry > We should probably have an explicit flag for DHCP vs. static -- although a separate "specified IP address" field (where blank or "DHCP" == DHCP) would work too. IP_ADDRESS should probably be used for the actual IP address. Usage type is not for this at all. The intent of usage type is to identify what the NIC is used for (i.e. management NIC, etc.) When the comments field was proposed I'd initially considered that USAGE_TYPE might do this, but I think comments should probably be separate. USAGE_TYPE should be confined to a known list -- so it will be easy to deteremine the management NIC, etc. for a host. Scott From pmyers at redhat.com Sat Sep 13 16:15:34 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Sat, 13 Sep 2008 12:15:34 -0400 Subject: [Ovirt-devel] [PATCH] Added additional fields to the nic table. In-Reply-To: <48CBE59B.3040403@redhat.com> References: <1221252721-12129-1-git-send-email-dpierce@redhat.com> <48CBD7A4.5050503@redhat.com> <48CBE59B.3040403@redhat.com> Message-ID: <48CBE726.6070400@redhat.com> Scott Seago wrote: > Perry N. Myers wrote: >> Darryl L. Pierce wrote: >>> The new fields are netmask and broadcast. >>> >>> You will need to run a migration with this patch. >> >> I'm not the right one to give ACKs on object model changes in the DB, >> but this looks ok with one question... >> >> How does the administrator indicate that a given NIC should be >> configured via DHCP? Is this done by explicitly setting the >> IP_ADDRESS field? >> >> One of the things I'd like to get back from the host along with >> broadcast and netmask is the actual IP. In the case of a host that is >> statically configured this IP will be the same as the admin configured >> IP. But in the case of a NIC using DHCP this will be useful info for >> the administrator. >> >> If IP_ADDRESS is used to determine whether the NIC is DHCP or not, we >> can't just simply add IP_ADDRESS to the list of data that is sent back >> via the node identify process. Since that would overwrite the empty >> field and switch the NIC from DHCP to static. >> >> We either need a field in the NIC table that indicates what mode the >> NIC is in (DHCP, bootp, static) or we need a second IP_ADDRESS field >> that is the ACTUAL_IP_ADDRESS instead of the configured IP_ADDRESS. >> There is a field in the nics table right now called USAGE_TYPE. If >> that is the intent of this field, then just ignore my comments :) >> >> Perry >> > We should probably have an explicit flag for DHCP vs. static -- although > a separate "specified IP address" field (where blank or "DHCP" == DHCP) > would work too. IP_ADDRESS should probably be used for the actual IP > address. I'm in favor or a new field that has a constrained set of values (DHCP, bootp, static) that the user selects from in the Node Edit screen. If DHCP/bootp are selected the admin configurable ip address, netmask, DNS server, default gateway fields should all be greyed out. If static is selected all of these fields can be edited. If the administrator selects DHCP/bootp then ovirt identify node puts in values for IP_ADDRESS, NETMASK, BROADCAST, DEFAULT_GATEWAY, DNS_SERVERS, etc... that are collected after the interface is brought up on the Node. However, these fields should still be greyed out to indicate that the information there is not configurable by the admin. Based on the current data model it looks like for static config we're missing a few items like the default gateway and dns fields. We'll need to add those to the model/UI and also extract them from the Node during identify. That all make sense? > Usage type is not for this at all. The intent of usage type is to > identify what the NIC is used for (i.e. management NIC, etc.) When the > comments field was proposed I'd initially considered that USAGE_TYPE > might do this, but I think comments should probably be separate. > USAGE_TYPE should be confined to a known list -- so it will be easy to > deteremine the management NIC, etc. for a host. Ok. I agree with keeping usage type as it is. A way of identifying what the purpose of the network interface is for. Storage, Management, Guest. In addition to this drop down, we also need a user configurable Label field. This should be a drop down that is editable. i.e. the user can select that a NIC belongs to LAN A, LAN B or define a new one called LAN C. This way NICs can be grouped together for purposes of determining which Nodes are suitable to start a VM or migrate a VM. Perry From apevec at redhat.com Sun Sep 14 14:13:05 2008 From: apevec at redhat.com (Alan Pevec) Date: Sun, 14 Sep 2008 16:13:05 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node] set correct ethtool command Message-ID: <1221401585-11438-1-git-send-email-apevec@redhat.com> Signed-off-by: Alan Pevec --- ovirt-identify-node/gather.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/ovirt-identify-node/gather.c b/ovirt-identify-node/gather.c index 4a664f7..5c01d31 100644 --- a/ovirt-identify-node/gather.c +++ b/ovirt-identify-node/gather.c @@ -214,6 +214,7 @@ get_nic_data(char *nic, nic_info_ptr nic_info_p) ifr.ifr_addr.sa_family = AF_INET; strncpy(ifr.ifr_name, interface, IFNAMSIZ - 1); + ecmd.cmd = ETHTOOL_GSET; ifr.ifr_data = (caddr_t)&ecmd; ioctl(sockfd, SIOCETHTOOL, &ifr); close(sockfd); -- 1.5.5.1 From jim at meyering.net Sun Sep 14 17:38:23 2008 From: jim at meyering.net (Jim Meyering) Date: Sun, 14 Sep 2008 19:38:23 +0200 Subject: [Ovirt-devel] [PATCH appliance] Added in libvirt, chkconfig and kvm as Requires for the appliance In-Reply-To: <1221319253-25029-1-git-send-email-pmyers@redhat.com> (Perry Myers's message of "Sat, 13 Sep 2008 11:20:53 -0400") References: <1221319253-25029-1-git-send-email-pmyers@redhat.com> Message-ID: <87myiamxv4.fsf@rho.meyering.net> Perry Myers wrote: > The create-ovirt-appliance script requires libvirt and chkconfig > to set up the appliance and network configurations. brctl is > brought in as a dependency of libvirt > > And the appliance requires libvirt and kvm to actually run. > > Any version of chkconfig should work, but as of right now we > require specific versions of libvirt and kvm from the ovirt > repositories. So the version checks for those packages > are somewhat more specific. This will change as we get the > migration patches out of the ovirt repo and upstream. > > Signed-off-by: Perry Myers > --- > ovirt-appliance.spec | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec > index 9cb1984..f06b65e 100644 > --- a/ovirt-appliance.spec > +++ b/ovirt-appliance.spec > @@ -20,6 +20,9 @@ BuildRequires: livecd-tools >= 017 > BuildRequires: syslinux > BuildRequires: qemu-img > BuildRequires: wget > +Requires: chkconfig > +Requires: libvirt >= 0.4.4-2ovirt2 > +Requires: kvm >= 72-3ovirt3 ACK. it might be nice to add a comment reminding us to make the changes: # FIXME: remove ovirt* suffix when the required functionality is upstream From jim at meyering.net Sun Sep 14 17:41:21 2008 From: jim at meyering.net (Jim Meyering) Date: Sun, 14 Sep 2008 19:41:21 +0200 Subject: [Ovirt-devel] [PATCH release] Add subject prefix config to update target In-Reply-To: <1221319365-25083-1-git-send-email-pmyers@redhat.com> (Perry Myers's message of "Sat, 13 Sep 2008 11:22:45 -0400") References: <1221319365-25083-1-git-send-email-pmyers@redhat.com> Message-ID: <87hc8imxq6.fsf@rho.meyering.net> Perry Myers wrote: > This allows git format-patch to generate subject prefixes that > are specific to each of the oVirt repositories making it easier > to see what repo a patch is intended for. i.e. > > [PATCH appliance] ... > + @cd $@ && git config format.subjectprefix "PATCH $@" ACK. definitely worth it. From pmyers at redhat.com Sun Sep 14 21:48:20 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Sun, 14 Sep 2008 17:48:20 -0400 Subject: [Ovirt-devel] [PATCH appliance] Added in libvirt, chkconfig and kvm as Requires for the appliance In-Reply-To: <87myiamxv4.fsf@rho.meyering.net> References: <1221319253-25029-1-git-send-email-pmyers@redhat.com> <87myiamxv4.fsf@rho.meyering.net> Message-ID: <48CD86A4.4080403@redhat.com> Jim Meyering wrote: > Perry Myers wrote: > >> The create-ovirt-appliance script requires libvirt and chkconfig >> to set up the appliance and network configurations. brctl is >> brought in as a dependency of libvirt >> >> And the appliance requires libvirt and kvm to actually run. >> >> Any version of chkconfig should work, but as of right now we >> require specific versions of libvirt and kvm from the ovirt >> repositories. So the version checks for those packages >> are somewhat more specific. This will change as we get the >> migration patches out of the ovirt repo and upstream. >> >> Signed-off-by: Perry Myers >> --- >> ovirt-appliance.spec | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec >> index 9cb1984..f06b65e 100644 >> --- a/ovirt-appliance.spec >> +++ b/ovirt-appliance.spec >> @@ -20,6 +20,9 @@ BuildRequires: livecd-tools >= 017 >> BuildRequires: syslinux >> BuildRequires: qemu-img >> BuildRequires: wget >> +Requires: chkconfig >> +Requires: libvirt >= 0.4.4-2ovirt2 >> +Requires: kvm >= 72-3ovirt3 > > ACK. > it might be nice to add a comment reminding us to make the changes: > > # FIXME: remove ovirt* suffix when the required functionality is upstream Added comment and pushed. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From pmyers at redhat.com Sun Sep 14 23:49:55 2008 From: pmyers at redhat.com (Perry Myers) Date: Sun, 14 Sep 2008 19:49:55 -0400 Subject: [Ovirt-devel] [PATCH appliance] Fake Node creation now creates nodes with 128MB disk for use in testing Message-ID: <1221436195-25570-1-git-send-email-pmyers@redhat.com> This allows easy testing of Node 'installation' and persistent config data. Signed-off-by: Perry Myers --- create-ovirt-appliance | 19 ++++++++++++++++--- ovirt-appliance.spec | 1 + 2 files changed, 17 insertions(+), 3 deletions(-) diff --git a/create-ovirt-appliance b/create-ovirt-appliance index 071781a..c291041 100755 --- a/create-ovirt-appliance +++ b/create-ovirt-appliance @@ -14,6 +14,9 @@ NAME_DEFAULT=ovirt-appliance NET_SCRIPTS=/etc/sysconfig/network-scripts BRIDGENAME=ovirtbr0 +NODE_DISK_SIZE=128M +NODE_DISK_FMT=raw + imgdir=$IMGDIR_DEFAULT name=$NAME_DEFAULT @@ -57,6 +60,7 @@ EOF gen_fake_managed_node() { local num=$1 + local disk=$2 local last_mac=$(( 54 + $num )) cat <destroy $KVM_BINARY + + + + @@ -144,7 +152,7 @@ fi # now make sure the packages we need are installed if [ -e /etc/redhat-release ]; then - PACKAGES="libvirt kvm" + PACKAGES="libvirt kvm qemu-img" CHECK=$(rpm $(printf " -q %s " "$PACKAGES") &> /dev/null; echo $?) KVM_BINARY=/usr/bin/qemu-kvm elif [ -e /etc/debian_version ]; then @@ -199,12 +207,18 @@ if [ -n "$bridge" ]; then && die "$bridge device active with ip address, aborting!" fi +mkdir -p $imgdir + # define the fake managed nodes we will use. for i in `seq 3 5` ; do + imgname="node${i}.img" + if [ ! -f $imgdir/$imgname ]; then + qemu-img create -f $NODE_DISK_FMT $imgdir/$imgname $NODE_DISK_SIZE + fi virsh destroy node$i >& /dev/null virsh undefine node$i >& /dev/null TMPXML=$(mktemp) - gen_fake_managed_node $i > $TMPXML + gen_fake_managed_node $i $imgdir/$imgname > $TMPXML virsh define $TMPXML rm $TMPXML done @@ -265,7 +279,6 @@ fi virsh undefine bundled } > /dev/null 2>&1 -mkdir -p $imgdir imgname=$name.img test ! -r $imgdir/$imgname && die "Disk image not found at $imgdir/$imgname" virsh destroy $name > /dev/null 2>&1 diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index 52c248d..d2b29bb 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -25,6 +25,7 @@ BuildRequires: wget # is fixed, these Requires should be fixed. Requires: libvirt >= 0.4.4-2ovirt2 Requires: kvm >= 72-3ovirt3 +Requires: qemu-img %define app_root %{_datadir}/%{name} -- 1.5.5.1 From pmyers at redhat.com Mon Sep 15 01:20:01 2008 From: pmyers at redhat.com (Perry Myers) Date: Sun, 14 Sep 2008 21:20:01 -0400 Subject: [Ovirt-devel] [PATCH node-image] Fix %post for pxe pkg to succeed regardless of whether or not cobbler is present Message-ID: <1221441601-26615-1-git-send-email-pmyers@redhat.com> Old %post would generate error if cobbler was not installed. This method tries cobbler sync but regardless of success || : ensures that %post succeeds. This eliminates error on livecd creation of Appliance since ovirt-node installs before cobbler is installed. Signed-off-by: Perry Myers --- ovirt-node-image.spec | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec index 01d906a..01b7c29 100644 --- a/ovirt-node-image.spec +++ b/ovirt-node-image.spec @@ -85,7 +85,7 @@ mkdir %{buildroot} %{__rm} -rf %{buildroot} %post pxe -(cobbler --help) > /dev/null 2>&1 && cobbler sync +cobbler sync > /dev/null 2>&1 || : %files %defattr(-,root,root,0644) -- 1.5.5.1 From clalance at redhat.com Mon Sep 15 07:30:14 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 15 Sep 2008 09:30:14 +0200 Subject: [Ovirt-devel] [PATCH node-image] Fix %post for pxe pkg to succeed regardless of whether or not cobbler is present In-Reply-To: <1221441601-26615-1-git-send-email-pmyers@redhat.com> References: <1221441601-26615-1-git-send-email-pmyers@redhat.com> Message-ID: <48CE0F06.30800@redhat.com> Perry Myers wrote: > diff --git a/ovirt-node-image.spec b/ovirt-node-image.spec > index 01d906a..01b7c29 100644 > --- a/ovirt-node-image.spec > +++ b/ovirt-node-image.spec > @@ -85,7 +85,7 @@ mkdir %{buildroot} > %{__rm} -rf %{buildroot} > > %post pxe > -(cobbler --help) > /dev/null 2>&1 && cobbler sync > +cobbler sync > /dev/null 2>&1 || : Ah, I see. My previous version didn't cause a problem, but just printed out a bogus %post error message (which is probably why I didn't notice). This way, %post exits with a 0 exit code, as you say above. Good. ACK -- Chris Lalancette From clalance at redhat.com Mon Sep 15 10:38:03 2008 From: clalance at redhat.com (Chris Lalancette) Date: Mon, 15 Sep 2008 12:38:03 +0200 Subject: [Ovirt-devel] Updated kvm and libvirt packages in the repos Message-ID: <48CE3B0B.8030902@redhat.com> All, Just as a heads up, I've uploaded new versions of the kvm and libvirt packages to our ovirt repos. The kvm change is minor, but important; it takes away our temporary hack to fix the PXE boot under emulation and fixes it with the proper patch that went into upstream qemu. Most users probably won't even notice. The libvirt change is more substantial; F-9 is presently going to get a 0.4.5 updated libvirt package, which would have superseded the version in our ovirt repos. To get ahead of that, I forward-ported the migration patch that we are currently carrying to 0.4.5, built it, and uploaded it. I've done light testing with both of these packages, and things seem to be working as they were before. But especially since 0.4.5 is so new, please give it a test. If there are problems, please let me know via this list. -- Chris Lalancette From mmorsi at redhat.com Mon Sep 15 12:09:47 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Mon, 15 Sep 2008 08:09:47 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CA9A9E.3060603@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> <48CA8510.6030408@redhat.com> <48CA8F27.6080301@redhat.com> <48CA9362.2010005@redhat.com> <48CA9A9E.3060603@redhat.com> Message-ID: <48CE508B.4010607@redhat.com> Scott Seago wrote: > Chris Lalancette wrote: >> Scott Seago wrote: >> >>> Yeah -- we need to do them in the same place. As it is with this >>> patch, there's a bit of a race condition if you edit a vm right >>> after creating (but before taskomatic executes create_vm). >>> Originally I'd made the decision to put the system create in >>> taskomatic, since that's where all the other action-oriented bits >>> that call out to external servers are handled. It's probably not >>> that big a deal either way though, as we're already making cobbler >>> calls from the WUI to get the profile list. >>> >>> But yes, we need to either put both of these calls in taskomatic or >>> gut create_vm and put both in the WUI. My original preference here >>> was for taskomatic to handle it, but the reprovision case makes that >>> much more complex (since we'd need a new task type, etc), so maybe >>> it makes more sense to do it all in the WUI. >>> >>> Any other opinions on this? >>> >> >> Not an opinion (since I don't really care where it's done, as long as >> it is >> consistent), but a fact: in theory the cobbler stuff could hang up >> the WUI if >> there are network issues. If you do something like: >> >> iptables -A INPUT -p tcp --dport -j DROP >> >> on the cobbler server to simulate a network outage, then try to >> connect to it >> remotely, you will hang up for quite a while TCP attempts to >> connect. It's one >> reason to slightly prefer taskomatic to do it, but it may not be >> compelling >> enough. I just thought I would point it out. >> >> > On the other hand, we're already getting the profile list on the WUI > -- the above problem will affect the WUI anyway unless we also > generate the cobbler profile list on the back end. Now we may > eventually have to do this anyway if we ever want to define > per-profile access control -- but as things stand now, just doing the > cobbler system bit in taskomatic doesn't completely eliminate the > cobbler connectivity issue for the WUI. > > Scott It seems the best / most flexible way for future requirements would be to move all the cobbler calls out to task-o-matic, and setup some caching system so as to not to run into the wui being hung up when cobbler cannot be reached (for both setting and getting the profile). Unfortunately, this requires significant design decisions early on, including how and when we should cache, managing discrepancies (what if the user picks a cobbler item from the local cache that has since been deleting from the server), and semi-major model changes / additions, all of which is out of the scope of this vm re-provisioning requirement. It seems to me that this should all become a separate requirement for future development, and currently we can leave the implementation as is, or move the bits setting the cobbler profile from task-o-matic into the wui for the time being for consistency. I don't think the whole create_vm process needs to be gutted from task-o-matic, simply the portions involving cobbler if we go that route. After this component is checked off, then we can tackle the issues and design considerations of integrating cobbler with task-o-matic and the cobbler cache with the wui. -Mo From sseago at redhat.com Mon Sep 15 13:10:00 2008 From: sseago at redhat.com (Scott Seago) Date: Mon, 15 Sep 2008 09:10:00 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CE508B.4010607@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> <48CA8510.6030408@redhat.com> <48CA8F27.6080301@redhat.com> <48CA9362.2010005@redhat.com> <48CA9A9E.3060603@redhat.com> <48CE508B.4010607@redhat.com> Message-ID: <48CE5EA8.6000705@redhat.com> Mohammed Morsi wrote: > Scott Seago wrote: > >> On the other hand, we're already getting the profile list on the WUI >> -- the above problem will affect the WUI anyway unless we also >> generate the cobbler profile list on the back end. Now we may >> eventually have to do this anyway if we ever want to define >> per-profile access control -- but as things stand now, just doing the >> cobbler system bit in taskomatic doesn't completely eliminate the >> cobbler connectivity issue for the WUI. >> >> Scott >> > It seems the best / most flexible way for future requirements would be > to move all the cobbler calls out to task-o-matic, and setup some > caching system so as to not to run into the wui being hung up when > cobbler cannot be reached (for both setting and getting the profile). > Unfortunately, this requires significant design decisions early on, > including how and when we should cache, managing discrepancies (what if > the user picks a cobbler item from the local cache that has since been > deleting from the server), and semi-major model changes / additions, all > of which is out of the scope of this vm re-provisioning requirement. > > It seems to me that this should all become a separate requirement for > future development, and currently we can leave the implementation as is, > or move the bits setting the cobbler profile from task-o-matic into the > wui for the time being for consistency. I don't think the whole > create_vm process needs to be gutted from task-o-matic, simply the > portions involving cobbler if we go that route. After this component is > checked off, then we can tackle the issues and design considerations of > integrating cobbler with task-o-matic and the cobbler cache with the wui. > > -Mo > That seems reasonable to me. Note that when I said gut create_vm -- I didn't mean remove the operation entirely -- just remove the cobbler bits from it. Currently that's all that it does though -- so create_vm will once again become a no-op (like it was before we added cobbler). But we should still keep it, as it is a logical action taken -- it just so happens that at the moment there's nothing taskomatic needs to do for it. So yes, lets pull out the cobbler bits from the create_vm action and put the cobbler image creation into the wui like you're doing for edit VM. Scott From pmyers at redhat.com Mon Sep 15 13:12:03 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 15 Sep 2008 09:12:03 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CE508B.4010607@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CA7EB0.5070506@redhat.com> <48CA8510.6030408@redhat.com> <48CA8F27.6080301@redhat.com> <48CA9362.2010005@redhat.com> <48CA9A9E.3060603@redhat.com> <48CE508B.4010607@redhat.com> Message-ID: <48CE5F23.4020302@redhat.com> Mohammed Morsi wrote: > Scott Seago wrote: >> Chris Lalancette wrote: >>> Scott Seago wrote: >>> >>>> Yeah -- we need to do them in the same place. As it is with this >>>> patch, there's a bit of a race condition if you edit a vm right >>>> after creating (but before taskomatic executes create_vm). >>>> Originally I'd made the decision to put the system create in >>>> taskomatic, since that's where all the other action-oriented bits >>>> that call out to external servers are handled. It's probably not >>>> that big a deal either way though, as we're already making cobbler >>>> calls from the WUI to get the profile list. >>>> >>>> But yes, we need to either put both of these calls in taskomatic or >>>> gut create_vm and put both in the WUI. My original preference here >>>> was for taskomatic to handle it, but the reprovision case makes that >>>> much more complex (since we'd need a new task type, etc), so maybe >>>> it makes more sense to do it all in the WUI. >>>> >>>> Any other opinions on this? >>>> >>> Not an opinion (since I don't really care where it's done, as long as >>> it is >>> consistent), but a fact: in theory the cobbler stuff could hang up >>> the WUI if >>> there are network issues. If you do something like: >>> >>> iptables -A INPUT -p tcp --dport -j DROP >>> >>> on the cobbler server to simulate a network outage, then try to >>> connect to it >>> remotely, you will hang up for quite a while TCP attempts to >>> connect. It's one >>> reason to slightly prefer taskomatic to do it, but it may not be >>> compelling >>> enough. I just thought I would point it out. >>> >>> >> On the other hand, we're already getting the profile list on the WUI >> -- the above problem will affect the WUI anyway unless we also >> generate the cobbler profile list on the back end. Now we may >> eventually have to do this anyway if we ever want to define >> per-profile access control -- but as things stand now, just doing the >> cobbler system bit in taskomatic doesn't completely eliminate the >> cobbler connectivity issue for the WUI. >> >> Scott > It seems the best / most flexible way for future requirements would be > to move all the cobbler calls out to task-o-matic, and setup some > caching system so as to not to run into the wui being hung up when > cobbler cannot be reached (for both setting and getting the profile). > Unfortunately, this requires significant design decisions early on, > including how and when we should cache, managing discrepancies (what if > the user picks a cobbler item from the local cache that has since been > deleting from the server), and semi-major model changes / additions, all > of which is out of the scope of this vm re-provisioning requirement. > > It seems to me that this should all become a separate requirement for > future development, and currently we can leave the implementation as is, > or move the bits setting the cobbler profile from task-o-matic into the > wui for the time being for consistency. I don't think the whole > create_vm process needs to be gutted from task-o-matic, simply the > portions involving cobbler if we go that route. After this component is > checked off, then we can tackle the issues and design considerations of > integrating cobbler with task-o-matic and the cobbler cache with the wui. I somewhat agree with you here... In that the long term solution should be future development. However, for the short term solution, leave the create_system stuff in Taskomatic that is associated with the create_vm action since that should logically be done by Taskomatic when it is ready do to that action. Pulling the cobbler profile/image list can stay in the WUI as we don't need a separate taskomatic request for that. Editing the VM to reprovision it does require a Taskomatic task since the VM definition needs to be redefined (i.e. the boot method needs to be changed from hd to net or cdrom). So the act of reprovisioning should result in a taskomatic task that also creates a new system (or edits the old system depending on how the cobbler Ruby API works). Perry From dmc at filteredperception.org Wed Sep 10 02:59:33 2008 From: dmc at filteredperception.org (Douglas McClendon) Date: Tue, 09 Sep 2008 19:59:33 -0700 Subject: [Fedora-livecd-list] Re: [Ovirt-devel] root access required? In-Reply-To: <20080909142232.GA25270@amd.home.annexia.org> References: <48C54CC9.1080701@redhat.com> <20080909142232.GA25270@amd.home.annexia.org> Message-ID: <48C73815.20503@filteredperception.org> Richard W.M. Jones wrote: > On Mon, Sep 08, 2008 at 12:03:21PM -0400, Perry N. Myers wrote: >> Ben Guthro wrote: >>> In my endeavor to set up a build environment for our developers >>> experimenting with oVirt / libvirt, I have come across a general >>> dislike that the build of the ovirt managed node requires the user to >>> be root. > [...] >> The dependency on needing root is inherited from livecd-tools. So for us >> to remove root as a requirement for building this needs to be changed >> upstream. I'd start by posting questions/requests to the livecd mailing >> lists and see if the developers there can easily fix this. >> >> Once root is not longer required for livecd-tools, we will be able to >> build everything in ovirt as non-root. > > I would also LOVE to see livecd-creator not needing root. Has anyone > talked to the livecd developers about this (email CC'd)? I can't find > any recent discussion on their mailing list about it though. FWIW, I've done a lot of work over the years on my livecd creation project (viros.org), and the main reason I worked on it instead of solely on livecd-creator was a strong personal preference on not requiring root. My method for succeeding involves using qemu/kvm appliances running just from a highly customized fedora-based initrd-only system. The result is that it is 6 odd times slower than livecd-creator, but it doesn't require root. Thinking about the pre/post-inst rpm scripts being run under the limited protection of a chroot in livecd-creator just doesn't sit well with me. So it's definitely doable, but there is a price to pay. Several aspects that necessitated needing virtualization may now be doable via the fact that fuse is enabled by default for users. But I think there are still a few places you need root (virtualized or not, but not just fakeroot) to get the job done. -dmc From dmc at filteredperception.org Wed Sep 10 03:00:04 2008 From: dmc at filteredperception.org (Douglas McClendon) Date: Tue, 09 Sep 2008 20:00:04 -0700 Subject: [Fedora-livecd-list] Re: [Ovirt-devel] root access required? In-Reply-To: <20080909142232.GA25270@amd.home.annexia.org> References: <48C54CC9.1080701@redhat.com> <20080909142232.GA25270@amd.home.annexia.org> Message-ID: <48C73834.6030302@filteredperception.org> Richard W.M. Jones wrote: > On Mon, Sep 08, 2008 at 12:03:21PM -0400, Perry N. Myers wrote: >> Ben Guthro wrote: >>> In my endeavor to set up a build environment for our developers >>> experimenting with oVirt / libvirt, I have come across a general >>> dislike that the build of the ovirt managed node requires the user to >>> be root. > [...] >> The dependency on needing root is inherited from livecd-tools. So for us >> to remove root as a requirement for building this needs to be changed >> upstream. I'd start by posting questions/requests to the livecd mailing >> lists and see if the developers there can easily fix this. >> >> Once root is not longer required for livecd-tools, we will be able to >> build everything in ovirt as non-root. > > I would also LOVE to see livecd-creator not needing root. Has anyone > talked to the livecd developers about this (email CC'd)? I can't find > any recent discussion on their mailing list about it though. FWIW, I've done a lot of work over the years on my livecd creation project (viros.org), and the main reason I worked on it instead of solely on livecd-creator was a strong personal preference on not requiring root. My method for succeeding involves using qemu/kvm appliances running just from a highly customized fedora-based initrd-only system. The result is that it is 6 odd times slower than livecd-creator, but it doesn't require root. Thinking about the pre/post-inst rpm scripts being run under the limited protection of a chroot in livecd-creator just doesn't sit well with me. So it's definitely doable, but there is a price to pay. Several aspects that necessitated needing virtualization may now be doable via the fact that fuse is enabled by default for users. But I think there are still a few places you need root (virtualized or not, but not just fakeroot) to get the job done. -dmc From sseago at redhat.com Mon Sep 15 14:58:45 2008 From: sseago at redhat.com (Scott Seago) Date: Mon, 15 Sep 2008 10:58:45 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> Message-ID: <48CE7825.4080504@redhat.com> Mohammed Morsi wrote: > --- > wui/src/app/controllers/vm_controller.rb | 73 +++++++++++++++++++++++++----- > wui/src/app/views/vm/_form.rhtml | 6 ++- > 2 files changed, 65 insertions(+), 14 deletions(-) > > diff --git a/wui/src/app/controllers/vm_controller.rb b/wui/src/app/controllers/vm_controller.rb > index e55ec28..82d8952 100644 > --- a/wui/src/app/controllers/vm_controller.rb > +++ b/wui/src/app/controllers/vm_controller.rb > @@ -193,6 +215,43 @@ class VmController < ApplicationController > end > > protected > + def _setup_provisioning_options > + @provisioning_options = [[Vm::PXE_OPTION_LABEL, Vm::PXE_OPTION_VALUE], > + [Vm::HD_OPTION_LABEL, Vm::HD_OPTION_VALUE]] > + # FIXME add cobbler images too > + begin > + @provisioning_options += Cobbler::Profile.find.collect do |profile| > + [profile.name + Vm::COBBLER_PROFILE_SUFFIX, profile.name] > + > + end > + rescue > + #if cobbler doesn't respond/is misconfigured/etc just don't add profiles > + end > + end > + > + def _setup_vm_provision(params) > This is fine for now -- but we eventually need to move this into an edit_vm task -- so go ahead and include a FIXME comment to mention this for now. > + # spaces are invalid in the cobbler name > + name = params[:vm][:description].gsub(" ", "-") > + provision = params[:vm][:provisioning_and_boot_settings] > + unless provision == Vm::PXE_OPTION_VALUE or > + provision == Vm::HD_OPTION_VALUE > + found = false > + Cobbler::System.find.each{ |system| > + if system.name == name > + system.profile = provision > + system.save > + found = true > + end > + } > + unless found > + system = Cobbler::System.create("name" => name, > + "profile" => provision) > + # do we need to set any of the other system attributes? > + system.save > + end > + end > + end > + > def pre_new > # if no vm_resource_pool is passed in, find (or auto-create) it based on hardware_pool_id > unless params[:vm_resource_pool_id] > ACK, once the FIXME comment is added. Scott From dpierce at redhat.com Mon Sep 15 15:02:36 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Mon, 15 Sep 2008 11:02:36 -0400 (EDT) Subject: [Ovirt-devel] [PATCH] Added additional fields to the nic table. In-Reply-To: <48CBD7A4.5050503@redhat.com> Message-ID: <84896217.12791221490956520.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Perry N. Myers" wrote: > Darryl L. Pierce wrote: > > The new fields are netmask and broadcast. > > > > You will need to run a migration with this patch. > > I'm not the right one to give ACKs on object model changes in the DB, > but > this looks ok with one question... > > How does the administrator indicate that a given NIC should be > configured > via DHCP? Is this done by explicitly setting the IP_ADDRESS field? The upcoming configuration generator patch addresses this. I had initially set a "use_dhcp" column, but have refactored that, based on this feedback. Now there's a boot_types table that contains the list of boot types: bootp, dhcp and static. The nics table ties to that and the generator uses that information to decide whether to send down a static IP configuration or a bootproto. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" From dpierce at redhat.com Mon Sep 15 15:03:39 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Mon, 15 Sep 2008 11:03:39 -0400 (EDT) Subject: [Ovirt-devel] Re: [PATCH] Added additional fields to the nic table. In-Reply-To: <1221252721-12129-1-git-send-email-dpierce@redhat.com> Message-ID: <1127400475.14131221491019401.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> ----- "Darryl L. Pierce" wrote: > The new fields are netmask and broadcast. > > You will need to run a migration with this patch. Can I get an ACK? -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" From pmyers at redhat.com Mon Sep 15 15:08:02 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 15 Sep 2008 11:08:02 -0400 Subject: [Ovirt-devel] Re: [PATCH] Added additional fields to the nic table. In-Reply-To: <1127400475.14131221491019401.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> References: <1127400475.14131221491019401.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <48CE7A52.2010801@redhat.com> Darryl L. Pierce wrote: > ----- "Darryl L. Pierce" wrote: > >> The new fields are netmask and broadcast. >> >> You will need to run a migration with this patch. > > Can I get an ACK? This is ok even with the discussion on this thread, since that discussion doesn't change the posted patch just other things on the server side. So ACK (just based on review of the patch, have not tested it myself). Darryl if you've done end to end tests of this, should be ok to commit. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From mmorsi at redhat.com Mon Sep 15 15:16:04 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Mon, 15 Sep 2008 11:16:04 -0400 Subject: [Ovirt-devel] Re: [PATCH] added ability to reprovision vm via edit vm form In-Reply-To: <48CE7825.4080504@redhat.com> References: <1220526954-12622-1-git-send-email-mmorsi@redhat.com> <48CE7825.4080504@redhat.com> Message-ID: <48CE7C34.8030600@redhat.com> Scott Seago wrote: > Mohammed Morsi wrote: >> >> + def _setup_vm_provision(params) >> > This is fine for now -- but we eventually need to move this into an > edit_vm task -- so go ahead and include a FIXME comment to mention > this for now. > > ACK, once the FIXME comment is added. > > Scott Comment added and pushed. Thanks. -Mo From bkearney at redhat.com Mon Sep 15 16:07:00 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 15 Sep 2008 12:07:00 -0400 Subject: [Ovirt-devel] Appliance Building using thincrust In-Reply-To: <48CA6257.8050302@redhat.com> References: <1219416455-18149-1-git-send-email-bkearney@redhat.com> <48CA6257.8050302@redhat.com> Message-ID: <48CE8824.6000906@redhat.com> Mohammed Morsi wrote: > bkearney at redhat.com wrote: >> Two patches. The first pulls in the appliance recipe from thincrust. The second modifies the kickstart file to use hte new rpms from the first. Note that most "flat files" from the kickstart files are now acutal files in the first patch. >> >> _______________________________________________ >> Ovirt-devel mailing list >> Ovirt-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/ovirt-devel >> > Hey Brian, > I started reviewing these patches this morning. Obviously with the > repo refactoring some changes will need to be made, as well as some > terminology updates ('wui' should probably be renamed to 'server' in a > few locations), but for the most part this all looks good. Other than > some directory layout tweaks due to the repo refactoring, a few things I > noticed that need to be changed is the removal of the firefox profile > from the appliance (firefox is no longer installed on the appliance > since we now support password-based / simple kerb auth); as well as the > removal of the build-all script (this functionality is mostly handled > via make / rpmbuild). Other than that, this looks to be good to go > (though I won't know for sure until I can apply the patch against a > ovirt-appliance checkout and test it). > > In the meantime, just to make sure I'm understanding how this all > works, you are removing all the cruft from the ovirt-appliance > kickstart, besides the bare essentials; eg. setting up the necessary > host resolution, iSCSI / NFS disc configuration, the ovirtAppliance > package to be installed (which I'm assuming will be in the oVirt repo > when this is all committed), and starting the ace init service on > startup. On the ovirtAppliance rpm side you've moved most of the > configuration previously in the kickstart to the > /usr/share/ace/appliances/ovirt directory which will be loaded and used > by ace when the service is started. Yes, the goal is to use the kickstart file to only describe the packages which are laid down. Any other configuration is moved to the control of puppet. The main change is to move all of the "file creation" items into one of the two locations under //usr/share/ace/appliances/ovirt - the files directory is used to house files which are copied as is to their final location. - the templates directory allows for erb driven templates. The variables are defined by the appliance recipe and what is in facter. - Updates can be done either to the puppet recipe, or to an updates file.. which ever you prefer. > > Overall it all makes sense and looks great. One last thing I'm trying to > figure out is the best way to add some minor changes to configure the > appliance to run in a test / demo mode, for example when autobuild is > going through the build process and setting up the appliance. These > changes include implanting the host's public ssh key onto the appliance, > delaying sshd to start as one of the last services, and setting the > rails environment to 'test'. Looking at your patches, perhaps one > approach (feel free to suggest an easier and/or better one) would be to > create a 'ovirt-test' ace configuration, residing in > /usr/share/ace/appliances/ovirt-test, which would be identical to the > 'ovirt' one save the aformentioned changes, and use the autobuild.sh > script in the ovirt-appliance repo to sed ovirt-appliance.ks (previously > wui-appliance/wui-devel.ks) to change "echo ovirt >> > /etc/sysconfig/ace/appliancename" to "echo ovirt-test >> > /etc/sysconfig/ace/appliancename". Since it has to do w/ autobuild I can > take care of this last part once your changes are in, but wanted to get > your feedback on the best approach. We have two options. The "correct" way would be a seperate recipe. We could also look to an augseas-command which sets the value based on the exisence of a control value in some other value. Either would work. -- bk From bkearney at redhat.com Mon Sep 15 16:07:24 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Mon, 15 Sep 2008 12:07:24 -0400 Subject: [Ovirt-devel] Appliance Building using thincrust In-Reply-To: <48CA6257.8050302@redhat.com> References: <1219416455-18149-1-git-send-email-bkearney@redhat.com> <48CA6257.8050302@redhat.com> Message-ID: <48CE883C.2010304@redhat.com> Mohammed Morsi wrote: > bkearney at redhat.com wrote: >> Two patches. The first pulls in the appliance recipe from thincrust. The second modifies the kickstart file to use hte new rpms from the first. Note that most "flat files" from the kickstart files are now acutal files in the first patch. >> >> _______________________________________________ >> Ovirt-devel mailing list >> Ovirt-devel at redhat.com >> https://www.redhat.com/mailman/listinfo/ovirt-devel >> > Hey Brian, > I started reviewing these patches this morning. Obviously with the > repo refactoring some changes will need to be made, as well as some > terminology updates ('wui' should probably be renamed to 'server' in a > few locations), but for the most part this all looks good. Other than > some directory layout tweaks due to the repo refactoring, a few things I > noticed that need to be changed is the removal of the firefox profile > from the appliance (firefox is no longer installed on the appliance > since we now support password-based / simple kerb auth); as well as the > removal of the build-all script (this functionality is mostly handled > via make / rpmbuild). Other than that, this looks to be good to go > (though I won't know for sure until I can apply the patch against a > ovirt-appliance checkout and test it). > > In the meantime, just to make sure I'm understanding how this all > works, you are removing all the cruft from the ovirt-appliance > kickstart, besides the bare essentials; eg. setting up the necessary > host resolution, iSCSI / NFS disc configuration, the ovirtAppliance > package to be installed (which I'm assuming will be in the oVirt repo > when this is all committed), and starting the ace init service on > startup. On the ovirtAppliance rpm side you've moved most of the > configuration previously in the kickstart to the > /usr/share/ace/appliances/ovirt directory which will be loaded and used > by ace when the service is started. Yes, the goal is to use the kickstart file to only describe the packages which are laid down. Any other configuration is moved to the control of puppet. The main change is to move all of the "file creation" items into one of the two locations under //usr/share/ace/appliances/ovirt - the files directory is used to house files which are copied as is to their final location. - the templates directory allows for erb driven templates. The variables are defined by the appliance recipe and what is in facter. - Updates can be done either to the puppet recipe, or to an updates file.. which ever you prefer. > > Overall it all makes sense and looks great. One last thing I'm trying to > figure out is the best way to add some minor changes to configure the > appliance to run in a test / demo mode, for example when autobuild is > going through the build process and setting up the appliance. These > changes include implanting the host's public ssh key onto the appliance, > delaying sshd to start as one of the last services, and setting the > rails environment to 'test'. Looking at your patches, perhaps one > approach (feel free to suggest an easier and/or better one) would be to > create a 'ovirt-test' ace configuration, residing in > /usr/share/ace/appliances/ovirt-test, which would be identical to the > 'ovirt' one save the aformentioned changes, and use the autobuild.sh > script in the ovirt-appliance repo to sed ovirt-appliance.ks (previously > wui-appliance/wui-devel.ks) to change "echo ovirt >> > /etc/sysconfig/ace/appliancename" to "echo ovirt-test >> > /etc/sysconfig/ace/appliancename". Since it has to do w/ autobuild I can > take care of this last part once your changes are in, but wanted to get > your feedback on the best approach. We have two options. The "correct" way would be a separate recipe. We could also look to an augseas-command which sets the value based on the existence of a control value in some other value. Either would work. -- bk From pmyers at redhat.com Mon Sep 15 20:25:21 2008 From: pmyers at redhat.com (Perry Myers) Date: Mon, 15 Sep 2008 16:25:21 -0400 Subject: [Ovirt-devel] [PATCH appliance] Fake Node creation now creates nodes with 128MB disk for use in testing Message-ID: <1221510321-15680-1-git-send-email-pmyers@redhat.com> This allows easy testing of Node 'installation' and persistent config data. Includes suggestions by Alan Pevec for making the spec file portable between Fedora and RHEL based systems by removing Requires: qemu-img and replacing with Requires: /usr/bin/qemu-img Also removes the PACKAGES check for Red Hat/Fedora systems since these checks are handled by the RPM deps. Signed-off-by: Perry Myers --- create-ovirt-appliance | 21 +++++++++++++++++---- ovirt-appliance.spec | 1 + 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/create-ovirt-appliance b/create-ovirt-appliance index 071781a..773d4d6 100755 --- a/create-ovirt-appliance +++ b/create-ovirt-appliance @@ -14,6 +14,9 @@ NAME_DEFAULT=ovirt-appliance NET_SCRIPTS=/etc/sysconfig/network-scripts BRIDGENAME=ovirtbr0 +NODE_DISK_SIZE=128M +NODE_DISK_FMT=raw + imgdir=$IMGDIR_DEFAULT name=$NAME_DEFAULT @@ -57,6 +60,7 @@ EOF gen_fake_managed_node() { local num=$1 + local disk=$2 local last_mac=$(( 54 + $num )) cat <destroy $KVM_BINARY + + + + @@ -144,8 +152,8 @@ fi # now make sure the packages we need are installed if [ -e /etc/redhat-release ]; then - PACKAGES="libvirt kvm" - CHECK=$(rpm $(printf " -q %s " "$PACKAGES") &> /dev/null; echo $?) + # We rely on RPM deps for this in Red Hat/Fedora systems + CHECK=0 KVM_BINARY=/usr/bin/qemu-kvm elif [ -e /etc/debian_version ]; then # Works in Ubuntu 8.04. Still needs testing in Debian @@ -199,12 +207,18 @@ if [ -n "$bridge" ]; then && die "$bridge device active with ip address, aborting!" fi +mkdir -p $imgdir + # define the fake managed nodes we will use. for i in `seq 3 5` ; do + imgname="node${i}.img" + if [ ! -f $imgdir/$imgname ]; then + qemu-img create -f $NODE_DISK_FMT $imgdir/$imgname $NODE_DISK_SIZE + fi virsh destroy node$i >& /dev/null virsh undefine node$i >& /dev/null TMPXML=$(mktemp) - gen_fake_managed_node $i > $TMPXML + gen_fake_managed_node $i $imgdir/$imgname > $TMPXML virsh define $TMPXML rm $TMPXML done @@ -265,7 +279,6 @@ fi virsh undefine bundled } > /dev/null 2>&1 -mkdir -p $imgdir imgname=$name.img test ! -r $imgdir/$imgname && die "Disk image not found at $imgdir/$imgname" virsh destroy $name > /dev/null 2>&1 diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index 52c248d..bd32391 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -25,6 +25,7 @@ BuildRequires: wget # is fixed, these Requires should be fixed. Requires: libvirt >= 0.4.4-2ovirt2 Requires: kvm >= 72-3ovirt3 +Requires: /usr/bin/qemu-img %define app_root %{_datadir}/%{name} -- 1.5.5.1 From apevec at redhat.com Mon Sep 15 20:28:38 2008 From: apevec at redhat.com (Alan Pevec) Date: Mon, 15 Sep 2008 22:28:38 +0200 Subject: [Ovirt-devel] [PATCH appliance] Fake Node creation now creates nodes with 128MB disk for use in testing In-Reply-To: <1221510321-15680-1-git-send-email-pmyers@redhat.com> References: <1221510321-15680-1-git-send-email-pmyers@redhat.com> Message-ID: <48CEC576.6000605@redhat.com> ACK From pmyers at redhat.com Tue Sep 16 00:43:16 2008 From: pmyers at redhat.com (Perry Myers) Date: Mon, 15 Sep 2008 20:43:16 -0400 Subject: [Ovirt-devel] [PATCH appliance] Fix spec to provide ability to excludepkgs from Fedora mirrors Message-ID: <1221525796-1388-1-git-send-email-pmyers@redhat.com> And set it to not bring in rubygem-rails, activerecord and activesupport pkgs since we need to address problems with upgrading from 2.0.1 to 2.1.0. bad_pkgs can be overridden using --define macro in rpmbuild. Signed-off-by: Perry Myers --- ovirt-appliance.spec | 9 +++++---- 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/ovirt-appliance.spec b/ovirt-appliance.spec index bd32391..8a2158e 100644 --- a/ovirt-appliance.spec +++ b/ovirt-appliance.spec @@ -3,6 +3,7 @@ %{!?ovirt_url: %define ovirt_url http://ovirt.org/repos/ovirt} %{?fedora_url: %define fedora_tree_url %{fedora_url}/releases/%{fedora}/Fedora/%{_arch}/os} %{!?fedora_tree_url: %define fedora_tree_url http://download.fedoraproject.org/pub/fedora/linux/releases/%{fedora}/Fedora/%{_arch}/os} +%{!?bad_pkgs: %define bad_pkgs rubygem-rails,rubygem-activesupport,rubygem-activerecord} %define fedora_mirror http://mirrors.fedoraproject.org/mirrorlist Summary: oVirt Appliance @@ -42,14 +43,14 @@ The oVirt Appliance image and scripts to install on a Fedora Host if [ -n "%{?fedora_url}" ]; then cat > repos.ks << EOF repo --name=f%{fedora} --baseurl=%{fedora_url}/releases/%{fedora}/Everything/%{_arch}/os -repo --name=f%{fedora}-updates --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch} -repo --name=f%{fedora}-updates-newkey --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch}.newkey +repo --name=f%{fedora}-updates --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch} --excludepkgs=%{bad_pkgs} +repo --name=f%{fedora}-updates-newkey --baseurl=%{fedora_url}/updates/%{fedora}/%{_arch}.newkey --excludepkgs=%{bad_pkgs} EOF else cat > repos.ks << EOF repo --name=f%{fedora} --mirrorlist=%{fedora_mirror}?repo=fedora-%{fedora}&arch=%{_arch} -repo --name=f%{fedora}-updates --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}&arch=%{_arch} -repo --name=f%{fedora}-updates-newkey --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}.newkey&arch=%{_arch} +repo --name=f%{fedora}-updates --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}&arch=%{_arch} --excludepkgs=%{bad_pkgs} +repo --name=f%{fedora}-updates-newkey --mirrorlist=%{fedora_mirror}?repo=updates-released-f%{fedora}.newkey&arch=%{_arch} --excludepkgs=%{bad_pkgs} EOF fi -- 1.5.5.1 From pmyers at redhat.com Tue Sep 16 00:45:37 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Mon, 15 Sep 2008 20:45:37 -0400 Subject: [Ovirt-devel] Re: [PATCH appliance] Fix spec to provide ability to excludepkgs from Fedora mirrors In-Reply-To: <1221525796-1388-1-git-send-email-pmyers@redhat.com> References: <1221525796-1388-1-git-send-email-pmyers@redhat.com> Message-ID: <48CF01B1.1040609@redhat.com> Perry Myers wrote: > And set it to not bring in rubygem-rails, activerecord and > activesupport pkgs since we need to address problems with > upgrading from 2.0.1 to 2.1.0. > > bad_pkgs can be overridden using --define macro in rpmbuild. Note, since the builds were presently broken due to Ruby I committed this change without ACKs. If anyone has any problems with the patch let me know and we can correct it with additional patches. Also, since the versions prior to 2.1.0 for the above packages were 2.0.2 and they were all in the Fedora 9 base repo, there was no need to host any of these packages in the ovirt.org repo. Perry From mmorsi at redhat.com Tue Sep 16 11:01:47 2008 From: mmorsi at redhat.com (Mohammed Morsi) Date: Tue, 16 Sep 2008 07:01:47 -0400 Subject: [Ovirt-devel] Re: [Fwd: [PATCH] autobuild fixes / improvements] In-Reply-To: <48CE88D0.70503@redhat.com> References: <48CE7F41.3090102@redhat.com> <48CE88D0.70503@redhat.com> Message-ID: <48CF921B.7060809@redhat.com> Alan Pevec wrote: > Mohammed Morsi wrote: >> * remove static version >> * use extra_release in spec >> * define ovirt_local_repo so as not to rely on .rpmmacros > >> --- a/autobuild.sh >> +++ b/autobuild.sh >> @@ -27,6 +27,8 @@ test -f Makefile && make -k distclean || : >> >> make tar >> >> +version=`sed s/\ .*$// version` > > sed is confusing, I'd prefer awk, like in release.mk: > > +version=$(awk '{print $1}' version) > > ACK for the rest Change made and appropriate changes pushed to appropriate repos. -Mo From pmyers at redhat.com Tue Sep 16 13:21:16 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 16 Sep 2008 09:21:16 -0400 Subject: [Ovirt-devel] ovirt-docs repository Message-ID: <48CFB2CC.10807@redhat.com> Chris and Susan: Dan B. has suggested that it might make more sense for each document you generate to have it's own separate git repository with the same structure. So, instead of ovirt-docs, we'd currently have: ovirt-doc-using-the-ovirt-admin-ui ovirt-doc-ovirt-installation-guide And as you generate more docs we'll create additional git repositories for them. This only makes sense if the docs src directories don't share a lot of common data. My understanding is the common data is all in the publican-ovirt package, so these all should be easily separable. The only files the different docs directories would have in common would be the build Makefiles and other small build files. Let me know if this makes sense and I'll split up the present ovirt-docs repo into two, one for each of the docs mentioned above. Perry -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From berrange at redhat.com Tue Sep 16 13:25:22 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 16 Sep 2008 14:25:22 +0100 Subject: [Ovirt-devel] ovirt-docs repository In-Reply-To: <48CFB2CC.10807@redhat.com> References: <48CFB2CC.10807@redhat.com> Message-ID: <20080916132522.GC17803@redhat.com> On Tue, Sep 16, 2008 at 09:21:16AM -0400, Perry N. Myers wrote: > Chris and Susan: > > Dan B. has suggested that it might make more sense for each document you > generate to have it's own separate git repository with the same structure. > So, instead of ovirt-docs, we'd currently have: > > ovirt-doc-using-the-ovirt-admin-ui > ovirt-doc-ovirt-installation-guide Or a little less verbose names... ovirt-doc-admin-ui-guide ovirt-doc-install-guide > And as you generate more docs we'll create additional git repositories for > them. This only makes sense if the docs src directories don't share a lot > of common data. My understanding is the common data is all in the > publican-ovirt package, so these all should be easily separable. > > The only files the different docs directories would have in common would > be the build Makefiles and other small build files. > > Let me know if this makes sense and I'll split up the present ovirt-docs > repo into two, one for each of the docs mentioned above. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From pmyers at redhat.com Tue Sep 16 13:27:51 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 16 Sep 2008 09:27:51 -0400 Subject: [Ovirt-devel] ovirt-docs repository In-Reply-To: <20080916132522.GC17803@redhat.com> References: <48CFB2CC.10807@redhat.com> <20080916132522.GC17803@redhat.com> Message-ID: <48CFB457.4070302@redhat.com> Daniel P. Berrange wrote: > On Tue, Sep 16, 2008 at 09:21:16AM -0400, Perry N. Myers wrote: >> Chris and Susan: >> >> Dan B. has suggested that it might make more sense for each document you >> generate to have it's own separate git repository with the same structure. >> So, instead of ovirt-docs, we'd currently have: >> >> ovirt-doc-using-the-ovirt-admin-ui >> ovirt-doc-ovirt-installation-guide > > Or a little less verbose names... > > ovirt-doc-admin-ui-guide > ovirt-doc-install-guide Heh. You have a problem with: ovirt-doc-how-to-install-ovirt-in-a-production-environment as a repo name? :) The short names are fine. Perry From bkearney at redhat.com Tue Sep 16 15:11:12 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 16 Sep 2008 11:11:12 -0400 Subject: [Ovirt-devel] Feedback on the ovirt build docs Message-ID: <48CFCC90.9050009@redhat.com> I just built ovirt based on the new repo split. Some feedback on the docs [1] - You list the repos, which caused me to go check them out. Then, the cool make file did it again. I would suggest a note to that effect to save the download time. - The make file variables should be higher in the doc. I started running the steps, stopped to make sure the repo was on the next branch, then saw that the variables would have done it for me. - My first build failed, then I set the OVIRT_BRANCH and FEDORA_URL env variables and it worked. Dont know if I got a bad mirror, or if those have to be set. Other then that.. very good and much improved over the last time I tried it. -- bk [1] http://www.ovirt.org/build-instructions.html From pmyers at redhat.com Tue Sep 16 15:27:47 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 16 Sep 2008 11:27:47 -0400 Subject: [Ovirt-devel] Feedback on the ovirt build docs In-Reply-To: <48CFCC90.9050009@redhat.com> References: <48CFCC90.9050009@redhat.com> Message-ID: <48CFD073.4060509@redhat.com> Bryan Kearney wrote: > I just built ovirt based on the new repo split. Some feedback on the > docs [1] > > - You list the repos, which caused me to go check them out. Then, the > cool make file did it again. I would suggest a note to that effect to > save the download time. Will make a note on the build instructions page to this effect. > - The make file variables should be higher in the doc. I started running > the steps, stopped to make sure the repo was on the next branch, then > saw that the variables would have done it for me. I'll move that around. > - My first build failed, then I set the OVIRT_BRANCH and FEDORA_URL env > variables and it worked. Dont know if I got a bad mirror, or if those > have to be set. They don't need to be set. But it is preferable to have OVIRT_BRANCH=next so you get the latest development code. Jim was toying with setting the default branch to next, but instead of that I could just make OVIRT_BRANCH default to next. Thoughts? Perry From bkearney at redhat.com Tue Sep 16 16:02:36 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 16 Sep 2008 12:02:36 -0400 Subject: [Ovirt-devel] Feedback on the ovirt build docs In-Reply-To: <48CFD073.4060509@redhat.com> References: <48CFCC90.9050009@redhat.com> <48CFD073.4060509@redhat.com> Message-ID: <48CFD89C.5080103@redhat.com> Perry N. Myers wrote: > Bryan Kearney wrote: >> I just built ovirt based on the new repo split. Some feedback on the >> docs [1] >> >> - You list the repos, which caused me to go check them out. Then, the >> cool make file did it again. I would suggest a note to that effect to >> save the download time. > > Will make a note on the build instructions page to this effect. > >> - The make file variables should be higher in the doc. I started >> running the steps, stopped to make sure the repo was on the next >> branch, then saw that the variables would have done it for me. > > I'll move that around. > >> - My first build failed, then I set the OVIRT_BRANCH and FEDORA_URL >> env variables and it worked. Dont know if I got a bad mirror, or if >> those have to be set. > > They don't need to be set. But it is preferable to have > OVIRT_BRANCH=next so you get the latest development code. As I said, I may have hit a bad mirror. > > Jim was toying with setting the default branch to next, but instead of > that I could just make OVIRT_BRANCH default to next. Thoughts? Yeah, I think if I am checking out the code I more then likely want the development branch. -- bk From pmyers at redhat.com Tue Sep 16 16:18:58 2008 From: pmyers at redhat.com (Perry Myers) Date: Tue, 16 Sep 2008 12:18:58 -0400 Subject: [Ovirt-devel] [PATCH release] Update so default branch is next and added convenience target for updating RPMS Message-ID: <1221581938-20796-1-git-send-email-pmyers@redhat.com> This change will come with some docs changes on ovirt.org website to reflect the slightly different process as well as a new build of ovirt-release and ovirt-build RPMS in the ovirt.org repos. Signed-off-by: Perry Myers --- ovirt.mk | 11 +++++++++-- 1 files changed, 9 insertions(+), 2 deletions(-) diff --git a/ovirt.mk b/ovirt.mk index a52239b..2141b46 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -3,8 +3,9 @@ OVIRT_GIT_SERVER ?= git://ovirt.org # For users with write access #OVIRT_GIT_SERVER = ssh://g-$USER at ovirt.org/git -# Set to 'next' to get the latest (unreleased) updates -OVIRT_BRANCH ?= master +# Set to 'master' to get the last released version, +# 'next' is development snapshot +OVIRT_BRANCH ?= next SUBDIRS ?= release server node node-image appliance docs @@ -69,5 +70,11 @@ rel-build: bumprelease build ver-build: bumpversion build +update-host: + @cd $(OVIRT_CACHE_DIR)/ovirt && \ + sudo yum localinstall -y --nogpgcheck \ + ovirt-appliance-*$(shell uname -i).rpm \ + ovirt-build-*noarch.rpm ovirt-release-*noarch.rpm + .PHONY: all build clean distclean publish $(SUBDIRS) update status \ bumpgit bumprelease bumpversion dev-build rel-build ver-build -- 1.5.5.1 From clalance at redhat.com Tue Sep 16 16:37:50 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 16 Sep 2008 18:37:50 +0200 Subject: [Ovirt-devel] Modeling LVM storage Message-ID: <48CFE0DE.6040908@redhat.com> sseago and I (and variously, other folks) had a somewhat longish conversation on IRC today about carving up storage with LVM. This is the second time we've beaten this horse, so hopefully we are somewhat OK now. The basic idea is that, given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to either: 1) Assign the entire LUN to a guest (this is the way that ovirt works right now) 2) Carve up the LUN using LVM, and then hand out individual logical volumes to guests. Libvirt handles this case sort of implicitly; that is, you first build a storage pool for iscsi, and find all of the volumes on it. Then you build an LVM storage pool out of the iSCSI LUN, and then you can create volumes on top of that. We can follow the same sort of model for ovirt. That is, we currently have a StoragePool defined in the model, which contains 0 or more StorageVolumes. So the idea is that we now add a new type of StoragePool, LVM, which consists of one or more iSCSI StorageVolumes, and on top of that, you have a new type of StorageVolume, LVM, which is what you eventually assign to guests. Note that the above model should eventually support binding multiple iSCSI LUNs into a single LVMPool, although we won't expose that functionality to the user for the moment. Once those model changes are in place, then we just need the backend taskomatic code to handle this (I've worked on that somewhat today, so I have a pretty good handle on what it will require), and the frontend WUI pieces. This latter can get somewhat complex, so for the time being, we will have pretty rudimentary support. That is, during VM creation time, we'll allow a user to either choose an existing whole LUN for the guest, choose an already existing (but not in use) LVM volume for the guest, or carve out a new LVM volume for the guest (subject to physical disk space and user quota, naturally). Later on we'll add more complicated handling of LVM, such as deletion, resizing, etc. etc. -- Chris Lalancette From hbrock at redhat.com Tue Sep 16 16:48:10 2008 From: hbrock at redhat.com (Hugh O. Brock) Date: Tue, 16 Sep 2008 12:48:10 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE0DE.6040908@redhat.com> References: <48CFE0DE.6040908@redhat.com> Message-ID: <20080916164810.GS10338@redhat.com> On Tue, Sep 16, 2008 at 06:37:50PM +0200, Chris Lalancette wrote: > sseago and I (and variously, other folks) had a somewhat longish conversation on > IRC today about carving up storage with LVM. This is the second time we've > beaten this horse, so hopefully we are somewhat OK now. The basic idea is that, > given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to either: > > 1) Assign the entire LUN to a guest (this is the way that ovirt works right now) > 2) Carve up the LUN using LVM, and then hand out individual logical volumes to > guests. > > Libvirt handles this case sort of implicitly; that is, you first build a storage > pool for iscsi, and find all of the volumes on it. Then you build an LVM > storage pool out of the iSCSI LUN, and then you can create volumes on top of that. > > We can follow the same sort of model for ovirt. That is, we currently have a > StoragePool defined in the model, which contains 0 or more StorageVolumes. So > the idea is that we now add a new type of StoragePool, LVM, which consists of > one or more iSCSI StorageVolumes, and on top of that, you have a new type of > StorageVolume, LVM, which is what you eventually assign to guests. > > Note that the above model should eventually support binding multiple iSCSI LUNs > into a single LVMPool, although we won't expose that functionality to the user > for the moment. > > Once those model changes are in place, then we just need the backend taskomatic > code to handle this (I've worked on that somewhat today, so I have a pretty good > handle on what it will require), and the frontend WUI pieces. This latter can > get somewhat complex, so for the time being, we will have pretty rudimentary > support. That is, during VM creation time, we'll allow a user to either choose > an existing whole LUN for the guest, choose an already existing (but not in use) > LVM volume for the guest, or carve out a new LVM volume for the guest (subject > to physical disk space and user quota, naturally). Later on we'll add more > complicated handling of LVM, such as deletion, resizing, etc. etc. This looks good to me. One of the outstanding questions I have is what (if anything) to do about deleting storage volumes when a user deletes a VM, but that question goes beyond LVM specifically so I'm willing to table it for now. Take care, --Hugh From sseago at redhat.com Tue Sep 16 16:49:05 2008 From: sseago at redhat.com (Scott Seago) Date: Tue, 16 Sep 2008 12:49:05 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE0DE.6040908@redhat.com> References: <48CFE0DE.6040908@redhat.com> Message-ID: <48CFE381.3070306@redhat.com> Chris Lalancette wrote: > We can follow the same sort of model for ovirt. That is, we currently have a > StoragePool defined in the model, which contains 0 or more StorageVolumes. So > the idea is that we now add a new type of StoragePool, LVM, which consists of > one or more iSCSI StorageVolumes, and on top of that, you have a new type of > StorageVolume, LVM, which is what you eventually assign to guests. > > Just to clarify above part, as I think the above gives a bit of a wrong idea. Right now, each StoragePool has 0 or more StorageVolumes. The volumes must be of the same 'type' as the pool. Thus an NfsStoragePool as 0 or more NfsStorageVolumes, an IscsiStoragePool has 0 or more IscsiStorageVolumes. Following the same pattern, an LvmStoragePool has 0 or more LvmStorageVolumes. For all 3 types, the StorageVolumes can potentially be assigned to guests. In additon, for LvmStoragePools, we have a new association defined between it and StorageVolumes. an LvmStoragePool has 1 or more "source storage volumes" (I'm open to different names here -- I just didn't want the name to be iSCSI-specific), which for the moment must be IscsiStorageVolumes. When determining which storage volumes are available for guests, we'll have to filter out storage volumes which are connected to LvmStoragePools. > Note that the above model should eventually support binding multiple iSCSI LUNs > into a single LVMPool, although we won't expose that functionality to the user > for the moment. > > Scott From sseago at redhat.com Tue Sep 16 16:53:59 2008 From: sseago at redhat.com (Scott Seago) Date: Tue, 16 Sep 2008 12:53:59 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <20080916164810.GS10338@redhat.com> References: <48CFE0DE.6040908@redhat.com> <20080916164810.GS10338@redhat.com> Message-ID: <48CFE4A7.3090307@redhat.com> Hugh O. Brock wrote: > > This looks good to me. One of the outstanding questions I have is what > (if anything) to do about deleting storage volumes when a user deletes > a VM, but that question goes beyond LVM specifically so I'm willing to > table it for now. > > Take care, > --Hugh > > Right -- this is definitely unrelated to lvm. Right now, of course, nobody can add or delete storage volumes through the UI. We'll soon be adding the ability for HW admins and end users to add new NFS and LVM storage volumes, although presumably end users could only add volumes 1) to attach to a specific VM "right now"; and 2) up to their available quota for the VM pool that the VM belongs to. HW admins (on the storage tab) could more freely add storage volumes. Right now our model makes no provisions for showing storage volume ownership other than what VM it's attached to and what storage pool it belongs to, so presumably if a user creates a storage volume to attach to a new VM, when that VM drops the storage volume (or the VM is deleted), that storage volume will be just like any other unattached storage volume in the same storage pool. So the only ones that can delete storage volumes will be HW admins -- who can delete any unattached NFS or LVM volumes in HW pools they have permissions on. Scott From sofsthun at virtualiron.com Tue Sep 16 17:03:37 2008 From: sofsthun at virtualiron.com (Steve Ofsthun) Date: Tue, 16 Sep 2008 13:03:37 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE0DE.6040908@redhat.com> References: <48CFE0DE.6040908@redhat.com> Message-ID: <48CFE6E9.4080509@virtualiron.com> Chris Lalancette wrote: > sseago and I (and variously, other folks) had a somewhat longish conversation on > IRC today about carving up storage with LVM. This is the second time we've > beaten this horse, so hopefully we are somewhat OK now. The basic idea is that, > given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to either: > > 1) Assign the entire LUN to a guest (this is the way that ovirt works right now) > 2) Carve up the LUN using LVM, and then hand out individual logical volumes to > guests. How do you plan to distinguish between LVM PVs/LVs created by ovirt/libvirt on iscsi LUNs from LVM PVs/LVs created by guest OSes on directly connected iscsi LUNs? Just blindly running pvscan will run into all sorts of trouble. Steve From pmyers at redhat.com Tue Sep 16 17:08:33 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 16 Sep 2008 13:08:33 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE6E9.4080509@virtualiron.com> References: <48CFE0DE.6040908@redhat.com> <48CFE6E9.4080509@virtualiron.com> Message-ID: <48CFE811.4090406@redhat.com> Steve Ofsthun wrote: > Chris Lalancette wrote: >> sseago and I (and variously, other folks) had a somewhat longish >> conversation on >> IRC today about carving up storage with LVM. This is the second time >> we've >> beaten this horse, so hopefully we are somewhat OK now. The basic >> idea is that, >> given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to >> either: >> >> 1) Assign the entire LUN to a guest (this is the way that ovirt works >> right now) >> 2) Carve up the LUN using LVM, and then hand out individual logical >> volumes to >> guests. > > How do you plan to distinguish between LVM PVs/LVs created by > ovirt/libvirt on iscsi LUNs from LVM PVs/LVs created by guest OSes on > directly connected iscsi LUNs? Just blindly running pvscan will run > into all sorts of trouble. All storage is virtualized. Guests don't access iSCSI LUNs directly, they access it through libvirt storage API. So this shouldn't be an issue. If we allow guests to directly access iSCSI storage (or other storage) directly it bypasses our ability to restrict via oVirt permissions who can access what storage and limit storage usage by quotas. Perry From pmyers at redhat.com Tue Sep 16 17:14:19 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 16 Sep 2008 13:14:19 -0400 Subject: [Ovirt-devel] Re: [PATCH release] Update so default branch is next and added convenience target for updating RPMS In-Reply-To: <1221581938-20796-1-git-send-email-pmyers@redhat.com> References: <1221581938-20796-1-git-send-email-pmyers@redhat.com> Message-ID: <48CFE96B.0@redhat.com> Perry Myers wrote: > This change will come with some docs changes on ovirt.org website to reflect > the slightly different process as well as a new build of ovirt-release and > ovirt-build RPMS in the ovirt.org repos. Pushed this change, uploaded 0.92-4 ovirt-release and ovirt-build RPMs to the ovirt.org repo and updated build-instructions.html to reflect the changes. Let me know if there are any issues. Thanks, Perry From konrad at virtualiron.com Tue Sep 16 17:13:30 2008 From: konrad at virtualiron.com (Konrad Rzeszutek) Date: Tue, 16 Sep 2008 13:13:30 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE0DE.6040908@redhat.com> References: <48CFE0DE.6040908@redhat.com> Message-ID: <20080916171330.GA30673@mars.virtualiron.com> On Tue, Sep 16, 2008 at 06:37:50PM +0200, Chris Lalancette wrote: > sseago and I (and variously, other folks) had a somewhat longish conversation on > IRC today about carving up storage with LVM. This is the second time we've Ah, sorry I missed it. > beaten this horse, so hopefully we are somewhat OK now. The basic idea is that, > given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to either: > > 1) Assign the entire LUN to a guest (this is the way that ovirt works right now) > 2) Carve up the LUN using LVM, and then hand out individual logical volumes to > guests. > > Libvirt handles this case sort of implicitly; that is, you first build a storage > pool for iscsi, and find all of the volumes on it. Then you build an LVM When you say volumes, do you mean PVs/VGs? or just logical disks? > storage pool out of the iSCSI LUN, and then you can create volumes on top of that. Creating the storage pool implies then that uninitialized LUNs would go through the 'pvcreate/vgcreate/vgchange' process? This would also imply that for FC you would need to create a storage pool for the FC.. HBA and from there get the SCSI LUNs? What about the asynchronous nature of the FC wherein the remote ports can show up and new disks would appear without the need to setup a storage pool? With multipath in this picture this is going to get a bit tricky. It would seem as it would sit on top of the storage pool for iSCSI. And that would mean the LVM operations MUST be disallowed on the iSCSI/FC layer but "moved" up to the multipath storage pool? From sofsthun at virtualiron.com Tue Sep 16 17:23:15 2008 From: sofsthun at virtualiron.com (Steve Ofsthun) Date: Tue, 16 Sep 2008 13:23:15 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE811.4090406@redhat.com> References: <48CFE0DE.6040908@redhat.com> <48CFE6E9.4080509@virtualiron.com> <48CFE811.4090406@redhat.com> Message-ID: <48CFEB83.40908@virtualiron.com> Perry N. Myers wrote: > Steve Ofsthun wrote: >> Chris Lalancette wrote: >>> sseago and I (and variously, other folks) had a somewhat longish >>> conversation on >>> IRC today about carving up storage with LVM. This is the second time >>> we've >>> beaten this horse, so hopefully we are somewhat OK now. The basic >>> idea is that, >>> given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to >>> either: >>> >>> 1) Assign the entire LUN to a guest (this is the way that ovirt >>> works right now) >>> 2) Carve up the LUN using LVM, and then hand out individual logical >>> volumes to >>> guests. >> >> How do you plan to distinguish between LVM PVs/LVs created by >> ovirt/libvirt on iscsi LUNs from LVM PVs/LVs created by guest OSes on >> directly connected iscsi LUNs? Just blindly running pvscan will run >> into all sorts of trouble. > > All storage is virtualized. Guests don't access iSCSI LUNs directly, > they access it through libvirt storage API. So this shouldn't be an > issue. If we allow guests to directly access iSCSI storage (or other > storage) directly it bypasses our ability to restrict via oVirt > permissions who can access what storage and limit storage usage by quotas. I'm not being clear I think. If libvirt/ovirt allows entire LUNs to be connected as virtual disks to a guest OS, the guest OS can create LVM PVs/LVs on the virtual disks. These guest PVs/LVs are written directly onto the underlying physical LUNs. Since these LUNs are also directly visible to the host virtualization software (libvirt, etc), any PVs/LVs created by the guest may be seen by LVM running in the host environment. If this host environment naively runs pvscan, it will see both host created PVs and guest created PVs (on entire LUNS). The host environment needs to use some method to positively operate on host create PVs/LVs only and ignore guest created PVs/LVs. This can only happen when entire LUNs are passed to guest OSes. Steve From berrange at redhat.com Tue Sep 16 17:31:29 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 16 Sep 2008 18:31:29 +0100 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFEB83.40908@virtualiron.com> References: <48CFE0DE.6040908@redhat.com> <48CFE6E9.4080509@virtualiron.com> <48CFE811.4090406@redhat.com> <48CFEB83.40908@virtualiron.com> Message-ID: <20080916173129.GI17803@redhat.com> On Tue, Sep 16, 2008 at 01:23:15PM -0400, Steve Ofsthun wrote: > Perry N. Myers wrote: > >Steve Ofsthun wrote: > >>Chris Lalancette wrote: > >>>sseago and I (and variously, other folks) had a somewhat longish > >>>conversation on > >>>IRC today about carving up storage with LVM. This is the second time > >>>we've > >>>beaten this horse, so hopefully we are somewhat OK now. The basic > >>>idea is that, > >>>given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to > >>>either: > >>> > >>>1) Assign the entire LUN to a guest (this is the way that ovirt > >>>works right now) > >>>2) Carve up the LUN using LVM, and then hand out individual logical > >>>volumes to > >>>guests. > >> > >>How do you plan to distinguish between LVM PVs/LVs created by > >>ovirt/libvirt on iscsi LUNs from LVM PVs/LVs created by guest OSes on > >>directly connected iscsi LUNs? Just blindly running pvscan will run > >>into all sorts of trouble. > > > >All storage is virtualized. Guests don't access iSCSI LUNs directly, > >they access it through libvirt storage API. So this shouldn't be an > >issue. If we allow guests to directly access iSCSI storage (or other > >storage) directly it bypasses our ability to restrict via oVirt > >permissions who can access what storage and limit storage usage by quotas. > > I'm not being clear I think. If libvirt/ovirt allows entire LUNs to be > connected as virtual disks to a guest OS, the guest OS can create LVM > PVs/LVs on the virtual disks. These guest PVs/LVs are written directly > onto the underlying physical LUNs. Since these LUNs are also directly > visible to the host virtualization software (libvirt, etc), any PVs/LVs > created by the guest may be seen by LVM running in the host environment. > If this host environment naively runs pvscan, it will see both host created > PVs and guest created PVs (on entire LUNS). The host environment needs to > use some method to positively operate on host create PVs/LVs only and > ignore guest created PVs/LVs. This can only happen when entire LUNs are > passed to guest OSes. This also isn't solely an iSCSI issue, its basically a general problem you'll hit when assigning whole disks to guests, whether their iSCSI, SCSI, IDE, USB, etc. At very least you could create a single whole disk partition and give that to the guest instead - at worst you'd be loosing a sector or so to the partition table metadata, and the host won't accidentally see the LVM created by the guest. If you really want to assign whole disks to guests though, you need to black/white-list devices in /etc/lvm/lvm.conf, which becomes quite alot of pain to manage. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From clalance at redhat.com Tue Sep 16 17:31:36 2008 From: clalance at redhat.com (Chris Lalancette) Date: Tue, 16 Sep 2008 19:31:36 +0200 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE6E9.4080509@virtualiron.com> References: <48CFE0DE.6040908@redhat.com> <48CFE6E9.4080509@virtualiron.com> Message-ID: <48CFED78.605@redhat.com> Steve Ofsthun wrote: > Chris Lalancette wrote: >> sseago and I (and variously, other folks) had a somewhat longish >> conversation on IRC today about carving up storage with LVM. This is the >> second time we've beaten this horse, so hopefully we are somewhat OK now. >> The basic idea is that, given an iSCSI LUN (and SCSI and FC LUNs in the >> future), we want to either: >> >> 1) Assign the entire LUN to a guest (this is the way that ovirt works >> right now) 2) Carve up the LUN using LVM, and then hand out individual >> logical volumes to guests. > > How do you plan to distinguish between LVM PVs/LVs created by ovirt/libvirt > on iscsi LUNs from LVM PVs/LVs created by guest OSes on directly connected > iscsi LUNs? Just blindly running pvscan will run into all sorts of trouble. This actually shouldn't be a problem, I don't think. When we assign a whole LUN to a guest, the guest will in all likelihood lay down a partition table. Since the partition table isn't a valid LVM partition, scanning that LUN won't have any LVM metadata on it. Now, if you have the case where a guest *doesn't* lie down a partition table, and directly uses the whole disk as LVM, I guess we could run into a problem. I don't know how common a case that is, but at least in Fedora/RHEL land, we never do that by default. -- Chris Lalancette From berrange at redhat.com Tue Sep 16 17:38:17 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 16 Sep 2008 18:38:17 +0100 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFED78.605@redhat.com> References: <48CFE0DE.6040908@redhat.com> <48CFE6E9.4080509@virtualiron.com> <48CFED78.605@redhat.com> Message-ID: <20080916173817.GJ17803@redhat.com> On Tue, Sep 16, 2008 at 07:31:36PM +0200, Chris Lalancette wrote: > Steve Ofsthun wrote: > > Chris Lalancette wrote: > >> sseago and I (and variously, other folks) had a somewhat longish > >> conversation on IRC today about carving up storage with LVM. This is the > >> second time we've beaten this horse, so hopefully we are somewhat OK now. > >> The basic idea is that, given an iSCSI LUN (and SCSI and FC LUNs in the > >> future), we want to either: > >> > >> 1) Assign the entire LUN to a guest (this is the way that ovirt works > >> right now) 2) Carve up the LUN using LVM, and then hand out individual > >> logical volumes to guests. > > > > How do you plan to distinguish between LVM PVs/LVs created by ovirt/libvirt > > on iscsi LUNs from LVM PVs/LVs created by guest OSes on directly connected > > iscsi LUNs? Just blindly running pvscan will run into all sorts of trouble. > > This actually shouldn't be a problem, I don't think. When we assign a whole LUN > to a guest, the guest will in all likelihood lay down a partition table. Since > the partition table isn't a valid LVM partition, scanning that LUN won't have > any LVM metadata on it. Now, if you have the case where a guest *doesn't* lie > down a partition table, and directly uses the whole disk as LVM, I guess we > could run into a problem. I don't know how common a case that is, but at least > in Fedora/RHEL land, we never do that by default. That's basically saying that correct operation of the host would be relying on a specific configuration by the guest admin. I wouldn't assume that guest admin's are nice in that way - we have to assume hostile/badly-configured guests will appear every now & then and make oVirt robust against them. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From imain at redhat.com Tue Sep 16 17:44:27 2008 From: imain at redhat.com (Ian Main) Date: Tue, 16 Sep 2008 10:44:27 -0700 Subject: [Ovirt-devel] root access required? In-Reply-To: <20080908160816.GX2315@redhat.com> References: <20080908160816.GX2315@redhat.com> Message-ID: <20080916104427.13d826fb@tp.mains.net> On Mon, 8 Sep 2008 17:08:16 +0100 "Daniel P. Berrange" wrote: > I'd recommend doing the builds inside a virtual machine to protect your > real host from accidental/delibrate damage The last place I worked the build booted a VM and did all it's work in that. However, I was very happy to have builds just run as root on the host because it's WAY easier to work on and deal with issues. I'm guessing that you're just suggesting that those with concerns make a VM to do the build in, which is good, but I'd rather not move towards having a VM needed for building. Ian From berrange at redhat.com Tue Sep 16 17:59:52 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 16 Sep 2008 18:59:52 +0100 Subject: [Ovirt-devel] root access required? In-Reply-To: <20080916104427.13d826fb@tp.mains.net> References: <20080908160816.GX2315@redhat.com> <20080916104427.13d826fb@tp.mains.net> Message-ID: <20080916175952.GK17803@redhat.com> On Tue, Sep 16, 2008 at 10:44:27AM -0700, Ian Main wrote: > On Mon, 8 Sep 2008 17:08:16 +0100 > "Daniel P. Berrange" wrote: > > > > I'd recommend doing the builds inside a virtual machine to protect your > > real host from accidental/delibrate damage > > The last place I worked the build booted a VM and did all it's work in > that. However, I was very happy to have builds just run as root on the > host because it's WAY easier to work on and deal with issues. I'm > guessing that you're just suggesting that those with concerns make a > VM to do the build in, which is good, but I'd rather not move towards > having a VM needed for building. I didn't mean to suggest that booting a VM should be a core part of our build tools. Just that if you are concerned about integrity of your host, then you could optionally create yourself a VM for doing builds in. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From sseago at redhat.com Tue Sep 16 18:48:24 2008 From: sseago at redhat.com (Scott Seago) Date: Tue, 16 Sep 2008 14:48:24 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFE0DE.6040908@redhat.com> References: <48CFE0DE.6040908@redhat.com> Message-ID: <48CFFF78.2060501@redhat.com> Some additional clarification based on a conversation I just had with pmyers. No changes from the basic model side of things, but we do want to explicitly exclude any LVM bits in LUNs assigned directly to VMs. So if a VM carves up one of its assigned LUNs into multiple LVs, oVirt doesn't care -- we only show the whole LUN assigned to a VM. The other thing is that we don't want to explicitly scan all unused LUNs for PVs/LVs -- rather we should do this on-demand. If we think of it in terms of the "new VM" ui. There are several types of storage available, but selecting storage will basically be a two-step process. Initially the user will be presented with a list of NFS storage pools (i.e. NFS mounts), and iSCSI storage volumes (i.e. LUNs). If an NFS pool is chosen, the user can pick an existing unallocated NFS Storage Volume (image file) or create a new NFS Volume/image file with a specified size (within the user's quota) to be 1) added to the NFS pool; and 2) attached to the VM. If an iSCSI volume (LUN) is chosen, there are a couple of options. First of all, the LUN will be scanned for PVs/LVs. These PVs/LVs will be inserted into the oVirt DB as LVM storage pools/volumes. The user will be able to choose an existing LV, create a new LV, or choose the whole LUN to attach to the VM. The latter "whole LUN" option only exists if there are not any LVs currently attached to other VMs. When a whole LUN is attached to a VM, the individual PVs/LVs are removed from the ovirt DB, since they can be overwritten at any time by the VM anyway. The other aspect of this is what is seen on the Hardware Pool/Storage tab. Right now we see NFS/iSCSI pools in the top-level list, and NFS/iSSCSI storage volumes when we drill down. For NFS, we need to allow creation/deletion of NFS Volumes (image files). For iSCSI, we need to allow the user to drill down from iSCSI Volumes (LUNs) to LVM Pools and Volumes (VGs and LVs). Two things here we need to work out: 1) drilling down will require refreshing the LVM Pool, as we only scan these on demand -- at any given time, oVirt will not have a complete picture of all LVM Pools for every LUN in the db 2) The UI is already fairly crowded with the Target -> LUN drilldown -- now we're adding another level. I'm guessing that at the moment, the best way to show this will be via another facebox popup, but we still need to work through the UI implications. Perry -- does this cover most of what we discussed? Scott Chris Lalancette wrote: > sseago and I (and variously, other folks) had a somewhat longish conversation on > IRC today about carving up storage with LVM. This is the second time we've > beaten this horse, so hopefully we are somewhat OK now. The basic idea is that, > given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to either: > > 1) Assign the entire LUN to a guest (this is the way that ovirt works right now) > 2) Carve up the LUN using LVM, and then hand out individual logical volumes to > guests. > > Libvirt handles this case sort of implicitly; that is, you first build a storage > pool for iscsi, and find all of the volumes on it. Then you build an LVM > storage pool out of the iSCSI LUN, and then you can create volumes on top of that. > > We can follow the same sort of model for ovirt. That is, we currently have a > StoragePool defined in the model, which contains 0 or more StorageVolumes. So > the idea is that we now add a new type of StoragePool, LVM, which consists of > one or more iSCSI StorageVolumes, and on top of that, you have a new type of > StorageVolume, LVM, which is what you eventually assign to guests. > > Note that the above model should eventually support binding multiple iSCSI LUNs > into a single LVMPool, although we won't expose that functionality to the user > for the moment. > > Once those model changes are in place, then we just need the backend taskomatic > code to handle this (I've worked on that somewhat today, so I have a pretty good > handle on what it will require), and the frontend WUI pieces. This latter can > get somewhat complex, so for the time being, we will have pretty rudimentary > support. That is, during VM creation time, we'll allow a user to either choose > an existing whole LUN for the guest, choose an already existing (but not in use) > LVM volume for the guest, or carve out a new LVM volume for the guest (subject > to physical disk space and user quota, naturally). Later on we'll add more > complicated handling of LVM, such as deletion, resizing, etc. etc. > > From apevec at redhat.com Tue Sep 16 20:10:38 2008 From: apevec at redhat.com (Alan Pevec) Date: Tue, 16 Sep 2008 22:10:38 +0200 Subject: [Ovirt-devel] [PATCH] Added tar-src to ovirt.mk to help automate building SRPM archive to satisfy GPL Message-ID: <1221595838-17513-1-git-send-email-apevec@redhat.com> From: Perry Myers Signed-off-by: Perry Myers --- misc-scripts/getsrpms.py | 43 +++++++++++++++++++++++++++++++++++++++++++ ovirt-release.spec | 2 +- ovirt.mk | 37 +++++++++++++++++++++++++++++++++++-- 3 files changed, 79 insertions(+), 3 deletions(-) create mode 100755 misc-scripts/getsrpms.py diff --git a/misc-scripts/getsrpms.py b/misc-scripts/getsrpms.py new file mode 100755 index 0000000..3e3b244 --- /dev/null +++ b/misc-scripts/getsrpms.py @@ -0,0 +1,43 @@ +#!/usr/bin/python -tt +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU Library General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + +""" +NAME + getsrpms.py - stripped-down pungi-1.2.18.1 which downloads SRPMs only + +SYNOPSIS + getsrpms.py kickstart.cfg yum_cache + + kickstart.cfg - kickstart with repo commands and %package section + yum_cache - YUM cache directory +""" + +import pypungi.config +import pypungi.gather +import pykickstart.parser +import pykickstart.version +import sys + +config = pypungi.config.Config() + +# Set up the kickstart parser and pass in the kickstart file we were handed +ksparser = pykickstart.parser.KickstartParser(pykickstart.version.makeVersion()) +ksparser.readKickstart(sys.argv[1]) + +config.set('default', 'version', '') +config.set('default', 'cachedir', sys.argv[2]) +mygather = pypungi.gather.Gather(config, ksparser) +mygather.getPackageObjects() +mygather.getSRPMList() +mygather.downloadSRPMs() diff --git a/ovirt-release.spec b/ovirt-release.spec index 0be355d..851f5b1 100644 --- a/ovirt-release.spec +++ b/ovirt-release.spec @@ -22,7 +22,7 @@ which are not yet in Fedora. Summary: oVirt Build Scripts for developers Group: Applications/System Requires: %{name} = %{version} -Requires: gcc autogen libtool rpm-build createrepo git +Requires: gcc autogen libtool rpm-build createrepo git pungi %description -n ovirt-build Developer makefile and scripts to help automate the building of oVirt from source repositories. diff --git a/ovirt.mk b/ovirt.mk index a52239b..0928e57 100644 --- a/ovirt.mk +++ b/ovirt.mk @@ -5,12 +5,16 @@ OVIRT_GIT_SERVER ?= git://ovirt.org # Set to 'next' to get the latest (unreleased) updates OVIRT_BRANCH ?= master - +OVIRT_URL ?= http://ovirt.org/repos/ovirt +FEDORA_MIRROR ?= http://mirrors.fedoraproject.org/mirrorlist SUBDIRS ?= release server node node-image appliance docs SUBDIR_SEP = ============================================================ export OVIRT_CACHE_DIR ?= $(HOME)/ovirt-cache +SRC_KS = $(OVIRT_CACHE_DIR)/src.ks +F_REL = $(shell rpm -q --qf '%{VERSION}' fedora-release) +BUILD_DIR := $(shell pwd) define subdir_gen_and_make echo $(SUBDIR_SEP) $$dir; \ @@ -69,5 +73,34 @@ rel-build: bumprelease build ver-build: bumpversion build +tar-src: + @mkdir -p $(OVIRT_CACHE_DIR) + @( if [ -n "$(FEDORA_URL)" ]; then \ + echo "repo --name=f$(F_REL) --baseurl=$(FEDORA_URL)/releases/$(F_REL)/Everything/\$$basearch/os" ; \ + echo "repo --name=f$(F_REL)-updates --baseurl=$(FEDORA_URL)/updates/$(F_REL)/\$$basearch" ; \ + echo "repo --name=f$(F_REL)-updates-newkey --baseurl=$(FEDORA_URL)/updates/$(F_REL)/\$$basearch.newkey" ; \ + echo "repo --name=f$(F_REL)-src --baseurl=$(FEDORA_URL)/releases/$(F_REL)/Everything/source/SRPMS" ; \ + echo "repo --name=f$(F_REL)-updates-src --baseurl=$(FEDORA_URL)/updates/$(F_REL)/SRPMS" ; \ + echo "repo --name=f$(F_REL)-updates-src-newkey --baseurl=$(FEDORA_URL)/updates/$(F_REL)/SRPMS.newkey" ; \ + else \ + echo "repo --name=f$(F_REL) --mirrorlist=$(FEDORA_MIRROR)?repo=fedora-$(F_REL)&arch=\$$basearch" ; \ + echo "repo --name=f$(F_REL)-updates --mirrorlist=$(FEDORA_MIRROR)?repo=updates-released-f$(F_REL)&arch=\$$basearch" ; \ + echo "repo --name=f$(F_REL)-updates-newkey --mirrorlist=$(FEDORA_MIRROR)?repo=updates-released-f$(F_REL).newkey&arch=\$$basearch" ; \ + echo "repo --name=f$(F_REL)-src --mirrorlist=$(FEDORA_MIRROR)?repo=fedora-source-$(F_REL)&arch=src" ; \ + echo "repo --name=f$(F_REL)-updates-src --mirrorlist=$(FEDORA_MIRROR)?repo=updates-released-source-f$(F_REL)&arch=src" ; \ + echo "repo --name=f$(F_REL)-updates-src-newkey --mirrorlist=$(FEDORA_MIRROR)?repo=updates-released-source-f$(F_REL).newkey&arch=src" ; \ + fi ; \ + echo "%packages --nobase" ; \ + for dir in $(SUBDIRS); do \ + if test -f $$dir/common-pkgs.ks ; then \ + grep -v '^-' $$dir/common-pkgs.ks ; \ + fi ; \ + done ; \ + echo "%end" ) > $(SRC_KS) + cd $(OVIRT_CACHE_DIR) && \ + $(BUILD_DIR)/release/misc-scripts/getsrpms.py $(SRC_KS) $(OVIRT_CACHE_DIR)/yum + cd $(OVIRT_CACHE_DIR)/source && \ + tar cf ovirt-source.tar SRPMS + .PHONY: all build clean distclean publish $(SUBDIRS) update status \ - bumpgit bumprelease bumpversion dev-build rel-build ver-build + bumpgit bumprelease bumpversion dev-build rel-build ver-build tar-src -- 1.5.5.1 From sofsthun at virtualiron.com Tue Sep 16 21:05:12 2008 From: sofsthun at virtualiron.com (Steve Ofsthun) Date: Tue, 16 Sep 2008 17:05:12 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48CFFF78.2060501@redhat.com> References: <48CFE0DE.6040908@redhat.com> <48CFFF78.2060501@redhat.com> Message-ID: <48D01F88.7010903@virtualiron.com> Scott Seago wrote: > Some additional clarification based on a conversation I just had with > pmyers. > > No changes from the basic model side of things, but we do want to > explicitly exclude any LVM bits in LUNs assigned directly to VMs. So if > a VM carves up one of its assigned LUNs into multiple LVs, oVirt doesn't > care -- we only show the whole LUN assigned to a VM. The other thing is > that we don't want to explicitly scan all unused LUNs for PVs/LVs -- > rather we should do this on-demand. How would this "on-demand" scanning be done? The only way to selectively scan volumes (with pvscan) is to update /etc/lvm/lvm.conf to restrict the desired list of volumes to scan. This can be a pain to manage, particularly if the local node requires LVM access to boot. If a newly scanned LUN contains volume information that conflicts with an existing volume group (say VolGroup00), the pvscan will error out due to conflicting volume group information (not so bad). More importantly though, if the system is rebooted at this point, the reboot will fail to activate the real VolGroup00 possibly compromising the entire boot process (not so good). Even if a boot volume isn't compromised, some active volume group is no longer accessible. A safer alternative would be to modify pvscan to allow selective volume scanning without changing /etc/lvm/lvm.conf. Is this a possible alternative? Would a modified pvscan be acceptable in upstream lvm? Another alternative, as Daniel mentioned, is to not allow a guest direct access to the entire LUN. Steve > If we think of it in terms of the "new VM" ui. There are several types > of storage available, but selecting storage will basically be a two-step > process. Initially the user will be presented with a list of NFS storage > pools (i.e. NFS mounts), and iSCSI storage volumes (i.e. LUNs). If an > NFS pool is chosen, the user can pick an existing unallocated NFS > Storage Volume (image file) or create a new NFS Volume/image file with a > specified size (within the user's quota) to be 1) added to the NFS pool; > and 2) attached to the VM. > > If an iSCSI volume (LUN) is chosen, there are a couple of options. First > of all, the LUN will be scanned for PVs/LVs. These PVs/LVs will be > inserted into the oVirt DB as LVM storage pools/volumes. The user will > be able to choose an existing LV, create a new LV, or choose the whole > LUN to attach to the VM. The latter "whole LUN" option only exists if > there are not any LVs currently attached to other VMs. When a whole LUN > is attached to a VM, the individual PVs/LVs are removed from the ovirt > DB, since they can be overwritten at any time by the VM anyway. > > The other aspect of this is what is seen on the Hardware Pool/Storage > tab. Right now we see NFS/iSCSI pools in the top-level list, and > NFS/iSSCSI storage volumes when we drill down. For NFS, we need to allow > creation/deletion of NFS Volumes (image files). For iSCSI, we need to > allow the user to drill down from iSCSI Volumes (LUNs) to LVM Pools and > Volumes (VGs and LVs). Two things here we need to work out: > 1) drilling down will require refreshing the LVM Pool, as we only scan > these on demand -- at any given time, oVirt will not have a complete > picture of all LVM Pools for every LUN in the db > 2) The UI is already fairly crowded with the Target -> LUN drilldown -- > now we're adding another level. I'm guessing that at the moment, the > best way to show this will be via another facebox popup, but we still > need to work through the UI implications. > > Perry -- does this cover most of what we discussed? > > Scott > > > Chris Lalancette wrote: >> sseago and I (and variously, other folks) had a somewhat longish >> conversation on >> IRC today about carving up storage with LVM. This is the second time >> we've >> beaten this horse, so hopefully we are somewhat OK now. The basic >> idea is that, >> given an iSCSI LUN (and SCSI and FC LUNs in the future), we want to >> either: >> >> 1) Assign the entire LUN to a guest (this is the way that ovirt works >> right now) >> 2) Carve up the LUN using LVM, and then hand out individual logical >> volumes to >> guests. >> >> Libvirt handles this case sort of implicitly; that is, you first build >> a storage >> pool for iscsi, and find all of the volumes on it. Then you build an LVM >> storage pool out of the iSCSI LUN, and then you can create volumes on >> top of that. >> >> We can follow the same sort of model for ovirt. That is, we currently >> have a >> StoragePool defined in the model, which contains 0 or more >> StorageVolumes. So >> the idea is that we now add a new type of StoragePool, LVM, which >> consists of >> one or more iSCSI StorageVolumes, and on top of that, you have a new >> type of >> StorageVolume, LVM, which is what you eventually assign to guests. >> >> Note that the above model should eventually support binding multiple >> iSCSI LUNs >> into a single LVMPool, although we won't expose that functionality to >> the user >> for the moment. >> >> Once those model changes are in place, then we just need the backend >> taskomatic >> code to handle this (I've worked on that somewhat today, so I have a >> pretty good >> handle on what it will require), and the frontend WUI pieces. This >> latter can >> get somewhat complex, so for the time being, we will have pretty >> rudimentary >> support. That is, during VM creation time, we'll allow a user to >> either choose >> an existing whole LUN for the guest, choose an already existing (but >> not in use) >> LVM volume for the guest, or carve out a new LVM volume for the guest >> (subject >> to physical disk space and user quota, naturally). Later on we'll add >> more >> complicated handling of LVM, such as deletion, resizing, etc. etc. >> >> > > _______________________________________________ > Ovirt-devel mailing list > Ovirt-devel at redhat.com > https://www.redhat.com/mailman/listinfo/ovirt-devel From pmyers at redhat.com Tue Sep 16 22:33:10 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Tue, 16 Sep 2008 18:33:10 -0400 Subject: [Ovirt-devel] Modeling LVM storage In-Reply-To: <48D01F88.7010903@virtualiron.com> References: <48CFE0DE.6040908@redhat.com> <48CFFF78.2060501@redhat.com> <48D01F88.7010903@virtualiron.com> Message-ID: <48D03426.4020505@redhat.com> Steve Ofsthun wrote: > Scott Seago wrote: >> Some additional clarification based on a conversation I just had with >> pmyers. >> >> No changes from the basic model side of things, but we do want to >> explicitly exclude any LVM bits in LUNs assigned directly to VMs. So >> if a VM carves up one of its assigned LUNs into multiple LVs, oVirt >> doesn't care -- we only show the whole LUN assigned to a VM. The other >> thing is that we don't want to explicitly scan all unused LUNs for >> PVs/LVs -- rather we should do this on-demand. > > How would this "on-demand" scanning be done? > > The only way to selectively scan volumes (with pvscan) is to update > /etc/lvm/lvm.conf to restrict the desired list of volumes to scan. This > can be a pain to manage, particularly if the local node requires LVM > access to boot. If a newly scanned LUN contains volume information that > conflicts with an existing volume group (say VolGroup00), the pvscan > will error out due to conflicting volume group information (not so > bad). More importantly though, if the system is rebooted at this point, > the reboot will fail to activate the real VolGroup00 possibly > compromising the entire boot process (not so good). Even if a boot > volume isn't compromised, some active volume group is no longer accessible. Good points. One thing we could do is hijack a Node to do the scanning for us, since they will never require LVM to boot and shouldn't have anything in /etc/lvm/lvm.conf. But regardless the process is somewhat convoluted, I agree. > A safer alternative would be to modify pvscan to allow selective volume > scanning without changing /etc/lvm/lvm.conf. Is this a possible > alternative? Would a modified pvscan be acceptable in upstream lvm? I agree this would be a much better alternative, but have no idea how difficult it would be to get this upstream. > Another alternative, as Daniel mentioned, is to not allow a guest direct > access to the entire LUN. The only reason I had for allowing direct LUN access is for hypervisors that don't understand LVM but can use iSCSI. Not sure if this niche case warrants the pain associated with direct LUN access. For example if we eventually get libvirt support for VMware ESX Nodes we wouldn't be able to give them iSCSI storage since they wouldn't understand what to do with an LVM volume on an iSCSI LUN. We'd have to stick with providing them NFS file based images. (I believe the same problems will occur with Fibre Channel attached storage as well if you want to do LVM on top of FC) If we don't care about that case, then I would be in favor of always creating a VG on every LUN in oVirt. If a vm wants the 'entire LUN' we create a single LV on the VG and give it to the VM. Perry From berrange at redhat.com Wed Sep 17 11:49:41 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 17 Sep 2008 12:49:41 +0100 Subject: [Ovirt-devel] PATCH: Remove qemu from node image Message-ID: <20080917114941.GB27699@redhat.com> The YUM dep solver for file deps is utterly stupid, and pulls in the older 'qemu' RPM when resolving /usr/bin/qemu-img, instead of the newer qemu-img sub-RPM. Even if you explicitly have -qemu in the kickstart filelist. While we could just remove qemu in the %post script, this relies on yum having installed qemu-img too - this happens to be the case by luck, but we shouldn't rely on it. The best workaround is to explicitly request 'qemu-img' in the kickstart so it never has to go off and dep-solve for /usr/bin/qemu-img Daniel diff --git a/common-pkgs.ks b/common-pkgs.ks index 70707fc..2c3d56a 100644 --- a/common-pkgs.ks +++ b/common-pkgs.ks @@ -28,6 +28,10 @@ bind-utils syslinux cronie hal +# Stupid yum dep solver pulls in older 'qemu' to resolve +# /usr/bin/qemu-img dep. This forces it to pick the new +# qemu-img RPM. +qemu-img ovirt-node -policycoreutils -audit-libs-python -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Sep 17 13:07:38 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 17 Sep 2008 14:07:38 +0100 Subject: [Ovirt-devel] PATCH: Remove qemu from node image In-Reply-To: <20080917114941.GB27699@redhat.com> References: <20080917114941.GB27699@redhat.com> Message-ID: <20080917130738.GE27699@redhat.com> On Wed, Sep 17, 2008 at 12:49:41PM +0100, Daniel P. Berrange wrote: > The YUM dep solver for file deps is utterly stupid, and pulls in the older > 'qemu' RPM when resolving /usr/bin/qemu-img, instead of the newer qemu-img > sub-RPM. Even if you explicitly have -qemu in the kickstart filelist. > > While we could just remove qemu in the %post script, this relies on yum > having installed qemu-img too - this happens to be the case by luck, but > we shouldn't rely on it. > > The best workaround is to explicitly request 'qemu-img' in the kickstart > so it never has to go off and dep-solve for /usr/bin/qemu-img Here's an updated one, which also removes the redundant calls to erase qemu - which never worked anyway. diff --git a/common-pkgs.ks b/common-pkgs.ks index 70707fc..b914eea 100644 --- a/common-pkgs.ks +++ b/common-pkgs.ks @@ -28,6 +28,10 @@ bind-utils syslinux cronie hal +# Stupid yum dep solver pulls in older 'qemu' to resolve +# /usr/bin/qemu-img dep. This forces it to pick the new +# qemu-img RPM. +qemu-img ovirt-node -policycoreutils -audit-libs-python @@ -62,6 +66,5 @@ ovirt-node -cpio -hwdata -file --qemu -libvirt-python /usr/sbin/lokkit diff --git a/common-post.ks b/common-post.ks index e234249..c0f4005 100644 --- a/common-post.ks +++ b/common-post.ks @@ -51,7 +51,7 @@ echo "Removing excess RPMs" # it afterwards, which we do here rpm -e system-config-firewall-tui system-config-network-tui rhpl \ rpm-python dbus-python kudzu newt-python newt -rpm -e qemu kpartx mkinitrd isomd5sum dmraid python python-libs +rpm -e kpartx mkinitrd isomd5sum dmraid python python-libs RPM="rpm -v -e --nodeps" Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Sep 17 13:08:20 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 17 Sep 2008 14:08:20 +0100 Subject: [Ovirt-devel] PATCH: Fix node-image autobuild.sh with local repos Message-ID: <20080917130820.GF27699@redhat.com> The ovirt_local_repo macro needs to be a proper URI, not a file path... diff --git a/autobuild.sh b/autobuild.sh index ba5c3cb..08500c3 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -42,6 +42,6 @@ if [ -f /usr/bin/rpmbuild ]; then cp rpm-build/ovirt-node-image-$version.tar.gz $AUTOBUILD_PACKAGE_ROOT/rpm/SOURCES/ rpmbuild --nodeps --define "extra_release $EXTRA_RELEASE" \ - --define "ovirt_local_repo $AUTOBUILD_PACKAGE_ROOT/rpm/RPMS" \ + --define "ovirt_local_repo file://$AUTOBUILD_PACKAGE_ROOT/rpm/RPMS" \ -ba --clean ovirt-node-image.spec fi Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From apevec at redhat.com Wed Sep 17 13:29:15 2008 From: apevec at redhat.com (Alan Pevec) Date: Wed, 17 Sep 2008 15:29:15 +0200 Subject: [Ovirt-devel] [PATCH ovirt-node-image] do not use empty variables Message-ID: <1221658155-24824-1-git-send-email-apevec@redhat.com> to avoid error: Macro %fedora_url has empty body Signed-off-by: Alan Pevec --- Makefile | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 60fa9b4..969fa04 100644 --- a/Makefile +++ b/Makefile @@ -4,10 +4,13 @@ all: rpms include release.mk # FEDORA_URL env var can be set to the root of a fedora mirror +ifneq ($(FEDORA_URL),) +RPM_FLAGS += --define "fedora_url $(FEDORA_URL)" +endif # OVIRT_URL env var can be set to the root of an ovirt.org mirror -RPM_FLAGS += \ - --define "fedora_url $(FEDORA_URL)" \ - --define "ovirt_url $(OVIRT_URL)" +ifneq ($(OVIRT_URL),) +RPM_FLAGS += --define "ovirt_url $(OVIRT_URL)" +endif clean: rm -rf $(pkg_name)-* -- 1.5.5.1 From jim at meyering.net Wed Sep 17 14:25:09 2008 From: jim at meyering.net (Jim Meyering) Date: Wed, 17 Sep 2008 16:25:09 +0200 Subject: [Ovirt-devel] [PATCH node-image] enable SELinux in the node Message-ID: <874p4eg88q.fsf@rho.meyering.net> Here are 5 change sets. The first enables SELinux in the node. However, the resulting .iso image size went up to 72M. The following 4 patches pare that back down to 51M, which is 1M below the original size of 52M. >From db6be7aeae14812a0642b85c1f7ee10dedac2810 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 16 Sep 2008 15:52:20 +0200 Subject: [PATCH node-image] Enable SELinux in the node. * common-install.ks: Use selinux --enforcing * common-pkgs.ks: Don't exclude the following, required for SELinux: policycoreutils libsemanage selinux-policy-targeted selinux-policy * ovirt-node-image.ks (%post): touch /.autorelabel so the node automatically relabels all files. Otherwise at least the following would be unlabeled_t: /etc/hosts /etc/shadow /etc/gshadow /etc/sysconfig/iptables --- common-install.ks | 2 +- common-pkgs.ks | 4 ---- ovirt-node-image.ks | 2 ++ 3 files changed, 3 insertions(+), 5 deletions(-) diff --git a/common-install.ks b/common-install.ks index b7671e9..f535323 100644 --- a/common-install.ks +++ b/common-install.ks @@ -2,7 +2,7 @@ lang C keyboard us timezone --utc UTC auth --useshadow --enablemd5 -selinux --disabled +selinux --enforcing firewall --disabled part / --size 550 --fstype ext2 services --enabled=ntpd,ntpdate,collectd,iptables,network diff --git a/common-pkgs.ks b/common-pkgs.ks index 70707fc..29d3cf7 100644 --- a/common-pkgs.ks +++ b/common-pkgs.ks @@ -29,10 +29,8 @@ syslinux cronie hal ovirt-node --policycoreutils -audit-libs-python -hdparm --libsemanage -ustr -authconfig -rhpl @@ -41,8 +39,6 @@ ovirt-node -prelink -newt-python -newt --selinux-policy-targeted --selinux-policy -kudzu -libselinux-python -rhpl diff --git a/ovirt-node-image.ks b/ovirt-node-image.ks index 9ec0b50..f5695d8 100644 --- a/ovirt-node-image.ks +++ b/ovirt-node-image.ks @@ -10,6 +10,8 @@ %post %include common-post.ks +touch /.autorelabel + %end %post --nochroot -- 1.6.0.1.308.gede4c >From e3d27bd525ecc5f833db60ae4c7088ec3be9ee81 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 16 Sep 2008 21:32:03 +0200 Subject: [PATCH node-image] common-post.ks: prune blacklisted packages with rpm -e --nodeps Otherwise, they were not being removed. --- common-post.ks | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/common-post.ks b/common-post.ks index e234249..d14c790 100644 --- a/common-post.ks +++ b/common-post.ks @@ -49,12 +49,14 @@ echo "Removing excess RPMs" # and livecd-tools needs lokkit to disable SELinux. # However, this is just an install-time dependency; we can remove # it afterwards, which we do here -rpm -e system-config-firewall-tui system-config-network-tui rhpl \ +$RPM -e system-config-firewall-tui system-config-network-tui rhpl \ rpm-python dbus-python kudzu newt-python newt -rpm -e qemu kpartx mkinitrd isomd5sum dmraid python python-libs RPM="rpm -v -e --nodeps" +$RPM -e qemu kpartx mkinitrd isomd5sum dmraid python python-libs +$RPM -e checkpolicy + # Remove additional RPMs forcefully $RPM gamin pm-utils kbd libuser passwd usermode \ vbetool ConsoleKit hdparm \ -- 1.6.0.1.308.gede4c >From 047ae89c284087ae3d3a373bf8cbab9540217b1a Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 17 Sep 2008 13:56:15 +0200 Subject: [PATCH node-image] allow for {,lib64} constructs in blacklist variables --- common-post.ks | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/common-post.ks b/common-post.ks index d14c790..a2a8630 100644 --- a/common-post.ks +++ b/common-post.ks @@ -142,8 +142,8 @@ docs_blacklist="/usr/share/omf /usr/share/gnome /usr/share/doc \ /usr/share/locale /usr/share/libthai /usr/share/man /usr/share/terminfo \ /usr/share/X11 /usr/share/i18n" -$RM $blacklist $blacklist_lib $blacklist_pango $blacklist_hal $blacklist_ssh \ - $docs_blacklist +eval $RM $blacklist $blacklist_lib $blacklist_pango $blacklist_hal \ + $blacklist_ssh $docs_blacklist echo "Cleanup empty directory structures in /usr/share" find /usr/share -type d -exec rmdir {} \; > /dev/null 2>&1 -- 1.6.0.1.308.gede4c >From 817655c2b4f0c200a929caddad69b1f8f52295c6 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 17 Sep 2008 14:12:25 +0200 Subject: [PATCH node-image] remove big /usr/sbin binaries remove system-config-* etc with --nodeps, too --- common-post.ks | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/common-post.ks b/common-post.ks index a2a8630..ea5b1b7 100644 --- a/common-post.ks +++ b/common-post.ks @@ -45,6 +45,8 @@ EOF echo "Removing excess RPMs" +RPM="rpm -v -e --nodeps" + # kernel pulls in mkinitrd which pulls in isomd5sum which pulls in python, # and livecd-tools needs lokkit to disable SELinux. # However, this is just an install-time dependency; we can remove @@ -122,7 +124,7 @@ blacklist="/boot /etc/alsa /etc/pki /usr/share/hwdata/MonitorsDB \ /usr/share/tabset /usr/share/libvirt /usr/share/augeas/lenses/tests \ /usr/share/tc /usr/share/emacs /usr/share/info /usr/kerberos \ /usr/src /usr/etc /usr/games /usr/include /usr/local \ - /usr/sbin/dell*" + /usr/sbin/{dell*,sasldblistusers2,build-locale-archive,glibc_post_upgrade.*}" blacklist_lib="/usr/lib{,64}/python2.5 /usr/lib{,64}/gconv \ /usr/{,lib64}/tc /usr/lib{,64}/tls /usr/lib{,64}/sse2 \ /usr/lib{,64}/pkgconfig /usr/lib{,64}/nss /usr/lib{,64}/X11 \ -- 1.6.0.1.308.gede4c >From a570566201f06108c9eabd6a588c329a8a59e55e Mon Sep 17 00:00:00 2001 From: Daniel P. Berrange Date: Wed, 17 Sep 2008 15:15:10 +0200 Subject: [PATCH node-image] exclude qemu cleanly, by explicitly including qemu-img Work around YUM dep solver problem: explicitly include qemu-img http://thread.gmane.org/gmane.comp.emulators.libvirt.ovirt/1984/focus=1985 [I had already removed qemu with the "rpm -e --nodeps" sledgehammer, but Dan P. Berrange found this cleaner way to do it. -jmm] --- common-pkgs.ks | 5 ++++- common-post.ks | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/common-pkgs.ks b/common-pkgs.ks index 29d3cf7..0149956 100644 --- a/common-pkgs.ks +++ b/common-pkgs.ks @@ -28,6 +28,10 @@ bind-utils syslinux cronie hal +# Stupid yum dep solver pulls in older 'qemu' to resolve +# /usr/bin/qemu-img dep. This forces it to pick the new +# qemu-img RPM. +qemu-img ovirt-node -audit-libs-python -hdparm @@ -58,6 +62,5 @@ ovirt-node -cpio -hwdata -file --qemu -libvirt-python /usr/sbin/lokkit diff --git a/common-post.ks b/common-post.ks index ea5b1b7..dfc6418 100644 --- a/common-post.ks +++ b/common-post.ks @@ -56,7 +56,7 @@ $RPM -e system-config-firewall-tui system-config-network-tui rhpl \ RPM="rpm -v -e --nodeps" -$RPM -e qemu kpartx mkinitrd isomd5sum dmraid python python-libs +$RPM -e kpartx mkinitrd isomd5sum dmraid python python-libs $RPM -e checkpolicy # Remove additional RPMs forcefully -- 1.6.0.1.308.gede4c From jim at meyering.net Wed Sep 17 14:50:17 2008 From: jim at meyering.net (Jim Meyering) Date: Wed, 17 Sep 2008 16:50:17 +0200 Subject: [Ovirt-devel] PATCH: Remove qemu from node image In-Reply-To: <20080917130738.GE27699@redhat.com> (Daniel P. Berrange's message of "Wed, 17 Sep 2008 14:07:38 +0100") References: <20080917114941.GB27699@redhat.com> <20080917130738.GE27699@redhat.com> Message-ID: <87y71qesie.fsf@rho.meyering.net> "Daniel P. Berrange" wrote: > On Wed, Sep 17, 2008 at 12:49:41PM +0100, Daniel P. Berrange wrote: >> The YUM dep solver for file deps is utterly stupid, and pulls in the older >> 'qemu' RPM when resolving /usr/bin/qemu-img, instead of the newer qemu-img >> sub-RPM. Even if you explicitly have -qemu in the kickstart filelist. >> >> While we could just remove qemu in the %post script, this relies on yum >> having installed qemu-img too - this happens to be the case by luck, but >> we shouldn't rely on it. >> >> The best workaround is to explicitly request 'qemu-img' in the kickstart >> so it never has to go off and dep-solve for /usr/bin/qemu-img > > Here's an updated one, which also removes the redundant calls to > erase qemu - which never worked anyway. Thanks, Dan. I'd already removed qemu via rpm -e --nodeps, but backed out that bit and have been using your patch instead -- to test my SELinux-adding changes. So I'll push this along with the SELinux-adding ones, pending review. From jim at meyering.net Wed Sep 17 14:53:27 2008 From: jim at meyering.net (Jim Meyering) Date: Wed, 17 Sep 2008 16:53:27 +0200 Subject: [Ovirt-devel] [PATCH node-image] enable SELinux in the node In-Reply-To: <874p4eg88q.fsf@rho.meyering.net> (Jim Meyering's message of "Wed, 17 Sep 2008 16:25:09 +0200") References: <874p4eg88q.fsf@rho.meyering.net> Message-ID: <87skryesd4.fsf@rho.meyering.net> Jim Meyering wrote: > Here are 5 change sets. > > The first enables SELinux in the node. > However, the resulting .iso image size went up to 72M. > The following 4 patches pare that back down to 51M, which is 1M below > the original size of 52M. > ... >>From e3d27bd525ecc5f833db60ae4c7088ec3be9ee81 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Tue, 16 Sep 2008 21:32:03 +0200 > Subject: [PATCH node-image] common-post.ks: prune blacklisted packages with rpm -e --nodeps > > Otherwise, they were not being removed. > --- > common-post.ks | 6 ++++-- > 1 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/common-post.ks b/common-post.ks > index e234249..d14c790 100644 > --- a/common-post.ks > +++ b/common-post.ks > @@ -49,12 +49,14 @@ echo "Removing excess RPMs" > # and livecd-tools needs lokkit to disable SELinux. > # However, this is just an install-time dependency; we can remove > # it afterwards, which we do here > -rpm -e system-config-firewall-tui system-config-network-tui rhpl \ > +$RPM -e system-config-firewall-tui system-config-network-tui rhpl \ > rpm-python dbus-python kudzu newt-python newt > -rpm -e qemu kpartx mkinitrd isomd5sum dmraid python python-libs > > RPM="rpm -v -e --nodeps" > > +$RPM -e qemu kpartx mkinitrd isomd5sum dmraid python python-libs Alan Pevec noticed the above weirdness. In fact, it's not a use-before-definition of $RPM, but rather an unnecessary (duplicate) definition. This incremental change (about to be folded in) removes it. Thanks, Alan! From pmyers at redhat.com Wed Sep 17 17:14:21 2008 From: pmyers at redhat.com (Perry N. Myers) Date: Wed, 17 Sep 2008 13:14:21 -0400 Subject: [Ovirt-devel] [PATCH ovirt-node-image] do not use empty variables In-Reply-To: <1221658155-24824-1-git-send-email-apevec@redhat.com> References: <1221658155-24824-1-git-send-email-apevec@redhat.com> Message-ID: <48D13AED.3050401@redhat.com> Alan Pevec wrote: > to avoid error: Macro %fedora_url has empty body I changed this from ifneq when I fixed the ovirt-appliance repo. As soon as we move node-image to automake we won't be able to use ifneq and then we'll be back to what is here now... Perry > Signed-off-by: Alan Pevec > --- > Makefile | 9 ++++++--- > 1 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/Makefile b/Makefile > index 60fa9b4..969fa04 100644 > --- a/Makefile > +++ b/Makefile > @@ -4,10 +4,13 @@ all: rpms > include release.mk > > # FEDORA_URL env var can be set to the root of a fedora mirror > +ifneq ($(FEDORA_URL),) > +RPM_FLAGS += --define "fedora_url $(FEDORA_URL)" > +endif > # OVIRT_URL env var can be set to the root of an ovirt.org mirror > -RPM_FLAGS += \ > - --define "fedora_url $(FEDORA_URL)" \ > - --define "ovirt_url $(OVIRT_URL)" > +ifneq ($(OVIRT_URL),) > +RPM_FLAGS += --define "ovirt_url $(OVIRT_URL)" > +endif > > clean: > rm -rf $(pkg_name)-* -- |=- Red Hat, Engineering, Emerging Technologies, Boston -=| |=- Email: pmyers at redhat.com -=| |=- Office: +1 412 474 3552 Mobile: +1 703 362 9622 -=| |=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=| From slinabery at redhat.com Wed Sep 17 21:04:44 2008 From: slinabery at redhat.com (Steve Linabery) Date: Wed, 17 Sep 2008 16:04:44 -0500 Subject: [Ovirt-devel] [PATCH server] Add max/min methods to stats results, various other fixes to stats Message-ID: <20080917210444.GA6106@redhat.com> >From df0bb94ed5549ab6826da255f9acca5e414938aa Mon Sep 17 00:00:00 2001 From: Steve Linabery Date: Wed, 17 Sep 2008 15:22:39 -0500 Subject: [PATCH] Add max/min methods to stats results, various other fixes to stats --- src/app/util/stats/Stats.rb | 64 +++++++++++++++++++++++++++++++---- src/app/util/stats/StatsDataList.rb | 28 +++++++++++++-- src/app/util/stats/statsTest.rb | 38 +++++++++++++------- 3 files changed, 107 insertions(+), 23 deletions(-) diff --git a/src/app/util/stats/Stats.rb b/src/app/util/stats/Stats.rb index f6ced4b..b434232 100644 --- a/src/app/util/stats/Stats.rb +++ b/src/app/util/stats/Stats.rb @@ -29,6 +29,8 @@ require 'util/stats/StatsRequest' def fetchRollingAve?(rrdPath, start, endTime, interval, myFunction, lIndex, returnList, aveLen=7) final = 0 + my_min = 0 + my_max = 0 # OK, first thing we need to do is to move the start time back in order to # have data to average. @@ -65,19 +67,32 @@ def fetchRollingAve?(rrdPath, start, endTime, interval, myFunction, lIndex, retu final += rdata end final = (final / aveLen ) + + # Determine min / max to help with autoscale. + unless final.is_a? (Float) && final.nan? + my_min = [my_min, final].min + my_max = [my_max, final].max + end returnList.append_data( StatsData.new(fstart + interval * ( i - indexOffset), final )) # Now shift the head off the array roll.shift end end - + + # Now add the min / max to the lists + returnList.set_min_value(my_min) + returnList.set_max_value(my_max) + return returnList end def fetchRollingCalcUsedData?(rrdPath, start, endTime, interval, myFunction, lIndex, returnList, aveLen=7) + my_min = 0 + my_max = 0 + # OK, first thing we need to do is to move the start time back in order to have data to average. indexOffset = ( aveLen / 2 ).to_i @@ -120,12 +135,22 @@ def fetchRollingCalcUsedData?(rrdPath, start, endTime, interval, myFunction, lIn final += rdata end final = (final / aveLen) + + # Determine min / max to help with autoscale. + unless final.is_a? (Float) && final.nan? + my_min = [my_min, final].min + my_max = [my_max, final].max + end returnList.append_data( StatsData.new(fstart + interval * ( i - indexOffset), final )) # Now shift the head off the array roll.shift end end + # Now add the min / max to the lists + returnList.set_min_value(my_min) + returnList.set_max_value(my_max) + return returnList end @@ -137,6 +162,9 @@ def fetchCalcUsedData?(rrdPath, start, endTime, interval, myFunction, lIndex, re # We also need to handle NaN differently # Finally, we need to switch Min and Max + my_min = 0 + my_max = 0 + lFunc = "AVERAGE" case myFunction when "MAX" @@ -155,13 +183,23 @@ def fetchCalcUsedData?(rrdPath, start, endTime, interval, myFunction, lIndex, re data.each do |vdata| i += 1 value = vdata[lIndex] - value = 100 if value.nan? - if ( value > 100 ) - value = 100 - end - value = 100 - value + value = 100 if value.nan? + if ( value > 100 ) + value = 100 + end + value = 100 - value + + # Determine min / max to help with autoscale. + unless value.is_a? (Float) && value.nan? + my_min = [my_min, value].min + my_max = [my_max, value].max + end returnList.append_data( StatsData.new(fstart + interval * i, value )) end + + # Now add the min / max to the lists + returnList.set_min_value(my_min) + returnList.set_max_value(my_max) return returnList end @@ -169,6 +207,9 @@ end def fetchRegData?(rrdPath, start, endTime, interval, myFunction, lIndex, returnList) + my_min = 0 + my_max = 0 + (fstart, fend, names, data, interval) = RRD.fetch(rrdPath, "--start", start.to_s, "--end", \ endTime.to_s, myFunction, "-r", interval.to_s) i = 0 @@ -177,9 +218,18 @@ def fetchRegData?(rrdPath, start, endTime, interval, myFunction, lIndex, returnL # Now, lets walk the returned data and create the ojects, and put them in a list. data.each do |vdata| + value = vdata[lIndex] i += 1 - returnList.append_data( StatsData.new(fstart + interval * i, vdata[lIndex] )) + unless value.is_a? (Float) && value.nan? + my_min = [my_min, value].min + my_max = [my_max, value].max + end + returnList.append_data( StatsData.new(fstart + interval * i, value )) end + + # Now add the min / max to the lists + returnList.set_min_value(my_min) + returnList.set_max_value(my_max) return returnList end diff --git a/src/app/util/stats/StatsDataList.rb b/src/app/util/stats/StatsDataList.rb index d6de29c..a39bcc4 100644 --- a/src/app/util/stats/StatsDataList.rb +++ b/src/app/util/stats/StatsDataList.rb @@ -29,13 +29,19 @@ class StatsDataList @data=[] @status = status @function = function - end + @min_value = 0 + @max_value = 0 + end def get_node?() return @node end - def get_devClass?() + def get_node?() + return @node + end + + def get_devClass?() return @devClass end @@ -66,4 +72,20 @@ class StatsDataList def length() return @data.length end -end + + def set_min_value(min) + @min_value = min + end + + def set_max_value(max) + @max_value = max + end + + def get_min_value?() + return @min_value + end + + def get_max_value?() + return @max_value + end +end diff --git a/src/app/util/stats/statsTest.rb b/src/app/util/stats/statsTest.rb index baedbc0..007bb71 100644 --- a/src/app/util/stats/statsTest.rb +++ b/src/app/util/stats/statsTest.rb @@ -33,11 +33,20 @@ require 'util/stats/Stats' # requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::Load, 0, LoadCounter::Load_15min, 0, 0, RRDResolution::Long ) # requestList << StatsRequest.new("node7.priv.ovirt.org", DevClass::NIC, 0, NicCounter::Octets_rx, 0, 0, RRDResolution::Long ) # requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::NIC, 1, NicCounter::Octets_rx, 0, 0, RRDResolution::Long ) - requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::NIC, 0, NicCounter::Octets_tx, 0, 604800, RRDResolution::Medium ) +# requestList << StatsRequest.new("node5.priv.ovirt.org", DevClass::NIC, 0, NicCounter::Octets_tx, 0, 604800, RRDResolution::Long, DataFunction::Average ) +# requestList << StatsRequest.new("node5.priv.ovirt.org", DevClass::NIC, 0, NicCounter::Octets_tx, 0, 604800, RRDResolution::Long, DataFunction::Peak ) +# requestList << StatsRequest.new("node5.priv.ovirt.org", DevClass::NIC, 0, NicCounter::Octets_tx, 0, 604800, RRDResolution::Long) # requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::Disk, 0, DiskCounter::Octets_read, 0, 0, RRDResolution::Long ) # requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::Disk, 0, DiskCounter::Octets_write, 0, 0, RRDResolution::Long ) # requestList << StatsRequest.new("node3.priv.ovirt.org", "cpu", 0, "idle", 1211688000, 3600, 10 ) -# requestList << StatsRequest.new("node4.priv.ovirt.org", DevClass::CPU, 0, CpuCounter::Idle, 0, 3600, RRDResolution::Short ) + + requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::CPU, 0, CpuCounter::CalcUsed, 0, 300, RRDResolution::Default, DataFunction::Average ) + requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::NIC, 0, NicCounter::Octets_rx, 0, 0, RRDResolution::Default ) +# requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::CPU, 0, CpuCounter::Idle, 0, 300, RRDResolution::Default, DataFunction::RollingAverage ) +# requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::CPU, 0, CpuCounter::Idle, 0, 300, RRDResolution::Default, DataFunction::Average ) + requestList << StatsRequest.new("node3.priv.ovirt.org", DevClass::CPU, 0, CpuCounter::CalcUsed, 0, 300, RRDResolution::Default, DataFunction::RollingAverage ) +# requestList << StatsRequest.new("node4.priv.ovirt.org", DevClass::CPU, 0, CpuCounter::Idle, 0, 3600, RRDResolution::Short, DataFunction::Average ) +# requestList << StatsRequest.new("node4.priv.ovirt.org", DevClass::CPU, 0, CpuCounter::CalcUsed, 0, 3600, RRDResolution::Short, DataFunction::Min ) # requestList << StatsRequest.new("node5.priv.ovirt.org", "cpu", 0, "idle", 1211688000, 3600, 500 ) # requestList << StatsRequest.new("node5.priv.ovirt.org", DevClass::Memory, 0, MemCounter::Used, 0, 3600, 10 ) @@ -58,21 +67,24 @@ require 'util/stats/Stats' myCounter = statsList.get_counter?() myStatus = statsList.get_status?() - case myStatus - when StatsStatus::E_NOSUCHNODE - puts "Can't find data for node " + myNodeName - when StatsStatus::E_UNKNOWN - puts "Can't find data for requested file path" - end - if tmp != myNodeName then + case myStatus + when StatsStatus::E_NOSUCHNODE + puts "Can't find data for node " + myNodeName + when StatsStatus::E_UNKNOWN + puts "Can't find data for requested file path" + end + if tmp != myNodeName then + puts + end + list = statsList.get_data?() + list.each do |d| + print("\t", myNodeName, "\t", myDevClass, "\t", myInstance, "\t", myCounter, "\t",d.get_value?, "\t",d.get_timestamp?) puts end - list = statsList.get_data?() - list.each do |d| - print("\t", myNodeName, "\t", myDevClass, "\t", myInstance, "\t", myCounter, "\t",d.get_value?, "\t",d.get_timestamp?) puts - end tmp = myNodeName + print("\tmin_value is: ", statsList.get_min_value?(), "\tmax_value is: ", statsList.get_max_value?()) + puts end -- 1.5.5.1 From sseago at redhat.com Wed Sep 17 21:23:47 2008 From: sseago at redhat.com (Scott Seago) Date: Wed, 17 Sep 2008 17:23:47 -0400 Subject: [Ovirt-devel] [PATCH] finished smart pools implementation. Message-ID: <1221686627-3506-1-git-send-email-sseago@redhat.com> Nav now works for smart pools (but Jay's going to do some tweaking). All of the smart pool tabs work properly with add/remove functions, although summary is stubbed out. search results are not yet integrated with smart pools. Signed-off-by: Scott Seago --- src/app/controllers/application.rb | 8 +- src/app/controllers/hardware_controller.rb | 122 +++-------- src/app/controllers/host_controller.rb | 5 + src/app/controllers/pool_controller.rb | 31 +++- src/app/controllers/resources_controller.rb | 4 +- src/app/controllers/smart_pool_controller.rb | 22 -- src/app/controllers/smart_pools_controller.rb | 239 ++++++++++++++++++++ src/app/controllers/storage_controller.rb | 5 + src/app/controllers/tree_controller.rb | 14 +- src/app/controllers/vm_controller.rb | 5 + src/app/models/directory_pool.rb | 1 + src/app/models/pool.rb | 42 +++- src/app/models/smart_pool.rb | 23 ++ src/app/views/hardware/_move_menu.rhtml | 17 -- src/app/views/hardware/show_hosts.rhtml | 12 +- src/app/views/hardware/show_storage.rhtml | 4 +- src/app/views/host/_grid.rhtml | 14 +- src/app/views/host/add_to_smart_pool.rhtml | 28 +++ src/app/views/host/addhost.html.erb | 2 +- src/app/views/layouts/_navigation_tabs.rhtml | 17 ++ src/app/views/layouts/_side_toolbar.rhtml | 5 + src/app/views/layouts/_tree.rhtml | 6 +- src/app/views/resources/show_vms.rhtml | 1 + src/app/views/smart_pools/_form.rhtml | 6 + src/app/views/smart_pools/_pools_grid.rhtml | 39 ++++ src/app/views/smart_pools/add_pool_dialog.rhtml | 52 +++++ src/app/views/smart_pools/new.rhtml | 26 ++ src/app/views/smart_pools/show.rhtml | 17 ++ .../{hardware => smart_pools}/show_hosts.rhtml | 64 ++--- src/app/views/smart_pools/show_pools.rhtml | 74 ++++++ src/app/views/smart_pools/show_storage.rhtml | 72 ++++++ src/app/views/smart_pools/show_users.rhtml | 2 + src/app/views/smart_pools/show_vms.rhtml | 77 +++++++ src/app/views/storage/_grid.rhtml | 19 ++- src/app/views/storage/add_to_smart_pool.rhtml | 22 ++ src/app/views/vm/_grid.rhtml | 70 ++++--- src/app/views/vm/add_to_smart_pool.rhtml | 27 +++ src/db/migrate/017_add_smart_pools.rb | 2 +- .../jquery-treeview/jquery.treeview.async.js | 2 +- src/public/javascripts/jquery.ovirt.treeview.js | 12 +- src/public/javascripts/ovirt.js | 66 ++++++ version | 2 +- 42 files changed, 1043 insertions(+), 235 deletions(-) delete mode 100644 src/app/controllers/smart_pool_controller.rb create mode 100644 src/app/controllers/smart_pools_controller.rb delete mode 100644 src/app/views/hardware/_move_menu.rhtml create mode 100644 src/app/views/host/add_to_smart_pool.rhtml create mode 100644 src/app/views/smart_pools/_form.rhtml create mode 100644 src/app/views/smart_pools/_pools_grid.rhtml create mode 100644 src/app/views/smart_pools/add_pool_dialog.rhtml create mode 100644 src/app/views/smart_pools/new.rhtml create mode 100644 src/app/views/smart_pools/show.rhtml copy src/app/views/{hardware => smart_pools}/show_hosts.rhtml (50%) create mode 100644 src/app/views/smart_pools/show_pools.rhtml create mode 100644 src/app/views/smart_pools/show_storage.rhtml create mode 100644 src/app/views/smart_pools/show_users.rhtml create mode 100644 src/app/views/smart_pools/show_vms.rhtml create mode 100644 src/app/views/storage/add_to_smart_pool.rhtml create mode 100644 src/app/views/vm/add_to_smart_pool.rhtml diff --git a/src/app/controllers/application.rb b/src/app/controllers/application.rb index 3126748..5753613 100644 --- a/src/app/controllers/application.rb +++ b/src/app/controllers/application.rb @@ -89,7 +89,7 @@ class ApplicationController < ActionController::Base end # don't define find_opts for array inputs - def json_hash(full_items, attributes, arg_list=[], find_opts={}) + def json_hash(full_items, attributes, arg_list=[], find_opts={}, id_method=:id) page = params[:page].to_i paginate_opts = {:page => page, :order => "#{params[:sortname]} #{params[:sortorder]}", @@ -101,7 +101,7 @@ class ApplicationController < ActionController::Base json_hash[:total] = item_list.total_entries json_hash[:rows] = item_list.collect do |item| item_hash = {} - item_hash[:id] = item.id + item_hash[:id] = item.send(id_method) item_hash[:cell] = attributes.collect do |attr| if attr.is_a? Array value = item @@ -116,8 +116,8 @@ class ApplicationController < ActionController::Base json_hash end # don't define find_opts for array inputs - def json_list(full_items, attributes, arg_list=[], find_opts={}) - render :json => json_hash(full_items, attributes, arg_list, find_opts).to_json + def json_list(full_items, attributes, arg_list=[], find_opts={}, id_method=:id) + render :json => json_hash(full_items, attributes, arg_list, find_opts, id_method).to_json end diff --git a/src/app/controllers/hardware_controller.rb b/src/app/controllers/hardware_controller.rb index a366e4c..9695cfb 100644 --- a/src/app/controllers/hardware_controller.rb +++ b/src/app/controllers/hardware_controller.rb @@ -1,4 +1,4 @@ -# +# # Copyright (C) 2008 Red Hat, Inc. # Written by Scott Seago # @@ -20,10 +20,6 @@ class HardwareController < PoolController - XML_OPTS = { - :include => [ :storage_pools, :hosts, :quota ] - } - EQ_ATTRIBUTES = [ :name, :parent_id ] verify :method => [:post, :put], :only => [ :create, :update ], @@ -59,12 +55,12 @@ class HardwareController < PoolController end def json_view_tree - json_tree_internal(Permission::PRIV_VIEW, false) + json_tree_internal(Permission::PRIV_VIEW, :select_hardware_and_vm_pools) end def json_move_tree - json_tree_internal(Permission::PRIV_MODIFY, true) + json_tree_internal(Permission::PRIV_MODIFY, :select_hardware_pools) end - def json_tree_internal(privilege, filter_vm_pools) + def json_tree_internal(privilege, filter_method) id = params[:id] if id @pool = Pool.find(id) @@ -77,11 +73,9 @@ class HardwareController < PoolController end if @pool pools = @pool.children - pools = Pool.select_hardware_pools(pools) if filter_vm_pools open_list = [] else pools = Pool.list_for_user(get_login_user,Permission::PRIV_VIEW) - pools = Pool.select_hardware_pools(pools) if filter_vm_pools current_id = params[:current_id] if current_id current_pool = Pool.find(current_id) @@ -90,26 +84,26 @@ class HardwareController < PoolController open_list = [] end end + pools = Pool.send(filter_method, pools) - render :json => Pool.nav_json(pools, open_list, filter_vm_pools) + render :json => Pool.nav_json(pools, open_list, + (filter_method==:select_hardware_pools)) end def show_vms show end - def show_hosts - @hardware_pools = HardwarePool.find :all + def show_hosts show end - + def show_graphs show end def show_storage show - @hardware_pools = HardwarePool.find :all end def show_tasks @@ -142,21 +136,16 @@ class HardwareController < PoolController # filtering on which pool to exclude id = params[:exclude_pool] hosts = Host - find_opts = {:include => :hardware_pool, + find_opts = {:include => :hardware_pool, :conditions => ["pools.id != ?", id]} include_pool = true end - attr_list = [] - attr_list << :id if params[:checkboxes] - attr_list << :hostname - attr_list << [:hardware_pool, :name] if include_pool - attr_list += [:uuid, :hypervisor_type, :num_cpus, :cpu_speed, :arch, :memory_in_mb, :status_str, :load_average] - json_list(hosts, attr_list, [:all], find_opts) + super(:full_items => hosts,:include_pool => include_pool,:find_opts => find_opts) end def vm_pools_json - json_list(Pool, - [:id, :name, :id], + json_list(Pool, + [:id, :name, :id], [@pool, :children], {:finder => 'call_finder', :conditions => ["type = 'VmResourcePool'"]}) end @@ -172,24 +161,22 @@ class HardwareController < PoolController # filtering on which pool to exclude id = params[:exclude_pool] storage_pools = StoragePool - find_opts = {:include => :hardware_pool, + find_opts = {:include => :hardware_pool, :conditions => ["pools.id != ?", id]} include_pool = true end - attr_list = [:id, :display_name, :ip_addr, :get_type_label] - attr_list.insert(2, [:hardware_pool, :name]) if include_pool - json_list(storage_pools, attr_list, [:all], find_opts) + super(:full_items => storage_pools,:include_pool => include_pool,:find_opts => find_opts) end def storage_volumes_json - json_list(@pool.all_storage_volumes, + json_list(@pool.all_storage_volumes, [:display_name, :size_in_gb, :get_type_label]) end def move pre_modify @resource_type = params[:resource_type] - render :layout => 'popup' + render :layout => 'popup' end def new @@ -279,87 +266,44 @@ class HardwareController < PoolController end end - #FIXME: we need permissions checks. user must have permission on src pool - # in addition to the current pool (which is checked). We also need to fail - # for hosts that aren't currently empty def add_hosts - host_ids_str = params[:resource_ids] - host_ids = host_ids_str.split(",").collect {|x| x.to_i} - - begin - @pool.transaction do - @pool.move_hosts(host_ids, @pool.id) - end - render :json => { :object => "host", :success => true, - :alert => "Hosts were successfully added to this Hardware pool." } - rescue - render :json => { :object => "host", :success => false, - :alert => "Error adding Hosts to this Hardware pool." } - end + edit_items(Host, :move_hosts, @pool.id, :add) end - #FIXME: we need permissions checks. user must have permission on src pool - # in addition to the current pool (which is checked). We also need to fail - # for hosts that aren't currently empty def move_hosts - target_pool_id = params[:target_pool_id] - host_ids_str = params[:resource_ids] - host_ids = host_ids_str.split(",").collect {|x| x.to_i} - - begin - @pool.transaction do - @pool.move_hosts(host_ids, target_pool_id) - end - render :json => { :object => "host", :success => true, - :alert => "Hosts were successfully moved." } - rescue - render :json => { :object => "host", :success => false, - :alert => "Error moving hosts." } - end + edit_items(Host, :move_hosts, params[:target_pool_id], :move) end - #FIXME: we need permissions checks. user must have permission on src pool - # in addition to the current pool (which is checked). We also need to fail - # for storage that aren't currently empty def add_storage - storage_pool_ids_str = params[:resource_ids] - storage_pool_ids = storage_pool_ids_str.split(",").collect {|x| x.to_i} - - begin - @pool.transaction do - @pool.move_storage(storage_pool_ids, @pool.id) - end - render :json => { :object => "storage_pool", :success => true, - :alert => "Storage Pools were successfully added to this Hardware pool." } - rescue - render :json => { :object => "storage_pool", :success => false, - :alert => "Error adding storage pools to this Hardware pool." } - end + edit_items(StoragePool, :move_storage, @pool.id, :add) + end + + def move_storage + edit_items(StoragePool, :move_storage, params[:target_pool_id], :move) end #FIXME: we need permissions checks. user must have permission on src pool # in addition to the current pool (which is checked). We also need to fail # for storage that aren't currently empty - def move_storage - target_pool_id = params[:target_pool_id] - storage_pool_ids_str = params[:resource_ids] - storage_pool_ids = storage_pool_ids_str.split(",").collect {|x| x.to_i} + def edit_items(item_class, item_method, target_pool_id, action) + resource_ids_str = params[:resource_ids] + resource_ids = resource_ids_str.split(",").collect {|x| x.to_i} begin @pool.transaction do - @pool.move_storage(storage_pool_ids, target_pool_id) + @pool.send(item_method, resource_ids, target_pool_id) end - render :json => { :object => "storage_pool", :success => true, - :alert => "Storage Pools were successfully moved." } + render :json => { :success => true, + :alert => "#{item_action.to_s} #{item_class.table_name.humanize} successful." } rescue - render :json => { :object => "storage_pool", :success => false, - :alert => "Error moving storage pools." } + render :json => { :success => false, + :alert => "#{item_action.to_s} #{item_class.table_name.humanize} failed." } end end def removestorage pre_modify - render :layout => 'popup' + render :layout => 'popup' end def destroy diff --git a/src/app/controllers/host_controller.rb b/src/app/controllers/host_controller.rb index 5174c88..417d11f 100644 --- a/src/app/controllers/host_controller.rb +++ b/src/app/controllers/host_controller.rb @@ -84,6 +84,11 @@ class HostController < ApplicationController render :layout => 'popup' end + def add_to_smart_pool + @pool = SmartPool.find(params[:smart_pool_id]) + render :layout => 'popup' + end + def new end diff --git a/src/app/controllers/pool_controller.rb b/src/app/controllers/pool_controller.rb index ce41701..02ef290 100644 --- a/src/app/controllers/pool_controller.rb +++ b/src/app/controllers/pool_controller.rb @@ -23,9 +23,14 @@ class PoolController < ApplicationController before_filter :pre_show_pool, :only => [:show_vms, :show_users, :show_hosts, :show_storage, :users_json, :show_tasks, :tasks, - :vms_json, :vm_pools_json, + :vm_pools_json, + :pools_json, :show_pools, :storage_volumes_json, :quick_summary] + XML_OPTS = { + :include => [ :storage_pools, :hosts, :quota ] + } + def show respond_to do |format| format.html { @@ -86,6 +91,28 @@ class PoolController < ApplicationController json_hash(@pool.tasks, attr_list, [:all], find_opts) end + def hosts_json(args) + attr_list = [] + attr_list << :id if params[:checkboxes] + attr_list << :hostname + attr_list << [:hardware_pool, :name] if args[:include_pool] + attr_list += [:uuid, :hypervisor_type, :num_cpus, :cpu_speed, :arch, :memory_in_mb, :status_str, :load_average] + json_list(args[:full_items], attr_list, [:all], args[:find_opts]) + end + + def storage_pools_json(args) + attr_list = [:id, :display_name, :ip_addr, :get_type_label] + attr_list.insert(2, [:hardware_pool, :name]) if args[:include_pool] + json_list(args[:full_items], attr_list, [:all], args[:find_opts]) + end + + def vms_json(args) + attr_list = [:id, :description, :uuid, + :num_vcpus_allocated, :memory_allocated_in_mb, + :vnic_mac_addr, :state, :id] + json_list(args[:full_items], attr_list, [:all], args[:find_opts]) + end + def new render :layout => 'popup' end @@ -120,7 +147,7 @@ class PoolController < ApplicationController @current_pool_id=@pool.id set_perms(@perm_obj) unless @can_view - flash[:notice] = 'You do not have permission to view this pool pool: redirecting to top level' + flash[:notice] = 'You do not have permission to view this pool: redirecting to top level' respond_to do |format| format.html { redirect_to :controller => "dashboard" } format.xml { head :forbidden } diff --git a/src/app/controllers/resources_controller.rb b/src/app/controllers/resources_controller.rb index a0a65a6..4e1daba 100644 --- a/src/app/controllers/resources_controller.rb +++ b/src/app/controllers/resources_controller.rb @@ -68,8 +68,8 @@ class ResourcesController < PoolController end def vms_json - json_list(@pool.vms, - [:id, :description, :uuid, :num_vcpus_allocated, :memory_allocated_in_mb, :vnic_mac_addr, :state, :id]) + pre_show + super(:full_items => @pool.vms, :find_opts => find_opts, :include_pool => :true) end def create diff --git a/src/app/controllers/smart_pool_controller.rb b/src/app/controllers/smart_pool_controller.rb deleted file mode 100644 index eb087a6..0000000 --- a/src/app/controllers/smart_pool_controller.rb +++ /dev/null @@ -1,22 +0,0 @@ -# -# Copyright (C) 2008 Red Hat, Inc. -# Written by Scott Seago -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; version 2 of the License. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, -# MA 02110-1301, USA. A copy of the GNU General Public License is -# also available at http://www.gnu.org/copyleft/gpl.html. -# - -class SmartPoolController < ApplicationController -end diff --git a/src/app/controllers/smart_pools_controller.rb b/src/app/controllers/smart_pools_controller.rb new file mode 100644 index 0000000..99ae8b8 --- /dev/null +++ b/src/app/controllers/smart_pools_controller.rb @@ -0,0 +1,239 @@ +# +# Copyright (C) 2008 Red Hat, Inc. +# Written by Scott Seago +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; version 2 of the License. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, +# MA 02110-1301, USA. A copy of the GNU General Public License is +# also available at http://www.gnu.org/copyleft/gpl.html. +# + +class SmartPoolsController < PoolController + + before_filter :pre_modify, :only => [:add_hosts, :remove_hosts, + :add_storage, :remove_storage, + :add_vms, :remove_vms, + :add_pools, :remove_pools] + def show_vms + show + end + + def show_hosts + show + end + + def show_pools + show + end + + def show_storage + show + end + + def create + begin + @pool.create_with_parent(@parent) + render :json => { :object => "smart_pool", :success => true, + :alert => "Smart Pool was successfully created." } + rescue + render :json => { :object => "smart_pool", :success => false, + :errors => @pool.errors.localize_error_messages.to_a} + end + end + + def update + begin + @pool.update_attributes!(params[:smart_pool]) + render :json => { :object => "smart_pool", :success => true, + :alert => "Smart Pool was successfully modified." } + rescue + render :json => { :object => "smart_pool", :success => false, + :errors => @pool.errors.localize_error_messages.to_a} + end + end + + def add_pool_dialog + pre_modify + @selected_pools = @pool.tagged_pools.collect {|pool| pool.id} + render :layout => 'popup' + end + + def hosts_json + super(items_json_internal(Host, :tagged_hosts)) + end + + def storage_pools_json + super(items_json_internal(StoragePool, :tagged_storage_pools)) + end + + def vms_json + super(items_json_internal(Vm, :tagged_vms)) + end + + def pools_json + args = items_json_internal(Pool, :tagged_pools) + attr_list = [:id, :name, :get_type_label] + json_list(args[:full_items], attr_list, [:all], args[:find_opts], :class_and_id) + + end + + def items_json_internal(item_class, item_assoc) + if params[:id] + pre_show + full_items = @pool.send(item_assoc) + find_opts = {} + else + # FIXME: no permissions or usage checks here yet + # filtering on which pool to exclude + id = params[:exclude_pool] + full_items = item_class + pool_items = SmartPool.find(id, + :include => item_assoc).send(item_assoc).collect {|x| x.id} + if pool_items.empty? + conditions = [] + else + conditions = ["#{item_class.table_name}.id not in (?)", pool_items] + end + find_opts = {:conditions => conditions} + end + { :full_items => full_items, :find_opts => find_opts, :include_pool => :true} + end + + def add_hosts + edit_items(Host, :add_items, :add) + end + + def remove_hosts + edit_items(Host, :remove_items, :remove) + end + + def add_storage + edit_items(StoragePool, :add_items, :add) + end + + def remove_storage + edit_items(StoragePool, :remove_items, :remove) + end + + def add_vms + edit_items(Vm, :add_items, :add) + end + + def remove_vms + edit_items(Vm, :remove_items, :remove) + end + + def add_pools + edit_items(Pool, :add_items, :add) + end + + def remove_pools + edit_items(Pool, :remove_items, :remove) + end + + def edit_items(item_class, item_method, item_action) + resource_ids_str = params[:resource_ids] + resource_ids = resource_ids_str.split(",").collect {|x| x.to_i} + begin + @pool.send(item_method,item_class, resource_ids) + render :json => { :success => true, + :alert => "#{item_action.to_s} #{item_class.table_name.humanize} successful." } + rescue + render :json => { :success => false, + :alert => "#{item_action.to_s} #{item_class.table_name.humanize} failed." } + end + end + + def destroy + if @pool.destroy + alert="Smart Pool was successfully deleted." + success=true + else + alert="Failed to delete Smart pool." + success=false + end + render :json => { :object => "smart_pool", :success => success, :alert => alert } + end + + # handled + # show_hosts + # show_graphs + # show_storage + # show + # show_vms + # show_tasks + # new xxx + # create xxx + # hosts_json + # storage_pools_json + # add_hosts + # move_hosts + # add_storage + # move_storage + # removestorage + + #HW only + # json_view_tree + # json_move_tree + # vm_pools_json + # move + #VM only + # vms_json + # delete + # vm_actions + #both + # move + # update + # destroy + + #inherited + # used + # new + # edit + # show_users + # users_json + # unneeded + # tasks + # show_tasks + # quick_summary + + protected + #filter methods + def pre_new + @pool = SmartPool.new + @parent = DirectoryPool.get_or_create_user_root(get_login_user) + @perm_obj = @parent + @current_pool_id=@parent.id + end + def pre_create + @pool = SmartPool.new(params[:smart_pool]) + @parent = DirectoryPool.get_or_create_user_root(get_login_user) + @perm_obj = @parent + @current_pool_id=@parent.id + end + def pre_edit + @pool = SmartPool.find(params[:id]) + @parent = @pool.parent + @perm_obj = @pool + @current_pool_id=@pool.id + end + def pre_show + @pool = SmartPool.find(params[:id]) + super + end + def pre_modify + pre_edit + authorize_admin + end + +end diff --git a/src/app/controllers/storage_controller.rb b/src/app/controllers/storage_controller.rb index 7e97764..7eec618 100644 --- a/src/app/controllers/storage_controller.rb +++ b/src/app/controllers/storage_controller.rb @@ -199,6 +199,11 @@ class StorageController < ApplicationController render :layout => false end + def add_to_smart_pool + @pool = SmartPool.find(params[:smart_pool_id]) + render :layout => 'popup' + end + #FIXME: we need permissions checks. user must have permission on src pool # in addition to the current pool (which is checked). We also need to fail # for storage that aren't currently empty diff --git a/src/app/controllers/tree_controller.rb b/src/app/controllers/tree_controller.rb index 5ad8426..1aed544 100644 --- a/src/app/controllers/tree_controller.rb +++ b/src/app/controllers/tree_controller.rb @@ -1,10 +1,18 @@ class TreeController < ApplicationController - + + def get_pools + # TODO: split these into separate hash elements for HW and smart pools + pools = HardwarePool.get_default_pool.full_set_nested(:method => :json_hash_element, + :privilege => Permission::PRIV_VIEW, :user => get_login_user) + pools += DirectoryPool.get_smart_root.full_set_nested(:method => :json_hash_element, + :privilege => Permission::PRIV_VIEW, :user => get_login_user, + :smart_pool_set => true) + end def fetch_nav - @pools = HardwarePool.get_default_pool.full_set_nested(:method => :json_hash_element) + @pools = get_pools end def fetch_json - render :json => HardwarePool.get_default_pool.full_set_nested(:method => :json_hash_element).to_json + render :json => get_pools.to_json end end diff --git a/src/app/controllers/vm_controller.rb b/src/app/controllers/vm_controller.rb index d3f16b6..6d06b48 100644 --- a/src/app/controllers/vm_controller.rb +++ b/src/app/controllers/vm_controller.rb @@ -35,6 +35,11 @@ class VmController < ApplicationController render :layout => 'selection' end + def add_to_smart_pool + @pool = SmartPool.find(params[:smart_pool_id]) + render :layout => 'popup' + end + def new render :layout => 'popup' end diff --git a/src/app/models/directory_pool.rb b/src/app/models/directory_pool.rb index f62d980..82486af 100644 --- a/src/app/models/directory_pool.rb +++ b/src/app/models/directory_pool.rb @@ -55,6 +55,7 @@ class DirectoryPool < Pool permission.save! end end + user_root end end diff --git a/src/app/models/pool.rb b/src/app/models/pool.rb index 9d71fa5..eb71be8 100644 --- a/src/app/models/pool.rb +++ b/src/app/models/pool.rb @@ -111,6 +111,9 @@ class Pool < ActiveRecord::Base def self.select_vm_pools(pools) pools.select {|pool| pool[:type] == "VmResourcePool"} end + def self.select_hardware_and_vm_pools(pools) + pools.select {|pool| ["HardwarePool", "VmResourcePool"].include?(pool[:type])} + end def sub_hardware_pools children({:conditions => "type='HardwarePool'"}) @@ -225,22 +228,44 @@ class Pool < ActiveRecord::Base # or :current_id to specify which pool gets ":selected => true" set def full_set_nested(opts={}) method = opts.delete(:method) {:hash_element} + privilege = opts.delete(:privilege) + user = opts.delete(:user) + smart_pool_set = opts.delete(:smart_pool_set) + if privilege and user + opts[:include] = "permissions" + opts[:conditions] = "permissions.uid='#{user}' and + permissions.user_role in + ('#{Permission.roles_for_privilege(privilege).join("', '")}')" + end current_id = opts.delete(:current_id) opts.delete(:order) subtree_list = full_set(opts) - return_tree = send(method) - ref_hash = { id => return_tree} + subtree_list -= [self] if smart_pool_set + return_tree_list = [] + ref_hash = {} subtree_list.each do |pool| - unless pool.id==return_tree[:id] - new_element = pool.send(method) - ref_hash[pool.id] = new_element - parent = ref_hash[pool.parent_id] + new_element = pool.send(method) + ref_hash[pool.id] = new_element + parent = ref_hash[pool.parent_id] + if parent parent[:children] ||= [] parent[:children] << new_element + else + # for smart pools include the parent DirectoryPool + if smart_pool_set and pool[:type]=="SmartPool" + pool_parent = pool.parent + parent_element = pool_parent.send(method) + ref_hash[pool_parent.id] = parent_element + return_tree_list << parent_element + parent_element[:children] ||= [] + parent_element[:children] << new_element + else + return_tree_list << new_element + end end end ref_hash[current_id][:selected] = true if current_id - return_tree + return_tree_list end def self.call_finder(*args) @@ -273,6 +298,9 @@ class Pool < ActiveRecord::Base end end + def class_and_id + self.class.name + "_" + self.id.to_s + end protected def traverse_parents if id diff --git a/src/app/models/smart_pool.rb b/src/app/models/smart_pool.rb index e672c5b..9104ee5 100644 --- a/src/app/models/smart_pool.rb +++ b/src/app/models/smart_pool.rb @@ -30,6 +30,10 @@ class SmartPool < Pool :conditions => "smart_pool_tags.tagged_type = 'Vm'" + def get_type_label + "Smart Pool" + end + def create_for_user(user) create_with_parent(DirectoryPool.get_or_create_user_root(user)) end @@ -44,4 +48,23 @@ class SmartPool < Pool :tagged_id=>item.id}).destroy end + def add_items(item_class, item_ids) + items = item_class.find(:all, :conditions => "id in (#{item_ids.join(', ')})") + transaction do + items.each { |item| add_item(item)} + end + end + + def remove_items(item_class, item_ids) + tags = smart_pool_tags.find(:all, + :conditions => "tagged_id in + (#{item_ids.join(', ')}) + and tagged_type='#{item_class.name}'") + transaction do + tags.each do |tag| + tag.destroy + end + end + end + end diff --git a/src/app/views/hardware/_move_menu.rhtml b/src/app/views/hardware/_move_menu.rhtml deleted file mode 100644 index cc7ed73..0000000 --- a/src/app/views/hardware/_move_menu.rhtml +++ /dev/null @@ -1,17 +0,0 @@ -<%= image_tag "icon_move.png", :style => "vertical-align:middle;" %>  Move    <%= image_tag "icon_toolbar_arrow.gif", :style => "vertical-align:middle;" %> -
          - <% @hardware_pools.each { |hw_pool| %> - <% if @pool.parent_id != hw_pool.id and @pool.id != hw_pool.id %> -
        • - <% else %> -
        • - <% end %> - <%= image_tag "icon_hdwarepool.png" %> -   <%= hw_pool.name %> -
          • - <% } %> - -
        • - Move to New Resource Group... -
          • -
        diff --git a/src/app/views/hardware/show_hosts.rhtml b/src/app/views/hardware/show_hosts.rhtml index 31c575d..5c34af3 100644 --- a/src/app/views/hardware/show_hosts.rhtml +++ b/src/app/views/hardware/show_hosts.rhtml @@ -26,7 +26,7 @@ { hosts = get_selected_hosts() if (validate_selected(hosts, "host")) { - $.post('<%= url_for :controller => "hardware", :action => "move_hosts", :id => @pool %>', + $.post('<%= url_for :controller => "hardware", :action => "remove_hosts", :id => @pool %>', { resource_ids: hosts.toString(), target_pool_id: <%= HardwarePool.get_default_pool.id %> }, function(data,status){ $tabs.tabs("load",$tabs.data('selected.tabs')); @@ -35,15 +35,15 @@ } if (hosts.indexOf($('#hosts_selection_id').html()) != -1){ empty_summary('hosts_selection', 'Host') - } + } }, 'json'); } } function hosts_select(selected_rows) { - var selected_ids = new Array() - for(i=0; i nil, :show_pool => false, :checkboxes => true, - :on_select => "hosts_select", + :on_select => "hosts_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", :on_unhover => "load_widget_unhover", @@ -79,7 +79,7 @@
        <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> - +
        No hosts found in this pool.

        <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   diff --git a/src/app/views/hardware/show_storage.rhtml b/src/app/views/hardware/show_storage.rhtml index 564b9ed..973478a 100644 --- a/src/app/views/hardware/show_storage.rhtml +++ b/src/app/views/hardware/show_storage.rhtml @@ -50,7 +50,7 @@ function storage_select(selected_rows) { var selected_ids = new Array() ; - for(i=0; i
        <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> - +
        No storage Volumes found in this pool.

        <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   diff --git a/src/app/views/host/_grid.rhtml b/src/app/views/host/_grid.rhtml index 553adf9..be47011 100644 --- a/src/app/views/host/_grid.rhtml +++ b/src/app/views/host/_grid.rhtml @@ -1,6 +1,13 @@ <%= render :partial => 'graph/load_graph.rhtml' %> <% hosts_per_page.nil? ? hosts_per_page = 40: hosts_per_page = hosts_per_page %> +<% if (hwpool.nil? or + ((hwpool.is_a? HardwarePool) and (hwpool.hosts.size > hosts_per_page)) or + ((hwpool.is_a? SmartPool) and (hwpool.tagged_hosts.size > hosts_per_page))) + usepager = 'true' + else + usepager = 'false' + end %>
        <%= "" if checkboxes %> @@ -10,7 +17,8 @@ $("#<%= table_id %>").flexigrid ( { - url: '<%= url_for :controller => "hardware", + url: '<%= url_for :controller => (defined? pool_controller) ? + pool_controller : "hardware", :action => "hosts_json", :escape => false, :id => (hwpool.nil? ? nil : hwpool.id), @@ -38,8 +46,8 @@ ], sortname: "hostname", sortorder: "asc", - usepager: <%= (hwpool.nil? or hwpool.hosts.size > hosts_per_page) ? 'true' : 'false' %>, - useRp: <%= (hwpool.nil? or hwpool.hosts.size > hosts_per_page) ? 'true' : 'false' %>, + usepager: <%= usepager %>, + useRp: <%= usepager %>, rp: <%= hosts_per_page %>, showTableToggleBtn: true, onSelect: <%= on_select %>, diff --git a/src/app/views/host/add_to_smart_pool.rhtml b/src/app/views/host/add_to_smart_pool.rhtml new file mode 100644 index 0000000..a89f8de --- /dev/null +++ b/src/app/views/host/add_to_smart_pool.rhtml @@ -0,0 +1,28 @@ +<%- content_for :title do -%> + <%= _("Add Host to Smart Pool") %> +<%- end -%> +<%- content_for :description do -%> + Select hosts from the list below to add to the <%= @pool.name %> smart pool. +<%- end -%> +
        +
        +
        + <%= render :partial => "/host/grid", :locals => { :table_id => "add_smart_hosts_grid", + :hwpool => nil, + :pool_controller => "smart_pools", + :exclude_pool => @pool.id, + :exclude_host => nil, + :checkboxes => true, + :on_select => false, + :on_deselect => false, + :on_hover => false, + :on_unhover => false, + :is_popup => true, + :hosts_per_page => 10} %> +
        + +<%= popup_footer("add_hosts_to_smart_pool('#{url_for :controller => "smart_pools", + :action => "add_hosts", + :id => @pool}')", + "Add Hosts") %> +
        diff --git a/src/app/views/host/addhost.html.erb b/src/app/views/host/addhost.html.erb index 7edd4c5..967643e 100644 --- a/src/app/views/host/addhost.html.erb +++ b/src/app/views/host/addhost.html.erb @@ -24,4 +24,4 @@ :action => "add_hosts", :id => @hardware_pool}')", "Add Hosts") %> -
        \ No newline at end of file +
        diff --git a/src/app/views/layouts/_navigation_tabs.rhtml b/src/app/views/layouts/_navigation_tabs.rhtml index 4b0f18d..af3fa61 100644 --- a/src/app/views/layouts/_navigation_tabs.rhtml +++ b/src/app/views/layouts/_navigation_tabs.rhtml @@ -30,6 +30,23 @@
      +<% elsif controller.controller_name == "smart_pools" %> + +
        + + + + + + +
      <% elsif controller.controller_name == "search" %>
        diff --git a/src/app/views/layouts/_side_toolbar.rhtml b/src/app/views/layouts/_side_toolbar.rhtml index 763f4a2..29ed542 100644 --- a/src/app/views/layouts/_side_toolbar.rhtml +++ b/src/app/views/layouts/_side_toolbar.rhtml @@ -21,4 +21,9 @@ <%= confirmation_dialog("conf_nav_delete_pool", "Are you sure?", "delete_#{pool[:type]=='HardwarePool' ? 'hw' : 'vm'}_pool(#{pool.id})") %>
    <% end -%> +
    + + <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Smart Pool" %> + +
    diff --git a/src/app/views/layouts/_tree.rhtml b/src/app/views/layouts/_tree.rhtml index eb15676..0e6e138 100644 --- a/src/app/views/layouts/_tree.rhtml +++ b/src/app/views/layouts/_tree.rhtml @@ -12,12 +12,14 @@ //animated: "normal", url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" }); var tree_reload = { url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" } $('#test-tree').everyTime(15000,function(){ load(tree_reload, {}, this, this); diff --git a/src/app/views/resources/show_vms.rhtml b/src/app/views/resources/show_vms.rhtml index 857f56b..2895c6b 100644 --- a/src/app/views/resources/show_vms.rhtml +++ b/src/app/views/resources/show_vms.rhtml @@ -70,6 +70,7 @@
    <%= render :partial => "/vm/grid", :locals => { :table_id => "vms_grid", :pool => @pool, + :exclude_pool => nil, :on_select => "vms_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", diff --git a/src/app/views/smart_pools/_form.rhtml b/src/app/views/smart_pools/_form.rhtml new file mode 100644 index 0000000..2f2156a --- /dev/null +++ b/src/app/views/smart_pools/_form.rhtml @@ -0,0 +1,6 @@ +<%= error_messages_for 'vm_resource_pool' %> + + +<%= text_field_with_label "Name", 'smart_pool', 'name' %> + + diff --git a/src/app/views/smart_pools/_pools_grid.rhtml b/src/app/views/smart_pools/_pools_grid.rhtml new file mode 100644 index 0000000..a5f1a99 --- /dev/null +++ b/src/app/views/smart_pools/_pools_grid.rhtml @@ -0,0 +1,39 @@ +<% resources_per_page = 40 %> +
    + + + +
    + diff --git a/src/app/views/smart_pools/add_pool_dialog.rhtml b/src/app/views/smart_pools/add_pool_dialog.rhtml new file mode 100644 index 0000000..0d8cea6 --- /dev/null +++ b/src/app/views/smart_pools/add_pool_dialog.rhtml @@ -0,0 +1,52 @@ +<%- content_for :title do -%> + Add a Hardware or Virtual Machine Pool +<%- end -%> +<%- content_for :description do -%> + Choose a Hardware or Virtual Machine Pool to add to this Smart Pool +<%- end -%> + + + +
    +
      +
      + +
      +
      +
      +
      Cancel
      +
      +
      +
      diff --git a/src/app/views/smart_pools/new.rhtml b/src/app/views/smart_pools/new.rhtml new file mode 100644 index 0000000..7d488af --- /dev/null +++ b/src/app/views/smart_pools/new.rhtml @@ -0,0 +1,26 @@ +<%- content_for :title do -%> + <%= _("Add New Smart Pool") %> +<%- end -%> +<%- content_for :description do -%> + Add a new Smart Pool. +<%- end -%> + +
      +
      + <%= render :partial => 'form' %> +
      + <%= popup_footer("$('#smart_pool_form').submit()", "Create Smart Pool") %> +
      + + diff --git a/src/app/views/smart_pools/show.rhtml b/src/app/views/smart_pools/show.rhtml new file mode 100644 index 0000000..45b1753 --- /dev/null +++ b/src/app/views/smart_pools/show.rhtml @@ -0,0 +1,17 @@ +
      + +
      <%= image_tag "icon_hdwarepool.png", :style=>"vertical-align:middle;" %> <%= @pool.name %>


      + +
      <%= image_tag "icon_smry_res.png", :style=>"vertical-align:middle;" %> Resources

      +
      + What do we show here for Smart Pools? +
      + +

      +
      <%= image_tag "icon_smry_his.png", :style=>"vertical-align:middle;" %> History

      + What do we show here for Smart Pools? + +
      <%= image_tag "icon_smry_perf.png", :style=>"vertical-align:middle;" %> Performance

      + What do we show here for Smart Pools? +
      + diff --git a/src/app/views/hardware/show_hosts.rhtml b/src/app/views/smart_pools/show_hosts.rhtml similarity index 50% copy from src/app/views/hardware/show_hosts.rhtml copy to src/app/views/smart_pools/show_hosts.rhtml index 31c575d..706c84f 100644 --- a/src/app/views/hardware/show_hosts.rhtml +++ b/src/app/views/smart_pools/show_hosts.rhtml @@ -1,89 +1,77 @@
      -<% if @pool.hosts.size != 0 %> +<% if @pool.tagged_hosts.size != 0 %>
      - <%= render :partial => "/host/grid", :locals => { :table_id => "hosts_grid", + <%= render :partial => "/host/grid", :locals => { :table_id => "smart_hosts_grid", :hwpool => @pool, + :pool_controller => "smart_pools", :exclude_pool => nil, :exclude_host => nil, - :show_pool => false, + :show_pool => true, :checkboxes => true, - :on_select => "hosts_select", + :on_select => "smart_hosts_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", :on_unhover => "load_widget_unhover", :is_popup => false, :hosts_per_page => 40} %>
      -
      -
      -
      Select a host above.
      -
      +
      +
      +
      Select a host above.
      +
      <% else %>
      <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> - +
      No hosts found in this pool.

      <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   - Add first host to this hardware pool + Add first host to this smart pool
      diff --git a/src/app/views/smart_pools/show_pools.rhtml b/src/app/views/smart_pools/show_pools.rhtml new file mode 100644 index 0000000..f9d4b19 --- /dev/null +++ b/src/app/views/smart_pools/show_pools.rhtml @@ -0,0 +1,74 @@ + + + + +
      +<% if @pool.tagged_pools.size != 0 %> +
      + <%= render :partial => "/smart_pools/pools_grid", :locals => { :table_id => "smart_pools_grid", + :pool => @pool, + :pool_controller => "smart_pools", + :checkboxes => true, + :on_select => "smart_pools_select", + :on_deselect => false, + :on_hover => false, + :on_unhover => false} %> +
      +
      +
      +
      Select a pool above.
      +
      +
      +<% else %> +
      +
      + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> + +
      + No pools found in this pool.

      + <%= image_tag "icon_addpool.png", :style=>"vertical-align:middle;" %>   + Add first Pool to this smart pool +
      +
      +
      +<% end %> diff --git a/src/app/views/smart_pools/show_storage.rhtml b/src/app/views/smart_pools/show_storage.rhtml new file mode 100644 index 0000000..89e5e14 --- /dev/null +++ b/src/app/views/smart_pools/show_storage.rhtml @@ -0,0 +1,72 @@ + + + +
      +<% if @pool.tagged_storage_pools.size != 0 %> +
      + <%= render :partial => "/storage/grid", :locals => { :table_id => "smart_storage_grid", + :hwpool => @pool, + :pool_controller => "smart_pools", + :exclude_pool => nil, + :on_select => "smart_storage_select", + :is_popup => false} %> +
      + +
      +
      +
      Select a storage pool.
      +
      +
      +<% else %> +
      +
      + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> + +
      + No storage Pools found in this pool.

      + <%= image_tag "icon_addstorage.png", :style=>"vertical-align:middle;" %>   + Add first storage volume to this smart pool +
      +
      +
      +<% end %> diff --git a/src/app/views/smart_pools/show_users.rhtml b/src/app/views/smart_pools/show_users.rhtml new file mode 100644 index 0000000..7d1efb8 --- /dev/null +++ b/src/app/views/smart_pools/show_users.rhtml @@ -0,0 +1,2 @@ + <%= render :partial => "/user/show", :locals => { :parent_controller => "smart_pools", + :pool => @pool } %> diff --git a/src/app/views/smart_pools/show_vms.rhtml b/src/app/views/smart_pools/show_vms.rhtml new file mode 100644 index 0000000..990e4ab --- /dev/null +++ b/src/app/views/smart_pools/show_vms.rhtml @@ -0,0 +1,77 @@ + + + + +
      +<% if @pool.tagged_vms.size != 0 %> +
      + <%= render :partial => "/vm/grid", :locals => { :table_id => "smart_vms_grid", + :pool => @pool, + :pool_controller => "smart_pools", + :exclude_pool => nil, + :show_pool => true, + :checkboxes => true, + :on_select => "smart_vms_select", + :on_deselect => "load_widget_deselect", + :on_hover => "load_widget_hover", + :on_unhover => "load_widget_unhover", + :is_popup => false, + :vms_per_page => 40} %> +
      +
      +
      +
      Select a vm above.
      +
      +
      +<% else %> +
      +
      + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> + +
      + No vms found in this pool.

      + <%= image_tag "icon_addvm.png", :style=>"vertical-align:middle;" %>   + Add first VM to this smart pool +
      +
      +
      +<% end %> diff --git a/src/app/views/storage/_grid.rhtml b/src/app/views/storage/_grid.rhtml index c36f4d3..21ca109 100644 --- a/src/app/views/storage/_grid.rhtml +++ b/src/app/views/storage/_grid.rhtml @@ -1,4 +1,11 @@ -<% storage_per_page = 40 %> +<% storage_per_page = 40 unless (defined? storage_per_page) and !(storage_per_page.nil?) %> +<% if (hwpool.nil? or + ((hwpool.is_a? HardwarePool) and (hwpool.storage_pools.size > storage_per_page)) or + ((hwpool.is_a? SmartPool) and (hwpool.tagged_storage_pools.size > storage_per_page))) + usepager = 'true' + else + usepager = 'false' + end %>
      @@ -9,7 +16,11 @@ $("#<%= table_id %>").flexigrid ( { - url: '<%= url_for :controller => "hardware", :action => "storage_pools_json", :id => (hwpool.nil? ? nil : hwpool.id), :exclude_pool => exclude_pool %>', + url: '<%= url_for :controller => (defined? pool_controller) ? + pool_controller : "hardware", + :action => "storage_pools_json", + :id => (hwpool.nil? ? nil : hwpool.id), + :exclude_pool => exclude_pool %>', dataType: 'json', <% if is_popup %> width: 700, @@ -23,8 +34,8 @@ ], sortname: "ip_addr", sortorder: "asc", - usepager: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, - useRp: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, + usepager: <%= usepager %>, + useRp: <%= usepager %>, rp: <%= storage_per_page %>, showTableToggleBtn: true, onSelect: <%= on_select %> diff --git a/src/app/views/storage/add_to_smart_pool.rhtml b/src/app/views/storage/add_to_smart_pool.rhtml new file mode 100644 index 0000000..2eedae3 --- /dev/null +++ b/src/app/views/storage/add_to_smart_pool.rhtml @@ -0,0 +1,22 @@ +<%- content_for :title do -%> + <%= _("Add Storage Pool to Smart Pool") %> +<%- end -%> +<%- content_for :description do -%> + Select storage pools from the list below to add to the <%= @pool.name %> smart pool. +<%- end -%> +
      +
      +
      + <%= render :partial => "/storage/grid", :locals => { :table_id => "add_smart_storage_grid", + :hwpool => nil, + :pool_controller => "smart_pools", + :exclude_pool => @pool.id, + :on_select => false, + :is_popup => true} %> +
      + +<%= popup_footer("add_storage_to_smart_pool('#{url_for :controller => "smart_pools", + :action => "add_storage", + :id => @pool}')", + "Add Storage Pools") %> +
      diff --git a/src/app/views/vm/_grid.rhtml b/src/app/views/vm/_grid.rhtml index c56e6b8..a538824 100644 --- a/src/app/views/vm/_grid.rhtml +++ b/src/app/views/vm/_grid.rhtml @@ -1,42 +1,56 @@ <%= render :partial => 'graph/load_graph.rhtml' %> -<% vms_per_page = 10 %> +<% vms_per_page = 40 unless (defined? vms_per_page) and !(vms_per_page.nil?) %> +<% if (pool.nil? or + ((pool.is_a? VmResourcePool) and (pool.vms.size > vms_per_page)) or + ((pool.is_a? SmartPool) and (pool.tagged_vms.size > vms_per_page))) + usepager = 'true' + else + usepager = 'false' + end %>
      > +
        > + > + > + > + > + > + > +
      > <% elsif controller.controller_name == "search" %> >
        > > diff --git a/src/app/views/layouts/_side_toolbar.rhtml b/src/app/views/layouts/_side_toolbar.rhtml > index 763f4a2..29ed542 100644 > --- a/src/app/views/layouts/_side_toolbar.rhtml > +++ b/src/app/views/layouts/_side_toolbar.rhtml > @@ -21,4 +21,9 @@ > <%= confirmation_dialog("conf_nav_delete_pool", "Are you sure?", "delete_#{pool[:type]=='HardwarePool' ? 'hw' : 'vm'}_pool(#{pool.id})") %> >
      > <% end -%> > +
      > + > + <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Smart Pool" %> > + > +
      >
      > diff --git a/src/app/views/layouts/_tree.rhtml b/src/app/views/layouts/_tree.rhtml > index eb15676..0e6e138 100644 > --- a/src/app/views/layouts/_tree.rhtml > +++ b/src/app/views/layouts/_tree.rhtml > @@ -12,12 +12,14 @@ > //animated: "normal", > url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", > hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", > - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" > + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", > + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" > }); > var tree_reload = { > url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", > hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", > - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" > + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", > + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" > } > $('#test-tree').everyTime(15000,function(){ > load(tree_reload, {}, this, this); > diff --git a/src/app/views/resources/show_vms.rhtml b/src/app/views/resources/show_vms.rhtml > index 857f56b..2895c6b 100644 > --- a/src/app/views/resources/show_vms.rhtml > +++ b/src/app/views/resources/show_vms.rhtml > @@ -70,6 +70,7 @@ >
      > <%= render :partial => "/vm/grid", :locals => { :table_id => "vms_grid", > :pool => @pool, > + :exclude_pool => nil, > :on_select => "vms_select", > :on_deselect => "load_widget_deselect", > :on_hover => "load_widget_hover", > diff --git a/src/app/views/smart_pools/_form.rhtml b/src/app/views/smart_pools/_form.rhtml > new file mode 100644 > index 0000000..2f2156a > --- /dev/null > +++ b/src/app/views/smart_pools/_form.rhtml > @@ -0,0 +1,6 @@ > +<%= error_messages_for 'vm_resource_pool' %> > + > + > +<%= text_field_with_label "Name", 'smart_pool', 'name' %> > + > + > diff --git a/src/app/views/smart_pools/_pools_grid.rhtml b/src/app/views/smart_pools/_pools_grid.rhtml > new file mode 100644 > index 0000000..a5f1a99 > --- /dev/null > +++ b/src/app/views/smart_pools/_pools_grid.rhtml > @@ -0,0 +1,39 @@ > +<% resources_per_page = 40 %> > +
      > +
      > + > +
      > +
      > + > diff --git a/src/app/views/smart_pools/add_pool_dialog.rhtml b/src/app/views/smart_pools/add_pool_dialog.rhtml > new file mode 100644 > index 0000000..0d8cea6 > --- /dev/null > +++ b/src/app/views/smart_pools/add_pool_dialog.rhtml > @@ -0,0 +1,52 @@ > +<%- content_for :title do -%> > + Add a Hardware or Virtual Machine Pool > +<%- end -%> > +<%- content_for :description do -%> > + Choose a Hardware or Virtual Machine Pool to add to this Smart Pool > +<%- end -%> > + > + > + > +
      > +
        > +
        > + > +
        > +
        > +
        > +
        Cancel
        > +
        > +
        > +
        > diff --git a/src/app/views/smart_pools/new.rhtml b/src/app/views/smart_pools/new.rhtml > new file mode 100644 > index 0000000..7d488af > --- /dev/null > +++ b/src/app/views/smart_pools/new.rhtml > @@ -0,0 +1,26 @@ > +<%- content_for :title do -%> > + <%= _("Add New Smart Pool") %> > +<%- end -%> > +<%- content_for :description do -%> > + Add a new Smart Pool. > +<%- end -%> > + > +
        > +
        > + <%= render :partial => 'form' %> > +
        > + <%= popup_footer("$('#smart_pool_form').submit()", "Create Smart Pool") %> > +
        > + > + > diff --git a/src/app/views/smart_pools/show.rhtml b/src/app/views/smart_pools/show.rhtml > new file mode 100644 > index 0000000..45b1753 > --- /dev/null > +++ b/src/app/views/smart_pools/show.rhtml > @@ -0,0 +1,17 @@ > +
        > + > +
        <%= image_tag "icon_hdwarepool.png", :style=>"vertical-align:middle;" %> <%= @pool.name %>


        > + > +
        <%= image_tag "icon_smry_res.png", :style=>"vertical-align:middle;" %> Resources

        > +
        > + What do we show here for Smart Pools? > +
        > + > +

        > +
        <%= image_tag "icon_smry_his.png", :style=>"vertical-align:middle;" %> History

        > + What do we show here for Smart Pools? > + > +
        <%= image_tag "icon_smry_perf.png", :style=>"vertical-align:middle;" %> Performance

        > + What do we show here for Smart Pools? > +
        > + > diff --git a/src/app/views/hardware/show_hosts.rhtml b/src/app/views/smart_pools/show_hosts.rhtml > similarity index 50% > copy from src/app/views/hardware/show_hosts.rhtml > copy to src/app/views/smart_pools/show_hosts.rhtml > index 31c575d..706c84f 100644 > --- a/src/app/views/hardware/show_hosts.rhtml > +++ b/src/app/views/smart_pools/show_hosts.rhtml > @@ -1,89 +1,77 @@ > > > > >
        > -<% if @pool.hosts.size != 0 %> > +<% if @pool.tagged_hosts.size != 0 %> >
        > - <%= render :partial => "/host/grid", :locals => { :table_id => "hosts_grid", > + <%= render :partial => "/host/grid", :locals => { :table_id => "smart_hosts_grid", > :hwpool => @pool, > + :pool_controller => "smart_pools", > :exclude_pool => nil, > :exclude_host => nil, > - :show_pool => false, > + :show_pool => true, > :checkboxes => true, > - :on_select => "hosts_select", > + :on_select => "smart_hosts_select", > :on_deselect => "load_widget_deselect", > :on_hover => "load_widget_hover", > :on_unhover => "load_widget_unhover", > :is_popup => false, > :hosts_per_page => 40} %> >
        > -
        > -
        > -
        Select a host above.
        > -
        > +
        > +
        > +
        Select a host above.
        > +
        >
        > <% else %> >
        >
        > <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > - > + >
        > No hosts found in this pool.

        > <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   > - Add first host to this hardware pool > + Add first host to this smart pool >
        >
        >
        > diff --git a/src/app/views/smart_pools/show_pools.rhtml b/src/app/views/smart_pools/show_pools.rhtml > new file mode 100644 > index 0000000..f9d4b19 > --- /dev/null > +++ b/src/app/views/smart_pools/show_pools.rhtml > @@ -0,0 +1,74 @@ > + > + > + > + > +
        > +<% if @pool.tagged_pools.size != 0 %> > +
        > + <%= render :partial => "/smart_pools/pools_grid", :locals => { :table_id => "smart_pools_grid", > + :pool => @pool, > + :pool_controller => "smart_pools", > + :checkboxes => true, > + :on_select => "smart_pools_select", > + :on_deselect => false, > + :on_hover => false, > + :on_unhover => false} %> > +
        > +
        > +
        > +
        Select a pool above.
        > +
        > +
        > +<% else %> > +
        > +
        > + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > + > +
        > + No pools found in this pool.

        > + <%= image_tag "icon_addpool.png", :style=>"vertical-align:middle;" %>   > + Add first Pool to this smart pool > +
        > +
        > +
        > +<% end %> > diff --git a/src/app/views/smart_pools/show_storage.rhtml b/src/app/views/smart_pools/show_storage.rhtml > new file mode 100644 > index 0000000..89e5e14 > --- /dev/null > +++ b/src/app/views/smart_pools/show_storage.rhtml > @@ -0,0 +1,72 @@ > + > + > + > +
        > +<% if @pool.tagged_storage_pools.size != 0 %> > +
        > + <%= render :partial => "/storage/grid", :locals => { :table_id => "smart_storage_grid", > + :hwpool => @pool, > + :pool_controller => "smart_pools", > + :exclude_pool => nil, > + :on_select => "smart_storage_select", > + :is_popup => false} %> > +
        > + > +
        > +
        > +
        Select a storage pool.
        > +
        > +
        > +<% else %> > +
        > +
        > + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > + > +
        > + No storage Pools found in this pool.

        > + <%= image_tag "icon_addstorage.png", :style=>"vertical-align:middle;" %>   > + Add first storage volume to this smart pool > +
        > +
        > +
        > +<% end %> > diff --git a/src/app/views/smart_pools/show_users.rhtml b/src/app/views/smart_pools/show_users.rhtml > new file mode 100644 > index 0000000..7d1efb8 > --- /dev/null > +++ b/src/app/views/smart_pools/show_users.rhtml > @@ -0,0 +1,2 @@ > + <%= render :partial => "/user/show", :locals => { :parent_controller => "smart_pools", > + :pool => @pool } %> > diff --git a/src/app/views/smart_pools/show_vms.rhtml b/src/app/views/smart_pools/show_vms.rhtml > new file mode 100644 > index 0000000..990e4ab > --- /dev/null > +++ b/src/app/views/smart_pools/show_vms.rhtml > @@ -0,0 +1,77 @@ > + > + > + > + > +
        > +<% if @pool.tagged_vms.size != 0 %> > +
        > + <%= render :partial => "/vm/grid", :locals => { :table_id => "smart_vms_grid", > + :pool => @pool, > + :pool_controller => "smart_pools", > + :exclude_pool => nil, > + :show_pool => true, > + :checkboxes => true, > + :on_select => "smart_vms_select", > + :on_deselect => "load_widget_deselect", > + :on_hover => "load_widget_hover", > + :on_unhover => "load_widget_unhover", > + :is_popup => false, > + :vms_per_page => 40} %> > +
        > +
        > +
        > +
        Select a vm above.
        > +
        > +
        > +<% else %> > +
        > +
        > + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > + > +
        > + No vms found in this pool.

        > + <%= image_tag "icon_addvm.png", :style=>"vertical-align:middle;" %>   > + Add first VM to this smart pool > +
        > +
        > +
        > +<% end %> > diff --git a/src/app/views/storage/_grid.rhtml b/src/app/views/storage/_grid.rhtml > index c36f4d3..21ca109 100644 > --- a/src/app/views/storage/_grid.rhtml > +++ b/src/app/views/storage/_grid.rhtml > @@ -1,4 +1,11 @@ > -<% storage_per_page = 40 %> > +<% storage_per_page = 40 unless (defined? storage_per_page) and !(storage_per_page.nil?) %> > +<% if (hwpool.nil? or > + ((hwpool.is_a? HardwarePool) and (hwpool.storage_pools.size > storage_per_page)) or > + ((hwpool.is_a? SmartPool) and (hwpool.tagged_storage_pools.size > storage_per_page))) > + usepager = 'true' > + else > + usepager = 'false' > + end %> > >
        >
        > @@ -9,7 +16,11 @@ > $("#<%= table_id %>").flexigrid > ( > { > - url: '<%= url_for :controller => "hardware", :action => "storage_pools_json", :id => (hwpool.nil? ? nil : hwpool.id), :exclude_pool => exclude_pool %>', > + url: '<%= url_for :controller => (defined? pool_controller) ? > + pool_controller : "hardware", > + :action => "storage_pools_json", > + :id => (hwpool.nil? ? nil : hwpool.id), > + :exclude_pool => exclude_pool %>', > dataType: 'json', > <% if is_popup %> > width: 700, > @@ -23,8 +34,8 @@ > ], > sortname: "ip_addr", > sortorder: "asc", > - usepager: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, > - useRp: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, > + usepager: <%= usepager %>, > + useRp: <%= usepager %>, > rp: <%= storage_per_page %>, > showTableToggleBtn: true, > onSelect: <%= on_select %> > diff --git a/src/app/views/storage/add_to_smart_pool.rhtml b/src/app/views/storage/add_to_smart_pool.rhtml > new file mode 100644 > index 0000000..2eedae3 > --- /dev/null > +++ b/src/app/views/storage/add_to_smart_pool.rhtml > @@ -0,0 +1,22 @@ > +<%- content_for :title do -%> > + <%= _("Add Storage Pool to Smart Pool") %> > +<%- end -%> > +<%- content_for :description do -%> > + Select storage pools from the list below to add to the <%= @pool.name %> smart pool. > +<%- end -%> > +
        > +
        > +
        > + <%= render :partial => "/storage/grid", :locals => { :table_id => "add_smart_storage_grid", > + :hwpool => nil, > + :pool_controller => "smart_pools", > + :exclude_pool => @pool.id, > + :on_select => false, > + :is_popup => true} %> > +
        > + > +<%= popup_footer("add_storage_to_smart_pool('#{url_for :controller => "smart_pools", > + :action => "add_storage", > + :id => @pool}')", > + "Add Storage Pools") %> > +
        > diff --git a/src/app/views/vm/_grid.rhtml b/src/app/views/vm/_grid.rhtml > index c56e6b8..a538824 100644 > --- a/src/app/views/vm/_grid.rhtml > +++ b/src/app/views/vm/_grid.rhtml > @@ -1,42 +1,56 @@ > <%= render :partial => 'graph/load_graph.rhtml' %> > -<% vms_per_page = 10 %> > +<% vms_per_page = 40 unless (defined? vms_per_page) and !(vms_per_page.nil?) %> > +<% if (pool.nil? or > + ((pool.is_a? VmResourcePool) and (pool.vms.size > vms_per_page)) or > + ((pool.is_a? SmartPool) and (pool.tagged_vms.size > vms_per_page))) > + usepager = 'true' > + else > + usepager = 'false' > + end %> >
        > > > >
        > @@ -63,7 +63,7 @@ :exclude_host => nil, :show_pool => false, :checkboxes => true, - :on_select => "hosts_select", + :on_select => "hosts_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", :on_unhover => "load_widget_unhover", @@ -79,7 +79,7 @@
        <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> - +
        No hosts found in this pool.

        <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   diff --git a/src/app/views/hardware/show_storage.rhtml b/src/app/views/hardware/show_storage.rhtml index 564b9ed..6466f9b 100644 --- a/src/app/views/hardware/show_storage.rhtml +++ b/src/app/views/hardware/show_storage.rhtml @@ -15,7 +15,7 @@ +
          + + + + + + +
        <% elsif controller.controller_name == "search" %>
          diff --git a/src/app/views/layouts/_side_toolbar.rhtml b/src/app/views/layouts/_side_toolbar.rhtml index 763f4a2..e1958f1 100644 --- a/src/app/views/layouts/_side_toolbar.rhtml +++ b/src/app/views/layouts/_side_toolbar.rhtml @@ -1,24 +1,41 @@ <% pool = @current_pool_id ? Pool.find(@current_pool_id) : nil %> +<% if pool and pool[:type]=="HardwarePool" + delete_url = url_for(:controller => "hardware", :action => "destroy") + elsif pool and pool[:type]=="VmResourcePool" + delete_url = url_for(:controller => "resources", :action => "destroy") + elsif pool and pool[:type]=="SmartPool" + delete_url = url_for(:controller => "smart_pools", :action => "destroy") + else + delete_url = "" + end %> + <%if pool -%> -<%if pool[:type]=="HardwarePool" -%> -
          - - <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Hardware Pool" %> - -
          + <%if pool[:type]=="HardwarePool" -%> +
          + + <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Hardware Pool" %> + +
          +
          + + <%= image_tag "icon_add_vmpool.png", :title=>"Add Virtual Machine Pool" %> + +
          + <% end -%> +<% end -%>
          - - <%= image_tag "icon_add_vmpool.png", :title=>"Add Virtual Machine Pool" %> + + <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Smart Pool" %>
          -<% end -%> -
          +<%if pool -%> +
          <%= image_tag "icon_delete.gif", :title=>"Delete Selected Pool" %> -
          - +
          + <% end -%>
          diff --git a/src/app/views/layouts/_tree.rhtml b/src/app/views/layouts/_tree.rhtml index eb15676..0e6e138 100644 --- a/src/app/views/layouts/_tree.rhtml +++ b/src/app/views/layouts/_tree.rhtml @@ -12,12 +12,14 @@ //animated: "normal", url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" }); var tree_reload = { url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" } $('#test-tree').everyTime(15000,function(){ load(tree_reload, {}, this, this); diff --git a/src/app/views/layouts/redux.rhtml b/src/app/views/layouts/redux.rhtml index d6cfe24..01540d4 100644 --- a/src/app/views/layouts/redux.rhtml +++ b/src/app/views/layouts/redux.rhtml @@ -90,32 +90,6 @@ }); return false;})},function(){}); }); - - function delete_vm_pool(id, parent) - { - $(document).trigger('close.facebox'); - $.post('<%= url_for :controller => "resources", :action => "destroy" %>', - {id: id}, - function(data,status){ - // need to redirect to the parent using the new ajax reload stuff - $("#vmpools_grid").flexReload(); - if (data.alert) { - $.jGrowl(data.alert); - } - }, 'json'); - } - function delete_hw_pool(id, parent) - { - $(document).trigger('close.facebox'); - $.post('<%= url_for :controller => "hardware", :action => "destroy" %>', - {id: id}, - function(data,status){ - // need to redirect to the parent using the new ajax reload stuff - if (data.alert) { - $.jGrowl(data.alert); - } - }, 'json'); - } <%= yield :scripts -%> diff --git a/src/app/views/resources/show_vms.rhtml b/src/app/views/resources/show_vms.rhtml index 857f56b..beca048 100644 --- a/src/app/views/resources/show_vms.rhtml +++ b/src/app/views/resources/show_vms.rhtml @@ -26,7 +26,7 @@ } function delete_vms() { - vms = get_selected_vms() + var vms = get_selected_vms(); if (validate_selected(vms, "vm")) { $.post('<%= url_for :controller => "vm", :action => "delete", :id => @pool %>', { vm_ids: vms.toString() }, @@ -43,7 +43,7 @@ } function vm_actions(action) { - vms = get_selected_vms() + var vms = get_selected_vms(); if (validate_selected(vms, "vm")) { jQuery.facebox('
          '); $('#vm_action_results').load('<%= url_for :controller => "resources", @@ -70,10 +70,12 @@
          <%= render :partial => "/vm/grid", :locals => { :table_id => "vms_grid", :pool => @pool, + :exclude_pool => nil, :on_select => "vms_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", - :on_unhover => "load_widget_unhover" } %> + :on_unhover => "load_widget_unhover", + :is_popup => false } %>
          diff --git a/src/app/views/smart_pools/_form.rhtml b/src/app/views/smart_pools/_form.rhtml new file mode 100644 index 0000000..2f2156a --- /dev/null +++ b/src/app/views/smart_pools/_form.rhtml @@ -0,0 +1,6 @@ +<%= error_messages_for 'vm_resource_pool' %> + + +<%= text_field_with_label "Name", 'smart_pool', 'name' %> + + diff --git a/src/app/views/smart_pools/_pools_grid.rhtml b/src/app/views/smart_pools/_pools_grid.rhtml new file mode 100644 index 0000000..a5f1a99 --- /dev/null +++ b/src/app/views/smart_pools/_pools_grid.rhtml @@ -0,0 +1,39 @@ +<% resources_per_page = 40 %> +
          +
          + +
          +
          + diff --git a/src/app/views/smart_pools/add_pool_dialog.rhtml b/src/app/views/smart_pools/add_pool_dialog.rhtml new file mode 100644 index 0000000..0d8cea6 --- /dev/null +++ b/src/app/views/smart_pools/add_pool_dialog.rhtml @@ -0,0 +1,52 @@ +<%- content_for :title do -%> + Add a Hardware or Virtual Machine Pool +<%- end -%> +<%- content_for :description do -%> + Choose a Hardware or Virtual Machine Pool to add to this Smart Pool +<%- end -%> + + + +
          +
            +
            + +
            +
            +
            +
            Cancel
            +
            +
            +
            diff --git a/src/app/views/smart_pools/new.rhtml b/src/app/views/smart_pools/new.rhtml new file mode 100644 index 0000000..7d488af --- /dev/null +++ b/src/app/views/smart_pools/new.rhtml @@ -0,0 +1,26 @@ +<%- content_for :title do -%> + <%= _("Add New Smart Pool") %> +<%- end -%> +<%- content_for :description do -%> + Add a new Smart Pool. +<%- end -%> + +
            +
            + <%= render :partial => 'form' %> +
            + <%= popup_footer("$('#smart_pool_form').submit()", "Create Smart Pool") %> +
            + + diff --git a/src/app/views/smart_pools/show.rhtml b/src/app/views/smart_pools/show.rhtml new file mode 100644 index 0000000..45b1753 --- /dev/null +++ b/src/app/views/smart_pools/show.rhtml @@ -0,0 +1,17 @@ +
            + +
            <%= image_tag "icon_hdwarepool.png", :style=>"vertical-align:middle;" %> <%= @pool.name %>


            + +
            <%= image_tag "icon_smry_res.png", :style=>"vertical-align:middle;" %> Resources

            +
            + What do we show here for Smart Pools? +
            + +

            +
            <%= image_tag "icon_smry_his.png", :style=>"vertical-align:middle;" %> History

            + What do we show here for Smart Pools? + +
            <%= image_tag "icon_smry_perf.png", :style=>"vertical-align:middle;" %> Performance

            + What do we show here for Smart Pools? +
            + diff --git a/src/app/views/hardware/show_hosts.rhtml b/src/app/views/smart_pools/show_hosts.rhtml similarity index 50% copy from src/app/views/hardware/show_hosts.rhtml copy to src/app/views/smart_pools/show_hosts.rhtml index 31c575d..a4b6be7 100644 --- a/src/app/views/hardware/show_hosts.rhtml +++ b/src/app/views/smart_pools/show_hosts.rhtml @@ -1,89 +1,77 @@
            -<% if @pool.hosts.size != 0 %> +<% if @pool.tagged_hosts.size != 0 %>
            - <%= render :partial => "/host/grid", :locals => { :table_id => "hosts_grid", + <%= render :partial => "/host/grid", :locals => { :table_id => "smart_hosts_grid", :hwpool => @pool, + :pool_controller => "smart_pools", :exclude_pool => nil, :exclude_host => nil, - :show_pool => false, + :show_pool => true, :checkboxes => true, - :on_select => "hosts_select", + :on_select => "smart_hosts_select", :on_deselect => "load_widget_deselect", :on_hover => "load_widget_hover", :on_unhover => "load_widget_unhover", :is_popup => false, :hosts_per_page => 40} %>
            -
            -
            -
            Select a host above.
            -
            +
            +
            +
            Select a host above.
            +
            <% else %>
            <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> - +
            No hosts found in this pool.

            <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   - Add first host to this hardware pool + Add first host to this smart pool
            diff --git a/src/app/views/smart_pools/show_pools.rhtml b/src/app/views/smart_pools/show_pools.rhtml new file mode 100644 index 0000000..8e89701 --- /dev/null +++ b/src/app/views/smart_pools/show_pools.rhtml @@ -0,0 +1,74 @@ + + + + +
            +<% if @pool.tagged_pools.size != 0 %> +
            + <%= render :partial => "/smart_pools/pools_grid", :locals => { :table_id => "smart_pools_grid", + :pool => @pool, + :pool_controller => "smart_pools", + :checkboxes => true, + :on_select => "smart_pools_select", + :on_deselect => false, + :on_hover => false, + :on_unhover => false} %> +
            +
            +
            +
            Select a pool above.
            +
            +
            +<% else %> +
            +
            + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> + +
            + No pools found in this pool.

            + <%= image_tag "icon_addpool.png", :style=>"vertical-align:middle;" %>   + Add first Pool to this smart pool +
            +
            +
            +<% end %> diff --git a/src/app/views/smart_pools/show_storage.rhtml b/src/app/views/smart_pools/show_storage.rhtml new file mode 100644 index 0000000..7cf425a --- /dev/null +++ b/src/app/views/smart_pools/show_storage.rhtml @@ -0,0 +1,72 @@ + + + +
            +<% if @pool.tagged_storage_pools.size != 0 %> +
            + <%= render :partial => "/storage/grid", :locals => { :table_id => "smart_storage_grid", + :hwpool => @pool, + :pool_controller => "smart_pools", + :exclude_pool => nil, + :on_select => "smart_storage_select", + :is_popup => false} %> +
            + +
            +
            +
            Select a storage pool.
            +
            +
            +<% else %> +
            +
            + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> + +
            + No storage Pools found in this pool.

            + <%= image_tag "icon_addstorage.png", :style=>"vertical-align:middle;" %>   + Add first storage volume to this smart pool +
            +
            +
            +<% end %> diff --git a/src/app/views/smart_pools/show_users.rhtml b/src/app/views/smart_pools/show_users.rhtml new file mode 100644 index 0000000..7d1efb8 --- /dev/null +++ b/src/app/views/smart_pools/show_users.rhtml @@ -0,0 +1,2 @@ + <%= render :partial => "/user/show", :locals => { :parent_controller => "smart_pools", + :pool => @pool } %> diff --git a/src/app/views/smart_pools/show_vms.rhtml b/src/app/views/smart_pools/show_vms.rhtml new file mode 100644 index 0000000..e56600b --- /dev/null +++ b/src/app/views/smart_pools/show_vms.rhtml @@ -0,0 +1,77 @@ + + + + +
            +<% if @pool.tagged_vms.size != 0 %> +
            + <%= render :partial => "/vm/grid", :locals => { :table_id => "smart_vms_grid", + :pool => @pool, + :pool_controller => "smart_pools", + :exclude_pool => nil, + :show_pool => true, + :checkboxes => true, + :on_select => "smart_vms_select", + :on_deselect => "load_widget_deselect", + :on_hover => "load_widget_hover", + :on_unhover => "load_widget_unhover", + :is_popup => false, + :vms_per_page => 40} %> +
            +
            +
            +
            Select a vm above.
            +
            +
            +<% else %> +
            +
            + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> + +
            + No vms found in this pool.

            + <%= image_tag "icon_addvm.png", :style=>"vertical-align:middle;" %>   + Add first VM to this smart pool +
            +
            +
            +<% end %> diff --git a/src/app/views/storage/_grid.rhtml b/src/app/views/storage/_grid.rhtml index c36f4d3..c8876bb 100644 --- a/src/app/views/storage/_grid.rhtml +++ b/src/app/views/storage/_grid.rhtml @@ -1,4 +1,12 @@ -<% storage_per_page = 40 %> +<% storage_per_page = 40 unless (defined? storage_per_page) and !(storage_per_page.nil?) %> +<% pool_controller = 'hardware' unless (defined? pool_controller) and !(pool_controller.nil?) %> +<% if (hwpool.nil? or + ((hwpool.is_a? HardwarePool) and (hwpool.storage_pools.size > storage_per_page)) or + ((hwpool.is_a? SmartPool) and (hwpool.tagged_storage_pools.size > storage_per_page))) + usepager = 'true' + else + usepager = 'false' + end %>
            @@ -9,7 +17,10 @@ $("#<%= table_id %>").flexigrid ( { - url: '<%= url_for :controller => "hardware", :action => "storage_pools_json", :id => (hwpool.nil? ? nil : hwpool.id), :exclude_pool => exclude_pool %>', + url: '<%= url_for :controller => pool_controller, + :action => "storage_pools_json", + :id => (hwpool.nil? ? nil : hwpool.id), + :exclude_pool => exclude_pool %>', dataType: 'json', <% if is_popup %> width: 700, @@ -23,8 +34,8 @@ ], sortname: "ip_addr", sortorder: "asc", - usepager: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, - useRp: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, + usepager: <%= usepager %>, + useRp: <%= usepager %>, rp: <%= storage_per_page %>, showTableToggleBtn: true, onSelect: <%= on_select %> diff --git a/src/app/views/storage/add_to_smart_pool.rhtml b/src/app/views/storage/add_to_smart_pool.rhtml new file mode 100644 index 0000000..2eedae3 --- /dev/null +++ b/src/app/views/storage/add_to_smart_pool.rhtml @@ -0,0 +1,22 @@ +<%- content_for :title do -%> + <%= _("Add Storage Pool to Smart Pool") %> +<%- end -%> +<%- content_for :description do -%> + Select storage pools from the list below to add to the <%= @pool.name %> smart pool. +<%- end -%> +
            +
            +
            + <%= render :partial => "/storage/grid", :locals => { :table_id => "add_smart_storage_grid", + :hwpool => nil, + :pool_controller => "smart_pools", + :exclude_pool => @pool.id, + :on_select => false, + :is_popup => true} %> +
            + +<%= popup_footer("add_storage_to_smart_pool('#{url_for :controller => "smart_pools", + :action => "add_storage", + :id => @pool}')", + "Add Storage Pools") %> +
            diff --git a/src/app/views/user/_show.rhtml b/src/app/views/user/_show.rhtml index 916afe8..5b3ffb7 100644 --- a/src/app/views/user/_show.rhtml +++ b/src/app/views/user/_show.rhtml @@ -12,7 +12,7 @@ } function delete_users() { - permissions = get_selected_users(); + var permissions = get_selected_users(); if (validate_selected(permissions, "user")) { $.post('<%= url_for :controller => "permission", :action => "delete", :id => pool.id %>', { permission_ids: permissions.toString() }, @@ -26,7 +26,7 @@ } function update_users(role) { - permissions = get_selected_users() + var permissions = get_selected_users(); if (validate_selected(permissions, "users")) { $.post('<%= url_for :controller => "permission", :action => "update_roles" %>', { permission_ids: permissions.toString(), user_role: role }, diff --git a/src/app/views/vm/_grid.rhtml b/src/app/views/vm/_grid.rhtml index c56e6b8..a322ea3 100644 --- a/src/app/views/vm/_grid.rhtml +++ b/src/app/views/vm/_grid.rhtml @@ -1,42 +1,56 @@ <%= render :partial => 'graph/load_graph.rhtml' %> -<% vms_per_page = 10 %> +<% pool_controller = 'resources' unless (defined? pool_controller) and !(pool_controller.nil?) %> +<% vms_per_page = 40 unless (defined? vms_per_page) and !(vms_per_page.nil?) %> +<% if (pool.nil? or + ((pool.is_a? VmResourcePool) and (pool.vms.size > vms_per_page)) or + ((pool.is_a? SmartPool) and (pool.tagged_vms.size > vms_per_page))) + usepager = 'true' + else + usepager = 'false' + end %>
            > @@ -63,7 +63,7 @@ > :exclude_host => nil, > :show_pool => false, > :checkboxes => true, > - :on_select => "hosts_select", > + :on_select => "hosts_select", > :on_deselect => "load_widget_deselect", > :on_hover => "load_widget_hover", > :on_unhover => "load_widget_unhover", > @@ -79,7 +79,7 @@ >
            >
            > <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > - > + >
            > No hosts found in this pool.

            > <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   > diff --git a/src/app/views/hardware/show_storage.rhtml b/src/app/views/hardware/show_storage.rhtml > index 564b9ed..6466f9b 100644 > --- a/src/app/views/hardware/show_storage.rhtml > +++ b/src/app/views/hardware/show_storage.rhtml > @@ -15,7 +15,7 @@ > > +
              > + > + > + > + > + > + > +
            > <% elsif controller.controller_name == "search" %> >
              > > diff --git a/src/app/views/layouts/_side_toolbar.rhtml b/src/app/views/layouts/_side_toolbar.rhtml > index 763f4a2..e1958f1 100644 > --- a/src/app/views/layouts/_side_toolbar.rhtml > +++ b/src/app/views/layouts/_side_toolbar.rhtml > @@ -1,24 +1,41 @@ > <% pool = @current_pool_id ? Pool.find(@current_pool_id) : nil %> > +<% if pool and pool[:type]=="HardwarePool" > + delete_url = url_for(:controller => "hardware", :action => "destroy") > + elsif pool and pool[:type]=="VmResourcePool" > + delete_url = url_for(:controller => "resources", :action => "destroy") > + elsif pool and pool[:type]=="SmartPool" > + delete_url = url_for(:controller => "smart_pools", :action => "destroy") > + else > + delete_url = "" > + end %> > + > <%if pool -%> > -<%if pool[:type]=="HardwarePool" -%> > -
              > - > - <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Hardware Pool" %> > - > -
              > + <%if pool[:type]=="HardwarePool" -%> > +
              > + > + <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Hardware Pool" %> > + > +
              > +
              > + > + <%= image_tag "icon_add_vmpool.png", :title=>"Add Virtual Machine Pool" %> > + > +
              > + <% end -%> > +<% end -%> >
              > - > - <%= image_tag "icon_add_vmpool.png", :title=>"Add Virtual Machine Pool" %> > + > + <%=image_tag "icon_add_hardwarepool.png", :title=>"Add Smart Pool" %> > >
              > -<% end -%> > -
              > +<%if pool -%> > +
              > > <%= image_tag "icon_delete.gif", :title=>"Delete Selected Pool" %> > > -
              > - > +
              > + > <% end -%> >
              > diff --git a/src/app/views/layouts/_tree.rhtml b/src/app/views/layouts/_tree.rhtml > index eb15676..0e6e138 100644 > --- a/src/app/views/layouts/_tree.rhtml > +++ b/src/app/views/layouts/_tree.rhtml > @@ -12,12 +12,14 @@ > //animated: "normal", > url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", > hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", > - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" > + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", > + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" > }); > var tree_reload = { > url: "<%= url_for :controller =>'/tree', :action => 'fetch_json' %>", > hardware_url: "<%= url_for :controller =>'/hardware', :action => 'show' %>", > - resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>" > + resource_url: "<%= url_for :controller =>'/resources', :action => 'show' %>", > + smart_url: "<%= url_for :controller =>'/smart_pools', :action => 'show' %>" > } > $('#test-tree').everyTime(15000,function(){ > load(tree_reload, {}, this, this); > diff --git a/src/app/views/layouts/redux.rhtml b/src/app/views/layouts/redux.rhtml > index d6cfe24..01540d4 100644 > --- a/src/app/views/layouts/redux.rhtml > +++ b/src/app/views/layouts/redux.rhtml > @@ -90,32 +90,6 @@ > }); > return false;})},function(){}); > }); > - > - function delete_vm_pool(id, parent) > - { > - $(document).trigger('close.facebox'); > - $.post('<%= url_for :controller => "resources", :action => "destroy" %>', > - {id: id}, > - function(data,status){ > - // need to redirect to the parent using the new ajax reload stuff > - $("#vmpools_grid").flexReload(); > - if (data.alert) { > - $.jGrowl(data.alert); > - } > - }, 'json'); > - } > - function delete_hw_pool(id, parent) > - { > - $(document).trigger('close.facebox'); > - $.post('<%= url_for :controller => "hardware", :action => "destroy" %>', > - {id: id}, > - function(data,status){ > - // need to redirect to the parent using the new ajax reload stuff > - if (data.alert) { > - $.jGrowl(data.alert); > - } > - }, 'json'); > - } > > <%= yield :scripts -%> > > diff --git a/src/app/views/resources/show_vms.rhtml b/src/app/views/resources/show_vms.rhtml > index 857f56b..beca048 100644 > --- a/src/app/views/resources/show_vms.rhtml > +++ b/src/app/views/resources/show_vms.rhtml > @@ -26,7 +26,7 @@ > } > function delete_vms() > { > - vms = get_selected_vms() > + var vms = get_selected_vms(); > if (validate_selected(vms, "vm")) { > $.post('<%= url_for :controller => "vm", :action => "delete", :id => @pool %>', > { vm_ids: vms.toString() }, > @@ -43,7 +43,7 @@ > } > function vm_actions(action) > { > - vms = get_selected_vms() > + var vms = get_selected_vms(); > if (validate_selected(vms, "vm")) { > jQuery.facebox('
              '); > $('#vm_action_results').load('<%= url_for :controller => "resources", > @@ -70,10 +70,12 @@ >
              > <%= render :partial => "/vm/grid", :locals => { :table_id => "vms_grid", > :pool => @pool, > + :exclude_pool => nil, > :on_select => "vms_select", > :on_deselect => "load_widget_deselect", > :on_hover => "load_widget_hover", > - :on_unhover => "load_widget_unhover" } %> > + :on_unhover => "load_widget_unhover", > + :is_popup => false } %> >
              >
              >
              > diff --git a/src/app/views/smart_pools/_form.rhtml b/src/app/views/smart_pools/_form.rhtml > new file mode 100644 > index 0000000..2f2156a > --- /dev/null > +++ b/src/app/views/smart_pools/_form.rhtml > @@ -0,0 +1,6 @@ > +<%= error_messages_for 'vm_resource_pool' %> > + > + > +<%= text_field_with_label "Name", 'smart_pool', 'name' %> > + > + > diff --git a/src/app/views/smart_pools/_pools_grid.rhtml b/src/app/views/smart_pools/_pools_grid.rhtml > new file mode 100644 > index 0000000..a5f1a99 > --- /dev/null > +++ b/src/app/views/smart_pools/_pools_grid.rhtml > @@ -0,0 +1,39 @@ > +<% resources_per_page = 40 %> > +
              > +
              > + > +
              > +
              > + > diff --git a/src/app/views/smart_pools/add_pool_dialog.rhtml b/src/app/views/smart_pools/add_pool_dialog.rhtml > new file mode 100644 > index 0000000..0d8cea6 > --- /dev/null > +++ b/src/app/views/smart_pools/add_pool_dialog.rhtml > @@ -0,0 +1,52 @@ > +<%- content_for :title do -%> > + Add a Hardware or Virtual Machine Pool > +<%- end -%> > +<%- content_for :description do -%> > + Choose a Hardware or Virtual Machine Pool to add to this Smart Pool > +<%- end -%> > + > + > + > +
              > +
                > +
                > + > +
                > +
                > +
                > +
                Cancel
                > +
                > +
                > +
                > diff --git a/src/app/views/smart_pools/new.rhtml b/src/app/views/smart_pools/new.rhtml > new file mode 100644 > index 0000000..7d488af > --- /dev/null > +++ b/src/app/views/smart_pools/new.rhtml > @@ -0,0 +1,26 @@ > +<%- content_for :title do -%> > + <%= _("Add New Smart Pool") %> > +<%- end -%> > +<%- content_for :description do -%> > + Add a new Smart Pool. > +<%- end -%> > + > +
                > +
                > + <%= render :partial => 'form' %> > +
                > + <%= popup_footer("$('#smart_pool_form').submit()", "Create Smart Pool") %> > +
                > + > + > diff --git a/src/app/views/smart_pools/show.rhtml b/src/app/views/smart_pools/show.rhtml > new file mode 100644 > index 0000000..45b1753 > --- /dev/null > +++ b/src/app/views/smart_pools/show.rhtml > @@ -0,0 +1,17 @@ > +
                > + > +
                <%= image_tag "icon_hdwarepool.png", :style=>"vertical-align:middle;" %> <%= @pool.name %>


                > + > +
                <%= image_tag "icon_smry_res.png", :style=>"vertical-align:middle;" %> Resources

                > +
                > + What do we show here for Smart Pools? > +
                > + > +

                > +
                <%= image_tag "icon_smry_his.png", :style=>"vertical-align:middle;" %> History

                > + What do we show here for Smart Pools? > + > +
                <%= image_tag "icon_smry_perf.png", :style=>"vertical-align:middle;" %> Performance

                > + What do we show here for Smart Pools? > +
                > + > diff --git a/src/app/views/hardware/show_hosts.rhtml b/src/app/views/smart_pools/show_hosts.rhtml > similarity index 50% > copy from src/app/views/hardware/show_hosts.rhtml > copy to src/app/views/smart_pools/show_hosts.rhtml > index 31c575d..a4b6be7 100644 > --- a/src/app/views/hardware/show_hosts.rhtml > +++ b/src/app/views/smart_pools/show_hosts.rhtml > @@ -1,89 +1,77 @@ > > > > >
                > -<% if @pool.hosts.size != 0 %> > +<% if @pool.tagged_hosts.size != 0 %> >
                > - <%= render :partial => "/host/grid", :locals => { :table_id => "hosts_grid", > + <%= render :partial => "/host/grid", :locals => { :table_id => "smart_hosts_grid", > :hwpool => @pool, > + :pool_controller => "smart_pools", > :exclude_pool => nil, > :exclude_host => nil, > - :show_pool => false, > + :show_pool => true, > :checkboxes => true, > - :on_select => "hosts_select", > + :on_select => "smart_hosts_select", > :on_deselect => "load_widget_deselect", > :on_hover => "load_widget_hover", > :on_unhover => "load_widget_unhover", > :is_popup => false, > :hosts_per_page => 40} %> >
                > -
                > -
                > -
                Select a host above.
                > -
                > +
                > +
                > +
                Select a host above.
                > +
                >
                > <% else %> >
                >
                > <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > - > + >
                > No hosts found in this pool.

                > <%= image_tag "icon_addhost.png", :style=>"vertical-align:middle;" %>   > - Add first host to this hardware pool > + Add first host to this smart pool >
                >
                >
                > diff --git a/src/app/views/smart_pools/show_pools.rhtml b/src/app/views/smart_pools/show_pools.rhtml > new file mode 100644 > index 0000000..8e89701 > --- /dev/null > +++ b/src/app/views/smart_pools/show_pools.rhtml > @@ -0,0 +1,74 @@ > + > + > + > + > +
                > +<% if @pool.tagged_pools.size != 0 %> > +
                > + <%= render :partial => "/smart_pools/pools_grid", :locals => { :table_id => "smart_pools_grid", > + :pool => @pool, > + :pool_controller => "smart_pools", > + :checkboxes => true, > + :on_select => "smart_pools_select", > + :on_deselect => false, > + :on_hover => false, > + :on_unhover => false} %> > +
                > +
                > +
                > +
                Select a pool above.
                > +
                > +
                > +<% else %> > +
                > +
                > + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > + > +
                > + No pools found in this pool.

                > + <%= image_tag "icon_addpool.png", :style=>"vertical-align:middle;" %>   > + Add first Pool to this smart pool > +
                > +
                > +
                > +<% end %> > diff --git a/src/app/views/smart_pools/show_storage.rhtml b/src/app/views/smart_pools/show_storage.rhtml > new file mode 100644 > index 0000000..7cf425a > --- /dev/null > +++ b/src/app/views/smart_pools/show_storage.rhtml > @@ -0,0 +1,72 @@ > + > + > + > +
                > +<% if @pool.tagged_storage_pools.size != 0 %> > +
                > + <%= render :partial => "/storage/grid", :locals => { :table_id => "smart_storage_grid", > + :hwpool => @pool, > + :pool_controller => "smart_pools", > + :exclude_pool => nil, > + :on_select => "smart_storage_select", > + :is_popup => false} %> > +
                > + > +
                > +
                > +
                Select a storage pool.
                > +
                > +
                > +<% else %> > +
                > +
                > + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > + > +
                > + No storage Pools found in this pool.

                > + <%= image_tag "icon_addstorage.png", :style=>"vertical-align:middle;" %>   > + Add first storage volume to this smart pool > +
                > +
                > +
                > +<% end %> > diff --git a/src/app/views/smart_pools/show_users.rhtml b/src/app/views/smart_pools/show_users.rhtml > new file mode 100644 > index 0000000..7d1efb8 > --- /dev/null > +++ b/src/app/views/smart_pools/show_users.rhtml > @@ -0,0 +1,2 @@ > + <%= render :partial => "/user/show", :locals => { :parent_controller => "smart_pools", > + :pool => @pool } %> > diff --git a/src/app/views/smart_pools/show_vms.rhtml b/src/app/views/smart_pools/show_vms.rhtml > new file mode 100644 > index 0000000..e56600b > --- /dev/null > +++ b/src/app/views/smart_pools/show_vms.rhtml > @@ -0,0 +1,77 @@ > + > + > + > + > +
                > +<% if @pool.tagged_vms.size != 0 %> > +
                > + <%= render :partial => "/vm/grid", :locals => { :table_id => "smart_vms_grid", > + :pool => @pool, > + :pool_controller => "smart_pools", > + :exclude_pool => nil, > + :show_pool => true, > + :checkboxes => true, > + :on_select => "smart_vms_select", > + :on_deselect => "load_widget_deselect", > + :on_hover => "load_widget_hover", > + :on_unhover => "load_widget_unhover", > + :is_popup => false, > + :vms_per_page => 40} %> > +
                > +
                > +
                > +
                Select a vm above.
                > +
                > +
                > +<% else %> > +
                > +
                > + <%= image_tag 'no-grid-items.png', :style => 'float: left;' %> > + > +
                > + No vms found in this pool.

                > + <%= image_tag "icon_addvm.png", :style=>"vertical-align:middle;" %>   > + Add first VM to this smart pool > +
                > +
                > +
                > +<% end %> > diff --git a/src/app/views/storage/_grid.rhtml b/src/app/views/storage/_grid.rhtml > index c36f4d3..c8876bb 100644 > --- a/src/app/views/storage/_grid.rhtml > +++ b/src/app/views/storage/_grid.rhtml > @@ -1,4 +1,12 @@ > -<% storage_per_page = 40 %> > +<% storage_per_page = 40 unless (defined? storage_per_page) and !(storage_per_page.nil?) %> > +<% pool_controller = 'hardware' unless (defined? pool_controller) and !(pool_controller.nil?) %> > +<% if (hwpool.nil? or > + ((hwpool.is_a? HardwarePool) and (hwpool.storage_pools.size > storage_per_page)) or > + ((hwpool.is_a? SmartPool) and (hwpool.tagged_storage_pools.size > storage_per_page))) > + usepager = 'true' > + else > + usepager = 'false' > + end %> > >
                >
                > @@ -9,7 +17,10 @@ > $("#<%= table_id %>").flexigrid > ( > { > - url: '<%= url_for :controller => "hardware", :action => "storage_pools_json", :id => (hwpool.nil? ? nil : hwpool.id), :exclude_pool => exclude_pool %>', > + url: '<%= url_for :controller => pool_controller, > + :action => "storage_pools_json", > + :id => (hwpool.nil? ? nil : hwpool.id), > + :exclude_pool => exclude_pool %>', > dataType: 'json', > <% if is_popup %> > width: 700, > @@ -23,8 +34,8 @@ > ], > sortname: "ip_addr", > sortorder: "asc", > - usepager: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, > - useRp: <%= (hwpool.nil? or hwpool.storage_pools.size > storage_per_page) ? 'true' : 'false' %>, > + usepager: <%= usepager %>, > + useRp: <%= usepager %>, > rp: <%= storage_per_page %>, > showTableToggleBtn: true, > onSelect: <%= on_select %> > diff --git a/src/app/views/storage/add_to_smart_pool.rhtml b/src/app/views/storage/add_to_smart_pool.rhtml > new file mode 100644 > index 0000000..2eedae3 > --- /dev/null > +++ b/src/app/views/storage/add_to_smart_pool.rhtml > @@ -0,0 +1,22 @@ > +<%- content_for :title do -%> > + <%= _("Add Storage Pool to Smart Pool") %> > +<%- end -%> > +<%- content_for :description do -%> > + Select storage pools from the list below to add to the <%= @pool.name %> smart pool. > +<%- end -%> > +
                > +
                > +
                > + <%= render :partial => "/storage/grid", :locals => { :table_id => "add_smart_storage_grid", > + :hwpool => nil, > + :pool_controller => "smart_pools", > + :exclude_pool => @pool.id, > + :on_select => false, > + :is_popup => true} %> > +
                > + > +<%= popup_footer("add_storage_to_smart_pool('#{url_for :controller => "smart_pools", > + :action => "add_storage", > + :id => @pool}')", > + "Add Storage Pools") %> > +
                > diff --git a/src/app/views/user/_show.rhtml b/src/app/views/user/_show.rhtml > index 916afe8..5b3ffb7 100644 > --- a/src/app/views/user/_show.rhtml > +++ b/src/app/views/user/_show.rhtml > @@ -12,7 +12,7 @@ > } > function delete_users() > { > - permissions = get_selected_users(); > + var permissions = get_selected_users(); > if (validate_selected(permissions, "user")) { > $.post('<%= url_for :controller => "permission", :action => "delete", :id => pool.id %>', > { permission_ids: permissions.toString() }, > @@ -26,7 +26,7 @@ > } > function update_users(role) > { > - permissions = get_selected_users() > + var permissions = get_selected_users(); > if (validate_selected(permissions, "users")) { > $.post('<%= url_for :controller => "permission", :action => "update_roles" %>', > { permission_ids: permissions.toString(), user_role: role }, > diff --git a/src/app/views/vm/_grid.rhtml b/src/app/views/vm/_grid.rhtml > index c56e6b8..a322ea3 100644 > --- a/src/app/views/vm/_grid.rhtml > +++ b/src/app/views/vm/_grid.rhtml > @@ -1,42 +1,56 @@ > <%= render :partial => 'graph/load_graph.rhtml' %> > -<% vms_per_page = 10 %> > +<% pool_controller = 'resources' unless (defined? pool_controller) and !(pool_controller.nil?) %> > +<% vms_per_page = 40 unless (defined? vms_per_page) and !(vms_per_page.nil?) %> > +<% if (pool.nil? or > + ((pool.is_a? VmResourcePool) and (pool.vms.size > vms_per_page)) or > + ((pool.is_a? SmartPool) and (pool.tagged_vms.size > vms_per_page))) > + usepager = 'true' > + else > + usepager = 'false' > + end %> >
                > > > >
                >