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<mailto: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

I opened DCAEGEN2-270<https://jira.onap.org/browse/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<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]
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] 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



_______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Reply via email to