Feature changed by: J. Daniel Schmidt (jdsn) Feature #311066, revision 2 Title: Autoconfiguration of Eucalyptus Cloud Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) + Developer: (Novell) + Developer: bernd wiedemann (bwiedemann) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. -- openSUSE Feature: https://features.opensuse.org/311066

Feature changed by: J. Daniel Schmidt (jdsn) Feature #311066, revision 4 Title: Autoconfiguration of Eucalyptus Cloud Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) Developer: (Novell) Developer: (Novell) + Developer: (Novell) Developer: bernd wiedemann (bwiedemann) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. -- openSUSE Feature: https://features.opensuse.org/311066

Feature changed by: Bernhard Wiedemann (bmwiedemann) Feature #311066, revision 13 Title: Autoconfiguration of Eucalyptus Cloud Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) Developer: (Novell) Developer: (Novell) Developer: (Novell) Developer: (Novell) + Developer: (Novell) + Developer: (Novell) Developer: bernd wiedemann (bwiedemann) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. -- openSUSE Feature: https://features.opensuse.org/311066

Feature changed by: Robert Schweikert (rjschwei) Feature #311066, revision 15 Title: Autoconfiguration of Eucalyptus Cloud Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) Developer: (Novell) Developer: (Novell) Developer: (Novell) Developer: (Novell) Developer: (Novell) Developer: (Novell) Developer: (Novell) Developer: bernd wiedemann (bwiedemann) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. + Discussion: + #1: Robert Schweikert (rjschwei) (2011-01-19 15:06:08) + Work for automation is underway. + * Jiri Suchomel is working on a YaST module, I am testing and reporting + back to Jiri. + * I have a couple of python scripts that take care of auto registration + of Cloud nodes (not yet in the Virtualization:Cloud project) + Problems with automation: + * The biggest current problem is that Eucalyptus does not get along + with openSSL 1.0 (or openSSL 0.9.8h as found in SLES). This causes the + command line tools for registration of nodes etc. to fail. Registration + of nodes etc. currently only works through the browser, which + unfortunately makes this a manual process. I am working with the + Eucalyptus folks to address the issue regarding openSSL 1.0 + * A second issue is the use of DHCP. Although I figured out how to add + an identification feature to the dhcp server running on the head node, + I have not figured out how to enforce that the client, i.e. cloud node, + only accepts an offer from the head node. This is a problem that needs + resolution, thus if a DHCP expert can explain how this works as part of + this hackweek project big progress would be made. + Robert -- openSUSE Feature: https://features.opensuse.org/311066

Feature changed by: Bernhard Wiedemann (bmwiedemann) Feature #311066, revision 17 Title: Autoconfiguration of Eucalyptus Cloud Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) Developer: (Novell) Developer: (Novell) Developer: (Novell) - Developer: (Novell) - Developer: (Novell) - Developer: (Novell) - Developer: (Novell) - Developer: (Novell) - Developer: bernd wiedemann (bwiedemann) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. Discussion: #1: Robert Schweikert (rjschwei) (2011-01-19 15:06:08) Work for automation is underway. * Jiri Suchomel is working on a YaST module, I am testing and reporting back to Jiri. * I have a couple of python scripts that take care of auto registration of Cloud nodes (not yet in the Virtualization:Cloud project) Problems with automation: * The biggest current problem is that Eucalyptus does not get along with openSSL 1.0 (or openSSL 0.9.8h as found in SLES). This causes the command line tools for registration of nodes etc. to fail. Registration of nodes etc. currently only works through the browser, which unfortunately makes this a manual process. I am working with the Eucalyptus folks to address the issue regarding openSSL 1.0 * A second issue is the use of DHCP. Although I figured out how to add an identification feature to the dhcp server running on the head node, I have not figured out how to enforce that the client, i.e. cloud node, only accepts an offer from the head node. This is a problem that needs resolution, thus if a DHCP expert can explain how this works as part of this hackweek project big progress would be made. Robert + #2: Bernhard Wiedemann (bmwiedemann) (2011-01-19 16:44:24) (reply to + #1) + It would be good to have this interoperable with Ubuntu eucalyptus nodes + and cloud-controllers, which IIRC use avahi mdns/zero-conf for mutual + autodetection. + This could even replace (some of) the DHCP magic. -- openSUSE Feature: https://features.opensuse.org/311066

Feature changed by: Robert Schweikert (rjschwei) Feature #311066, revision 19 Title: Autoconfiguration of Eucalyptus Cloud Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) Developer: (Novell) Developer: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. Discussion: #1: Robert Schweikert (rjschwei) (2011-01-19 15:06:08) Work for automation is underway. * Jiri Suchomel is working on a YaST module, I am testing and reporting back to Jiri. * I have a couple of python scripts that take care of auto registration of Cloud nodes (not yet in the Virtualization:Cloud project) Problems with automation: * The biggest current problem is that Eucalyptus does not get along with openSSL 1.0 (or openSSL 0.9.8h as found in SLES). This causes the command line tools for registration of nodes etc. to fail. Registration of nodes etc. currently only works through the browser, which unfortunately makes this a manual process. I am working with the Eucalyptus folks to address the issue regarding openSSL 1.0 * A second issue is the use of DHCP. Although I figured out how to add an identification feature to the dhcp server running on the head node, I have not figured out how to enforce that the client, i.e. cloud node, only accepts an offer from the head node. This is a problem that needs resolution, thus if a DHCP expert can explain how this works as part of this hackweek project big progress would be made. Robert #2: Bernhard Wiedemann (bmwiedemann) (2011-01-19 16:44:24) (reply to #1) It would be good to have this interoperable with Ubuntu eucalyptus nodes and cloud-controllers, which IIRC use avahi mdns/zero-conf for mutual autodetection. This could even replace (some of) the DHCP magic. + #4: Robert Schweikert (rjschwei) (2011-01-19 19:35:09) (reply to #2) + I am fine using a discovery method that already exists. I am not sure + how to find out what Ubuntu is using though. I can install the Ubuntu + Enterprise cloud on a couple of systems, but that will not necessarily + help. + As far as DHCP is concerned I still think that a cloude node should get + it's address only from the dhcp server that is running on the head + node. Also, a given cloud node always has to get the same IP address + once it is registered. At least for the latter part of this problem + there has to be a solution in the Ubuntu ENterprise cloud product. #3: J. Daniel Schmidt (jdsn) (2011-01-19 16:57:04) (reply to #1) Doing it via DHCP was just one idea. I was not aware of the fact that there are already better solutions in place like avahi. When using avahi it even does not matter what network type (system, static, managed) you use for the cloud. So we really should follow the most compatible way. We even win the interoperability with Ubuntu for free. So in one cloud we could have mixed nodes. We should not invest in a SUSE-only solution in this case. -- openSUSE Feature: https://features.opensuse.org/311066

Feature changed by: Robert Schweikert (rjschwei) Feature #311066, revision 21 Title: Autoconfiguration of Eucalyptus Cloud Hackweek VI: Unconfirmed Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) Developer: (Novell) Developer: (Novell) Developer: (Novell) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. Discussion: #1: Robert Schweikert (rjschwei) (2011-01-19 15:06:08) Work for automation is underway. * Jiri Suchomel is working on a YaST module, I am testing and reporting back to Jiri. * I have a couple of python scripts that take care of auto registration of Cloud nodes (not yet in the Virtualization:Cloud project) Problems with automation: * The biggest current problem is that Eucalyptus does not get along with openSSL 1.0 (or openSSL 0.9.8h as found in SLES). This causes the command line tools for registration of nodes etc. to fail. Registration of nodes etc. currently only works through the browser, which unfortunately makes this a manual process. I am working with the Eucalyptus folks to address the issue regarding openSSL 1.0 * A second issue is the use of DHCP. Although I figured out how to add an identification feature to the dhcp server running on the head node, I have not figured out how to enforce that the client, i.e. cloud node, only accepts an offer from the head node. This is a problem that needs resolution, thus if a DHCP expert can explain how this works as part of this hackweek project big progress would be made. Robert #2: Bernhard Wiedemann (bmwiedemann) (2011-01-19 16:44:24) (reply to #1) It would be good to have this interoperable with Ubuntu eucalyptus nodes and cloud-controllers, which IIRC use avahi mdns/zero-conf for mutual autodetection. This could even replace (some of) the DHCP magic. #4: Robert Schweikert (rjschwei) (2011-01-19 19:35:09) (reply to #2) I am fine using a discovery method that already exists. I am not sure how to find out what Ubuntu is using though. I can install the Ubuntu Enterprise cloud on a couple of systems, but that will not necessarily help. As far as DHCP is concerned I still think that a cloude node should get it's address only from the dhcp server that is running on the head node. Also, a given cloud node always has to get the same IP address once it is registered. At least for the latter part of this problem there has to be a solution in the Ubuntu ENterprise cloud product. #5: J. Daniel Schmidt (jdsn) (2011-01-20 15:07:23) (reply to #4)

As far as DHCP is concerned I still think that a cloude node should get it's address only from the dhcp server that is running on the head node. This depends on the network mode that is used. Maybe some admin wants to assign IP addresses via his own DHCP, then we should not force him to do it differently.

+ #6: Robert Schweikert (rjschwei) (2011-01-20 15:33:04) (reply to #5) + Yes, but now it is no longer "automagic". If we want to account for all + possible ways an admin would want to configure the network we'll end up + with the 1000 question and answer problem. This is no longer automated + nor is it easy. + My idea of an automated cloud install is to show one YaST dialog when + the head node image gets installed, that's it. For cloud node + installation no interaction is necessary. This can of course be disable + after the cloud node image is installed. #3: J. Daniel Schmidt (jdsn) (2011-01-19 16:57:04) (reply to #1) Doing it via DHCP was just one idea. I was not aware of the fact that there are already better solutions in place like avahi. When using avahi it even does not matter what network type (system, static, managed) you use for the cloud. So we really should follow the most compatible way. We even win the interoperability with Ubuntu for free. So in one cloud we could have mixed nodes. We should not invest in a SUSE-only solution in this case. -- openSUSE Feature: https://features.opensuse.org/311066

Feature changed by: J. Daniel Schmidt (jdsn) Feature #311066, revision 24 Title: Autoconfiguration of Eucalyptus Cloud - Hackweek VI: Unconfirmed + Hackweek VI: Rejected by J. Daniel Schmidt (jdsn) + reject reason: We didnt' work on it, despite some cleanup. Now + obsoleted due to openstack cloud product. Priority Requester: Neutral Requested by: J. Daniel Schmidt (jdsn) Partner organization: openSUSE.org Description: Since end of 2010 the packages for Eucalyptus Cloud have been improved in order to work out of the box on SUSE systems. Nevertheless it requires a lot of manual configuration work to setup an entire cloud. The goal of this hackweek project is to autoconfigure as much as possible (avahi/zeroconf) and maybe provide a simple configuration tool to prompt for the remaining information and set it up. If time permits we try to provide SUSE Studio images for all Eucalyptus controllers. Discussion: #1: Robert Schweikert (rjschwei) (2011-01-19 15:06:08) Work for automation is underway. * Jiri Suchomel is working on a YaST module, I am testing and reporting back to Jiri. * I have a couple of python scripts that take care of auto registration of Cloud nodes (not yet in the Virtualization:Cloud project) Problems with automation: * The biggest current problem is that Eucalyptus does not get along with openSSL 1.0 (or openSSL 0.9.8h as found in SLES). This causes the command line tools for registration of nodes etc. to fail. Registration of nodes etc. currently only works through the browser, which unfortunately makes this a manual process. I am working with the Eucalyptus folks to address the issue regarding openSSL 1.0 * A second issue is the use of DHCP. Although I figured out how to add an identification feature to the dhcp server running on the head node, I have not figured out how to enforce that the client, i.e. cloud node, only accepts an offer from the head node. This is a problem that needs resolution, thus if a DHCP expert can explain how this works as part of this hackweek project big progress would be made. Robert #2: Bernhard Wiedemann (bmwiedemann) (2011-01-19 16:44:24) (reply to #1) It would be good to have this interoperable with Ubuntu eucalyptus nodes and cloud-controllers, which IIRC use avahi mdns/zero-conf for mutual autodetection. This could even replace (some of) the DHCP magic. #4: Robert Schweikert (rjschwei) (2011-01-19 19:35:09) (reply to #2) I am fine using a discovery method that already exists. I am not sure how to find out what Ubuntu is using though. I can install the Ubuntu Enterprise cloud on a couple of systems, but that will not necessarily help. As far as DHCP is concerned I still think that a cloude node should get it's address only from the dhcp server that is running on the head node. Also, a given cloud node always has to get the same IP address once it is registered. At least for the latter part of this problem there has to be a solution in the Ubuntu ENterprise cloud product. #5: J. Daniel Schmidt (jdsn) (2011-01-20 15:07:23) (reply to #4)

As far as DHCP is concerned I still think that a cloude node should get it's address only from the dhcp server that is running on the head node. This depends on the network mode that is used. Maybe some admin wants to assign IP addresses via his own DHCP, then we should not force him to do it differently.

#6: Robert Schweikert (rjschwei) (2011-01-20 15:33:04) (reply to #5) Yes, but now it is no longer "automagic". If we want to account for all possible ways an admin would want to configure the network we'll end up with the 1000 question and answer problem. This is no longer automated nor is it easy. My idea of an automated cloud install is to show one YaST dialog when the head node image gets installed, that's it. For cloud node installation no interaction is necessary. This can of course be disable after the cloud node image is installed. #3: J. Daniel Schmidt (jdsn) (2011-01-19 16:57:04) (reply to #1) Doing it via DHCP was just one idea. I was not aware of the fact that there are already better solutions in place like avahi. When using avahi it even does not matter what network type (system, static, managed) you use for the cloud. So we really should follow the most compatible way. We even win the interoperability with Ubuntu for free. So in one cloud we could have mixed nodes. We should not invest in a SUSE-only solution in this case. #7: Robert Schweikert (rjschwei) (2011-01-22 14:50:08) FYI, I learned that the issues with the command line tools are related to the use of bouncycastl. The eucalyptus source tarball provides bcprov.jar and even the latest released version of bcprov does not play nice with openSSL 1.0. RH is tracking the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=663136 -- openSUSE Feature: https://features.opensuse.org/311066