Re: [onap-discuss] [ONA][AAF] AAF with Istio/linkerd

Fri, 08 Nov 2019 05:35:17 -0800 


On 08.11.2019 14:24, [email protected] wrote:
> Hi Krzysztof,
> My goal was to test without having a specific version of AAF.
> I agree your patch would work but I've would have preferred an "official" way 
> (i.e. without rebuilding docker). If it's the only solution, I'll do!

Yeah in general it should be possible to override the hostname with 
0.0.0.0 from helm chart but I haven't managed to get this working as my 
own value of HOSTNAME env is always overwritten with pod name.

As I wrote below, I thinking that there is a name conflict and AAF 
shouldn't use HOSTNAME env as their own property but rather use sth like 
AAF_HOSTNAME which by default is set to HOSTNAME. But this is just my 
guess for now. Let's wait for feedback from Jonathan.

> 
> Regards,
> 
> ---
> Sylvain Desbureaux
> 
> Le 08/11/2019 13:24, « Krzysztof Opasiak » <[email protected]> a écrit :
> 
>      Hi Sylvain and Jonathan,
>
>      On 07.11.2019 14:51, GATHMAN, JONATHAN C wrote:
>      > OK, so what I'm hearing is that Sylvain would like to put SOME AAF 
> components behind SideCars, not necessarily all.  It would be a good exercise 
> to determine in an ISTIO world what elements AAF would actually provide, as 
> there are clearly overlaps.
>      >
>      > Obviously, AAF was designed to secure all relevant components, and 
> obviously, did it without Sidecars, as it was developed a few years before 
> K8s or even Docker was popular.
>      >
>      > Therefore, my recommendation is to focus on non-security related ONAP 
> Components (SSO and the like).
>
>      I believe that what Sylvian is trying to do is a very good way. First
>      let's try to make sure that we are actually able to deploy whole ONAP
>      with istio and then try to switch the components one by one to utilize
>      more of service mesh features.
>
>      >
>      > Unfortunately, I can't spend a ton of time on this, as it's not a 
> Frankfurt deliverable.  But I appreciate being kept in the loop.
>
>      @Jonathan
>      Have you ever tried to override the hostname aaf param from OOM helm 
> charts?
>
>      I'm not a specialist in this especially that AAF uses some complicated
>      construction with config init container but for me it looks like we have
>      some name conflict. Basically the param name is "hostname" so if you try
>      to pass this to the container from helm chart it gets overwritten by the
>      hostname env variable that contains the pod name...
>
>
>      @Sylvain,
>      I did some more debugging ad it looks like if you apply the below patch
>      to AAF sources the locate service should listen on all interfaces:
>
>      diff --git
>      
> a/auth/auth-core/src/main/java/org/onap/aaf/auth/server/JettyServiceStarter.java
>      
> b/auth/auth-core/src/main/java/org/onap/aaf/auth/server/JettyServiceStarter.java
>      index 3f0d2ebb..43579a95 100644
>      ---
>      
> a/auth/auth-core/src/main/java/org/onap/aaf/auth/server/JettyServiceStarter.java
>      +++
>      
> b/auth/auth-core/src/main/java/org/onap/aaf/auth/server/JettyServiceStarter.java
>      @@ -157,7 +157,7 @@ public class JettyServiceStarter<ENV extends
>      RosettaEnv, TRANS extends Trans> ex
>                // Add loggers MBean to server (will be picked up by
>      MBeanContainer above)
>        //        server.addBean(Log.getLog());
>
>      -        conn.setHost(hostname);
>      +        conn.setHost("0.0.0.0");
>                conn.setPort(port);
>                conn.setIdleTimeout(IDLE_TIMEOUT);
>                server.addConnector(conn);
>
>      would be great if you could confirm that it solved the issue.
>
>      Best regards,
>      --
>      Krzysztof Opasiak
>      Samsung R&D Institute Poland
>      Samsung Electronics
>
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
> falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged 
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete 
> this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been 
> modified, changed or falsified.
> Thank you.
> 

-- 
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#19403): https://lists.onap.org/g/onap-discuss/message/19403
Mute This Topic: https://lists.onap.org/mt/45686190/21656
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-



























					Reply via email to