nice explanation Will, c&p to the wiki and docs, i'd say On Fri, Feb 17, 2017 at 6:06 PM, Will Stevens <williamstev...@gmail.com> wrote: > Yes. Exactly. The "patches" don't require a new system vm template to be > distributed, but changes to the "appliance" does require a new system vm > template. > > On Feb 17, 2017 12:04 PM, "David Mabry" <dma...@ena.com> wrote: > >> Awesome. Thanks for the quick answer. That totally makes sense. Package >> changes (installation, etc…) are done in the “appliance” section of code. >> Any “config” changes required beyond package installation are done in the >> “patches” section of code. >> >> Thanks, >> David Mabry >> >> On 2/17/17, 10:52 AM, "williamstev...@gmail.com on behalf of Will >> Stevens" <williamstev...@gmail.com on behalf of wstev...@cloudops.com> >> wrote: >> >> So the System VM is "built" from two sources. >> >> 1) >> https://github.com/apache/cloudstack/tree/master/tools/ >> appliance/definitions/systemvmtemplate >> This defines what is actually built and is distributed as the SystemVM >> Template. You MUST use it if you change the packages included in the >> SystemVM template or change the core components in any way. Changing >> anything here REQUIRES a new SystemVM template to be distributed for >> that >> change to be used. >> >> 2) https://github.com/apache/cloudstack/tree/master/ >> systemvm/patches/debian >> This defines the systemvm.iso which is loaded into the System VM >> template >> after the system vm is deployed. This basically defines configuration >> which can be changed without requiring a new System VM template. This >> section does not handle installation of packages and such, instead it >> handles System VM configuration and functionality. So if settings >> files >> need to be changed (for say something like VPN) or if the way we >> handle IP >> address changes, etc... That is all handled from here. The >> systemvm.iso >> is generated by the management server (i think) and is pushed to the >> system >> vm after the system vm boots and the configuration which cloudstack >> manages >> is handled through this code. >> >> Is that clear? Let me know if you have more questions. I have had to >> do a >> bunch of stuff in this recently for some of the networking issues we >> have >> had as well as the StrongSwan VPN implementation (which changed both >> places). >> >> Using StrongSwan as an example: >> I had to modify (1) in order to remove the OpenSwan package >> installation >> and add the StrongSwan package installation. >> >> I had to modify (2) in order to change the configuration of the VPN in >> order to handle things the way that StrongSwan needed things done. So >> the >> changes to things like the `ipsec` command are handled in (2) because >> those >> are configuration changes and not package changes. >> >> Is that clearer? >> >> *Will STEVENS* >> Lead Developer >> >> <https://goo.gl/NYZ8KK> >> >> On Fri, Feb 17, 2017 at 11:18 AM, David Mabry <dma...@ena.com> wrote: >> >> > Hello everyone, >> > >> > I’m looking at making some changes to the system vm, but I have >> found that >> > there looks like there are 2 different places in the code that >> “build” the >> > systemvm. There is there is https://github.com/apache/ >> cloudstack/tree/ >> > 13bfdd71e6fffff52d2f613a802b3d16c9b40af7/systemvm/patches/debian, >> which >> > looks like it might be the “old” way and there is >> > https://github.com/apache/cloudstack/tree/ >> 87ef8137534fa798101f65c6691fcf >> > 71513ac978/tools/appliance/definitions/systemvmtemplate, which >> looks like >> > it might be the “new” way. If I wanted to make changes to how the >> systemvm >> > is built which place should I modify? I assume that I should modify >> the >> > build scripts in the “new” location, but I thought I would ask here >> first >> > just to be sure. >> > >> > --Mabry >> > >> >> >>
-- Daan
