Ramu, You’re confusing things.
dcae_keystone_url is the keystone of the openstack where you will deploy DCAE dnsaas_keystone_url is the keystone of the openstack providing DNS Designate support When creating a VM using a proxied DNS Designate, the dcae_keystone_url _must_ leverage the multicloud-titanium cloud driver, e.g. in your case dcae_keystone_url = http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0 <http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0>. This is because cloudify will create the resources for the VM to be created using the dcae_keystone_url. Among other things, this will create the record in the DNS zone. This is possible because the multicloud-titanium leverage AAI ESR information to know that for a particular cloud-site (identified by the dcae_keystone_url) it should be using another site that provides Designate support (dns-delegate) See cloud-extra-info, e.g. { "epa-caps": { "huge_page": "true", "cpu_pinning": "true", "cpu_thread_policy": "true", "numa_aware": "true", "sriov": "true", "dpdk_vswitch": "true", "rdt": "false", "numa_locality_pci": "true" }, "dns-delegate": { "cloud-owner": "pod25dns", "cloud-region-id": "RegionOne" } } Alexis > On Jan 30, 2018, at 2:07 PM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) > <ramanjaneyul_reddy.ak...@nokia.com> wrote: > > Hi Alexis, > Thanks for the response. > > I’m using below params in my env file while creating the heat stack. > > =================== > dnsaas_config_enabled: true > dnsaas_region: regionOne > dnsaas_keystone_url: http://<designate ip>/identity > dnsaas_tenant_name: admin > dnsaas_username: admin > dnsaas_password: password > dcae_keystone_url: http://<designate ip>:5000 > =================== > > To try it out, I changed the dnsaas_keystone_url.txt file on bootstrap and > tried to kick start the vm init script. > > Changed file content ============ > > root@dcae-dcae-bootstrap:~# cat /opt/config/dnsaas_keystone_url.txt > http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0 > root@dcae-dcae-bootstrap:~# > ============ > > I’m getting the same error as earlier. > > By the way with/without this change, on the designate instance I see the dns > zone getting created + recordset is being added. It means I believe it’s able > to talk to Designate successfully. > > ubuntu@designate:~/devstack$ openstack recordset list > 122ffabf-0268-41b1-a3d7-fed5ca4e2366 > +--------------------------------------+---------------------+------+------------------------------------------------------------------------+--------+--------+ > | id | name | type | records > | status | > action | > +--------------------------------------+---------------------+------+------------------------------------------------------------------------+--------+--------+ > | 14b0c34e-c88e-4ead-81b0-fe7f1c8d6679 | wJOo.dcae.onap.org. | NS | > ns1.devstack.org. | > ACTIVE | NONE | > | f95281a1-f97c-4beb-a7cc-77bbbb7d860c | wJOo.dcae.onap.org. | SOA | > ns1.devstack.org. lji.research.att.com. 1517329561 3565 600 86400 3600 | > ACTIVE | NONE | > +--------------------------------------+---------------------+------+------------------------------------------------------------------------+--------+--------+ > > > best regards, > Ramu > > > From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] > Sent: Tuesday, January 30, 2018 10:47 AM > To: Akula, Ramanjaneyul Reddy (Nokia - US/Irving) > <ramanjaneyul_reddy.ak...@nokia.com> > Cc: Yang, Bin <bin.y...@windriver.com>; onap-discuss > <onap-discuss@lists.onap.org>; Bisht, Suraj (Nokia - US/Irving) > <suraj.bi...@nokia.com>; Talari Nehemiah Vara, Vara (Nokia - US/Irving) > <vara.talari_nehemiah_v...@nokia.com> > Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with > Multicloud Titanium > > Ramu, > > What did you use for DCAE_PROXIED_KEYSTONE_URL parameter? It must be the > proxied url. See > https://github.com/onap/oom/blob/amsterdam/kubernetes/config/onap-parameters-sample.yaml#L143-L144 > > Hope this helps, > Alexis > > > On Jan 30, 2018, at 11:27 AM, Akula, Ramanjaneyul Reddy (Nokia - US/Irving) > <ramanjaneyul_reddy.ak...@nokia.com> wrote: > > Hi Alex/Bin, > I’m also witnessing the same problem in my cloud. > My cloud is built using RedHat OSP10 (Newton). > > Bottstrap log has below info. > > 2018-01-30 16:00:51 CFY <local> [security_group_38d63] Configuring node > 2018-01-30 16:00:51 CFY <local> [private_net_85fe3] Configuring node > 2018-01-30 16:00:51 CFY <local> [key_pair_31e7f] Configuring node > 2018-01-30 16:00:51 CFY <local> [floatingip_vm00_474ed] Configuring node > 2018-01-30 16:00:51 CFY <local> [key_pair_31e7f] Starting node > 2018-01-30 16:00:51 CFY <local> [private_net_85fe3] Starting node > 2018-01-30 16:00:51 CFY <local> [security_group_38d63] Starting node > 2018-01-30 16:00:51 CFY <local> [floatingip_vm00_474ed] Starting node > 2018-01-30 16:00:52 CFY <local> [fixedip_vm00_b112a] Creating node > 2018-01-30 16:00:52 CFY <local> [dns_cm_3211b] Creating node > 2018-01-30 16:00:52 CFY <local> [dns_vm00_3cba2] Creating node > 2018-01-30 16:00:52 CFY <local> [dns_cm_3211b.create] Sending task > 'dnsdesig.dns_plugin.aneeded' > 2018-01-30 16:00:52 CFY <local> [dns_vm00_3cba2.create] Sending task > 'dnsdesig.dns_plugin.aneeded' > 2018-01-30 16:00:52 CFY <local> [fixedip_vm00_b112a.create] Sending task > 'neutron_plugin.port.create' > 2018-01-30 16:00:52 CFY <local> [dns_cm_3211b.create] Task started > 'dnsdesig.dns_plugin.aneeded' > 2018-01-30 16:00:52 CFY <local> [dns_vm00_3cba2.create] Task started > 'dnsdesig.dns_plugin.aneeded' > 2018-01-30 16:00:52 CFY <local> [dns_cm_3211b.create] Task failed > 'dnsdesig.dns_plugin.aneeded' -> 'dns' > 2018-01-30 16:00:52 CFY <local> 'install' workflow execution failed: Workflow > failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns' > > My AAI is already populated with both the pods info as shown below > > =================== > { > "cloud-region": [ > { > "cloud-owner": "pod25", > "cloud-region-id": "regionOne", > "cloud-type": "openstack", > "owner-defined-type": "owner-defined-type", > "cloud-region-version": "titanium_cloud", > "identity-url": > "http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25_regionOne/identity/v2.0";, > "cloud-zone": "cloud zone", > "complex-name": "complex name", > "resource-version": "1517257340971" > }, > { > "cloud-owner": "pod25dns", > "cloud-region-id": "regionOne", > "cloud-type": "openstack", > "owner-defined-type": "owner-defined-type", > "cloud-region-version": "titanium_cloud", > "identity-url": > "http://10.0.14.1/api/multicloud-titanium_cloud/v0/pod25dns_regionOne/identity/v2.0";, > "cloud-zone": "cloud zone", > "complex-name": "complex name2", > "resource-version": "1517257341850" > } > ] > } > =================== > > > And on designate I see the new zone getting created. > > Appreciate any hints/clues on how to overcome this problem. > > > > best regards, > Ramu > > > From: onap-discuss-boun...@lists.onap.org > [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët > Sent: Friday, January 19, 2018 1:08 PM > To: Yang, Bin <bin.y...@windriver.com> > Cc: onap-discuss <onap-discuss@lists.onap.org> > Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with > Multicloud Titanium > > Ah, I missed the fact that when it’s proxied, dcae_keystone_url needs to be > the one from multivim. All good now. > > Alexis > > > > > On Jan 19, 2018, at 11:05 AM, Alexis de Talhouët <adetalhoue...@gmail.com> > wrote: > > Hum, actually, the DNS zone registration works. But now, the boot container > is failing with the following: > > 2018-01-19 15:52:53 CFY <local> [dns_cm_4834b.create] Sending task > 'dnsdesig.dns_plugin.aneeded' > 2018-01-19 15:52:53 CFY <local> [dns_vm00_73f5a.create] Sending task > 'dnsdesig.dns_plugin.aneeded' > 2018-01-19 15:52:53 CFY <local> [fixedip_vm00_91a2f] Creating node > 2018-01-19 15:52:53 CFY <local> [dns_cm_4834b.create] Task started > 'dnsdesig.dns_plugin.aneeded' > 2018-01-19 15:52:53 CFY <local> [dns_vm00_73f5a.create] Task started > 'dnsdesig.dns_plugin.aneeded' > 2018-01-19 15:52:53 CFY <local> [dns_cm_4834b.create] Task failed > 'dnsdesig.dns_plugin.aneeded' -> 'dns' > 2018-01-19 15:52:53 CFY <local> 'install' workflow execution failed: Workflow > failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns' > Workflow failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> ‘dns' > > Of course, the OpenStack on which I deploy DCAE doesn’t support DNS > Designate, I’m wondering what I could have missed? > > Alexis > > > > On Jan 19, 2018, at 10:46 AM, Alexis de Talhouët <adetalhoue...@gmail.com> > wrote: > > Bin, > > Awesome, I got it to work with my OpenStack Pike instance. > > One issue though, the register_multicloud_pod25dns_with_aai() is using > hardcoded username/password > https://gerrit.onap.org/r/gitweb?p=demo.git;a=blob;f=boot/dcae2_vm_init.sh;h=b071dffd53f0a431bbdff1c1228edce8ecddef2d;hb=refs/heads/amsterdam > > I opened DCAEGEN2-270 and submitted the fix > https://gerrit.onap.org/r/#/c/28673/ > > Current workaround is to push the data in AAI prior to having the script > running. So the put request will fail, but the validation will pass. > > Alexis > > > > On Jan 19, 2018, at 12:10 AM, Yang, Bin <bin.y...@windriver.com> wrote: > > Hi Alexis, > > Please refer to answers embedded below > > Best Regards, > Bin Yang, Solution Readiness Team, Wind River > Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189 > Skype: yangbincs993 > > -----Original Message----- > From: Alexis de Talhouët [mailto:adetalhoue...@gmail.com] > Sent: Friday, January 19, 2018 10:30 AM > To: Yang, Bin > Cc: onap-discuss > Subject: Re: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with > Multicloud Titanium > > Hi Bin, > > So if I understand correctly, I should register the VIM in multi cloud (do > you have an example or a link on how to ) and DCAE will be able to use it to > proxy DNS request (DNSaaS) to this instance. I was under the impression it > was hard coded to pod25 in the DCAE boostrap script, I’ll look again. > > > [Bin] Yes, pod25 was hard coded in DCAE bootstrap script, but it is just the > cloud owner name, most related information that DCAE bootstrap uses to > register a VIM instance are passed by HEAT template ( I believe OOM could > support that parameter injection , correct?) > > I’m glad this is already there then, I guess I got confused while reading the > script. I’ll try this tomorrow. > [Bin] I think it is the hardcoded 'titanium_cloud' in that script to confuse > you. This could be changed to be a parameter passing by HEAT/OOM. But right > now MultiCloud plugin for titanium_cloud support vanilla OpenStack version > like ocata, mitaka, newton as well. I didn't try the pike, but there is big > chance that pike can be supported without any modification. > > So you confirm I can already use the proxy setup provided by DCAE to use a > proxy for DNS Desginate other than the OpenLab one? > > I have OpenStack Pike, would that work? > [Bin] I didn't test with pike yet, you can give it a try . > > > OOM does already provide the support for this in Amsterdam. I guess what I > was looking for is a proxy setup using plain OpenStack APIs. and not using > Multicloud. But I’m all in for using Multicloud if available and working > already. > > [Bin]: I do think it will be valuable that OOM provide such kind of support > and I can share what I learned and hope you get more comprehensive > understanding of the requirement/solutions. > > Thanks, > Alexis > > > > On Jan 18, 2018, at 8:58 PM, Yang, Bin <bin.y...@windriver.com> wrote: > > Hi Alexis, > > I think it would be better to clarify that: proxy the DNS Designate > requests is the enhanced feature by MultiCloud to federate services from > different underlying VIM instances. In ONAP Amsterdam release it has been > implemented to support both vanilla OpenStack Ocata (and Newton as well, not > tested yet) and Titanium Cloud, and more to come in future releases. I had > tested with vanilla OpenStack Ocata and it works well. > > To utilize it , the consumer presuppose that the MultiCloud services are > ready and the VIM instances are registered. So for DCAEgen2 which has been > the actually consumer in ONAP Amsterdam release, the bootstrap VM did this > part , the VIM instance information (both underlying OpenStack and the > proxied one which exposes Designate services) are passed in by HEAT > template/environment file. I believe OOM can support this in similar way. > > This federation can be designed/implemented in various way but why it was > designed/implemented is that MultiCloud do the federation and the consumers > will be transparent with regards who provides DNSaaS services. > > BTW, I do think it will be valuable that OOM can offer the similar proxy > to DNS designate, I would like to share our experiences. > > Best Regards, > Bin Yang, Solution Readiness Team, Wind River > Direct +86,10,84777126 Mobile +86,13811391682 Fax +86,10,64398189 > Skype: yangbincs993 > > -----Original Message----- > From: onap-discuss-boun...@lists.onap.org > [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Alexis de Talhouët > Sent: Friday, January 19, 2018 6:34 AM > To: onap-discuss > Subject: [onap-discuss] [DCAGEN2] Proxied DNS Designate only with Multicloud > Titanium > > Hi experts, > > In the dcae_vm_init.sh script, we have the possibility to proxy the DNS > Designate requests to an OpenStack other than the one on which we spawn DCAE. > But this feature only allow to proxy to Multicloud Titanium cloud, it doesn’t > allow to proxy to an other plain OpenStack instance. > I was wondering whether a contribution to address this is Amsterdam would be > accepted, if yes, I can do it. > > Basically, I’d like to leverage the dnaas_* config bits to establish a > connection to an OpenStack directly, instead of using Multi-cloud. > I would have a add a param to let the user choose whether the use Multicloud > Titanium or plain OpenStack. > > Please, let me know what you think of this? > > FYI, I tend to think we should be able to have DNS Designate running where > ever we want in the infra, as long as it’s provided. Moreover, we’re working > on providing it in OOM, so it’s not required in ppl infra. > > Thanks, > Alexis > > > _______________________________________________ > onap-discuss mailing list > onap-discuss@lists.onap.org > https://lists.onap.org/mailman/listinfo/onap-discuss
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
