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 >> <mailto: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 >> >> <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 <https://jira.onap.org/browse/DCAEGEN2-270> and >> submitted the fix https://gerrit.onap.org/r/#/c/28673/ >> <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 >>> <mailto: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 >>> <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 >>>> <mailto: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> >>>> [mailto: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 <mailto:onap-discuss@lists.onap.org> >>>> https://lists.onap.org/mailman/listinfo/onap-discuss >>>> <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
