Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
I guess having one of many options is not a bad thing, as long as we dont make it defacto. On 4/1/15 12:30 PM, Chiradeep Vittal wrote: Ilya, there is already a external service. I think this is proposing a solution where that external service is not desired. Several “NFV” - type solutions use config drive to configure themselves instead using a http-based service. CoreOS also uses config drive. That is, this is not a replacement, but an additional option. From: ilya mailto:ilya.mailing.li...@gmail.com>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" mailto:dev@cloudstack.apache.org>> Date: Friday, March 20, 2015 at 6:12 PM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" mailto:dev@cloudstack.apache.org>> Subject: Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network I think config drive is not the best design choice. You are relying on external ISO to deliver content private to VM. The ISO is stored in secondary or primary storage, if exposed - I get the private data of all the VMs. There maybe issues with storage migration and general vmotion if ISO is attached. If we are following this model because openstack has chosen this path - i think its just wasted effort and wrong. In my opinion, an external service is much better solution, i.e. AWS - not OpenStack. Also, how does this work "CS retrieves the ip from the VM and update in the DB nics table. "? On 3/20/15 4:56 PM, Marcus wrote: 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 mailto: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 mailto: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<mailto: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" mailto:jayapalreddy.ur...@citrix.com>> To: dev@cloudstack.apache.org<mailto: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/jir
Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
Ilya, there is already a external service. I think this is proposing a solution where that external service is not desired. Several “NFV” - type solutions use config drive to configure themselves instead using a http-based service. CoreOS also uses config drive. That is, this is not a replacement, but an additional option. From: ilya mailto:ilya.mailing.li...@gmail.com>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" mailto:dev@cloudstack.apache.org>> Date: Friday, March 20, 2015 at 6:12 PM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" mailto:dev@cloudstack.apache.org>> Subject: Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network I think config drive is not the best design choice. You are relying on external ISO to deliver content private to VM. The ISO is stored in secondary or primary storage, if exposed - I get the private data of all the VMs. There maybe issues with storage migration and general vmotion if ISO is attached. If we are following this model because openstack has chosen this path - i think its just wasted effort and wrong. In my opinion, an external service is much better solution, i.e. AWS - not OpenStack. Also, how does this work "CS retrieves the ip from the VM and update in the DB nics table. "? On 3/20/15 4:56 PM, Marcus wrote: 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 mailto: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 mailto: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<mailto: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" mailto:jayapalreddy.ur...@citrix.com>> To: dev@cloudstack.apache.org<mailto: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
Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
To start this feature we are going with only shared network. Once it is done for shared network, it can be generalised for all the networks and external providers can be added at this point. The external provider does not have any thing to implement. Thanks, Jayapal On 21-Mar-2015, at 12:46 AM, Alena Prokharchyk 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 > 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" >>> 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
Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
Hi Adrian, For DHCP relay we need the VR with another interface which is in different network. >From CS we need to configure the another network for this. I think supporting VR as DHCP relay agent can be taken as separate feature. If we want to deploy VMs with external DHCP without VR, this feature will help. Thanks, Jayapal On 21-Mar-2015, at 10:53 AM, Marcus wrote: > There are some native hypervisor options, like virtio-socket for KVM, > vmx file parameters for VMware. We already use something like this for > the system vm bootstrap on KVM, that's how system vms get their ips. > > On Fri, Mar 20, 2015 at 6:12 PM, ilya wrote: >> I think config drive is not the best design choice. >> >> You are relying on external ISO to deliver content private to VM. The ISO is >> stored in secondary or primary storage, if exposed - I get the private data >> of all the VMs. There maybe issues with storage migration and general >> vmotion if ISO is attached. >> >> If we are following this model because openstack has chosen this path - i >> think its just wasted effort and wrong. >> >> In my opinion, an external service is much better solution, i.e. AWS - not >> OpenStack. >> >> Also, how does this work "CS retrieves the ip from the VM and update in the >> DB nics table. "? >> >> >> >> On 3/20/15 4:56 PM, Marcus wrote: >>> >>> 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 >>> 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 >>>> >>>> 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. >>>>
Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
There are some native hypervisor options, like virtio-socket for KVM, vmx file parameters for VMware. We already use something like this for the system vm bootstrap on KVM, that's how system vms get their ips. On Fri, Mar 20, 2015 at 6:12 PM, ilya wrote: > I think config drive is not the best design choice. > > You are relying on external ISO to deliver content private to VM. The ISO is > stored in secondary or primary storage, if exposed - I get the private data > of all the VMs. There maybe issues with storage migration and general > vmotion if ISO is attached. > > If we are following this model because openstack has chosen this path - i > think its just wasted effort and wrong. > > In my opinion, an external service is much better solution, i.e. AWS - not > OpenStack. > > Also, how does this work "CS retrieves the ip from the VM and update in the > DB nics table. "? > > > > On 3/20/15 4:56 PM, Marcus wrote: >> >> 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 >> 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 >>> >>> 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" >>>>> 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 > >
Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
I think config drive is not the best design choice. You are relying on external ISO to deliver content private to VM. The ISO is stored in secondary or primary storage, if exposed - I get the private data of all the VMs. There maybe issues with storage migration and general vmotion if ISO is attached. If we are following this model because openstack has chosen this path - i think its just wasted effort and wrong. In my opinion, an external service is much better solution, i.e. AWS - not OpenStack. Also, how does this work "CS retrieves the ip from the VM and update in the DB nics table. "? On 3/20/15 4:56 PM, Marcus wrote: 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 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 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" 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
Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
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 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 > 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" >> > 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
Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
>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 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" > > 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
RE: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
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" > 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
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" > 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=53740797 > > > Thanks, > Jayapal
[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=53740797 Thanks, Jayapal
