I agree, that's generally the model, right? The network offering describes where the services come from.
On Fri, Mar 20, 2015 at 12:16 PM, Alena Prokharchyk <alena1...@gmail.com> wrote: > From the FS: > > "Create empty network offering with no service selected. Only DHCP, DNS > services are provided by external servers. > Metadata - information is included in the config drive > Userdata, vm password, ssh key - If these are passed then included in > the config drive with user data service." > "Retrieving IP assigned by external DHCP server to userVM. Store it in CS > DB." > > > Why not just introduce the notion of the external provider for the > DHCP/DNS/UserData service? Not specifying the services on the offering and > implementing the service and storing the service data - UserData/MetaData > and IP - in the CloudStack DB, is confusing. Unless all the > metadata/userdata is stored/managed on/by the external provider side. > > On Fri, Mar 20, 2015 at 6:20 AM, Adrian Lewis <adr...@alsiconsulting.co.uk> > wrote: > >> Can't see the wiki at the moment as it's down for maintenance but on a >> slightly different but related note, would it be feasible to use DHCP relay >> functionality in dnsmasq on a VR and still get the IP address assigned by >> an >> external DHCP server registered into the ACS MS? Not quite sure if under >> normal circumstances ACS picks up the IP from dnsmasq or if ACS manages the >> pool and sends dnsmasq static leases. If it's picking up what dnsmasq >> decides to lease out, what is this mechanism and does/would it also work >> for >> DHCP relay? >> >> This doesn’t solve the issue of a DHCP server on the same network however >> and would still require a VR on the network with upstream connectivity to >> the DHCP server. >> >> I'm definitely definitely up for the concept of simple networks with no VR >> if we can provision some of the essentials without one. Big +1 >> >> >> -----Original Message----- >> From: Nux! [mailto:n...@li.nux.ro] >> Sent: 20 March 2015 09:34 >> To: dev@cloudstack.apache.org >> Subject: Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv >> zone shared network >> >> +1, good idea >> >> One thing though: let's make the config drive available for all types of >> zones, many people use the basic or adsg zones. >> >> Lucian >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> ----- Original Message ----- >> > From: "Jayapal Reddy Uradi" <jayapalreddy.ur...@citrix.com> >> > To: dev@cloudstack.apache.org >> > Sent: Friday, 20 March, 2015 09:12:19 >> > Subject: [PROPOSAL] DHCP/DNS offload and config drive support for adv >> > zone shared network >> >> > In advanced zone shared network if someone wants to use DHCP server >> > outside the cloudstack, currently it can be done by not selecting the >> > DHCP service But the problem here is that the VM actual ip is >> > different from what cloudstack showing. >> > >> > If there are no services selected for the network offering there is no >> > need of the VR. >> > In the absense of VR there should be way to provide password, >> > userdata/metadata, ssh keys to user vm. >> > >> > With this feature we can do the following. >> > 1. Create network without VR. >> > 2. Retrive the IP from the VM and update it in the cloudstack DB. >> > 3. Add config drive support for the VMs in this network. >> > >> > Please provide your comments for the below FS. >> > >> > ACS ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-8324 >> > FS: >> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=53740 >> > 797 >> > >> > >> > Thanks, >> > Jayapal >> > > > > -- > Alena Prokharchyk > https://twitter.com/Lemonjet > http://www.linkedin.com/pub/alena-prokharchyk/13/282/a7b
