cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: [PROPOSAL] DHCP/DNS offload and config drive support for adv zone shared network
Date Fri, 20 Mar 2015 23:56:52 GMT
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 <alena1108@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 <adrian@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:nux@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.uradi@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

Mime
View raw message